Re: standby recovery fails (tablespace related) (tentative patch and discussion)
От | Thomas Munro |
---|---|
Тема | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Дата | |
Msg-id | CA+hUKGK43KrMXUWp++abNprvMikdF4xnYZO6wZTcoSGXKjfQXA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: standby recovery fails (tablespace related) (tentative patch and discussion) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: standby recovery fails (tablespace related) (tentative patch and discussion)
|
Список | pgsql-hackers |
On Fri, Jul 29, 2022 at 9:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Matthias van de Meent <boekewurm+postgres@gmail.com> writes: > > I'd like to bring to your attention that the test that was introduced > > with 9e4f914b seem to be flaky in FreeBSD 13 in the CFBot builds: it > > sometimes times out while waiting for the secondary to catch up. Or, > > at least I think it does, and I'm not too familiar with TAP failure > > outputs: it returns with error code 29 and logs that I'd expect when > > the timeout is reached. > > It's also failing in the buildfarm, eg > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2022-07-28%2020%3A57%3A50 > > Looks like only conchuela so far, reinforcing the idea that we're > only seeing it on FreeBSD. I'd tentatively bet on a timing problem > that requires some FreeBSD scheduling quirk to manifest; we've seen > such quirks before. Maybe it just needs a replication slot? I see: ERROR: requested WAL segment 000000010000000000000003 has already been removed
В списке pgsql-hackers по дате отправления: