Re: Avoid orphaned objects dependencies, take 3 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Avoid orphaned objects dependencies, take 3
Date
Msg-id CA+TgmobnNpBhV13F+P6LKP+bLE3aBjzgeuf4yySnkHKceA475A@mail.gmail.com
Whole thread Raw
In response to Re: Avoid orphaned objects dependencies, take 3  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Avoid orphaned objects dependencies, take 3
Re: Avoid orphaned objects dependencies, take 3
List pgsql-hackers
On Thu, May 23, 2024 at 12:19 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> The reason why we are using a dirty snapshot here is for the cases where we are
> recording a dependency on a referenced object that we are creating at the same
> time behind the scene (for example, creating a composite type while creating
> a relation). Without the dirty snapshot, then the object we are creating behind
> the scene (the composite type) would not be visible and we would wrongly assume
> that it has been dropped.

The usual reason for using a dirty snapshot is that you want to see
uncommitted work by other transactions. It sounds like you're saying
you just need to see uncommitted work by the same transaction. If
that's true, I think using HeapTupleSatisfiesSelf would be clearer. Or
maybe we just need to put CommandCounterIncrement() calls in the right
places to avoid having the problem in the first place. Or maybe this
is another sign that we're doing the work at the wrong level.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: AIX support
Next
From: Tom Lane
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs