From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fixing order of resowner cleanup in 12, for Windows |
Date: | 2019-05-06 11:11:17 |
Message-ID: | CA+hUKGJL=gLQ4yZVa9yg08NYGEpVQ-CsCV8Dn2xSFwDBLSgTQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 6, 2019 at 9:26 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, May 6, 2019 at 3:43 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > Here's a way to produce an error which might produce the log message
> > on Windows. Does anyone want to try it?
>
> I can give it a try.
Thanks!
> > If it does produce the log message, then the attached patch should
> > make it go away.
>
> Are you referring to log message "LOG: could not rmdir directory
> "base/pgsql_tmp/pgsql_tmp3692.0.sharedfileset": Directory not empty"?
Yes.
> If so, I am getting it both before and after your patch.
Huh. I thought the only problem here was the phenomenon demonstrated
by [1]. I'm a bit stumped... if we've closed all the handles in every
backend before detaching, and then the last to detach unlinks all the
files first and then the directory, how can we get that error?
--
Thomas Munro
https://enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2019-05-06 11:51:20 | Re: Fixing order of resowner cleanup in 12, for Windows |
Previous Message | Stephen Frost | 2019-05-06 11:09:55 | Re: improving wraparound behavior |