Re: [PATCHES] Forcing current WAL file to be archived

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCHES] Forcing current WAL file to be archived
Дата
Msg-id 19673.1155132288@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Forcing current WAL file to be archived  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [PATCHES] Forcing current WAL file to be archived  (Simon Riggs <simon@2ndquadrant.com>)
Re: [PATCHES] Forcing current WAL file to be archived  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> Something Hannu wrote has just reminded me that
> pg_current_xlog_location() returns the current Insert pointer rather
> than the current Write pointer.
> That would not be useful for streaming xlog records would it?

Good point.

> Methinks it should be the Write pointer all of the time, since I can't
> think of a valid reason for wanting to know where the Insert pointer is
> *before* we've written to the xlog file. Having it be the Insert pointer
> could lead to some errors.

However the start/stop_backup functions return the Insert pointer.
I can see scripts getting confused if pg_current_xlog_location reports
something less than what they just got from pg_stop_backup.

Is there value in exposing both pointers?  (Maybe not, it'll just cause
confusion probably.)

Another option is to have pg_current_xlog_location force a write (but
not fsync) as far as the Insert pointer it's about to return.  This
would eliminate any issues about inconsistency between results, but
perhaps there's too much performance penalty.

I'm not necessarily against your suggestion, just trying to be sure
we've thought about all the options.

            regards, tom lane

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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: proposal for PL packages for 8.3.
Следующее
От: "korryd@enterprisedb.com"
Дата:
Сообщение: Re: 8.2 features status