Re: old_snapshot_threshold's interaction with hash index
От | Kevin Grittner |
---|---|
Тема | Re: old_snapshot_threshold's interaction with hash index |
Дата | |
Msg-id | CACjxUsMam4rmP6TvhX+=UVk_VFnMrufr+0gCGz95X2UQi81SXw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: old_snapshot_threshold's interaction with hash index (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: old_snapshot_threshold's interaction with hash index
|
Список | pgsql-hackers |
On Tue, May 3, 2016 at 10:45 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Mon, May 2, 2016 at 04:02:35PM -0500, Kevin Grittner wrote: >> On Sun, May 1, 2016 at 1:43 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> >> >> Currently we do the test for old snapshot (TestForOldSnapshot) for hash >> >> indexes while scanning them. Does this test makes any sense for hash >> >> indexes considering LSN on hash index will always be zero (as hash indexes >> >> are not WAL-logged)? It seems to me that PageLSN check in >> >> TestForOldSnapshot() will always return false which means that the error >> >> "snapshot too old" won't be generated for hash indexes. >> >> >> >> Am I missing something here, if not, then I think we need a way to >> >> prohibit pruning for hash indexes based on old_snapshot_threshold? >> > >> > What I mean to say here is prohibit pruning the relation which has hash >> > index based on old_snapshot_threshold. >> >> Good spot; added to the open issues page. > > Uh, I have no idea how this would be fixed if the PageLSN is zero. Do > you? Yes, I see three ways, the most obvious of which is what Amit suggested -- don't do early vacuum on a table which has a hash index. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: