pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Michael Paquier <michael@paquier.xyz>
To: Alexander Kukushkin <cyberdemn@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15346: Replica fails to start after the crash
Date: Wed, 29 Aug 2018 13:54:36 -0700
Message-ID: <20180829205436.GE5903@paquier.xyz> (raw)
In-Reply-To: <CAFh8B==_6cY1f7rF4oxK+wjpWKaYzs96Q6Tn5=4QRWJiVnjmDg@mail.gmail.com>
References: <CA+q6zcVjv1Lp-3=prBbpq2CbBioK91SHarfw3F8FHuUN4EwcUA@mail.gmail.com>
	<20180822175034.lnvwk5js32k6mjyz@alvherre.pgsql>
	<20180823041420.GA1158@paquier.xyz>
	<CAFh8B==4gpwor6ODercru0iifqwd0nQrdRvXzmorWkMRQa4q=g@mail.gmail.com>
	<CAFh8B=nHdsX83hTZMqGqbht39ud+DRQOv4_Te+xu3DuPssQbZA@mail.gmail.com>
	<CAFh8B=mYGP1J8ueHKU40Dr4bNBUPJj1rTbZ6Wpg4gR30uCRunA@mail.gmail.com>
	<20180829061723.GA5903@paquier.xyz>
	<CAFh8B=kuFyBsth-1wuPqncnTiCa7reKzCz=RzO1X-Y78U74F5g@mail.gmail.com>
	<20180829121051.GC5903@paquier.xyz>
	<CAFh8B==_6cY1f7rF4oxK+wjpWKaYzs96Q6Tn5=4QRWJiVnjmDg@mail.gmail.com>

On Wed, Aug 29, 2018 at 03:05:25PM +0200, Alexander Kukushkin wrote:
> BTW, I am thinking that we should return InvalidTransactionId from the
> btree_xlog_delete_get_latestRemovedXid if the index page we read from
> disk is newer then xlog record we are currently processing. Please see
> the patch attached.

This is not a solution in my opinion, as you could invalidate activities
of backends connected to the database when the incorrect consistent
point allows connections to come in too early.

What happens if you replay with hot_standby = on up to the latest point,
without any concurrent connections, then issue a checkpoint on the
standby once you got to a point newer than the complain, and finally
restart the standby with the bgworker?

Another idea I have would be to make the standby promote, issue a
checkpoint on it, and then use pg_rewind as a trick to update the
control file to a point newer than the inconsistency.  As PG < 9.6.10
could make the minimum recovery point go backwards, applying the upgrade
after the consistent point got to an incorrect state would trigger the
failure.
--
Michael

Attachments:

  signature.asc (application/pgp-signature, 832B) download

view thread (35+ messages)  latest in thread

Message-ID: <20180829205436.GE5903@paquier.xyz>
Permalink:  ../20180829205436.GE5903@paquier.xyz/
Also on:    postgresql.org/message-id/20180829205436.GE5903@paquier.xyz

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: michael@paquier.xyz, cyberdemn@gmail.com, alvherre@2ndquadrant.com, 9erthalion6@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #15346: Replica fails to start after the crash
  In-Reply-To: <20180829205436.GE5903@paquier.xyz>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox