From: | "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gilles Darold <gilles(at)darold(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Nasby, Jim" <nasbyj(at)amazon(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
Subject: | Re: [BUG] orphaned function |
Date: | 2021-03-29 11:20:24 |
Message-ID: | d59d4a02-02fe-f0a5-9660-0ed034ade452@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Alvaro,
Thanks for the feedback!
On 3/27/21 3:13 PM, Alvaro Herrera wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 2021-Feb-02, Drouvot, Bertrand wrote:
>
>> On 12/18/20 12:26 AM, Tom Lane wrote:
>>> But any of these options lead to the same question: why stop there?
>>> An approach that would actually be defensible, perhaps, is to incorporate
>>> this functionality into the dependency mechanism: any time we're about to
>>> create a pg_depend or pg_shdepend entry, take out an AccessShareLock on
>>> the referenced object, and then check to make sure it still exists.
>>> This would improve the dependency mechanism so it prevents creation-time
>>> race conditions, not just attempts to drop dependencies of
>>> already-committed objects.
>> Agree that working with pg_depend and pg_shdepend is the way to go.
>>
>> Instead of using the locking machinery (and then make the one that
>> would currently produce the orphaned object waiting), Jim proposed
>> another approach: make use of special snapshot (like a dirty one
>> depending of the case).
>>
>> That way instead of locking we could instead report an error,
>> something like this:
>>
>> postgres=# drop schema tobeorph;
>> ERROR: cannot drop schema tobeorph because other objects that are currently under creation depend on it
>> DETAIL: function under creation tobeorph.bdttime() depends on schema tobeorph
> Sounds like an idea worth trying.
Great, if no objections is coming then I'll work on a patch proposal.
> What are the semantics of that
> special snapshot? Why do we need a special snapshot at all -- doesn't
> CatalogSnapshot serve?
Yes, the CatalogSnapshot should serve the need.
By "special" I meant "dirty" for example.
>
> This item is classified as a bug-fix in the commitfest, but it doesn't
> sound like something we can actually back-patch.
Why couldn't it be back-patchable?
Thanks
Bertrand
From | Date | Subject | |
---|---|---|---|
Next Message | 曾文旌 | 2021-03-29 11:27:39 | Re: [Proposal] Global temporary tables |
Previous Message | Markus Wanner | 2021-03-29 11:16:36 | Re: [PATCH] Provide more information to filter_prepare |