Re: Wrong order of tests in findDependentObjects()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Wrong order of tests in findDependentObjects()
Date: 2016-11-28 19:48:10
Message-ID: 23800.1480362490@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>> I can't think of any reason you'd want the current behavior.

> But I think fixing it to not recurse to extensions during temp namespace
> cleanup might not be very hard. I'll take a look.

Here's a draft patch for that. Rather than sticking yet another special
assumption into deleteWhatDependsOn, I thought it was time to get rid of
that function altogether in favor of selecting its few special behaviors
via flag bits for performDeletion. So this adds PERFORM_DELETION_QUIETLY
and PERFORM_DELETION_SKIP_ORIGINAL flag bits to do that, plus a
PERFORM_DELETION_SKIP_EXTENSIONS bit that solves the problem at hand.
Treating this as a performDeletion flag bit also lets us disable extension
dropping in autovacuum's forced drop of temp tables, which would otherwise
be a nasty hole in the fix.

I'm not sure if this is a candidate for back-patching or not. I think
what it's fixing is mostly a convenience thing, since extension scripts
that explicitly drop any temp objects they've created are not at risk,
and that would be good extension authoring practice anyway IMO.
If we do back-patch we'd need to figure out whether we want to preserve
deleteWhatDependsOn as a stub function in the back branches. (I rather
doubt that any third party code is calling it, since it's so
special-purpose, but you never know ...)

Thoughts?

regards, tom lane

Attachment Content-Type Size
keep-extensions-when-dropping-temp-objects.patch text/x-diff 18.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Devrim Gündüz 2016-11-28 19:53:22 Re: Time to up bgwriter_lru_maxpages?
Previous Message Jim Nasby 2016-11-28 19:40:53 Time to up bgwriter_lru_maxpages?