Re: snapshot too old, configured by time
От | Peter Geoghegan |
---|---|
Тема | Re: snapshot too old, configured by time |
Дата | |
Msg-id | CAM3SWZTBFdosbz_0e8QtpY5dRTK6ThrZ_+Pe0CY21dRGVT8oJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: snapshot too old, configured by time (Kevin Grittner <kgrittn@gmail.com>) |
Ответы |
Re: snapshot too old, configured by time
Re: snapshot too old, configured by time |
Список | pgsql-hackers |
On Thu, Mar 17, 2016 at 2:15 PM, Kevin Grittner <kgrittn@gmail.com> wrote: > New patch just to merge in recent commits -- it was starting to > show some bit-rot. Tests folded in with main patch. I haven't read the patch, but I wonder: What are the implications here for B-Tree page recycling by VACUUM? I know that you understand this topic well, so I don't assume that you didn't address it. Offhand, I imagine that there'd be some special considerations. Why is it okay that an index scan could land on a deleted page with no interlock against VACUUM's page recycling? Or, what prevents that from happening in the first place? I worry that something weird could happen there. For example, perhaps the page LSN on what is actually a newly recycled page could be set such that the backend following a stale right spuriously raises a "snapshot too old" error. I suggest you consider making amcheck [1] a part of your testing strategy. I think that this patch is a good idea, and I'd be happy to take feedback from you on how to make amcheck more effective for testing this patch in particular. [1] https://commitfest.postgresql.org/9/561/ -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: