Re: [BUG] non archived WAL removed during production crash recovery

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: [BUG] non archived WAL removed during production crash recovery
Дата
Msg-id 20200423.140546.1055476118690602079.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: [BUG] non archived WAL removed during production crash recovery  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: [BUG] non archived WAL removed during production crash recovery  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Список pgsql-bugs
FWIW, the test for 10- looks fine, but I have one qustion.

+     'archive success reported in pg_stat_archiver for WAL segment $segment_name_

This seems intending to show an actual segment name in the message,
but it is really shown as "... WAL segment $segment_name_1". Is that
intended?

At Thu, 23 Apr 2020 08:46:18 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Wed, Apr 22, 2020 at 06:17:17PM +0200, Jehan-Guillaume de Rorthais wrote:
> > I found an extra useless line of code in v9 patch. Please, find in
> > attachment v10. Sorry for this.
> 
> Thanks for helping here, your changes make sense.  This looks mostly
> fine to me except that part:
> +$standby1->poll_query_until('postgres',
> +   qq{ SELECT pg_xlog_location_diff('$primary_lsn', pg_last_xlog_replay_location()) = 0 })
> +  or die "Timed out while waiting for xlog replay";
> Here we should check if $primary_lsn is at least
> pg_last_xlog_replay_location().  Checking for an equality may stuck
> the test if more WAL gets replayed.  For example you could have a
> concurrent autovacuum generating WAL.

Autovacuum is turned off in this case, but anyway other kinds of WAL
records can be generated.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Backend stuck in tirigger.c:afterTriggerInvokeEvents forever
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16385: Postgres YUM repo broke