"Vadim Mikheev" <vmikheev@sectorbase.com> writes:
>> 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.
Sure. The example was just to point out that we do have tuple
visibility rules, even in utility statements.
>> 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?
regards, tom lane