Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>, Mark Dilger <mark.dilger@enterprisedb.com>,
 Robert Haas <robertmhaas@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>,
 Alexander Lakhin <exclusion@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <17212-34dd4a1d6bba98bf@postgresql.org>
 <CAH2-Wzk3NzXYXsUKWBFuBm6aiXTh-_L2Dm9wPqfFenUvG+VbRw@mail.gmail.com>
 <543F3BF3-EDED-4C52-AF05-623921B6C409@enterprisedb.com>
 <CAH2-WzkXphRHgbaUXqMgb7SBmc_VbwdyWGYqphV6KbOH7stfxA@mail.gmail.com>
 <55A2BFE7-AAAF-4A64-BD3A-5C98EA982267@enterprisedb.com>
 <CAH2-WzniogVqNuWzNVLOKjkd8FBcSry29hN9=wiROUPw92fmGg@mail.gmail.com>
 <07159C9A-40DA-47BF-B2F4-! 203F5AC00890@enterprisedb.com>
 <CAH2-Wzkt-umhXfR1nqy=ZDXMfoN3LDK4W5VtchfWyRAuPWxtnA@mail.gmail.com>
 <40DB088B-C96F-49B2-BC84-BDC8D35C7E97@enterprisedb.com>
 <CAH2-Wzne7L9fX2LdZ9enNZpO2wuqbrsubCw2thH__CC_nZazjw@mail.gmail.com>
 <0B7DA7A4-2872-485B-BFDD-BF8E9BB07B26@enterprisedb.com>
 <CAH2-Wz=YnyANaKQDfx9pg0YNPS-LY66CXQrUzED4Rgm
 <726473.1634184950@sss.pgh.pa.us> <b5ec84db-c5af-bfac-fe4!
 f-a704a364f90b@dunslane.net> <903461.1634245763@sss.pgh.pa.us> <afb!
 18939-3a80-e4a8-7204-404df363fdf1@dunslane.net>
 <905705.1634248377@sss.pgh.pa.us>
 <122d1f3a-6e83-d2f8-3229-79cf8357136e@dunslane.net>
Message-ID: <575655c4-7b24-e0d5-6f1b-2541b3e1cb20@dunslane.net>
Date: Mon, 18 Oct 2021 14:07:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <122d1f3a-6e83-d2f8-3229-79cf8357136e@dunslane.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
 <https://www.postgresql.org/message-id/575655c4-7b24-e0d5-6f1b-2541b3e1cb20%40dunslane.net>
Precedence: bulk


On 10/15/21 10:46 AM, Andrew Dunstan wrote:
> On 10/14/21 5:52 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> Yes, that's been puzzling me too. I've just been staring at it again and
>>> nothing jumps out. But maybe we can investigate that offline if this
>>> test is deemed not worth keeping.
>> As Mark says, it'd be interesting to know whether the use of
>> background_psql is related, because if it is, we'd want to debug that.
>> (I don't really see how it could be related, but maybe I just lack
>> sufficient imagination today.)
>
>
> Yeah. I'm working on  getting a cut-down reproducible failure case.
>

I spend a good deal of time poking at this on Friday and Saturday.

It's quite clear that the use of

    my $h = $node->background_psql(...);
    $h->pump_nb;

is the root of the problem.

If that code is commented out, or even just moved to just after the
standby is started and before we check that replication has caught up
(which should meet the needs of the case where we found this), then the
problem goes away.

IPC::Run deals with this setup in a different way on Windows, mainly
because its select() only works on sockets and not other types of file
handles.

It does appear that TestLib::get_free_port() is not sufficiently robust,
as it should guarantee that the port/address can be bound.

I haven't got further that that, and I have other things I need to be
doing, but for now I think we just need to be careful wherever possible
to try to set up servers before trying to calling start/pump.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com