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.
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
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
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
> >
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
> >
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
> >
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:
> >
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
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