Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-08-11 Thread Alvaro Herrera
Alvaro Herrera wrote: BTW, shouldn't there be a step in BRIN vacuum that scans all the BRIN pages? If an empty page is missing from the FSM for any reason, there's nothing to add it there. Probably. I didn't change this part yet. There are two things to fix: 1. since we use

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-08-07 Thread Alvaro Herrera
-- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c index 0b257d9..909e4c6 100644 ---

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-08-07 Thread Alvaro Herrera
Heikki Linnakangas wrote: BRIN update is not quite right, however. brin_getinsertbuffer() can initialize a page, but the caller might bail out without using the page and WAL-logging the change. If that happens, the next update that uses the same page will WAL-log the change but it will not

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-07-27 Thread Heikki Linnakangas
On 07/23/2015 07:43 PM, Jeff Janes wrote: On Mon, Jul 20, 2015 at 1:23 PM, Heikki Linnakangas hlinn...@iki.fi wrote: I came up with the attached, for GIN and SP-GiST. Instead of WAL-logging the page initialization in SP-GiST vacuum, I changed it so that it simply leaves the page as all-zeroes,

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-07-27 Thread Amit Langote
On Tue, Jul 28, 2015 at 12:21 AM, Heikki Linnakangas hlinn...@iki.fi wrote: Thanks, I've pushed this, as well a fix to similar failure from B-tree vacuum that Amit Langote reported in the other thread. Thanks Heikki and sorry I didn't notice this new thread. Regards, Amit -- Sent via

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-07-23 Thread Alvaro Herrera
Heikki Linnakangas wrote: BRIN update is not quite right, however. brin_getinsertbuffer() can initialize a page, but the caller might bail out without using the page and WAL-logging the change. If that happens, the next update that uses the same page will WAL-log the change but it will not

[HACKERS] All-zero page in GIN index causes assertion failure

2015-07-20 Thread Heikki Linnakangas
This is a continuation of the discussion at http://www.postgresql.org/message-id/CAMkU=1zUc=h0oczntajaqqw7gxxvxcwsyq8dd2t7ohgsgve...@mail.gmail.com, I'm starting a new thread as this is a separate issue than the original LWLock bug. On Thu, Jul 16, 2015 at 12:03 AM, Jeff Janes

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-07-20 Thread Heikki Linnakangas
On 07/20/2015 11:14 AM, Heikki Linnakangas wrote: ISTM ginvacuumcleanup should check for PageIsNew, and put the page to the FSM. That's what btvacuumpage() gistvacuumcleanup() do. spgvacuumpage() seems to also check for PageIsNew(), but it seems broken in a different way: it initializes the page

Re: [HACKERS] All-zero page in GIN index causes assertion failure

2015-07-20 Thread Alvaro Herrera
Heikki Linnakangas wrote: Looking closer, heap vacuum does a similar thing, but there are two mitigating factors that make it safe in practice, I think: 1. An empty heap page is all-zeroes except for the small page header in the beginning of the page. For a torn page to matter, the page