| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, 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: | 2022-11-07 12:16:09 |
| Message-ID: | CA+hUKGKFh-F2fz_18j3N6bKr966gmaJxV40T0qhDwhKkW+291g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
So [1] on its own didn't fix this. My next guess is that the attached
might help.
Hmm. Following Michael's clue that this might involve log files and
pg_ctl, I noticed one thing: pg_ctl implements
wait_for_postmaster_stop() by waiting for kill(pid, 0) to fail, and
our kill emulation does CallNamedPipe(). If the server is in the
process of exiting and the kernel is cleaning up all the handles we
didn't close, is there any reason to expect the signal pipe to be
closed after the log file?
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Refactor-rmtree-to-use-get_dirent_type.patch | text/x-patch | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2022-11-07 13:11:52 | pgsql: Translation updates |
| Previous Message | Michael Paquier | 2022-11-07 03:34:58 | pgsql: Move code related to configuration files in directories to new f |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2022-11-07 12:21:52 | Re: Collation version tracking for macOS |
| Previous Message | Karthik Jagadish (kjagadis) | 2022-11-07 12:12:14 | Re: Postgres auto vacuum - Disable |