On 2014-03-17 09:14:51 -0400, Robert Haas wrote:
> On Mon, Mar 17, 2014 at 8:58 AM, Andres Freund <andres@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 <andres@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