From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | feichanghong(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18241: PushTransaction may cause Standby to execute ItemIdMarkDead |
Date: | 2023-12-12 08:57:01 |
Message-ID: | ZXggXVwX6F6gWZDq@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Dec 12, 2023 at 01:49:00PM +0900, Kyotaro Horiguchi wrote:
> This appears to be a bug that has existed for a long time since commit
> efc16ea520 (in 2009). Your fix looks correct to me, but as for me, the
> comment is not particularly necessary, and it would be sufficient to
> insert the new line in the location according to the member order
> within TransactionStateData.
Oops. It's surprising that this has never been diagnosed but at the
same time I don't really see subtransactions being a common pattern in
a read-only workload for a standby, and it can easily cause MVCC
issues by removing tuples too eagerly and a standby may still need
them. An issue if that this could cause problems if you do catalog
scans, which may explain a few bugs I recall seeing over the years,
even if these did not directly mention the use of ssavepoints. I'd
need to double-check the archives. If going through a driver layer
like the ODBC driver that enforces savepoints for each query, that
would be bad.
Your fix sounds good to me (no need for a comment), I'll take care of
it after looking a bit more at the area.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-12-12 09:03:43 | Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends |
Previous Message | Richard Guo | 2023-12-12 06:41:13 | Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN |