Message-ID: <f135c03dfe16d47a56f7f9ccddeaf85a328c024d.camel@j-davis.com>
Subject: Re: [16+] subscription can end up in inconsistent state
From: Jeff Davis <pgsql@j-davis.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>, Robert Haas
 <robertmhaas@gmail.com>,  Amit Kapila <amit.kapila16@gmail.com>,
 pgsql-bugs@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 17 Jan 2024 17:52:11 -0800
In-Reply-To: 
 <CALDaNm3Nr40=xVFUkPhazVEdGNQCughMCvYk_rad8ZY_5RPaEw@mail.gmail.com>
References: <e5892973ae2a80a1a3e0266806640dae3c428100.camel@j-davis.com>
	 <CAA4eK1LJEMfdxpV7xDhR3qOFoSt3LuKbbu5kRMBfYJ2imT8Few@mail.gmail.com>
	 <5dff4caf26f45ce224a33a5e18e110b93a351b2f.camel@j-davis.com>
	 <CALDaNm0fJ8dibhG-2sVKJaLP8pz-2T1o9epPvcdpb9FHyhn3gg@mail.gmail.com>
	 <CA+TgmoYy7Z=x+yaK1ugDqrUuMUNWcJkZdVF4E_+3L0tcmopcTA@mail.gmail.com>
	 <CALDaNm06nUm0URSYiduxi3VqdWZ=Swv4T8x0exHTr-aHMb4e+w@mail.gmail.com>
	 <CALDaNm1A50g3x+hiRT8UjPK3oETFtabTm=W-AhruHeNKh0Uz=Q@mail.gmail.com>
	 <CAHut+PsQBUGhPVTYRpGE8wogS5xbSouecGSCDdha-Bd-PP22ag@mail.gmail.com>
	 <CALDaNm3jbhVzT5XbBrU1=JfospGKz65a9mxJccR5O=c3Z13qjA@mail.gmail.com>
	 <CAHut+Pteo8qtXwEGNy42s2S-O=CU2wSZAicYd1bKn5TOTJyKWg@mail.gmail.com>
	 <CALDaNm2L9uDP3HsgSiBUGQWQAxVviA_BdcTHRUUiXTDJMpKD1Q@mail.gmail.com>
	 <5438ebe33bce797e5ffe24eaca81f1d130af9617.camel@j-davis.com>
	 <CALDaNm3Nr40=xVFUkPhazVEdGNQCughMCvYk_rad8ZY_5RPaEw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/f135c03dfe16d47a56f7f9ccddeaf85a328c024d.camel%40j-davis.com>
Precedence: bulk

On Wed, 2024-01-17 at 15:31 +0530, vignesh C wrote:
> There was a buildfarm failure at [1], I was able to reproduce it in
> my
> environment. The changes suggested by Tom Lane at [2] fixes the
> problem. Apart from that pg_hba.conf should have authentication
> configuration for the host which does not use unix domain sockets.
> The
> attached patch has the changes for the same.

I don't think adding --create-role=C2=A0is quite the right solution. The
point of the test is to distinguish between a password that comes from
the environment ($publisher_connstr1) vs specified in the connection
string ($publisher_connstr2).

There's no reason to use SSPI for that, and therefore no reason to
configure SSPI with --create-role. The change in your patch does allow
the connection initiated as part of CREATE SUBSCRIPTION to succeed, but
by a different path than what we need to test later anyway, so it seems
confusing to me. We might as well just get pg_hba.conf configured
correctly before issuing the CREATE SUBSCRIPTION.

We can't just add a "host" line to the pg_hba.conf, though, because
that violates this idea here (Cluster.pm):

  Authentication is set up so that only the current OS user can
  access the cluster. On Unix, we use Unix domain socket
  connections,=C2=A0with the socket in a directory that's only
  accessible to the current user to ensure that. On Windows, we
  use SSPI authentication to ensure the same (by pg_regress
  --config-auth).

The 001_password.pl test just doesn't run if !$use_unix_sockets and I
think we should do something similar.

We still need to move the pg_hba.conf changes up above the CREATE
SUBSCRIPTION.

Regards,
	Jeff Davis