On Thu, May 23, 2024 at 12:19 AM Bertrand Drouvot <bertranddrouvot...@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