Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
От | Shruthi Gowda |
---|---|
Тема | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) |
Дата | |
Msg-id | CAASxf_Pqp44ERghe3JkiDoxNhf7DCDg-=emq1ZV3TVKTKajLmA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
|
Список | pgsql-hackers |
On Mon, Dec 6, 2021 at 11:25 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Sun, Dec 5, 2021 at 11:44 PM Sadhuprasad Patro <b.sadhu@gmail.com> wrote: > > 3. > > @@ -504,11 +525,15 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt) > > */ > > pg_database_rel = table_open(DatabaseRelationId, RowExclusiveLock); > > > > - do > > + /* Select an OID for the new database if is not explicitly configured. */ > > + if (!OidIsValid(dboid)) > > { > > - dboid = GetNewOidWithIndex(pg_database_rel, DatabaseOidIndexId, > > - Anum_pg_database_oid); > > - } while (check_db_file_conflict(dboid)); > > > > I think we need to do 'check_db_file_conflict' for the USER given OID > > also.. right? It may already be present. > > Hopefully, if that happens, we straight up fail later on. That's right. If a database with user-specified OID exists, the createdb fails with a "duplicate key value" error. If just a data directory with user-specified OID exists, MakePGDirectory() fails to create the directory and the cleanup callback createdb_failure_callback() removes the directory that was not created by 'createdb()' function. The subsequent create database call with the same OID will succeed. Should we handle the case where a data directory exists and the corresponding DB with that oid does not exist? I presume this situation doesn't arise unless the user tries to create directories in the data path. Any thoughts? Thanks & Regards Shruthi KC EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: