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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
