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
|
Список | 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 по дате отправления: