Subject: Are these metadata ALTER TABLE commands transactionally safe?

From: Ron Johnson <[email-masked]>
Date: Thu, 14 May 2026 16:05:48 -0400

PG 17.9

BEGIN;
ALTER TABLE x RENAME TO x_hold;
ALTER TABLE y.x SET SCHEMA a;
ALTER TABLE x OWNER TO foo;
COMMIT;

I don't trust the validity of synthetic tests when Prod is ill-behaved JDBC
connections.

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 14 May 2026 14:26:05 -0700

> ALTER TABLE x OWNER TO foo;
Define “transactionally safe”.

> I don't trust the validity of synthetic tests when Prod is ill-behaved
> JDBC connections.
>
>
Then do them over a local connection using psql?

David J.

---

From: Ron Johnson <[email-masked]>
Date: Thu, 14 May 2026 21:03:47 -0400

> Define “transactionally safe”.

Any open transactions will still see the original tables.

> Then do them over a local connection using psql?

The applications which I don't want to throw errors are ill-behaved JDBC
connections.  Sorry for the ambiguity.

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 14 May 2026 18:13:03 -0700

> Any open transactions will still see the original tables.

That would involve locking, most DDL simply won’t happen while open
transactions are using the objects.  Normal visibility semantics then apply
beyond that - which depend on isolation level.

David J.