Re: gist microvacuum doesn't appear to care about hot standby?

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:
> > On Thu, Dec 13, 2018 at 7:28 AM Alexander Korotkov
> > <a.korotkov@postgrespro.ru> wrote:
> > > On Thu, Dec 13, 2018 at 1:45 AM Andres Freund <andres@anarazel.de> wrote:
> > > > Is there any reason something like that isn't necessary for gist? If so,
> > > > where's that documented? If not, uh, isn't that a somewhat serious bug
> > > > in gist?
> > >
> > > Thank you for pointing!  This looks like a bug for me too.  I'm going
> > > to investigate more on this and provide a fix in next couple of days.
> >
> > 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?

1. https://www.postgresql.org/message-id/20181214014235.dal5ogljs3bmlq44%40alap3.anarazel.de

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