Gilles Darold writes:
> Le 17/11/2022 à 17:59, Tom Lane a écrit :
>> I didn't want to back-patch e3fcbbd62 at the time, but it's probably aged
>> long enough now to be safe to back-patch. If we do anything here,
>> it should be to back-patch the whole thing, else we've only partially
>> fixed the
Le 17/11/2022 à 17:59, Tom Lane a écrit :
Gilles Darold writes:
I have an incorrect behavior with pg_dump prior PG version 15. With
PostgreSQL 15, thanks to commit e3fcbbd623b9ccc16cdbda374654d91a4727d173
the problem is gone but for older versions it persists with locks on
partitioned tables.
Le 17/11/2022 à 17:59, Tom Lane a écrit :
Gilles Darold writes:
I have an incorrect behavior with pg_dump prior PG version 15. With
PostgreSQL 15, thanks to commit e3fcbbd623b9ccc16cdbda374654d91a4727d173
the problem is gone but for older versions it persists with locks on
partitioned tables.
Gilles Darold writes:
> I have an incorrect behavior with pg_dump prior PG version 15. With
> PostgreSQL 15, thanks to commit e3fcbbd623b9ccc16cdbda374654d91a4727d173
> the problem is gone but for older versions it persists with locks on
> partitioned tables.
I didn't want to back-patch e3fcbb
Hi,
I have an incorrect behavior with pg_dump prior PG version 15. With
PostgreSQL 15, thanks to commit e3fcbbd623b9ccc16cdbda374654d91a4727d173
the problem is gone but for older versions it persists with locks on
partitioned tables.
When we try to dump a database where a table is locked,