Re: SetQuerySnapshot() for utility statements
От | Tom Lane |
---|---|
Тема | Re: SetQuerySnapshot() for utility statements |
Дата | |
Msg-id | 11145.971981198@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SetQuerySnapshot() for utility statements ("Vadim Mikheev" <vmikheev@sectorbase.com>) |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: