Re: BUG #17212: pg_amcheck fails on checking temporary relations

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date: 2021-10-18 18:07:38
Message-ID: 575655c4-7b24-e0d5-6f1b-2541b3e1cb20@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


On 10/15/21 10:46 AM, Andrew Dunstan wrote:
> On 10/14/21 5:52 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Efrain J. Berdecia 2021-10-18 18:20:07 Re: BUG #17229: Segmentation Fault after upgrading to version 13
Previous Message Alvaro Herrera 2021-10-18 14:40:35 Re: Snapshot leak warning with lo_export in subtransaction

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-10-18 19:02:56 Re: XTS cipher mode for cluster file encryption
Previous Message Alvaro Herrera 2021-10-18 17:40:31 Re: Partition Check not updated when insert into a partition