| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Changeset Extraction v7.9.1 |
| Date: | 2014-03-17 12:58:15 |
| Message-ID: | 20140317125815.GC16438@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-03-17 08:00:22 -0400, Robert Haas wrote:
> On Mon, Mar 17, 2014 at 7:27 AM, Andres Freund <andres(at)2ndquadrant(dot)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?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-03-17 13:13:38 | Re: Changeset Extraction v7.9.1 |
| Previous Message | Andres Freund | 2014-03-17 12:29:24 | Re: Changeset Extraction v7.9.1 |