Re: race condition in pg_class
От | Tom Lane |
---|---|
Тема | Re: race condition in pg_class |
Дата | |
Msg-id | 1802710.1757608564@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: race condition in pg_class (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: race condition in pg_class
|
Список | pgsql-hackers |
[ blast-from-the-past department ] Noah Misch <noah@leadboat.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
В списке pgsql-hackers по дате отправления: