Re: old_snapshot_threshold's interaction with hash index
От | Bruce Momjian |
---|---|
Тема | Re: old_snapshot_threshold's interaction with hash index |
Дата | |
Msg-id | 20160503154505.GC27541@momjian.us обсуждение исходный текст |
Ответ на | Re: old_snapshot_threshold's interaction with hash index (Kevin Grittner <kgrittn@gmail.com>) |
Ответы |
Re: old_snapshot_threshold's interaction with hash index
|
Список | pgsql-hackers |
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? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: