pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedfix pg_mkdir_p to tolerate concurrent directory creation
11+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2026-06-19 f25a07b2d9 aa80c34c85 f0a831ef3e 9951e3d382 4647ac1423 4b3bc6b714 Make pg_mkdir_p() tolerant of a concurrent directory creation.
* fix pg_mkdir_p to tolerate concurrent directory creation
@ 2026-06-18 13:18 Andrew Dunstan <andrew@dunslane.net>
2026-06-18 14:24 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 14:01 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 2 replies; 11+ messages in thread
From: Andrew Dunstan @ 2026-06-18 13:18 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
While working on the pytest stuff, I found this issue when making it
work on Windows, but the issue can exist everywhere. pg_mkdir_p can fail
if there is a concurrent directory creation. This patch makes it
tolerant of concurrent directory creation. To make it more robust it
stops using stat() on Windows and instead uses GetFileAttributes().
I think this makes the function actually meet the contract set out in
the file's header comment:
* pg_mkdir_p --- create a directory and, if necessary, parent directories
*
* This is equivalent to "mkdir -p" except we don't complain if the target
* directory already exists.
Thanks to Bryan Green for help with the Windows part.
There might be a few call sites that actually work around this bug that
we can clean up.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Attachments:
0001-Make-pg_mkdir_p-tolerant-of-a-concurrent-directory-c.patch (text/x-patch, 3.6K) download
From 55de4a69c6fcfbe72c5801acd67a78bae6d89e96 Mon Sep 17 00:00:00 2001
From: Andrew Dunstan <andrew@dunslane.net>
Date: Thu, 18 Jun 2026 08:49:57 -0400
Subject: [PATCH] Make pg_mkdir_p tolerant of a concurrent directory creation
pg_mkdir_p creates each missing path component with a stat() followed
by mkdir(). If the stat() reports the component as absent but another
process creates it in the window before this process's mkdir(), mkdir()
fails with EEXIST and pg_mkdir_p treated that as a hard error -- unlike
"mkdir -p", which is meant to be idempotent and race-tolerant.
This shows up when several processes concurrently create paths that
share an ancestor directory: for example, parallel initdb runs whose
data directories live under a common temporary directory. One process
wins the race to create the shared ancestor and the others fail with
could not create directory "...": File exists
On Windows, stat() opens a file handle and participates in share-mode
locking, which means it can transiently fail on a directory another
process is concurrently creating. Use GetFileAttributes() instead: it
requests only FILE_READ_ATTRIBUTES and is exempt from share-mode
denial, so it reliably sees a concurrently-created directory. Use the
same probe for the post-mkdir() fallback check.
On other platforms, after a failing mkdir() with EEXIST, the error is
genuine only if the path is still not a directory.
---
src/port/pgmkdirp.c | 52 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/src/port/pgmkdirp.c b/src/port/pgmkdirp.c
index 7d7cea4dd0e..2ce9186f11f 100644
--- a/src/port/pgmkdirp.c
+++ b/src/port/pgmkdirp.c
@@ -56,7 +56,9 @@
int
pg_mkdir_p(char *path, int omode)
{
+#ifndef WIN32
struct stat sb;
+#endif
mode_t numask,
oumask;
int last,
@@ -119,6 +121,42 @@ pg_mkdir_p(char *path, int omode)
if (last)
(void) umask(oumask);
+#ifdef WIN32
+ {
+ /*
+ * On Windows, stat() opens a handle and can transiently fail on a
+ * directory another process is concurrently creating. Probe with
+ * a path-based attribute query instead: it requests only
+ * FILE_READ_ATTRIBUTES and is exempt from share-mode denial, so it
+ * reliably sees a concurrently-created directory.
+ */
+ DWORD attr = GetFileAttributes(path);
+
+ if (attr != INVALID_FILE_ATTRIBUTES)
+ {
+ /* pre-existing entry */
+ if (!(attr & FILE_ATTRIBUTE_DIRECTORY))
+ {
+ errno = last ? EEXIST : ENOTDIR;
+ retval = -1;
+ break;
+ }
+ /* already a directory: nothing to do, fall through */
+ }
+ else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
+ {
+ /* tolerate a concurrent creation; re-probe the same way */
+ attr = GetFileAttributes(path);
+ if (errno != EEXIST ||
+ attr == INVALID_FILE_ATTRIBUTES ||
+ !(attr & FILE_ATTRIBUTE_DIRECTORY))
+ {
+ retval = -1;
+ break;
+ }
+ }
+ }
+#else
/* check for pre-existing directory */
if (stat(path, &sb) == 0)
{
@@ -134,9 +172,19 @@ pg_mkdir_p(char *path, int omode)
}
else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
{
- retval = -1;
- break;
+ /*
+ * Tolerate a concurrent creation: another process may have
+ * created the directory in the window between the stat() above
+ * and this mkdir(). Only treat it as an error if the path still
+ * is not a directory.
+ */
+ if (errno != EEXIST || stat(path, &sb) != 0 || !S_ISDIR(sb.st_mode))
+ {
+ retval = -1;
+ break;
+ }
}
+#endif
if (!last)
*p = '/';
}
--
2.43.0
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
@ 2026-06-18 14:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-18 15:37 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 11+ messages in thread
From: Tom Lane @ 2026-06-18 14:24 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Andrew Dunstan <andrew@dunslane.net> writes:
> While working on the pytest stuff, I found this issue when making it
> work on Windows, but the issue can exist everywhere. pg_mkdir_p can fail
> if there is a concurrent directory creation.
This bit:
+ if (errno != EEXIST || stat(path, &sb) != 0 || !S_ISDIR(sb.st_mode))
+ {
+ retval = -1;
+ break;
+ }
looks like it could corrupt the reported errno, ie stat() could
overwrite what mkdir() reported.
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-18 14:24 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-06-18 15:37 ` Andrew Dunstan <andrew@dunslane.net>
2026-06-18 15:43 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Dunstan @ 2026-06-18 15:37 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2026-06-18 Th 10:24 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> While working on the pytest stuff, I found this issue when making it
>> work on Windows, but the issue can exist everywhere. pg_mkdir_p can fail
>> if there is a concurrent directory creation.
> This bit:
>
> + if (errno != EEXIST || stat(path, &sb) != 0 || !S_ISDIR(sb.st_mode))
> + {
> + retval = -1;
> + break;
> + }
>
> looks like it could corrupt the reported errno, ie stat() could
> overwrite what mkdir() reported.
>
>
Oh, good catch, thanks! Here's a revised patch.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Attachments:
v2-0001-Make-pg_mkdir_p-tolerant-of-a-concurrent-director.patch (text/x-patch, 3.8K) download
From ab26c8e02b20edc13ce9216c92a2141dc7ca9f90 Mon Sep 17 00:00:00 2001
From: Andrew Dunstan <andrew@dunslane.net>
Date: Thu, 18 Jun 2026 11:34:33 -0400
Subject: [PATCH v2] Make pg_mkdir_p tolerant of a concurrent directory
creation
pg_mkdir_p creates each missing path component with a stat() followed
by mkdir(). If the stat() reports the component as absent but another
process creates it in the window before this process's mkdir(), mkdir()
fails with EEXIST and pg_mkdir_p treated that as a hard error -- unlike
"mkdir -p", which is meant to be idempotent and race-tolerant.
This shows up when several processes concurrently create paths that
share an ancestor directory: for example, parallel initdb runs whose
data directories live under a common temporary directory. One process
wins the race to create the shared ancestor and the others fail with
could not create directory "...": File exists
On Windows, stat() opens a file handle and participates in share-mode
locking, which means it can transiently fail on a directory another
process is concurrently creating. Use GetFileAttributes() instead: it
requests only FILE_READ_ATTRIBUTES and is exempt from share-mode
denial, so it reliably sees a concurrently-created directory. Use the
same probe for the post-mkdir() fallback check.
On other platforms, after a failing mkdir() with EEXIST, the error is
genuine only if the path is still not a directory. Save errno before
the stat() probe so that mkdir()'s error is not clobbered if we have
to report failure.
---
src/port/pgmkdirp.c | 55 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/src/port/pgmkdirp.c b/src/port/pgmkdirp.c
index 7d7cea4dd0e..f4c481515d1 100644
--- a/src/port/pgmkdirp.c
+++ b/src/port/pgmkdirp.c
@@ -56,7 +56,9 @@
int
pg_mkdir_p(char *path, int omode)
{
+#ifndef WIN32
struct stat sb;
+#endif
mode_t numask,
oumask;
int last,
@@ -119,6 +121,42 @@ pg_mkdir_p(char *path, int omode)
if (last)
(void) umask(oumask);
+#ifdef WIN32
+ {
+ /*
+ * On Windows, stat() opens a handle and can transiently fail on a
+ * directory another process is concurrently creating. Probe with
+ * a path-based attribute query instead: it requests only
+ * FILE_READ_ATTRIBUTES and is exempt from share-mode denial, so it
+ * reliably sees a concurrently-created directory.
+ */
+ DWORD attr = GetFileAttributes(path);
+
+ if (attr != INVALID_FILE_ATTRIBUTES)
+ {
+ /* pre-existing entry */
+ if (!(attr & FILE_ATTRIBUTE_DIRECTORY))
+ {
+ errno = last ? EEXIST : ENOTDIR;
+ retval = -1;
+ break;
+ }
+ /* already a directory: nothing to do, fall through */
+ }
+ else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
+ {
+ /* tolerate a concurrent creation; re-probe the same way */
+ attr = GetFileAttributes(path);
+ if (errno != EEXIST ||
+ attr == INVALID_FILE_ATTRIBUTES ||
+ !(attr & FILE_ATTRIBUTE_DIRECTORY))
+ {
+ retval = -1;
+ break;
+ }
+ }
+ }
+#else
/* check for pre-existing directory */
if (stat(path, &sb) == 0)
{
@@ -134,9 +172,22 @@ pg_mkdir_p(char *path, int omode)
}
else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
{
- retval = -1;
- break;
+ /*
+ * Tolerate a concurrent creation: another process may have
+ * created the directory in the window between the stat() above
+ * and this mkdir(). Save errno before the stat() probe so that
+ * mkdir()'s error is not clobbered if we have to report failure.
+ */
+ int save_errno = errno;
+
+ if (save_errno != EEXIST || stat(path, &sb) != 0 || !S_ISDIR(sb.st_mode))
+ {
+ errno = save_errno;
+ retval = -1;
+ break;
+ }
}
+#endif
if (!last)
*p = '/';
}
--
2.43.0
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-18 14:24 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
2026-06-18 15:37 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
@ 2026-06-18 15:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-18 16:56 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2026-06-18 15:43 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Andrew Dunstan <andrew@dunslane.net> writes:
> Oh, good catch, thanks! Here's a revised patch.
The Unix side of this LGTM. I have no idea about the Windows
half (... but are we sure GetFileAttributes() can't change errno?)
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-18 14:24 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
2026-06-18 15:37 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-18 15:43 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-06-18 16:56 ` Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Dunstan @ 2026-06-18 16:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2026-06-18 Th 11:43 AM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net> writes:
>> Oh, good catch, thanks! Here's a revised patch.
> The Unix side of this LGTM. I have no idea about the Windows
> half (... but are we sure GetFileAttributes() can't change errno?)
>
>
I'm told it does not. Google says:
GetFileAttributes does not set errno. Because it is a Win32 API function
rather than a standard C library function, it sets the thread-local
Last-Error Code instead.
|
|
|cheers|
|
|
|andrew|
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
@ 2026-06-19 14:01 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-06-19 14:51 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 15:07 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 11+ messages in thread
From: Álvaro Herrera @ 2026-06-19 14:01 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2026-Jun-18, Andrew Dunstan wrote:
>
> While working on the pytest stuff, I found this issue when making it work on
> Windows, but the issue can exist everywhere. pg_mkdir_p can fail if there is
> a concurrent directory creation. This patch makes it tolerant of concurrent
> directory creation.
Hmm, should the 'break's in the loop be 'continue's? If you're creating
path a/b/c, and a concurrent process beats you but is only attempting to
do a/b, then with the break you'll fail to create the final c.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree. (Don Knuth)
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-19 14:01 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-06-19 14:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 11+ messages in thread
From: Tom Lane @ 2026-06-19 14:51 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Andrew Dunstan <andrew@dunslane.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> Hmm, should the 'break's in the loop be 'continue's? If you're creating
> path a/b/c, and a concurrent process beats you but is only attempting to
> do a/b, then with the break you'll fail to create the final c.
Maybe I'm confused, but I think it's right as-is. The "break"s are
places where we're giving up and reporting a hard error. If we want
to continue to the next directory level, we just fall through ---
and doing that with "continue" would be wrong because it'd miss the
step at the bottom of the loop:
if (!last)
*p = '/';
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-19 14:01 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-06-19 15:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 15:40 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 11+ messages in thread
From: Tom Lane @ 2026-06-19 15:07 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Andrew Dunstan <andrew@dunslane.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Actually ... given this change, why don't we drop the initial stat()
call? Just try mkdir(), and move on if it succeeds. If not, but
there's already a directory there, we're good. That eliminates the
race condition without duplicating code.
regards, tom lane
Attachments:
v3-0001-Make-pg_mkdir_p-tolerant-of-a-concurrent-director.patch (text/x-diff, 1.7K) download
diff --git a/src/port/pgmkdirp.c b/src/port/pgmkdirp.c
index 7d7cea4dd0e..3e6b06fce79 100644
--- a/src/port/pgmkdirp.c
+++ b/src/port/pgmkdirp.c
@@ -56,7 +56,6 @@
int
pg_mkdir_p(char *path, int omode)
{
- struct stat sb;
mode_t numask,
oumask;
int last,
@@ -119,24 +118,46 @@ pg_mkdir_p(char *path, int omode)
if (last)
(void) umask(oumask);
- /* check for pre-existing directory */
- if (stat(path, &sb) == 0)
+ if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
{
- if (!S_ISDIR(sb.st_mode))
+ /*
+ * If we got EEXIST because there's already a directory there,
+ * don't complain.
+ */
+#ifndef WIN32
+ int save_errno = errno;
+ struct stat sb;
+
+ if (save_errno != EEXIST ||
+ stat(path, &sb) != 0 ||
+ !S_ISDIR(sb.st_mode))
{
- if (last)
- errno = EEXIST;
- else
- errno = ENOTDIR;
+ /* Don't let stat replace mkdir's errno */
+ errno = save_errno;
retval = -1;
break;
}
+#else /* WIN32 */
+ /*
+ * On Windows, stat() opens a handle and can transiently fail on a
+ * directory another process is concurrently creating. Probe with
+ * a path-based attribute query instead: it requests only
+ * FILE_READ_ATTRIBUTES and is exempt from share-mode denial, so
+ * it reliably sees a concurrently-created directory. We assume
+ * GetFileAttributes() won't change errno.
+ */
+ DWORD attr = GetFileAttributes(path);
+
+ if (errno != EEXIST ||
+ attr == INVALID_FILE_ATTRIBUTES ||
+ !(attr & FILE_ATTRIBUTE_DIRECTORY))
+ {
+ retval = -1;
+ break;
+ }
+#endif /* WIN32 */
}
- else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) < 0)
- {
- retval = -1;
- break;
- }
+
if (!last)
*p = '/';
}
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-19 14:01 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Álvaro Herrera <alvherre@kurilemu.de>
2026-06-19 15:07 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-06-19 15:40 ` Andrew Dunstan <andrew@dunslane.net>
2026-06-19 16:52 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Dunstan @ 2026-06-19 15:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Álvaro Herrera <alvherre@kurilemu.de>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2026-06-19 Fr 11:07 AM, Tom Lane wrote:
> Actually ... given this change, why don't we drop the initial stat()
> call? Just try mkdir(), and move on if it succeeds. If not, but
> there's already a directory there, we're good. That eliminates the
> race condition without duplicating code.
LGTM, thanks!
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-19 14:01 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Álvaro Herrera <alvherre@kurilemu.de>
2026-06-19 15:07 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 15:40 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
@ 2026-06-19 16:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 18:39 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2026-06-19 16:52 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Andrew Dunstan <andrew@dunslane.net> writes:
> LGTM, thanks!
OK, pushed.
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: fix pg_mkdir_p to tolerate concurrent directory creation
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-19 14:01 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Álvaro Herrera <alvherre@kurilemu.de>
2026-06-19 15:07 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 15:40 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-19 16:52 ` Re: fix pg_mkdir_p to tolerate concurrent directory creation Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-06-19 18:39 ` Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Dunstan @ 2026-06-19 18:39 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2026-06-19 Fr 12:52 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> LGTM, thanks!
> OK, pushed.
>
>
Thanks!
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2026-06-19 18:39 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-18 13:18 fix pg_mkdir_p to tolerate concurrent directory creation Andrew Dunstan <andrew@dunslane.net>
2026-06-18 14:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-18 15:37 ` Andrew Dunstan <andrew@dunslane.net>
2026-06-18 15:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-18 16:56 ` Andrew Dunstan <andrew@dunslane.net>
2026-06-19 14:01 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-06-19 14:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 15:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 15:40 ` Andrew Dunstan <andrew@dunslane.net>
2026-06-19 16:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-06-19 18:39 ` Andrew Dunstan <andrew@dunslane.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox