Re: Cygwin cleanup - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Cygwin cleanup
Date
Msg-id 20220804033828.GK19644@telsasoft.com
Whole thread Raw
In response to Re: Cygwin cleanup  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Cygwin cleanup
List pgsql-hackers
On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > > XXX We would never want this to run by default in CI, but it'd be nice
> > > to be able to ask for it with ci-os-only!  (See commented out line)
> > >  only_if: $CIRRUS_CHANGE_MESSAGE =~ '.*\nci-os-only:[^\n]*cygwin.*'
> >
> > Doesn't this already do what's needed?
> > As long as it doesn't also check: CHANGE_MESSAGE !~ 'ci-os-only',
> > the task will runs only on request.
> 
> Yeah I was just trying to say that I was sharing the script in a way
> that always runs, but for commit we'd want that.

That makes more sense after noticing that you created a cf entry (for which
cfbot has been skipping my patch due to my "only_if" line).  There's still a
few persistent issues:

This fails ~50% of the time in recovery 010-truncate
I hacked around this by setting data_sync_retry.
https://cirrus-ci.com/task/5289444063313920
I found these, not sure if they're relevant.
https://www.postgresql.org/message-id/flat/CAA4eK1Kft05mwNuZbTVRmz8SNS3r%2BuriuCT8DxL5KJy5btoS-A%40mail.gmail.com
https://www.postgresql.org/message-id/flat/CAFiTN-uGxgo5258hZy2QJoz%3Ds7_Cs7v9%3Db8Z2GgFV7qmQUOwxw%40mail.gmail.com

And an fsync abort in 013 which seems similar to this other one.
data_sync_retry also avoids this issue.
https://cirrus-ci.com/task/6283023745286144?logs=cores#L34
https://www.postgresql.org/message-id/flat/CAMVYW_4QhjZ-19Xpr2x1B19soRCNu1BXHM8g1mOnAVtd5VViDw%40mail.gmail.com

And sometimes various assertions failing in regress parallel_select (and then times out)
https://api.cirrus-ci.com/v1/artifact/task/5537540282253312/log/src/test/regress/log/postmaster.log
https://api.cirrus-ci.com/v1/artifact/task/6108746773430272/log/src/test/regress/log/postmaster.log
Or "could not map dynamic shared memory segment" (actually in 027-stream-regress):
https://cirrus-ci.com/task/6168860746317824

And segfault in vacuum parallel
https://api.cirrus-ci.com/v1/artifact/task/5404589569605632/log/src/test/regress/log/postmaster.log

Sometimes semctl() failed: Resource temporarily unavailable

https://api.cirrus-ci.com/v1/artifact/task/5027860623654912/log/src/test/subscription/tmp_check/log/014_binary_publisher.log

https://api.cirrus-ci.com/v1/artifact/task/5027860623654912/log/src/bin/pg_rewind/tmp_check/log/001_basic_standby_local.log

Some more
https://cirrus-ci.com/task/6468927780814848

If you're lucky, there's only 1 or 2 problems, of which those are different
symptoms..  Maybe for now this needs to disable tap tests :(

This shows that it *can* pass, if slowly, and infrequently:
https://cirrus-ci.com/task/6546858536337408

This fixes my changes to configure for getopt.
And simplifies the changes to *.pl (the .exe changes weren't necessary at all).
And removes the changes for implicit-fallthrough; I realized that configure was
  just deciding that it didn't work and not using it at all.
And adds support for backtraces.
And remove kerberos and and add libxml

Why did you write "|| exit /b 1" in all the bash invocations ?  I think cirrus
handles that automatically.

-- 
Justin

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: PostgreSQL 15 minor fixes in protocol.sgml
Next
From: Andres Freund
Date:
Subject: Re: Cleaning up historical portability baggage