Re: SetQuerySnapshot() for utility statements
От | Vadim Mikheev |
---|---|
Тема | Re: SetQuerySnapshot() for utility statements |
Дата | |
Msg-id | 009701c039f9$c5f54780$bb7a30d0@sectorbase.com обсуждение исходный текст |
Ответ на | Re: SetQuerySnapshot() for utility statements ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Ответы |
Re: SetQuerySnapshot() for utility statements
|
Список | pgsql-hackers |
> >> 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
В списке pgsql-hackers по дате отправления: