Random bits of info

Running this on a Greenplum DB 4.2 system will show you where you have data skew > 10%. From the Greenplum admin guide gp_skew_idle_fractions: select * from gp_toolkit.gp_skew_idle_fractions where siffraction > 0.1; sifoid: objectid of the table sifnamespace: schema name sifrelname: table name siffraction: The percentage of the system that is idle during a table scan, which is an indicator of uneven data distribution or query processing skew. For example, a value of 0.1 indicates 10% skew, a value of 0.5 indicates 50% skew, and so on. Tables that have more than 10% skew should have their distribution policies evaluated.

Just ran into something I haven't seen before. I was attempting to upload information to an ftp site. I opened Finder, entered ftp://sitename, and a connection was made and a new finder window opened. Tried to rsync in a terminal over to the /Volume/sitename but was told it was read-only. Same result when dragging and dropping in Finder. Ran ftp sitename from a Terminal and it all worked. I was able to put files on the server. Guess I need to lookup up and figure out what in the heck Finder does different than command line ftp. UPDATE: Ok, after some searching I learned Finder mounts FTP as read-only. Don't know why but at least I now know.

I've got some queries that run for a long time. Sometimes longer than others. I wanted to see how long active queries have been running. Here's a view to consistently do that: CREATE VIEW public.view_activequeries AS ( SELECT age(query_start, backend_start) AS queryage,* FROM pg_stat_activity WHERE current_query NOT LIKE '%IDLE%' ORDER BY queryage DESC); Then you just run: select * from public.view_activequeries; You get a list of all active queries in descending order of how long they have been running, i.e. longest running queries listed first.

--->  All credit goes here  <--- In case that ever disappears: place in .bash_profile ####SSHagent settings#### SSH_ENV="$HOME/.ssh/environment" function start_agent {      echo "Initializing new SSH agent..."      /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"      echo succeeded      chmod 600 "${SSH_ENV}"      . "${SSH_ENV}" > /dev/null      /usr/bin/ssh-add; } # Source SSH settings, if applicable if [ -f "${SSH_ENV}" ]; then      . "${SSH_ENV}" > /dev/null      ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {          start_agent;      } else      start_agent; fi

I needed a quick way to send an email when a script was done. Did some digging around and converted another CGI script to a plain perl script and finally got the syntax correct.  #!/usr/bin/env perl my $sendmail = "/usr/sbin/sendmail -t"; my $reply_to = "Reply-to: replyto\@addresshere\n"; my $subject = "Subject: Some amazing subject\n"; my $send_to = "To: destination\@addresshere\n"; open (SENDMAIL, "|$sendmail") or die "Cannot open sendmail: $!\n"; print SENDMAIL $reply_to; print SENDMAIL $subject; print SENDMAIL $send_to; print SENDMAIL "Content-type: text/plain\n"; print SENDMAIL "Content here. You could also put the content in a variable above."; close(SENDMAIL);

Looks like account caching of AD accounts is dependent on the same Kerberos preauthentication issue I blogged about a couple of posts back. So unchecking the box "Do not require Kerberos preauthentication" on our user accounts resulted in network credentials being cached and network accounts able to log in even when the notification said network accounts were unavailable.

I've had the same ssh keys for years. I just rsync them to a new system when I get one. I always seem to end up with mucked up permissions moving them around and never seem to remember how the permissions were set. Here's my reminder. ~/.ssh 700 ~/.ssh/authorized_keys 600 ~/.ssh/config 644 ~/.ssh/id_dsa 600 ~/.ssh/id_dsa.pub 644 ~/.ssh/known_hosts 644