Re: BUG #3692: Conflicting create table statements throw unexpected error
От | Bruce Momjian |
---|---|
Тема | Re: BUG #3692: Conflicting create table statements throw unexpected error |
Дата | |
Msg-id | 200803250011.m2P0BvY18707@momjian.us обсуждение исходный текст |
Ответ на | BUG #3692: Conflicting create table statements throw unexpected error ("Bill Moran" <wmoran@collaborativefusion.com>) |
Список | pgsql-bugs |
Added to TODO: o Prevent concurrent CREATE TABLE table1 from sometimes returning a cryptic error message http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php --------------------------------------------------------------------------- Bill Moran wrote: > > The following bug has been logged online: > > Bug reference: 3692 > Logged by: Bill Moran > Email address: wmoran@collaborativefusion.com > PostgreSQL version: 8.2.5 > Operating system: FreeBSD > Description: Conflicting create table statements throw unexpected > error > Details: > > (also occurs on 8.1.10) > > Issuing a statement like: > CREATE TABLE table2 AS SELECT * FROM table1; > > simultaneously in two separate sessions should result in an error like > "ERROR: relation "table2" already exists" (in one or the other of the > sessions, depending on the exact timing of things). > > However, if table1 has enough rows that the command takes a while to execute > (a few seconds seems to be all it takes) the error is far more cryptic: > ERROR: duplicate key violates unique constraint "pg_type_typname_nsp_index" > > It seems to me that there's some sort of race condition that if the second > command starts before the first has completed, the backend doesn't really > understand what went wrong. > > For a front end, this is tough to parse. A "relation exists" error on a > table should probably be 42P07, but the duplicate key violation results in > 23505, which means a front end will likely behave incorrectly. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-bugs по дате отправления: