Re: Add a perl function in Cluster.pm to generate WAL
От | Tom Lane |
---|---|
Тема | Re: Add a perl function in Cluster.pm to generate WAL |
Дата | |
Msg-id | 370894.1704325169@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add a perl function in Cluster.pm to generate WAL (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Add a perl function in Cluster.pm to generate WAL
Re: Add a perl function in Cluster.pm to generate WAL |
Список | pgsql-hackers |
Michael Paquier <michael@paquier.xyz> writes: > I have added a comment about pg_logical_emit_message() being in > non-transactional mode and the flush implied by pg_switch_wal() as > that's important, edited a bit the whole, then applied the patch. Buildfarm member skink has failed 3 times in 035_standby_logical_decoding.pl in the last couple of days: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-01-03%2020%3A07%3A15 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-01-03%2017%3A09%3A27 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-01-01%2020%3A10%3A18 These all look like # poll_query_until timed out executing this query: # select (confl_active_logicalslot = 1) from pg_stat_database_conflicts where datname = 'testdb' # expecting this output: # t # last actual query output: # f although it's notable that two different tests are involved (vacuum vs. vacuum full). I am not real sure what is happening there, but I see that c161ab74f changed some details of how that test works, so I wonder if it's responsible for these failures. The timing isn't a perfect match, since this commit went in two weeks ago, but I don't see any more-recent commits that seem like plausible explanations. regards, tom lane
В списке pgsql-hackers по дате отправления: