I had a discussion with a few people recently about a hack I wrote for
pg_receivexlog at some point, but never ended up submitting, and in
cleaning that up realized I had an open item on it.
The idea is to add a switch to pg_receivexlog (in this case, -a, but
that can always be bikeshedded ot coursE) that acts somewhat like
archive_command on the backend. The idea is to have pg_receivexlog
fire off an external command at the end of each segment - for example
a command to gzip the file, or to archive it off into a Magic Cloud
(TM) or something like that.
You can do this now with basically looping around waiting for files
without the .partial suffix, but that's kind of ugly.
My current hack just fires off this command using sytem(). That will
block the pg_receivexlog process, obviously. The question is, if we
want this, what kind of behaviour would we want here? One option is to
do just that, which should be safe enough for something like gzip but
might cause trouble if the external command blocks on network for
example. Another option would be to just fork() and run it in the
background, which could in theory lead to unlimited number of
processes if they all hang. Or of course we could have a background
process that queues them up - much like we do in the main backend,
which is definitely more complicated.
Thoughts on the best way to deal with that?
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
