Re: Changeset Extraction v7.9.1

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Changeset Extraction v7.9.1
Дата
Msg-id 20140318142344.GG13855@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Changeset Extraction v7.9.1  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Hi,

On 2014-03-17 14:16:38 +0100, Andres Freund wrote:
> On 2014-03-17 09:13:38 -0400, Robert Haas wrote:
> > On Mon, Mar 17, 2014 at 8:29 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > >> Perhaps there could be a switch for an fsync interval, or something
> > >> like that.  The default could be, say, to fsync every 10 seconds.  And
> > >> if you want to change it, then go ahead; 0 disables.  Writing to
> > >> standard output would be documented as unreliable.  Other ideas
> > >> welcome.
> > >
> > > Hm. That'll be a bit nasty. fsync() is async signal safe, but it's still
> > > forbidden to be called from a signal on windows IIRC. I guess we can
> > > couple it with the standby_message_timeout stuff.
> >
> > Eh... I don't see any need to involve signals.  I'd just check after
> > each write() whether enough time has passed, or something like that.
>
> What if no new writes are needed? Because e.g. there's either no write
> activity on the primary or all writes are in another database or
> somesuch?
> I think checking in sendFeedback() is the best bet...

So, I've tried to implement the things you asked for. Changes:
* reopen config files on SIGHUP to allow for rotating files
* use PQEexpBuffer instead of handrolling stuff
* fsync the output file if either --fsync-interval seconds passed, or
  the server asks for feedback.
* report back a correct flush position.
* updated documentation

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_archivecleanup bug
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Portability issues in shm_mq