From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |
Date: | 2020-11-13 20:30:00 |
Message-ID: | ccd33e2c-9816-6c04-1cf7-031218bbc035@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
13.11.2020 23:16, Tom Lane wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
>> Shouldn't pg_ls_dir_files() retry stat() on ERROR_ACCESS_DENIED just
>> like the pgwin32_open() does to ignore files in "delete pending" state?
> That would soon lead us to changing every stat() caller in the system
> to have Windows-specific looping logic. No thanks. If we need to do
> this, let's put in a Windows wrapper layer comparable to pgwin32_open()
> for open().
Maybe pgwin32_safestat() should perform this... For now it checks
GetLastError() for ERROR_DELETE_PENDING, but as we've found out
previously this error code in fact is not returned by the OS.
And if the fix is not going to be quick, probably it should be discussed
in another thread...
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-11-13 21:02:19 | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |
Previous Message | Tom Lane | 2020-11-13 20:16:13 | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |