From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Yet another fast GiST build |
Date: | 2020-09-21 08:45:59 |
Message-ID: | e1d41317-7420-b7ba-0d88-19625012e31e@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21/09/2020 11:08, Heikki Linnakangas wrote:
> I think they need to, so that they can stamp the page with the LSN of
> the WAL record. But GiST build is special in that regard, because it
> stamps all pages with GistBuildLSN.
Actually, don't we have a problem with that, even before this patch?
Even though we set the LSN to the magic GistBuildLSN value when we build
the index, WAL replay will write the LSN of the record instead. That
would mess with the LSN-NSN interlock. After WAL replay (or in a
streaming replica), a scan on the GiST index might traverse right-links
unnecessarily.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2020-09-21 09:01:04 | Re: Binaries on s390x arch |
Previous Message | Heikki Linnakangas | 2020-09-21 08:08:01 | Re: Yet another fast GiST build |