From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: could not create directory "...": File exists |
Date: | 2013-01-17 19:31:54 |
Message-ID: | 15649.1358451114@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Or maybe we should just write this off as a case we can't realistically
>> fix before we have MVCC catalog scans. It seems that any other fix is
>> going to be hopelessly ugly.
> I feel like we should be able to do better than what we have now, at
> least. Using ShareLock prevented the specific case that we were
> experiencing and is therefore MUCH better (for us, anyway) than
> released versions where we ran into the error on a regular basis.
If it actually *reliably* fixed the problem, rather than just reducing
the probabilities, that would mean that the updates your other sessions
were doing didn't release RowExclusiveLock early. Have you dug into the
code to see if that's true? (Or even more to the point, if it's still
true in HEAD? I have no idea if all the recent refactoring has changed
this behavior for GRANT.)
My thought about a localized fix is similar to Andres' --- maybe we
could take a snapshot and use a real MVCC scan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-17 19:39:53 | Re: PATCH: optimized DROP of multiple tables within a transaction |
Previous Message | Jeff Davis | 2013-01-17 19:24:46 | Re: Removing PD_ALL_VISIBLE |