From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
Subject: | Re: pg_upgrade test failure |
Date: | 2023-01-31 21:20:23 |
Message-ID: | CA+hUKGKxdepGLuGOmYsRmaWiheBKQoVvyXx2wS-zhmAZavPX4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Wed, Feb 1, 2023 at 9:54 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> ... I have one more idea ...
I also had a second idea, barely good enough to mention and probably
just paranoia. In a nearby thread I learned that process exit does
not release Windows advisory file locks synchronously, which surprised
this Unix hacker; it made me wonder what else might be released lazily
after process exit. Handles?! However, as previously mentioned, it's
possible that even with fully Unix-like resource cleanup on process
exit, we could be confused if we are using "the process that was on
the end of this pipe has closed it" as a proxy for "the process is
gone, *all* its handles are closed". In any case, the previous kluge
should help wallpaper over any of that too, for this test anyway.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-01-31 21:53:20 | pgsql: Remove dead NoMovementScanDirection code |
Previous Message | Thomas Munro | 2023-01-31 21:08:17 | Re: pg_upgrade test failure |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-01-31 21:52:14 | Re: Show various offset arrays for heap WAL records |
Previous Message | Thomas Munro | 2023-01-31 21:08:17 | Re: pg_upgrade test failure |