agora inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Disable background workers during servers start in pg_upgrade
30+ messages / 7 participants
[nested] [flat]
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade
@ 2021-01-20 16:25 Denis Laxalde <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw)
We disable shared_preload_libraries to prevent background workers to
initialize and start during server start in pg_upgrade.
In essence, this is for a similar reason that we use a restricted socket
access from f763b77193b04eba03a1f4ce46df34dc0348419e because background
workers may produce undesired activities during the upgrade.
Author: Denis Laxalde <[email protected]>
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>
---
src/bin/pg_upgrade/server.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c
index 31b1425202..fab95a2d24 100644
--- a/src/bin/pg_upgrade/server.c
+++ b/src/bin/pg_upgrade/server.c
@@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error)
* crash, the new cluster has to be recreated anyway. fsync=off is a big
* win on ext4.
*
+ * Turn off background workers by emptying shared_preload_libraries.
+ *
* Force vacuum_defer_cleanup_age to 0 on the new cluster, so that
* vacuumdb --freeze actually freezes the tuples.
*/
snprintf(cmd, sizeof(cmd),
- "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
+ "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
(cluster->controldata.cat_ver >=
BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" :
--
2.20.1
--lvvxlk2k67d5kdun--
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
@ 2023-07-06 12:24 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Gustafsson @ 2023-07-06 12:24 UTC (permalink / raw)
To: Nikolay Samokhvalov <[email protected]>; +Cc: Kyzer Davis (kydavis) <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
> On 22 Jun 2023, at 20:30, Nikolay Samokhvalov <[email protected]> wrote:
> Some small updates as I see them:
> - there is revision 7 now in https://github.com/ietf-wg-uuidrev/rfc4122bis
> - noticing that there is no commitfest record, I created one:
I will actually go ahead and close this entry in the current CF, not because we
don't want the feature but because it's unlikely that it will go in now given
that standardization is still underway. Comitting anything right now seems
premature, we might as well wait for standardization given that we have lots of
time before the v17 freeze.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
@ 2023-07-06 13:29 ` Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Matthias van de Meent @ 2023-07-06 13:29 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
On Thu, 6 Jul 2023 at 14:24, Daniel Gustafsson <[email protected]> wrote:
>
> > On 22 Jun 2023, at 20:30, Nikolay Samokhvalov <[email protected]> wrote:
>
> > Some small updates as I see them:
> > - there is revision 7 now in https://github.com/ietf-wg-uuidrev/rfc4122bis
> > - noticing that there is no commitfest record, I created one:
>
> I will actually go ahead and close this entry in the current CF, not because we
> don't want the feature but because it's unlikely that it will go in now given
> that standardization is still underway. Comitting anything right now seems
> premature, we might as well wait for standardization given that we have lots of
> time before the v17 freeze.
I'd like to note that this draft has recently had its last call
period, and has been proposed for publishing early last month. I don't
know how long this publishing process usually takes, but it seems like
the WG considers the text final, so unless this would take months I
wouldn't mind keeping this patch around as "waiting for external
process to complete". Sure, it's earlier than the actual release of
the standard, but that wasn't a blocker for SQL features that were
considered finalized either.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
@ 2023-07-06 13:43 ` Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Gustafsson @ 2023-07-06 13:43 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
> On 6 Jul 2023, at 15:29, Matthias van de Meent <[email protected]> wrote:
>
> On Thu, 6 Jul 2023 at 14:24, Daniel Gustafsson <[email protected]> wrote:
>>
>>> On 22 Jun 2023, at 20:30, Nikolay Samokhvalov <[email protected]> wrote:
>>
>>> Some small updates as I see them:
>>> - there is revision 7 now in https://github.com/ietf-wg-uuidrev/rfc4122bis
>>> - noticing that there is no commitfest record, I created one:
>>
>> I will actually go ahead and close this entry in the current CF, not because we
>> don't want the feature but because it's unlikely that it will go in now given
>> that standardization is still underway. Comitting anything right now seems
>> premature, we might as well wait for standardization given that we have lots of
>> time before the v17 freeze.
>
> I'd like to note that this draft has recently had its last call
> period, and has been proposed for publishing early last month.
Sure, but this document is in AD Evaluation and there are many stages left in
the IESG process, it may still take a fair bit of time before this is done.
> Sure, it's earlier than the actual release of
> the standard, but that wasn't a blocker for SQL features that were
> considered finalized either.
I can't speak for any SQL standard features we've committed before being
standardized, it's for sure not the norm for the project. I'm only commenting
on this particular Internet standard which we have plenty of time to commit
before v17 without rushing to beat a standards committee.
Also, if you look you can see that I moved it to the next CF in a vague hope
that standardization will be swift (which is admittedly never is).
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
@ 2023-07-06 14:02 ` Tom Lane <[email protected]>
2023-07-06 16:38 ` Re: UUID v7 Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Tom Lane @ 2023-07-06 14:02 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Matthias van de Meent <[email protected]>; Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
Daniel Gustafsson <[email protected]> writes:
> On 6 Jul 2023, at 15:29, Matthias van de Meent <[email protected]> wrote:
>> Sure, it's earlier than the actual release of
>> the standard, but that wasn't a blocker for SQL features that were
>> considered finalized either.
> I can't speak for any SQL standard features we've committed before being
> standardized, it's for sure not the norm for the project.
We have done a couple of things that way recently. An important
reason why we felt we could get away with that is that nowadays
we have people who actually sit on the SQL committee and have
reliable information on what's likely to make it into the final text
of the next version. I don't think we have equivalent visibility or
should have equivalent confidence about how UUID v7 standardization
will play out.
regards, tom lane
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
@ 2023-07-06 16:38 ` Peter Eisentraut <[email protected]>
2023-07-07 12:06 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Peter Eisentraut @ 2023-07-06 16:38 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; +Cc: Matthias van de Meent <[email protected]>; Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
On 06.07.23 16:02, Tom Lane wrote:
> Daniel Gustafsson <[email protected]> writes:
>> On 6 Jul 2023, at 15:29, Matthias van de Meent <[email protected]> wrote:
>>> Sure, it's earlier than the actual release of
>>> the standard, but that wasn't a blocker for SQL features that were
>>> considered finalized either.
>
>> I can't speak for any SQL standard features we've committed before being
>> standardized, it's for sure not the norm for the project.
>
> We have done a couple of things that way recently. An important
> reason why we felt we could get away with that is that nowadays
> we have people who actually sit on the SQL committee and have
> reliable information on what's likely to make it into the final text
> of the next version. I don't think we have equivalent visibility or
> should have equivalent confidence about how UUID v7 standardization
> will play out.
(I have been attending some meetings and I'm on the mailing list.)
Anyway, I think it would be reasonable to review this patch now. We
might leave it hanging in "Ready for Committer" for a while when we get
there. But surely review can start now.
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
2023-07-06 16:38 ` Re: UUID v7 Peter Eisentraut <[email protected]>
@ 2023-07-07 12:06 ` Andrey M. Borodin <[email protected]>
2023-07-07 13:31 ` RE: UUID v7 Kyzer Davis (kydavis) <[email protected]>
2023-07-10 16:50 ` Re: UUID v7 Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 30+ messages in thread
From: Andrey M. Borodin @ 2023-07-07 12:06 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Matthias van de Meent <[email protected]>; Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
> On 6 Jul 2023, at 21:38, Peter Eisentraut <[email protected]> wrote:
>
> I think it would be reasonable to review this patch now.
+1.
Also, I think we should discuss UUID v8. UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases. Revision 1 of IETF draft contained interesting code for v8: almost similar to v7, but with fields for "node ID" and "rolling sequence number".
I think this is reasonable approach, thus I attach implementation of UUID v8 per [0]. But from my point of view this implementation has some flaws.
These two new fields "node ID" and "sequence" are there not for uniqueness, but rather for data locality.
But they are placed at the end, in bytes 14 and 15, after randomly generated numbers.
I think that "sequence" is there to help generate local ascending identifiers when the real time clock do not provide enough resolution. So "sequence" field must be placed after 6 bytes of time-generated identifier.
On a contrary "node ID" must differentiate identifiers generated on different nodes. So it makes sense to place "node ID" before timing. So identifiers generated on different nodes will tend to be in different ranges.
Although, section "6.4. Distributed UUID Generation" states that "node ID" is there to decrease the likelihood of a collision. So my intuition might be wrong here.
Do we want to provide this "vendor-specific" UUID with tweaks for databases? Or should we limit the scope with well defined UUID v7?
Best regards, Andrey Borodin.
[0] https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis-01
Attachments:
[application/octet-stream] v2-0001-Implement-UUID-v7-and-v8-as-per-IETF-draft.patch (7.4K, ../../[email protected]/2-v2-0001-Implement-UUID-v7-and-v8-as-per-IETF-draft.patch)
download | inline diff:
From 9f4c97a81aae3087581a024374a06e49156f2689 Mon Sep 17 00:00:00 2001
From: Andrey Borodin <[email protected]>
Date: Fri, 10 Feb 2023 15:38:40 -0800
Subject: [PATCH v2] Implement UUID v7 and v8 as per IETF draft
---
doc/src/sgml/func.sgml | 18 ++++-
src/backend/utils/adt/uuid.c | 87 ++++++++++++++++++++++++
src/include/catalog/pg_proc.dat | 6 ++
src/test/regress/expected/opr_sanity.out | 2 +
src/test/regress/expected/uuid.out | 20 ++++++
src/test/regress/sql/uuid.sql | 12 ++++
6 files changed, 144 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5a47ce4343..b8b5ee210a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -13947,13 +13947,29 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
<primary>gen_random_uuid</primary>
</indexterm>
+ <indexterm>
+ <primary>gen_uuid_v7</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>gen_uuid_v8</primary>
+ </indexterm>
+
<para>
- <productname>PostgreSQL</productname> includes one function to generate a UUID:
+ <productname>PostgreSQL</productname> includes three functions to generate a UUID:
<synopsis>
<function>gen_random_uuid</function> () <returnvalue>uuid</returnvalue>
</synopsis>
This function returns a version 4 (random) UUID. This is the most commonly
used type of UUID and is appropriate for most applications.
+<synopsis>
+<function>gen_uuid_v7</function> () <returnvalue>uuid</returnvalue>
+</synopsis>
+ This function returns a version 7 (time-ordered + random) UUID.
+<synopsis>
+<function>gen_uuid_v8</function> () <returnvalue>uuid</returnvalue>
+</synopsis>
+ This function returns a version 8 (time-ordered + random + node ID + rolling sequence number) UUID.
</para>
<para>
diff --git a/src/backend/utils/adt/uuid.c b/src/backend/utils/adt/uuid.c
index 4f7aa768fd..44deead6b1 100644
--- a/src/backend/utils/adt/uuid.c
+++ b/src/backend/utils/adt/uuid.c
@@ -13,6 +13,9 @@
#include "postgres.h"
+#include <sys/time.h>
+
+#include "access/xlog.h"
#include "common/hashfn.h"
#include "lib/hyperloglog.h"
#include "libpq/pqformat.h"
@@ -421,3 +424,87 @@ gen_random_uuid(PG_FUNCTION_ARGS)
PG_RETURN_UUID_P(uuid);
}
+
+Datum
+gen_uuid_v7(PG_FUNCTION_ARGS)
+{
+ pg_uuid_t *uuid = palloc(UUID_LEN);
+ struct timeval tp;
+ uint64_t tms;
+
+ gettimeofday(&tp, NULL);
+
+ tms = ((uint64_t)tp.tv_sec) * 1000;
+ tms += ((uint64_t)tp.tv_usec) / 1000;
+
+ tms = pg_hton64(tms<<16);
+
+ /* Fill in time part */
+ memcpy(&uuid->data[0], &tms, 6);
+
+ /* fill everything after the timestamp with random bytes */
+ if (!pg_strong_random(&uuid->data[6], UUID_LEN - 6))
+ ereport(ERROR,
+ (errcode(ERRCODE_INTERNAL_ERROR),
+ errmsg("could not generate random values")));
+
+ /*
+ * Set magic numbers for a "version 7" (pseudorandom) UUID, see
+ * http://tools.ietf.org/html/rfc ???
+ * https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format#name-creating-a-uuidv7-value
+ */
+ /* set version field, top four bits are 0, 1, 1, 1 */
+ uuid->data[6] = (uuid->data[6] & 0x0f) | 0x70;
+ /* set variant field, top two bits are 1, 0 */
+ uuid->data[8] = (uuid->data[8] & 0x3f) | 0x80;
+
+ PG_RETURN_UUID_P(uuid);
+}
+
+static uint8_t sequence_counter;
+
+Datum
+gen_uuid_v8(PG_FUNCTION_ARGS)
+{
+ pg_uuid_t *uuid = palloc(UUID_LEN);
+ struct timeval tp;
+ uint32_t t;
+ uint16_t ut;
+ uint8_t node_id = GetSystemIdentifier();
+ uint8_t sequence = sequence_counter++;
+
+ /*
+ TODO: Consider supplying node ID and rolling sequence number
+ if (PG_NARGS() >= 1)
+ node_id = PG_GETARG_CHAR(0);
+ if (PG_NARGS() >= 2)
+ node_id = PG_GETARG_CHAR(1);
+ */
+
+ gettimeofday(&tp, NULL);
+ t = tp.tv_sec - 1577836800;
+ t = pg_hton32(t);
+ memcpy(&uuid->data[0], &t, 4);
+
+ /* 16 bit subsecond fraction (~15 microsecond resolution) */
+ ut = ((uint64_t)tp.tv_usec << 16) / 1000000;
+ memcpy(&uuid->data[4], &ut, 2);
+
+ /* fill everything after the timestamp with random bytes */
+ if (!pg_strong_random(&uuid->data[6], UUID_LEN - 6))
+ ereport(ERROR,
+ (errcode(ERRCODE_INTERNAL_ERROR),
+ errmsg("could not generate random values")));
+
+ /*
+ * Set magic numbers for a "version 8" UID, see
+ * https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#name-creating-a-uuidv8-value
+ */
+ uuid->data[6] = (uuid->data[6] & 0x0f) | 0x80;
+ uuid->data[8] = (uuid->data[8] & 0x3f) | 0x80;
+
+ uuid->data[14] = node_id;
+ uuid->data[15] = sequence;
+
+ PG_RETURN_UUID_P(uuid);
+}
\ No newline at end of file
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 6996073989..0c82f9280f 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -9119,6 +9119,12 @@
{ oid => '3432', descr => 'generate random UUID',
proname => 'gen_random_uuid', proleakproof => 't', provolatile => 'v',
prorettype => 'uuid', proargtypes => '', prosrc => 'gen_random_uuid' },
+{ oid => '3813', descr => 'generate UUID version 7',
+ proname => 'gen_uuid_v7', proleakproof => 't', provolatile => 'v',
+ prorettype => 'uuid', proargtypes => '', prosrc => 'gen_uuid_v7' },
+{ oid => '3814', descr => 'generate UUID version 8',
+ proname => 'gen_uuid_v8', proleakproof => 't', provolatile => 'v',
+ prorettype => 'uuid', proargtypes => '', prosrc => 'gen_uuid_v8' },
# pg_lsn
{ oid => '3229', descr => 'I/O',
diff --git a/src/test/regress/expected/opr_sanity.out b/src/test/regress/expected/opr_sanity.out
index a1bdf2c0b5..1fb9c654d3 100644
--- a/src/test/regress/expected/opr_sanity.out
+++ b/src/test/regress/expected/opr_sanity.out
@@ -857,6 +857,8 @@ sha384(bytea)
sha512(bytea)
gen_random_uuid()
starts_with(text,text)
+gen_uuid_v7()
+gen_uuid_v8()
macaddr8_eq(macaddr8,macaddr8)
macaddr8_lt(macaddr8,macaddr8)
macaddr8_le(macaddr8,macaddr8)
diff --git a/src/test/regress/expected/uuid.out b/src/test/regress/expected/uuid.out
index 8e7f21910d..516d4998a7 100644
--- a/src/test/regress/expected/uuid.out
+++ b/src/test/regress/expected/uuid.out
@@ -168,5 +168,25 @@ SELECT count(DISTINCT guid_field) FROM guid1;
2
(1 row)
+-- generation test for v7
+TRUNCATE guid1;
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+SELECT count(DISTINCT guid_field) FROM guid1;
+ count
+-------
+ 2
+(1 row)
+
+-- generation test for v8
+TRUNCATE guid1;
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v8());
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v8());
+SELECT count(DISTINCT guid_field) FROM guid1;
+ count
+-------
+ 2
+(1 row)
+
-- clean up
DROP TABLE guid1, guid2 CASCADE;
diff --git a/src/test/regress/sql/uuid.sql b/src/test/regress/sql/uuid.sql
index 9a8f437c7d..0d6784e70b 100644
--- a/src/test/regress/sql/uuid.sql
+++ b/src/test/regress/sql/uuid.sql
@@ -85,5 +85,17 @@ INSERT INTO guid1 (guid_field) VALUES (gen_random_uuid());
INSERT INTO guid1 (guid_field) VALUES (gen_random_uuid());
SELECT count(DISTINCT guid_field) FROM guid1;
+-- generation test for v7
+TRUNCATE guid1;
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+SELECT count(DISTINCT guid_field) FROM guid1;
+
+-- generation test for v8
+TRUNCATE guid1;
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v8());
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v8());
+SELECT count(DISTINCT guid_field) FROM guid1;
+
-- clean up
DROP TABLE guid1, guid2 CASCADE;
--
2.37.1 (Apple Git-137.1)
^ permalink raw reply [nested|flat] 30+ messages in thread
* RE: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
2023-07-06 16:38 ` Re: UUID v7 Peter Eisentraut <[email protected]>
2023-07-07 12:06 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
@ 2023-07-07 13:31 ` Kyzer Davis (kydavis) <[email protected]>
1 sibling, 0 replies; 30+ messages in thread
From: Kyzer Davis (kydavis) @ 2023-07-07 13:31 UTC (permalink / raw)
To: Andrey M. Borodin <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Matthias van de Meent <[email protected]>; Nikolay Samokhvalov <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
------=_NextPart_000_009D_01D9B0B5.C12D7050
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Great discussions group,
> I think it would be reasonable to review this patch now.
I am happy to review the format and logic for any proposed v7 and/or v8
UUID. Just point me to a PR or some code review location.
> Distributed UUID Generation" states that "node ID" is there to decrease
> the likelihood of a collision.
Correct, node identifiers help provide some bit space that ensures no
collision in the event the stars align where two nodes create the exact
UUID.
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
2023-07-06 16:38 ` Re: UUID v7 Peter Eisentraut <[email protected]>
2023-07-07 12:06 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
@ 2023-07-10 16:50 ` Peter Eisentraut <[email protected]>
2023-07-30 10:08 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
1 sibling, 1 reply; 30+ messages in thread
From: Peter Eisentraut @ 2023-07-10 16:50 UTC (permalink / raw)
To: Andrey M. Borodin <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Matthias van de Meent <[email protected]>; Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>
On 07.07.23 14:06, Andrey M. Borodin wrote:
> Also, I think we should discuss UUID v8. UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases. Revision 1 of IETF draft contained interesting code for v8: almost similar to v7, but with fields for "node ID" and "rolling sequence number".
> I think this is reasonable approach, thus I attach implementation of UUID v8 per [0].
I suggest we keep this thread to v7, which has pretty straightforward
semantics for PostgreSQL. v8 by definition has many possible
implementations, so you're going to have to make pretty strong arguments
that yours is the best and only one, if you are going to claim the
gen_uuid_v8 function name.
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: UUID v7
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
2023-07-06 16:38 ` Re: UUID v7 Peter Eisentraut <[email protected]>
2023-07-07 12:06 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
2023-07-10 16:50 ` Re: UUID v7 Peter Eisentraut <[email protected]>
@ 2023-07-30 10:08 ` Andrey M. Borodin <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Andrey M. Borodin @ 2023-07-30 10:08 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Matthias van de Meent <[email protected]>; Nikolay Samokhvalov <[email protected]>; Kyzer Davis (kydavis) <[email protected]>; Andres Freund <[email protected]>; Andrey Borodin <[email protected]>; pgsql-hackers; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected]
> On 10 Jul 2023, at 21:50, Peter Eisentraut <[email protected]> wrote:
>
> I suggest we keep this thread to v7, which has pretty straightforward semantics for PostgreSQL. v8 by definition has many possible implementations, so you're going to have to make pretty strong arguments that yours is the best and only one, if you are going to claim the gen_uuid_v8 function name.
Thanks Peter, I'll follow this course of action.
After discussion on GitHub with Sergey Prokhorenko [0] I understood that counter is optional, but useful part of UUID v7. It actually promotes sortability of data generated at high speed.
The standard does not specify how big counter should be. PFA patch with 16 bit counter. Maybe it worth doing 18bit counter - it will save us one byte of PRNG data. Currently we only take 2 bits out of the whole random byte.
Best regards, Andrey Borodin.
[0] https://github.com/x4m/pg_uuid_next/issues/1#issuecomment-1657074776 <https://github.com/x4m/pg_uuid_next/issues/1#issuecomment-1657074776;
Attachments:
[application/octet-stream] v3-0001-Implement-UUID-v7-as-per-IETF-draft.patch (5.7K, ../../[email protected]/3-v3-0001-Implement-UUID-v7-as-per-IETF-draft.patch)
download | inline diff:
From 67f4202555d1c8cf3230235e134d070ddb82173c Mon Sep 17 00:00:00 2001
From: Andrey Borodin <[email protected]>
Date: Fri, 10 Feb 2023 15:38:40 -0800
Subject: [PATCH v3] Implement UUID v7 as per IETF draft
Authors: Andrey Borodin, Sergey Prokhorenko
---
doc/src/sgml/func.sgml | 10 ++++-
src/backend/utils/adt/uuid.c | 50 ++++++++++++++++++++++++
src/include/catalog/pg_proc.dat | 3 ++
src/test/regress/expected/opr_sanity.out | 1 +
src/test/regress/expected/uuid.out | 10 +++++
src/test/regress/sql/uuid.sql | 6 +++
6 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index be2f54c914..b2d89cf415 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -13947,13 +13947,21 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
<primary>gen_random_uuid</primary>
</indexterm>
+ <indexterm>
+ <primary>gen_uuid_v7</primary>
+ </indexterm>
+
<para>
- <productname>PostgreSQL</productname> includes one function to generate a UUID:
+ <productname>PostgreSQL</productname> includes three functions to generate a UUID:
<synopsis>
<function>gen_random_uuid</function> () <returnvalue>uuid</returnvalue>
</synopsis>
This function returns a version 4 (random) UUID. This is the most commonly
used type of UUID and is appropriate for most applications.
+<synopsis>
+<function>gen_uuid_v7</function> () <returnvalue>uuid</returnvalue>
+</synopsis>
+ This function returns a version 7 (time-ordered + random) UUID.
</para>
<para>
diff --git a/src/backend/utils/adt/uuid.c b/src/backend/utils/adt/uuid.c
index 4f7aa768fd..49f9c03995 100644
--- a/src/backend/utils/adt/uuid.c
+++ b/src/backend/utils/adt/uuid.c
@@ -13,6 +13,9 @@
#include "postgres.h"
+#include <sys/time.h>
+
+#include "access/xlog.h"
#include "common/hashfn.h"
#include "lib/hyperloglog.h"
#include "libpq/pqformat.h"
@@ -421,3 +424,50 @@ gen_random_uuid(PG_FUNCTION_ARGS)
PG_RETURN_UUID_P(uuid);
}
+
+static uint16_t sequence_counter;
+
+Datum
+gen_uuid_v7(PG_FUNCTION_ARGS)
+{
+ pg_uuid_t *uuid = palloc(UUID_LEN);
+ struct timeval tp;
+ uint64_t tms;
+ uint16_t local_counter = sequence_counter++;
+
+ gettimeofday(&tp, NULL);
+
+ tms = ((uint64_t)tp.tv_sec) * 1000;
+ tms += ((uint64_t)tp.tv_usec) / 1000;
+
+ tms = pg_hton64(tms<<16);
+
+ /* Fill in time part */
+ memcpy(&uuid->data[0], &tms, 6);
+
+
+ /* fill everything after the timestamp and counter with random bytes */
+ if (!pg_strong_random(&uuid->data[8], UUID_LEN - 8))
+ ereport(ERROR,
+ (errcode(ERRCODE_INTERNAL_ERROR),
+ errmsg("could not generate random values")));
+
+ /* most significant 4 bits of counter */
+ uuid->data[6] = (unsigned char)(local_counter>>12);
+ /* next 8 bits */
+ uuid->data[7] = (unsigned char)(local_counter>>4);
+ /* least significant 4 bits in a middle of a byte, leaving 2 bits of entropy */
+ uuid->data[8] = (unsigned char)(local_counter<<2);
+
+ /*
+ * Set magic numbers for a "version 7" (pseudorandom) UUID, see
+ * http://tools.ietf.org/html/rfc ???
+ * https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format#name-creating-a-uuidv7-value
+ */
+ /* set version field, top four bits are 0, 1, 1, 1 */
+ uuid->data[6] = (uuid->data[6] & 0x0f) | 0x70;
+ /* set variant field, top two bits are 1, 0 */
+ uuid->data[8] = (uuid->data[8] & 0x3f) | 0x80;
+
+ PG_RETURN_UUID_P(uuid);
+}
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 6996073989..b11e0382c0 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -9119,6 +9119,9 @@
{ oid => '3432', descr => 'generate random UUID',
proname => 'gen_random_uuid', proleakproof => 't', provolatile => 'v',
prorettype => 'uuid', proargtypes => '', prosrc => 'gen_random_uuid' },
+{ oid => '3813', descr => 'generate UUID version 7',
+ proname => 'gen_uuid_v7', proleakproof => 't', provolatile => 'v',
+ prorettype => 'uuid', proargtypes => '', prosrc => 'gen_uuid_v7' },
# pg_lsn
{ oid => '3229', descr => 'I/O',
diff --git a/src/test/regress/expected/opr_sanity.out b/src/test/regress/expected/opr_sanity.out
index a1bdf2c0b5..3141183b01 100644
--- a/src/test/regress/expected/opr_sanity.out
+++ b/src/test/regress/expected/opr_sanity.out
@@ -857,6 +857,7 @@ sha384(bytea)
sha512(bytea)
gen_random_uuid()
starts_with(text,text)
+gen_uuid_v7()
macaddr8_eq(macaddr8,macaddr8)
macaddr8_lt(macaddr8,macaddr8)
macaddr8_le(macaddr8,macaddr8)
diff --git a/src/test/regress/expected/uuid.out b/src/test/regress/expected/uuid.out
index 8e7f21910d..fc9f50e69e 100644
--- a/src/test/regress/expected/uuid.out
+++ b/src/test/regress/expected/uuid.out
@@ -168,5 +168,15 @@ SELECT count(DISTINCT guid_field) FROM guid1;
2
(1 row)
+-- generation test for v7
+TRUNCATE guid1;
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+SELECT count(DISTINCT guid_field) FROM guid1;
+ count
+-------
+ 2
+(1 row)
+
-- clean up
DROP TABLE guid1, guid2 CASCADE;
diff --git a/src/test/regress/sql/uuid.sql b/src/test/regress/sql/uuid.sql
index 9a8f437c7d..02b8e7f10c 100644
--- a/src/test/regress/sql/uuid.sql
+++ b/src/test/regress/sql/uuid.sql
@@ -85,5 +85,11 @@ INSERT INTO guid1 (guid_field) VALUES (gen_random_uuid());
INSERT INTO guid1 (guid_field) VALUES (gen_random_uuid());
SELECT count(DISTINCT guid_field) FROM guid1;
+-- generation test for v7
+TRUNCATE guid1;
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+INSERT INTO guid1 (guid_field) VALUES (gen_uuid_v7());
+SELECT count(DISTINCT guid_field) FROM guid1;
+
-- clean up
DROP TABLE guid1, guid2 CASCADE;
--
2.37.1 (Apple Git-137.1)
^ permalink raw reply [nested|flat] 30+ messages in thread
end of thread, other threads:[~2023-07-30 10:08 UTC | newest]
Thread overview: 30+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]>
2023-07-06 12:24 Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 13:29 ` Re: UUID v7 Matthias van de Meent <[email protected]>
2023-07-06 13:43 ` Re: UUID v7 Daniel Gustafsson <[email protected]>
2023-07-06 14:02 ` Re: UUID v7 Tom Lane <[email protected]>
2023-07-06 16:38 ` Re: UUID v7 Peter Eisentraut <[email protected]>
2023-07-07 12:06 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
2023-07-07 13:31 ` RE: UUID v7 Kyzer Davis (kydavis) <[email protected]>
2023-07-10 16:50 ` Re: UUID v7 Peter Eisentraut <[email protected]>
2023-07-30 10:08 ` Re: UUID v7 Andrey M. Borodin <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox