Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
От | Thomas Munro |
---|---|
Тема | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Дата | |
Msg-id | CA+hUKGJVOve+ZBpz6Jf2GNG2bFE5bpc0U9zD7dBaqiHuW1SQow@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
|
Список | pgsql-hackers |
On Wed, May 4, 2022 at 7:44 AM Thomas Munro <thomas.munro@gmail.com> wrote: > It passes sometimes and fails sometimes. Here's the weird failure I > need to debug: > > https://api.cirrus-ci.com/v1/artifact/task/6033765456674816/log/src/test/recovery/tmp_check/log/regress_log_032_relfilenode_reuse > > Right at the end, it says: > > Warning: unable to close filehandle GEN26 properly: Bad file > descriptor during global destruction. > Warning: unable to close filehandle GEN21 properly: Bad file > descriptor during global destruction. > Warning: unable to close filehandle GEN6 properly: Bad file descriptor > during global destruction. > > I don't know what it means (Windows' fd->handle mapping table got > corrupted?) or even which program is printing it (you'd think maybe > perl? but how could that be affected by anything I did in > postgres.exe, but if it's not perl why is it always at the end like > that?). Hrmph. Got some off-list clues: that's just distracting Perl cleanup noise after something else went wrong (thanks Robert), and now I'm testing a theory from Andres that we're missing a barrier on the redo side when replaying XLOG_DBASE_CREATE_FILE_COPY. More soon.
В списке pgsql-hackers по дате отправления: