> >> Seems to me this is very broken. Isn't a query snapshot needed for
> >> any utility command that might do database accesses?
>
> > Not needed. We don't support multi-versioning for schema operations.
>
> No? Seems to me we're almost there. Look for instance at that DROP
> USER bug I just fixed: it was failing because it wasn't careful to make
> sure that during "DROP USER foo,bar", the loop iteration to delete user
> bar would see the changes the first loop iteration had made. So even ^^^^^^^^^^^^^^^^^^^
Snapshot defines visibility of changes made by other transactions.
Seems that you talk here about self-visibility, defined by CommandId.
> though we use a lot of table-level locking rather than true MVCC
> behavior for schema changes, ISTM that we still have to play by all the
> rules when it comes to tuple visibility. In particular I suspect we
> ought to be using standard query snapshot behavior...
What would it buy for us? MVCC lies to user - it returns view of data
as they were some time ago. What would we get by seeing old
view of catalog?
> > More of that, sometimes it would be better to read *dirty* data from
> > system tables - so, no snapshot required.
>
> There may be a small number of places like that, but for generic utility
> operations like CREATE/DROP USER, I don't see that this is a good idea.
But your fix for DROP USER didn't change anything about snapshot used by
scans so it's not good example.
Vadim