Re: race condition in pg_class
От | Tom Lane |
---|---|
Тема | Re: race condition in pg_class |
Дата | |
Msg-id | 1826823.1757619287@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: race condition in pg_class (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: race condition in pg_class
|
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > On Thu, Sep 11, 2025 at 12:36:04PM -0400, Tom Lane wrote: >> 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? > I have no specific notes or memories about that RESET TABLESPACE, but I likely > wanted "SET TABLESPACE pg_default". RESET TABLESPACE may still have the > effect of loading a catcache entry, as a later comment says: > ... > I'm inclined to change it as > attached. This doesn't reduce database.sql test coverage of dbcommands.c or > catcache.c, so I'll bet it doesn't lose anything vs. the original database.sql > commit. Some check-tests runs showed it adding database.sql coverage of > catcache.c:1908-1911 and catcache.c:1983-1984, so that's a bonus. Thanks, that looks sane. > Do you plan to back-patch that? That should dictate whether I back-patch the > test change. That change will convert some commands that are currently no-ops into errors, which doesn't seem like a great thing to do in minor releases. However ... it might still be okay to cram it into v18. Do you have an opinion about that? regards, tom lane
В списке pgsql-hackers по дате отправления: