Re: Visibility bug with prepared transaction with subtransactions on standby - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: Visibility bug with prepared transaction with subtransactions on standby
Date
Msg-id 09e2a70a-a6c2-4b5c-aeae-040a7449c9f2@gmail.com
Whole thread Raw
In response to Re: Visibility bug with prepared transaction with subtransactions on standby  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Visibility bug with prepared transaction with subtransactions on standby
List 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



pgsql-hackers by date:

Previous
From: "Andreas 'ads' Scherbaum"
Date:
Subject: Re: Crash: invalid DSA memory alloc request
Next
From: Heikki Linnakangas
Date:
Subject: Re: pure parsers and reentrant scanners