Re: BUG #13660: serializable snapshotting hangs
От | Kevin Grittner |
---|---|
Тема | Re: BUG #13660: serializable snapshotting hangs |
Дата | |
Msg-id | 1788034186.151912.1444226070374.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: BUG #13660: serializable snapshotting hangs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #13660: serializable snapshotting hangs
|
Список | pgsql-bugs |
On Wednesday, October 7, 2015 8:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Kevin Grittner <kgrittn@ymail.com> writes: >> Incorrect. Like vacuum and other visibility-related operations, >> long-running transactions in other databases in the same "cluster" >> (in the sense of a group of backends running under a single >> postmaster) will be an issue. I seem to recall that it was >> non-trivial to limit things in general to a single database, but >> perhaps the DEFERRABLE feature could be enhanced to do that without >> too much pain. > > How will that work in the case of serialized access to a shared catalog? The Serializable Snapshot Isolation techniques only work on top of MVCC snapshot isolation. At the time of the SSI patch, catalogs were not accessed according to those rules, so we excluded them from SSI handling -- it just could not have worked in a meaningful way. (So catalog access is currently identical under REPEATABLE READ and SERIALIZABLE transaction isolation levels.) I am not clear on whether MVCC snapshot access changes to the catalogs since then have made it possible to extend SSI into the catalogs, or what the pros and cons of that would be. So, until such time as as SSI is changed to cover catalogs, it would be safe to ignore that issue in implementing what the OP wants -- nothing would break. The question is whether providing this feature would paint us into a corner in terms of the possibility of later extending SSI to cover shared catalogs. It's worth taking a close look at that; but for right now this is basically a few spots below the top of my TODO list, and I don't have time available right now to do the analysis that requires. Thanks for pointing it out, though. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: