Hi hackers,
I was wondering whether there are any updates on the bug in visibility check
introduced in version 14.5.
Many thanks,
Dimos
[ServiceNow]
## Dimos Stamatakis (dimos.stamata...@servicenow.com):
> In our scenario we changed the permissions of this function in PG14.5
> (via an automated tool) and then pg_upgrade tries to change the
> permissions in PG15.1 as well.
Given that this function wasn't even documented and d
Hi hackers,
I attempted to perform an upgrade from PG-14.5 to PG-15.1 with pg_upgrade and
unfortunately it errors out because of a function that does not exist anymore
in PG-15.1.
The function is ‘pg_catalog.close_lb’ and it exists in 14.5 but not in 15.1.
In our scenario we changed the permissi
[External Email]
On 2022-Nov-25, Dimos Stamatakis wrote:
> So does this mean there is no race condition in this case and that
> this error is redundant?
No, it means I believe a bug exists but that I haven't spent enough time
on it to understand what it is.
Great! Please keep me
So does this mean there is no race condition in this case and that this error
is redundant?
Thanks,
Dimos
[ServiceNow]
From: Alvaro Herrera
Date: Thursday, 24. November 2022 at 19:24
To: Dimos Stamatakis
Cc: Peter Geoghegan , simon.ri...@enterprisedb.com
, pgsql-hackers@lists.postgresql.org
Hi hackers,
When running tpcc on sysbench with high concurrency (96 threads, scale factor
5) we realized that a fix for visibility check (introduced in PG-14.5) causes
sysbench to fail in 1 out of 70 runs.
The error is the following:
SQL error, errno = 0, state = 'XX000': new multixact has more
