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  (Peter Geoghegan <pg@heroku.com>)
Re: snapshot too old, configured by time  (Kevin Grittner <kgrittn@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: multivariate statistics v14
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: snapshot too old, configured by time