On Thu, Nov 29, 2018 at 11:48 AM Peter Geoghegan <pg@bowt.ie> wrote:
> On Wed, Nov 28, 2018 at 1:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > LGTM.
>
> Pushed. Thanks.
Thanks. So, of the three issues that came up in this thread, we have:
1. off_t overflow: fixed in aa551830.
2. Error reporting could be better: fixed in 1a990b20.
3. Windows can't unlink directories containing files that have been
unlinked but are still open. This generates a WARNING and a
left-behind empty directory when an error is raised.
Here's a draft patch for #3. I can't test it on Windows myself; we'd
need to confirm it by hacking code somewhere to raise errors while
either running a parallel CREATE INDEX or a batched parallel hash
join, perhaps something involving a low probability divide-by-zero, or
maybe someone could try reverting commit aa551830 and using the short
repro I gave in my previous message upthread.
Assuming this can be confirmed to solve the problem, the real question
is: is it a bad idea to back-patch code that changes the order of
resowner release in this way? Specifically, could someone be upset if
we start calling their DSM detach hook after we've released everything
else, where previously it was before most other stuff? (Do any
extensions use DSM segments, and specifically dsm_detach() hooks?)
--
Thomas Munro
http://www.enterprisedb.com