On Thu, 13 Mar 2025 at 18:10, Heikki Linnakangas wrote:
>
>
> Hmm, this problem isn't limited to this one pg_upgrade test, right? It
> could happen with any pg_upgrade invocation. And perhaps in a running
> server too, if a relfilenumber is reused quickly. In dropdb() and
> DropTableSpace() we do
On Thu, 13 Mar 2025 at 18:10, Heikki Linnakangas wrote:
>
> Hmm, this problem isn't limited to this one pg_upgrade test, right? It
> could happen with any pg_upgrade invocation. And perhaps in a running
> server too, if a relfilenumber is reused quickly.
Yes, it can happen with these scenarios.
On 2025-03-13 Th 5:04 AM, vignesh C wrote:
Hi,
In one of the recent buildfarm runs, the test
pg_upgrade/004_subscription test fails at [1].
It has failed with the following:
Restoring database schemas in the new cluster
*failure*
Consult the last few lines of
"C:/prog/bf/root/HEAD/pgsql.build
On 13/03/2025 11:04, vignesh C wrote:
## Analysis
I think it was caused due to the STATUS_DELETE_PENDING failure, not
related with recent
updates for pg_upgrade.
The file "base/1/2683" is an index file for
pg_largeobject_loid_pn_index, and the
output meant that file creation failed. Below is a b
Hi,
In one of the recent buildfarm runs, the test
pg_upgrade/004_subscription test fails at [1].
It has failed with the following:
Restoring database schemas in the new cluster
*failure*
Consult the last few lines of
"C:/prog/bf/root/HEAD/pgsql.build/testrun/pg_upgrade/004_subscription/data/t_004
