Re: DROP OWNED CASCADE vs Temp tables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: DROP OWNED CASCADE vs Temp tables
Date
Msg-id 20200113224506.GA5833@alvherre.pgsql
Whole thread Raw
In response to DROP OWNED CASCADE vs Temp tables  (Mithun Cy <mithun.cy@gmail.com>)
Responses Re: DROP OWNED CASCADE vs Temp tables  (Michael Paquier <michael@paquier.xyz>)
Re: DROP OWNED CASCADE vs Temp tables  (Michael Paquier <michael@paquier.xyz>)
Re: DROP OWNED CASCADE vs Temp tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: DROP OWNED CASCADE vs Temp tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2020-Jan-07, Mithun Cy wrote:

> I have a test where a user creates a temp table and then disconnect,
> concurrently we try to do DROP OWNED BY CASCADE on the same user. Seems
> this causes race condition between temptable deletion during disconnection
> (@RemoveTempRelations(myTempNamespace)) and DROP OWNED BY CASCADE operation
> which will try to remove same temp table when they find them as part of
> pg_shdepend.

Cute.

This seems fiddly to handle better; maybe you'd have to have a new
PERFORM_DELETION_* flag that says to ignore "missing" objects; so when
you go from shdepDropOwned, you pass that flag all the way down to
doDeletion(), so the objtype-specific function is called with
"missing_ok", and ignore if the object has already gone away.  That's
tedious because none of the Remove* functions have the concept of
missing_ok.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: isTempNamespaceInUse() is incorrect with its handling ofMyBackendId
Next
From: Peter Geoghegan
Date:
Subject: Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence