Re: DROP OWNED CASCADE vs Temp tables

2020-05-06 Thread Alvaro Herrera
On 2020-Apr-06, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Jan-14, Alvaro Herrera wrote: > >> Hmm, it seems to be doing it differently. Maybe it should be acquiring > >> locks on all objects in that nested loop and verified them for > >> existence, so that when it calls performMultiple

Re: DROP OWNED CASCADE vs Temp tables

2020-04-06 Thread Tom Lane
Alvaro Herrera writes: > On 2020-Jan-14, Alvaro Herrera wrote: >> Hmm, it seems to be doing it differently. Maybe it should be acquiring >> locks on all objects in that nested loop and verified them for >> existence, so that when it calls performMultipleDeletions the objects >> are already locked

Re: DROP OWNED CASCADE vs Temp tables

2020-02-19 Thread ahsan hadi
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested I have tested the patch with REL_12_STABLE for the given error sc

Re: DROP OWNED CASCADE vs Temp tables

2020-02-05 Thread Alvaro Herrera
On 2020-Jan-23, Alvaro Herrera wrote: > This is not a 100% solution: there's the cases when the user is removed > from an ACL and from a policy, and those deletions are done directly > instead of accumulating to the end for a mass deletion. > > I had to export AcquireDeletionLock (previously a st

Re: DROP OWNED CASCADE vs Temp tables

2020-01-23 Thread Alvaro Herrera
On 2020-Jan-14, Alvaro Herrera wrote: > On 2020-Jan-13, Tom Lane wrote: > > > That seems fundamentally wrong. By the time we've queued an object for > > deletion in dependency.c, we have a lock on it, and we've verified that > > the object is still there (cf. systable_recheck_tuple calls). > > I

Re: DROP OWNED CASCADE vs Temp tables

2020-01-14 Thread Alvaro Herrera
On 2020-Jan-13, Tom Lane wrote: > That seems fundamentally wrong. By the time we've queued an object for > deletion in dependency.c, we have a lock on it, and we've verified that > the object is still there (cf. systable_recheck_tuple calls). > If shdepDropOwned is doing it differently, I'd say s

Re: DROP OWNED CASCADE vs Temp tables

2020-01-13 Thread Tom Lane
Alvaro Herrera writes: > 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 >> (@RemoveTemp

Re: DROP OWNED CASCADE vs Temp tables

2020-01-13 Thread Michael Paquier
On Mon, Jan 13, 2020 at 07:45:06PM -0300, Alvaro Herrera wrote: > 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 o

Re: DROP OWNED CASCADE vs Temp tables

2020-01-13 Thread Alvaro Herrera
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)) a

DROP OWNED CASCADE vs Temp tables

2020-01-06 Thread Mithun Cy
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 w