On 2014-03-17 09:14:51 -0400, Robert Haas wrote: > On Mon, Mar 17, 2014 at 8:58 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2014-03-17 08:00:22 -0400, Robert Haas wrote: > >> On Mon, Mar 17, 2014 at 7:27 AM, Andres Freund <and...@2ndquadrant.com> > >> wrote: > >> >> - There doesn't seem to be any provision for this tool to ever switch > >> >> from one output file to the next. That seems like a practical need. > >> >> One idea would be to have it respond to SIGHUP by reopening the > >> >> originally-named output file. Another would be to switch, after so > >> >> many bytes, to filename.1, then filename.2, etc. > >> > > >> > Hm. So far I haven't had the need, but you're right, it would be > >> > useful. I don't like the .<n> notion, but SIGHUP would be fine with > >> > me. I'll add that. > >> > >> Cool. > > > > So, I've implemented this, but it won't work on windows afaics. There's > > no SIGHUP on windows, and the signal emulation code used in the backend > > is backend only... > > I'll be happy enough to declare this a known limitation for > > now. Arguments to the contrary, best complemented with a solution? > > Blarg. I don't really like that, but I admit I don't have a better > idea, unless it's to go back to the suffix idea, with something like > --file-size-limit=XXX to trigger the switch.
I think the SIGHUP support can be a useful independently from --file-size-limit, so adding it seems like a good idea anyway. I think anything more advanced than the SIGHUP stuff is for another day. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
