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:51:28 |
Message-ID: | 16046.1358452288@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> 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.
> My thought about a localized fix is similar to Andres' --- maybe we
> could take a snapshot and use a real MVCC scan.
BTW, it strikes me that the reason this particular SnapshotNow scan is a
big problem for you is that, because we stop and copy a subdirectory
after each tuple, the elapsed time for the seqscan is several orders of
magnitude more than it is for most (perhaps all) other cases where
SnapshotNow is used. So the window for trouble with concurrent updates
is that much bigger. This seems to provide a reasonably principled
argument why we might want to fix this case with a localized use of an
MVCC scan before we have such a fix globally.
Not that I wouldn't still want to mark it with a REVERT_ME_SOMEDAY
kind of annotation. We know we need the SnapshotNow scan fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-01-17 19:57:28 | Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave |
Previous Message | Alvaro Herrera | 2013-01-17 19:45:07 | Re: Teaching pg_receivexlog to follow timeline switches |