Re: Database-level collation version tracking

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Database-level collation version tracking
Дата
Msg-id ad5e7040-4c46-6c8f-2daf-611546bb857d@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Database-level collation version tracking  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Database-level collation version tracking  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On 07.02.22 17:08, Julien Rouhaud wrote:
> There's so limited testing in collate.* regression tests, so I thought it would
> be ok to add it there.  At least some ALTER DATABASE ... REFRESH VERSION would
> be good, similarly to collation-level versioning.

I don't think you can run ALTER DATABASE from the regression test 
scripts, since the database name is not fixed.  You'd have to paste the 
command together using psql tricks or something.  I guess it could be 
done, but maybe there is a better solution.  We could put it into the 
createdb test suite, or write a new TAP test suite somewhere.  There is 
no good precedent for this.

>> That code takes a RowExclusiveLock on pg_database.  Did you have something
>> else in mind?
> 
> But that lock won't prevent a concurrent DROP DATABASE, so it's totally
> expected to hit that cache lookup failed error.  There should either be a
> shdepLockAndCheckObject(), or changing the error message to some errmsg("data
> xxx does not exist").

I was not familiar with that function.  AFAICT, it is only used for 
database and role settings (AlterDatabaseSet(), AlterRoleSet()), but not 
when just updating the role or database catalog (e.g., AlterRole(), 
RenameRole(), RenameDatabase()).  So I don't think it is needed here. 
Maybe I'm missing something.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Frédéric Yhuel
Дата:
Сообщение: Should pg_restore vacuum the tables before the post-data stage?
Следующее
От: Joe Conway
Дата:
Сообщение: Re: [PATCH v2] use has_privs_for_role for predefined roles