From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Smolkin Grigory <smallkeen(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: race condition in pg_class |
Date: | 2025-09-11 16:36:04 |
Message-ID: | 1802710.1757608564@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
[ blast-from-the-past department ]
Noah Misch <noah(at)leadboat(dot)com> writes:
> I'm attaching patches implementing the LockTuple() design.
inplace010-tests-v1.patch from this message, committed as
0844b3968, contains this bit:
new file mode 100644
index 00000000000..0367c0e37ab
--- /dev/null
+++ b/src/test/regress/sql/database.sql
@@ -0,0 +1,17 @@
+CREATE DATABASE regression_tbd
+ ENCODING utf8 LC_COLLATE "C" LC_CTYPE "C" TEMPLATE template0;
+ALTER DATABASE regression_tbd RENAME TO regression_utf8;
+ALTER DATABASE regression_utf8 SET TABLESPACE regress_tblspace;
+ALTER DATABASE regression_utf8 RESET TABLESPACE;
+ALTER DATABASE regression_utf8 CONNECTION_LIMIT 123;
+
It emerges that the "ALTER DATABASE regression_utf8 RESET TABLESPACE"
command is a complete no-op [1]. I am guessing that that was not the
behavior you had in mind, and am wondering if we are losing any test
coverage thereby. Did you have a specific reason for manipulating the
TABLESPACE property and not some random GUC setting?
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/30783e-68c28a00-9-41004480%40130449754
From | Date | Subject | |
---|---|---|---|
Next Message | Paul A Jungwirth | 2025-09-11 16:54:54 | Re: Foreign key isolation tests |
Previous Message | Álvaro Herrera | 2025-09-11 16:30:30 | Re: Foreign key isolation tests |