To: Graham Leggett <minfrin@sharp.fm>
cc: pgsql-admin@postgresql.org
Subject: Re: Could not create a tablespace - permission denied 
In-reply-to: <480A190B.80408@sharp.fm> 
References: <4809EC7B.6060902@sharp.fm> <9189.1208619241@sss.pgh.pa.us>
	<480A12F5.5060609@sharp.fm> <9478.1208620229@sss.pgh.pa.us>
	<480A190B.80408@sharp.fm>
Comments: In-reply-to Graham Leggett <minfrin@sharp.fm>
	message dated "Sat, 19 Apr 2008 18:08:43 +0200"
Date: Sat, 19 Apr 2008 12:17:31 -0400
Message-ID: <9918.1208621851@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Graham Leggett <minfrin@sharp.fm> writes:
> Tom Lane wrote:
>> I think this explanation is fiction ... there is no "cacheing of
>> credentials" in there that I know about.

> The server is a standard REHL5 installed copy of postgresql, running as 
> the postgres user (as is standard on RHE5). Both the data directory and 
> the tablespace are running on ext3 filesystems local to the machine, 
> there are no NFS mounts anywhere. The machine does not have SELinux 
> installed, never mind enabled.

> After the postgres user was granted permission to access the tablespace 
> directory, and after it was verified that the postgres user was able to 
> access the tablespace directory, postgresql refused to allow the 
> tablespace to be created until the postgresql server was restarted.

Fascinating.  I think what you're describing must be a kernel bug ---
want to see if you can reproduce it without PG involved?  Just make a
test program that chmod's, sleeps awhile, and chmod's again, and
manually change the permissions while it's sleeping, in the same way
that you did in the problem case.

			regards, tom lane