Re: Changeset Extraction v7.9.1
От | Andres Freund |
---|---|
Тема | Re: Changeset Extraction v7.9.1 |
Дата | |
Msg-id | 20140317132003.GE16438@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Changeset Extraction v7.9.1 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: