> >> 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?
>
> Consistency. For example: pg_dump wants a consistent view of the
> database, so it runs in a serializable transaction. To the extent that
> it uses utility statements rather than standard SELECTs to look at the
> state of the system catalogs, it will get the wrong answer if the
> utility statements believe that they can ignore the transaction
> isolation mode setting.
>
> I'm not sure that there are any utility statements that would be useful
> for pg_dump, but certainly there could be such a thing, no?
I'm not sure are there any utilities just to look into catalog, seems all of
them to change them. So, is this reason to change heap_beginscan
parameters in dozens places?
(Note! If you just need to call SetQuerySnapshot once per statement
please do it - it doesn't matter for subject of this thread).
Now examples why old catalog view is bad: what if serializable xaction S
tries to use index I to read from user table, and meanwhile another xaction
deleted this index. Any reason to abort S? But we'll do this.
And what if index I over int column was changed to index with name "I"
but over text column? Or function F now needs in 3 args instead of 2
args as it was when S started?
Let me repeat - we don't support multi-versioning of metadata (schema).
So, changing snapshot parameter of heap_beginscan used for internal ops
we'll not make us more happy than we are not.
Vadim