| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Konstantin Knizhnik <knizhnik(at)neon(dot)tech> |
| Subject: | Re: Visibility bug with prepared transaction with subtransactions on standby |
| Date: | 2024-12-16 08:00:00 |
| Message-ID: | 09e2a70a-a6c2-4b5c-aeae-040a7449c9f2@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Heikki,
27.06.2024 21:35, Heikki Linnakangas wrote:
> All I heard is crickets, so committed and backported to all supported versions.
>
Recently hornet made some noise too: [1], by failing on the test
modification added with e9c8747ee (in REL_13_STABLE):
# issuing query via background psql: SELECT count(*) FROM t_009_tbl_standby_mvcc
# pump_until: process terminated unexpectedly when searching for "(?^:background_psql: QUERY_SEPARATOR)" with stream: ""
query failed: psql:<stdin>:6: ERROR: relation "t_009_tbl_standby_mvcc" does not exist
It looks like t_009_tbl_standby_mvcc had not arrived to standby yet when
it was queried.
I can reproduce the same with TEMP_CONFIG containing:
recovery_min_apply_delay = '500ms'
All the other tests (I ran check-world) pass with this setting. So maybe
this test lacks waiting for standby synchronization.
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2024-12-13%2022%3A14%3A10
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-12-16 08:07:52 | Re: per backend I/O statistics |
| Previous Message | Peter Eisentraut | 2024-12-16 07:39:06 | Re: pure parsers and reentrant scanners |