Date: Wed, 28 Nov 2018 21:39:58 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: splarv@ya.ru, pgsql-docs@lists.postgresql.org
Subject: Re: Return codes for archive and restore commands
Message-ID: <20181129023957.GU3415@tamriel.snowman.net>
References: <154340283171.1324.10549444217937216132@wrigleys.postgresql.org>
 <20181129022347.GH626@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="jHgdI7OefoZoiA5t"
Content-Disposition: inline
In-Reply-To: <20181129022347.GH626@paquier.xyz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--jHgdI7OefoZoiA5t
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Michael Paquier (michael@paquier.xyz) wrote:
> On Wed, Nov 28, 2018 at 11:00:31AM +0000, PG Doc comments form wrote:
> > For the archive command:
> > <=3D128 There are not errors in the PostgreSQL log (messages with sever=
ity
> > equal or higher than ERROR). Firstly 3 messages of type LOG about fault,
> > then WARNING about this and pause for 1 minute, then repeated.
> > >=3D129 FATAL error in the PostgeSQL log. The message about stoping an =
archive
> > process, but not the database. Repeated after roughly 16 seconds.
>=20
> This code is around for some time, and comes from this commit:
> commit: 3ad0728c817bf8abd2c76bd11d856967509b307c
> author: Tom Lane <tgl@sss.pgh.pa.us>
> date: Tue, 21 Nov 2006 20:59:53 +0000
> committer: Tom Lane <tgl@sss.pgh.pa.us>
> date: Tue, 21 Nov 2006 20:59:53 +0000
> On systems that have setsid(2) (which should be just about everything exc=
ept
> Windows), arrange for each postmaster child process to be its own process
> group leader, and deliver signals SIGINT, SIGTERM, SIGQUIT to the whole
> process group not only the direct child process.  This provides saner beh=
avior
> for archive and recovery scripts; in particular, it's possible to shut do=
wn a
> warm-standby recovery server using "pg_ctl stop -m immediate", since deli=
very
> of SIGQUIT to the startup subprocess will result in killing the waiting
> recovery_command.  Also, this makes Query Cancel and statement_timeout ap=
ply
> to scripts being run from backends via system().  (There is no support in=
 the
> core backend for that, but it's widely done using untrusted PLs.)  Per gr=
ipe
> from Stephen Harris and subsequent discussion.
>=20
> The relevant part if pgarch_archiveXlog() in pgarch.c, and this part
> is most relevant:
> * Per the Single Unix Spec, shells report exit status > 128 when a
> * called command died on a signal.
>=20
> > In this case PostgreSQL tries confirm rules for return codes of a unix
> > shell. A unix shell return 126 in the case of "command not executable",=
 127
> > in the case "command not found", 128+# of signal in the case if applica=
tion
> > interrupted by uncatched signal.
>=20
> If you were to rewrite those paragraphs or make them more precise, how
> would you actually shape your suggestions?  I personally quite like the
> current formulations, but I am rather used to it to be honest.

This is another example, at least imv, of why we really need to move
away from archive_command as an interface for doing WAL archiving.

Having discussed this quite a bit lately with David Steele and Magnus,
it's pretty clear that we need to completely rip out how this works
today and rewrite it based around an extension model where a background
worker can start up and essentially take the place of the archiver
process, with flexibility to jump forward through the WAL stream,
communicate clearly with other processes, handle failure to do so
gracefully based on the specific cases, etc.

We could then possibly write an extension to be included that mimics
what archive_command does today, but imv we should immediately consider
it deprecated and encourage people to move off of it.

Thanks!

Stephen

--jHgdI7OefoZoiA5t
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIbBAEBCgAGBQJb/1F9AAoJEO1sijiDR2RVdeQP+Oj7skVhsh9FO1uuGuodFK7m
yf8o/Wb9n7hrQbyRLChHz2SjZpLT3SiCWSLIFE/jzCXRky3wZmCQ71wOfFvxZ+od
lDgbTf6wdi1t6ClUif2HM8EaBSDPkPKd2aHrWKk/7rrpUFz1iJiFkA1NwFNM3VY7
rLzPhQEJrb+LM1jK5EXZewMu/DVCgv9xN3D3chig5pz2jdNhuY7hNk28RRXTfAEB
10/Cmz9+TFm1eRRmqZGMm0z7TyQFSR9dyqU9XVdEEmXpnx4D3uKRCmDiwsjEl+qV
71EUbpSzAuP4na3ID+se1TDrpQCI06KNYxX6oStNEWHoUO1fFC6oGWJMDkLRXXal
zm2Ewfd+2qdI05sppLFZghbPdC1/GJJEHqsEq/0gY9B+TT63o77ZwOXAv9sijScF
BMYNy8zwu5z0FDMr2FVwYbGpZlARCNurxJg+KRpd+yCxsU7A/GIxZrnrmH4DJ5qG
CNJWONgpy5BFZzmrU8YDH9yd5Nr0z8NuZJ1LEoUkl29eClmfEQLA6xy1R0eW/fUP
w1KaCSkN75B9/3L8fTA+zfUTIrdVFY8jlij/XHPYW39E4WQAlvaoxsM14Dkmi9gu
LCr6stYbD6UAi/n9QqChjfsNkRvl78x+2XOJ7NJ5vsLb0uwb6AT192NwKnXmq5fS
IoZi1V/cdgEpFKbe3nU=
=W7My
-----END PGP SIGNATURE-----

--jHgdI7OefoZoiA5t--