Re: could not create directory "...": File exists

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

In response to

Responses

Browse pgsql-hackers by date

  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