Re: gist microvacuum doesn't appear to care about hot standby? - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: gist microvacuum doesn't appear to care about hot standby?
Date
Msg-id CAPpHfdumLaHbJ5cF-iEbQTCRMbd=gdDg+CkbprL3JmMd9XBbPw@mail.gmail.com
Whole thread Raw
In response to Re: gist microvacuum doesn't appear to care about hot standby?  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: gist microvacuum doesn't appear to care about hot standby?
List pgsql-hackers
On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Mon, Dec 17, 2018 at 1:25 AM Andres Freund <andres@anarazel.de> wrote:
> > On 2018-12-17 01:03:52 +0300, Alexander Korotkov wrote:
> > > Sorry for delay.  Attached patch implements conflict handling for gist
> > > microvacuum like btree and hash.  I'm going to push it if no
> > > objections.
> > >
> > > Note, that it implements new WAL record type.  So, new WAL can\t be
> > > replayed on old minor release.  I'm note sure if we claim that it's
> > > usually possible.  Should we state something explicitly for this case?
> >
> > Please hold off committing for a bit. Adding new WAL records in a minor
> > release ought to be very well considered and a measure of last resort.
> >
> > Couldn't we determine the xid horizon on the primary, and reuse an
> > existing WAL record to trigger the conflict?  Or something along those
> > lines?
>
> I thought about that, but decided it's better to mimic B-tree and hash
> behavior rather than invent new logic in a minor release.  But given
> that new WAL record in minor release in substantial problem, that
> argument doesn't matter.
>
> Yes, it seems to be possible.  We can determine xid horizon on primary
> in the same way you proposed for B-tree and hash [1] and use
> XLOG_HEAP2_CLEANUP_INFO record to trigger the conflict.  Do you like
> me to make such patch for GiST based on your patch?

Got another tricky idea.  Now, deleted offset numbers are written to
buffer data.  We can also append them to record data.  So, basing on
record length we can resolve conflicts when offsets are provided in
record data.  Unpatched version will just ignore extra record data
tail.  That would cost us some redundant bigger wal records, but solve
other problems.  Any thoughts?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: New function pg_stat_statements_reset_query() to resetstatistics of a specific query
Next
From: Etsuro Fujita
Date:
Subject: Re: Problems with plan estimates in postgres_fdw