Re: Possible race condition in pg_mkdir_p()?

2019-07-31 Thread Ning Yu
On Wed, Jul 31, 2019 at 2:21 PM Michael Paquier wrote: > That's my impression as well. Please note that this does not involve > an actual bug in Postgres and that this is rather invasive, so this > does not really qualify for a back-patch. No objections to simplify > the backend on HEAD though.

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 1:31 PM Michael Paquier wrote: > > On Tue, Jul 30, 2019 at 10:19:45PM -0700, Andres Freund wrote: > > I don't really have a problem fixing this case if we think it's > > useful. But I'm a bit bothered by all the "fixes" being submitted that > > don't matter for PG itself. T

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 12:41 PM Michael Paquier wrote: > > On Wed, Jul 31, 2019 at 12:26:30PM +0800, Ning Yu wrote: > > Could I double confirm with you that you made a clean rebuild after > > applying the patches? pg_mkdir_p() is compiled as part of libpgport.a, > > a

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 12:11 PM Andres Freund wrote: > > Hi, > > On 2019-07-18 16:17:22 +0800, Ning Yu wrote: > > This seems buggy as it first checks the existence of the dir and makes the > > dir if it does not exist yet, however when executing concurrently a > >

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Wed, Jul 31, 2019 at 12:04 PM Michael Paquier wrote: > > On Tue, Jul 30, 2019 at 06:22:59PM +0800, Ning Yu wrote: > > In fact personally I'm thinking that whether could we replace all uses of > > MakePGDirectory() with pg_mkdir_p(), so we could simplify > >

Re: Possible race condition in pg_mkdir_p()?

2019-07-30 Thread Ning Yu
On Tue, Jul 30, 2019 at 4:04 PM Michael Paquier wrote: > > On Tue, Jul 23, 2019 at 02:54:20PM +0800, Ning Yu wrote: > > MakePGDirectory() is also called in TablespaceCreateDbspace(), EEXIST is > > considered as non-error for parent directories, however as it considers > >

Re: Possible race condition in pg_mkdir_p()?

2019-07-22 Thread Ning Yu
ever as it considers EEXIST as a failure for the last level of the path so the logic is still correct, we do not add a final stat() check for it. Best Regards Ning On Thu, Jul 18, 2019 at 4:57 PM Michael Paquier wrote: > On Thu, Jul 18, 2019 at 04:17:22PM +0800, Ning Yu wrote: > >

Possible race condition in pg_mkdir_p()?

2019-07-18 Thread Ning Yu
Hi Hackers, We found a race condition in pg_mkdir_p(), here is a simple reproducer: #!/bin/sh basedir=pgdata datadir=$basedir/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z logdir=$basedir/logs n=2 rm -rf $basedir mkdir -p $logdir # init databases concurren

Re: New Defects reported by Coverity Scan for PostgreSQL

2018-07-31 Thread Ning Yu
To make coverity happy we might be able to suppress this false alarm by adding a line like below: ``` /* coverity[SWAPPED_ARGUMENTS] */ lseg_closept_lseg(result, l2, l1); ``` >From my point of view it's better to also put some comments for humans to understand why we are passing l1 and l2 in reve