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-18 23:12:04
Message-ID: 8246.1358550724@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,
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Don't see what. The main reason we've not yet attempted a global fix is
>> that the most straightforward way (take a new snapshot each time we
>> start a new SnapshotNow scan) seems too expensive. But CREATE DATABASE
>> is so expensive that the cost of an extra snapshot there ain't gonna
>> matter.

> Patch attached. Passes the regression tests and our internal testing
> shows that it eliminates the error we were seeing (and doesn't cause
> blocking, which is even better).

I committed this with a couple of changes:

* I used GetLatestSnapshot rather than GetTransactionSnapshot. Since
we don't allow these operations inside transaction blocks, there
shouldn't be much difference, but in principle GetTransactionSnapshot
is the wrong thing; in a serializable transaction it could be quite old.

* After reviewing the other uses of SnapshotNow in dbcommands.c, I
decided we'd better make the same type of change in remove_dbtablespaces
and check_db_file_conflict, because those are likewise doing filesystem
operations on the strength of what they find in pg_tablespace.

I also ended up deciding to back-patch to 8.3 as well.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Phil Sorber 2013-01-18 23:51:30 Re: My first patch! (to \df output)
Previous Message Boszormenyi Zoltan 2013-01-18 22:45:40 Re: Contrib PROGRAM problem