Pavan Deolasee <pavan.deola...@gmail.com> writes: > On Thu, Apr 12, 2018 at 1:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> So while looking at this, it suddenly occurred to me that probing with >> SnapshotDirty isn't that safe for regular (non-TOAST) Oid assignment >> either.
> Yeah it occurred to me as well, but when I looked at the code, I couldn't > find a case that is broken. I even tried a few test cases with DDLs etc. I think it probably can't happen for catalog MVCC scans, because we generally take full new snapshots for those. The situation that would be hazardous is where we use an existing snapshot (so that it doesn't see the just-committed Other Transaction) but advance its command counter (so that it can see the new object we just made). So the sort of failure I'd predict is that a user query just after an object creation could see duplicate OIDs in the catalogs. To get to that point, you might need a stable function (using the troublesome snapshot) calling a volatile one (which contains the actual DDL). > But I think what you did is fine and more bullet proof. So +1 to that. Yeah, even if this isn't actually a reachable case, it's hard to argue that we should complicate the code and take API-break risks in the back branches to make a tiny optimization on the assumption that it can never happen. regards, tom lane