Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id CANgU5Zd54YpqxUzmybZzFV1_k-D0Minf-yw2_5VvzRn9RAB0AA@mail.gmail.com
Whole thread Raw
Responses Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
List pgsql-hackers
Hi,<br /><br />Consider the following sequence of events:<br /><br />s1 #> CREATE SCHEMA test_schema;<br /><br />s1
#>CREATE TABLE test_schema.c1(x int);<br /><br />Now open another session s2 and via gdb issue a breakpoint on
heap_create_with_catalog()which is called by DefineRelation().<br /><br />s2 #> CREATE TABLE test_schema.c2(y
int);<br/><br />The above will break on the function. Now issue a drop schema in session s1<br /><br />s1 #> DROP
SCHEMAtest_schema CASCADE;<br />NOTICE:  drop cascades to table test_schema.c1<br /> DROP SCHEMA<br /><br />Continuing
ingdb, also completes the creation of c2 table without any errors. We are now left with a dangling entry in pg_class
alongwith all the corresponding data files in our data directory. The problem becomes worse if c2 was created using a
TABLESPACE.Now dropping of that tablespace does not work at all. Am sure we can come up with myriad such other issues.
<br/><br />Am sure other CREATE commands in this namespace will have similar issues when faced with a concurrent DROP
SCHEMA.<br /><br />We definitely need some interlocking to handle this. For lack of better APIs, we could do a
LockDatabaseObject()call in AccessShareLock mode on the namespace and release the same on completion of the creation of
theobject. <br /><br />Thoughts? <br /><br />Regards,<br />Nikhils<br /> 

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: pg_comments (was: Allow \dd to show constraint comments)
Next
From: "Albe Laurenz"
Date:
Subject: Re: Disable OpenSSL compression