Re: [BUG] orphaned function
| От | Drouvot, Bertrand |
|---|---|
| Тема | Re: [BUG] orphaned function |
| Дата | |
| Msg-id | d59d4a02-02fe-f0a5-9660-0ed034ade452@amazon.com обсуждение исходный текст |
| Ответ на | Re: [BUG] orphaned function (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: [BUG] orphaned function
|
| Список | 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 canconfirm 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
В списке pgsql-hackers по дате отправления: