Re: recent failures on lorikeet - Mailing list pgsql-hackers

From Tom Lane
Subject Re: recent failures on lorikeet
Date
Msg-id 197605.1623677952@sss.pgh.pa.us
Whole thread Raw
In response to recent failures on lorikeet  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: recent failures on lorikeet  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> I've been looking at the recent spate of intermittent failures on my
> Cygwin animal lorikeet. Most of them look something like this, where
> there's 'VACUUM FULL pg_class' and an almost simultaneous "CREATE TABLE'
> which fails.

Do you have any idea what "exit code 127" signifies on that platform?
(BTW, not all of them look like that; many are reported as plain
segfaults.)  I hadn't spotted the association with a concurrent "VACUUM
FULL pg_class" before, that does seem interesting.

> Getting stack traces in this platform can be very difficult. I'm going
> to try forcing complete serialization of the regression tests
> (MAX_CONNECTIONS=1) to see if the problem goes away. Any other
> suggestions might be useful. Note that we're not getting the same issue
> on REL_13_STABLE, where the same group pf tests run together (inherit
> typed_table, vacuum)

If it does go away, that'd be interesting, but I don't see how it gets
us any closer to a fix.  Seems like a stack trace is a necessity to
narrow it down.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: unnesting multirange data types
Next
From: Andrew Dunstan
Date:
Subject: pg_dumpall --exclude-database case folding