Re: pg_stat_wal_receiver and flushedUpto/writtenUpto

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_stat_wal_receiver and flushedUpto/writtenUpto
Дата
Msg-id 20200516011547.GD212736@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_stat_wal_receiver and flushedUpto/writtenUpto  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: pg_stat_wal_receiver and flushedUpto/writtenUpto
Список pgsql-hackers
On Fri, May 15, 2020 at 07:34:46PM -0400, Alvaro Herrera wrote:
> IIRC the only reason to put the written LSN where it is is so that it's
> below the mutex, to indicate it's not protected by it.  Conceptually,
> the written LSN is "before" the flushed LSN, which is why I propose to
> put it ahead of it.

Sure.  My point was mainly that it is easier to compare if we are
missing any fields in the view and the order is respected.  But it
makes also sense to do things your way, so let's do that.

> Yeah, that seems good (I didn't verify the boilerplate in
> pg_stat_get_wal_receiver or pg_proc.dat).  I propose
>
> +       Last write-ahead log location already received and written to
> +       disk, but not flushed.  This should not be used for data
> +       integrity checks.

Thanks.  If there are no objections, I'll revisit that tomorrow and
apply it with those changes, just in time for beta1.
--
Michael

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Potentially misleading name of libpq pass phrase hook
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: Potentially misleading name of libpq pass phrase hook