agora inbox for [email protected]
help / color / mirror / Atom feed[PATCH v56 6/6] Exclude pg_stat directory from base backup
250+ messages / 8 participants
[nested] [flat]
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v39 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Tue_Oct__6_10_06_44_2020_382)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v44 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 2b2761a588..eaf4448943 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Mon_Dec_21_17_16_20_2020_608)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v41 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Fri_Nov__6_09_27_56_2020_738)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v40 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Wed_Nov__4_17_39_10_2020_208)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v57 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 84b22f4ac9..a2c88bd3a4 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Mar_18_16_56_02_2021_947)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v43 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 2b2761a588..eaf4448943 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Dec_11_16_50_03_2020_915)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v42 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Wed_Nov_11_10_07_22_2020_796)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v38 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Thu_Oct__1_09_07_22_2020_252)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v57 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 84b22f4ac9..a2c88bd3a4 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Mar_18_16_56_02_2021_947)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: Add LSN <-> time conversion functionality
@ 2024-02-16 20:41 Tomas Vondra <[email protected]>
2024-02-22 02:45 ` Re: Add LSN <-> time conversion functionality Melanie Plageman <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tomas Vondra @ 2024-02-16 20:41 UTC (permalink / raw)
To: Melanie Plageman <[email protected]>; pgsql-hackers; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; Daniel Gustafsson <[email protected]>
Hi,
I took a look at this today, to try to understand the purpose and how it
works. Let me share some initial thoughts and questions I have. Some of
this may be wrong/missing the point, so apologies for that.
The goal seems worthwhile in general - the way I understand it, the
patch aims to provide tracking of WAL "velocity", i.e. how much WAL was
generated over time. Which we now don't have, as we only maintain simple
cumulative stats/counters. And then uses it to estimate timestamp for a
given LSN, and vice versa, because that's what the pruning patch needs.
When I first read this, I immediately started wondering if this might
use the commit timestamp stuff we already have. Because for each commit
we already store the LSN and commit timestamp, right? But I'm not sure
that would be a good match - the commit_ts serves a very special purpose
of mapping XID => (LSN, timestamp), I don't see how to make it work for
(LSN=>timestmap) and (timestamp=>LSN) very easily.
As for the inner workings of the patch, my understanding is this:
- "LSNTimeline" consists of "LSNTime" entries representing (LSN,ts)
points, but those points are really "buckets" that grow larger and
larger for older periods of time.
- The entries are being added from bgwriter, i.e. on each loop we add
the current (LSN, timestamp) into the timeline.
- We then estimate LSN/timestamp using the data stored in LSNTimeline
(either LSN => timestamp, or the opposite direction).
Some comments in arbitrary order:
- AFAIK each entry represent an interval of time, and the next (older)
interval is twice as long, right? So the first interval is 1 second,
then 2 seconds, 4 seconds, 8 seconds, ...
- But I don't understand how the LSNTimeline entries are "aging" and get
less accurate, while the "current" bucket is short. lsntime_insert()
seems to simply move to the next entry, but doesn't that mean we insert
the entries into larger and larger buckets?
- The comments never really spell what amount of time the entries cover
/ how granular it is. My understanding is it's simply measured in number
of entries added, which is assumed to be constant and drive by
bgwriter_delay, right? Which is 200ms by default. Which seems fine, but
isn't the hibernation (HIBERNATE_FACTOR) going to mess with it?
Is there some case where bgwriter would just loop without sleeping,
filling the timeline much faster? (I can't think of any, but ...)
- The LSNTimeline comment claims an array of size 64 is large enough to
not need to care about filling it, but maybe it should briefly explain
why we can never fill it (I guess 2^64 is just too many).
- I don't quite understand why 0005 adds the functions to pageinspect.
This has nothing to do with pages, right?
- Not sure why we need 0001. Just so that the "estimate" functions in
0002 have a convenient "start" point? Surely we could look at the
current LSNTimeline data and use the oldest value, or (if there's no
data) use the current timestamp/LSN?
- I wonder what happens if we lose the data - we know that if people
reset statistics for whatever reason (or just lose them because of a
crash, or because they're on a replica), bad things happen to
autovacuum. What's the (expected) impact on pruning?
- What about a SRF function that outputs the whole LSNTimeline? Would be
useful for debugging / development, I think. (Just a suggestion).
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: Add LSN <-> time conversion functionality
2024-02-16 20:41 Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
@ 2024-02-22 02:45 ` Melanie Plageman <[email protected]>
2024-03-18 14:02 ` Re: Add LSN <-> time conversion functionality Daniel Gustafsson <[email protected]>
2024-03-18 17:29 ` Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
0 siblings, 2 replies; 250+ messages in thread
From: Melanie Plageman @ 2024-02-22 02:45 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Daniel Gustafsson <[email protected]>
Thanks so much for reviewing!
On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
<[email protected]> wrote:
>
> When I first read this, I immediately started wondering if this might
> use the commit timestamp stuff we already have. Because for each commit
> we already store the LSN and commit timestamp, right? But I'm not sure
> that would be a good match - the commit_ts serves a very special purpose
> of mapping XID => (LSN, timestamp), I don't see how to make it work for
> (LSN=>timestmap) and (timestamp=>LSN) very easily.
I took a look at the code in commit_ts.c, and I really don't see a way
of reusing any of this commit<->timestamp infrastructure for
timestamp<->LSN mappings.
> As for the inner workings of the patch, my understanding is this:
>
> - "LSNTimeline" consists of "LSNTime" entries representing (LSN,ts)
> points, but those points are really "buckets" that grow larger and
> larger for older periods of time.
Yes, they are buckets in the sense that they represent multiple values
but each contains a single LSNTime value which is the minimum of all
the LSNTimes we "merged" into that single array element. In order to
represent a range of time, you need to use two array elements. The
linear interpolation from time <-> LSN is all done with two elements.
> - AFAIK each entry represent an interval of time, and the next (older)
> interval is twice as long, right? So the first interval is 1 second,
> then 2 seconds, 4 seconds, 8 seconds, ...
>
> - But I don't understand how the LSNTimeline entries are "aging" and get
> less accurate, while the "current" bucket is short. lsntime_insert()
> seems to simply move to the next entry, but doesn't that mean we insert
> the entries into larger and larger buckets?
Because the earlier array elements can represent fewer logical members
than later ones and because elements are merged into the next element
when space runs out, later array elements will contain older data and
more of it, so those "ranges" will be larger. But, after thinking
about it and also reading your feedback, I realized my algorithm was
silly because it starts merging logical members before it has even
used the whole array.
The attached v3 has a new algorithm. Now, LSNTimes are added from the
end of the array forward until all array elements have at least one
logical member (array length == volume). Once array length == volume,
new LSNTimes will result in merging logical members in existing
elements. We want to merge older members because those can be less
precise. So, the number of logical members per array element will
always monotonically increase starting from the beginning of the array
(which contains the most recent data) and going to the end. We want to
use all the available space in the array. That means that each LSNTime
insertion will always result in a single merge. We want the timeline
to be inclusive of the oldest data, so merging means taking the
smaller value of two LSNTime values. I had to pick a rule for choosing
which elements to merge. So, I choose the merge target as the oldest
element whose logical membership is < 2x its predecessor. I merge the
merge target's predecessor into the merge target. Then I move all of
the intervening elements down 1. Then I insert the new LSNTime at
index 0.
> - The comments never really spell what amount of time the entries cover
> / how granular it is. My understanding is it's simply measured in number
> of entries added, which is assumed to be constant and drive by
> bgwriter_delay, right? Which is 200ms by default. Which seems fine, but
> isn't the hibernation (HIBERNATE_FACTOR) going to mess with it?
>
> Is there some case where bgwriter would just loop without sleeping,
> filling the timeline much faster? (I can't think of any, but ...)
bgwriter will wake up when there are buffers to flush, which is likely
correlated with there being new LSNs. So, actually it seems like it
might work well to rely on only filling the timeline when there are
things for bgwriter to do.
> - The LSNTimeline comment claims an array of size 64 is large enough to
> not need to care about filling it, but maybe it should briefly explain
> why we can never fill it (I guess 2^64 is just too many).
The new structure fits a different number of members. I have yet to
calculate that number, but it should be explained in the comments once
I do.
For example, if we made an LSNTimeline with volume 4, once every
element had one LSNTime and we needed to start merging, the following
is how many logical members each element would have after each of four
merges:
1111
1112
1122
1114
1124
So, if we store the number of members as an unsigned 64-bit int and we
have an LSNTimeline with volume 64, what is the maximum number of
members can we store if we hold all of the invariants described in my
algorithm above (we only merge when required, every element holds < 2x
the number of logical members as its predecessor, we do exactly one
merge every insertion [when required], membership must monotonically
increase [choose the oldest element meeting the criteria when deciding
what to merge])?
> - I don't quite understand why 0005 adds the functions to pageinspect.
> This has nothing to do with pages, right?
You're right. I just couldn't think of a good place to put the
functions. In version 3, I just put the SQL functions in pgstat_wal.c
and made them generally available (i.e. not in a contrib module). I
haven't added docs back yet. But perhaps a section near the docs
describing pg_xact_commit_timestamp() [1]? I wasn't sure if I should
put the SQL function source code in pgstatfuncs.c -- I kind of prefer
it in pgstat_wal.c but there are no other SQL functions there.
> - Not sure why we need 0001. Just so that the "estimate" functions in
> 0002 have a convenient "start" point? Surely we could look at the
> current LSNTimeline data and use the oldest value, or (if there's no
> data) use the current timestamp/LSN?
When there are 0 or 1 entries in the timeline you'll get an answer
that could be very off if you just return the current timestamp or
LSN. I guess that is okay?
> - I wonder what happens if we lose the data - we know that if people
> reset statistics for whatever reason (or just lose them because of a
> crash, or because they're on a replica), bad things happen to
> autovacuum. What's the (expected) impact on pruning?
This is an important question. Because stats aren't crashsafe, we
could return very inaccurate numbers for some time/LSN values if we
crash. I don't actually know what we could do about that. When I use
the LSNTimeline for the freeze heuristic it is less of an issue
because the freeze heuristic has a fallback strategy when there aren't
enough stats to do its calculations. But other users of this
LSNTimeline will simply get highly inaccurate results (I think?). Is
there anything we could do about this? It seems bad.
Andres had brought up something at some point about, what if the
database is simply turned off for awhile and then turned back on. Even
if you cleanly shut down, will there be "gaps" in the timeline? I
think that could be okay, but it is something to think about.
> - What about a SRF function that outputs the whole LSNTimeline? Would be
> useful for debugging / development, I think. (Just a suggestion).
Good idea! I've added this. Though, maybe there was a simpler way to
implement than I did.
Just a note, all of my comments could use a lot of work, but I want to
get consensus on the algorithm before I make sure and write about it
in a perfect way.
- Melanie
[1] https://www.postgresql.org/docs/devel/functions-info.html#FUNCTIONS-INFO-COMMIT-TIMESTAMP
Attachments:
[text/x-patch] v3-0005-Add-time-LSN-translation-functions.patch (4.3K, ../../CAAKRu_bw7Pgw8Mi9LJrBkFvPPHgvVjPphrT8ugbzs-2V0f+1Rw@mail.gmail.com/2-v3-0005-Add-time-LSN-translation-functions.patch)
download | inline diff:
From cf9e6f507bc9781bf79e8c39766c8e84209d2ada Mon Sep 17 00:00:00 2001
From: Melanie Plageman <[email protected]>
Date: Wed, 21 Feb 2024 20:06:29 -0500
Subject: [PATCH v3 5/5] Add time <-> LSN translation functions
Previous commits added a global LSNTimeline, maintained by background
writer, that allows approximate translations between time and LSNs.
Add SQL-callable functions to convert from LSN to time and back and a
SQL-callable function returning the entire LSNTimeline.
This could be useful in combination with SQL-callable functions
accessing a page LSN to approximate the time of last modification of a
page or estimating the LSN consumption rate to moderate maintenance
processes and balance system resource utilization.
---
src/backend/utils/activity/pgstat_wal.c | 58 +++++++++++++++++++++++++
src/include/catalog/pg_proc.dat | 22 ++++++++++
2 files changed, 80 insertions(+)
diff --git a/src/backend/utils/activity/pgstat_wal.c b/src/backend/utils/activity/pgstat_wal.c
index df4c91ee3cf..27f2b23cd88 100644
--- a/src/backend/utils/activity/pgstat_wal.c
+++ b/src/backend/utils/activity/pgstat_wal.c
@@ -18,6 +18,7 @@
#include "postgres.h"
#include "access/xlog.h"
+#include "funcapi.h"
#include "utils/pgstat_internal.h"
#include "executor/instrument.h"
#include "utils/builtins.h"
@@ -418,3 +419,60 @@ pgstat_wal_update_lsntimeline(TimestampTz time, XLogRecPtr lsn)
lsntime_insert(&stats_shmem->stats.timeline, time, lsn);
LWLockRelease(&stats_shmem->lock);
}
+
+PG_FUNCTION_INFO_V1(pg_estimate_lsn_at_time);
+PG_FUNCTION_INFO_V1(pg_estimate_time_at_lsn);
+PG_FUNCTION_INFO_V1(pg_lsntimeline);
+
+Datum
+pg_estimate_time_at_lsn(PG_FUNCTION_ARGS)
+{
+ XLogRecPtr lsn = PG_GETARG_LSN(0);
+ PgStatShared_Wal *stats_shmem = &pgStatLocal.shmem->wal;
+ TimestampTz result;
+
+ LWLockAcquire(&stats_shmem->lock, LW_SHARED);
+ result = estimate_time_at_lsn(&stats_shmem->stats.timeline, lsn);
+ LWLockRelease(&stats_shmem->lock);
+
+ PG_RETURN_TIMESTAMPTZ(result);
+}
+
+Datum
+pg_estimate_lsn_at_time(PG_FUNCTION_ARGS)
+{
+ PgStatShared_Wal *stats_shmem = &pgStatLocal.shmem->wal;
+ TimestampTz time = PG_GETARG_TIMESTAMPTZ(0);
+ XLogRecPtr result;
+
+ LWLockAcquire(&stats_shmem->lock, LW_SHARED);
+ result = estimate_lsn_at_time(&stats_shmem->stats.timeline, time);
+ LWLockRelease(&stats_shmem->lock);
+
+ PG_RETURN_LSN(result);
+}
+
+Datum
+pg_lsntimeline(PG_FUNCTION_ARGS)
+{
+ ReturnSetInfo *rsinfo;
+ LSNTimeline *timeline;
+ PgStatShared_Wal *stats_shmem = &pgStatLocal.shmem->wal;
+
+ InitMaterializedSRF(fcinfo, 0);
+ rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
+ LWLockAcquire(&stats_shmem->lock, LW_SHARED);
+ timeline = &stats_shmem->stats.timeline;
+ for (int i = LSNTIMELINE_VOLUME - timeline->length; i < LSNTIMELINE_VOLUME; i++)
+ {
+ Datum values[2] = {0};
+ bool nulls[2] = {0};
+
+ values[0] = timeline->data[i].time;
+ values[1] = timeline->data[i].lsn;
+ tuplestore_putvalues(rsinfo->setResult, rsinfo->setDesc,
+ values, nulls);
+ }
+ LWLockRelease(&stats_shmem->lock);
+ return (Datum) 0;
+}
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 9c120fc2b7f..e69cf9c2437 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -6326,6 +6326,28 @@
prorettype => 'timestamptz', proargtypes => 'xid',
prosrc => 'pg_xact_commit_timestamp' },
+{ oid => '9997',
+ descr => 'get approximate LSN at a particular point in time',
+ proname => 'pg_estimate_lsn_at_time', provolatile => 'v',
+ prorettype => 'pg_lsn', proargtypes => 'timestamptz',
+ prosrc => 'pg_estimate_lsn_at_time' },
+
+{ oid => '9996',
+ descr => 'get approximate time at a particular LSN',
+ proname => 'pg_estimate_time_at_lsn', provolatile => 'v',
+ prorettype => 'timestamptz', proargtypes => 'pg_lsn',
+ prosrc => 'pg_estimate_time_at_lsn' },
+
+{ oid => '9994',
+ descr => 'print the LSN timeline',
+ proname => 'pg_lsntimeline', prorows => '64',
+ proretset => 't', provolatile => 'v', proparallel => 's',
+ prorettype => 'record', proargtypes => '',
+ proallargtypes => '{timestamptz,pg_lsn}',
+ proargmodes => '{o,o}',
+ proargnames => '{time, lsn}',
+ prosrc => 'pg_lsntimeline' },
+
{ oid => '6168',
descr => 'get commit timestamp and replication origin of a transaction',
proname => 'pg_xact_commit_timestamp_origin', provolatile => 'v',
--
2.37.2
[text/x-patch] v3-0003-Add-LSNTimeline-to-PgStat_WalStats.patch (1.8K, ../../CAAKRu_bw7Pgw8Mi9LJrBkFvPPHgvVjPphrT8ugbzs-2V0f+1Rw@mail.gmail.com/3-v3-0003-Add-LSNTimeline-to-PgStat_WalStats.patch)
download | inline diff:
From 6fd317a319de144a7a999fc6230268521e72a36f Mon Sep 17 00:00:00 2001
From: Melanie Plageman <[email protected]>
Date: Wed, 21 Feb 2024 20:28:27 -0500
Subject: [PATCH v3 3/5] Add LSNTimeline to PgStat_WalStats
Add a globally maintained instance of the new LSNTimeline to
PgStat_WalStats and a utility function to insert new values.
---
src/backend/utils/activity/pgstat_wal.c | 10 ++++++++++
src/include/pgstat.h | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/src/backend/utils/activity/pgstat_wal.c b/src/backend/utils/activity/pgstat_wal.c
index 96e84319f6f..df4c91ee3cf 100644
--- a/src/backend/utils/activity/pgstat_wal.c
+++ b/src/backend/utils/activity/pgstat_wal.c
@@ -408,3 +408,13 @@ stop:
result = (double) (lsn - start.lsn) / lsns_elapsed * time_elapsed + start.time;
return Max(result, 0);
}
+
+void
+pgstat_wal_update_lsntimeline(TimestampTz time, XLogRecPtr lsn)
+{
+ PgStatShared_Wal *stats_shmem = &pgStatLocal.shmem->wal;
+
+ LWLockAcquire(&stats_shmem->lock, LW_EXCLUSIVE);
+ lsntime_insert(&stats_shmem->stats.timeline, time, lsn);
+ LWLockRelease(&stats_shmem->lock);
+}
diff --git a/src/include/pgstat.h b/src/include/pgstat.h
index 1926ddb00ed..8a63f56fdd3 100644
--- a/src/include/pgstat.h
+++ b/src/include/pgstat.h
@@ -482,6 +482,7 @@ typedef struct PgStat_WalStats
PgStat_Counter wal_sync;
PgStat_Counter wal_write_time;
PgStat_Counter wal_sync_time;
+ LSNTimeline timeline;
TimestampTz stat_reset_timestamp;
} PgStat_WalStats;
@@ -764,6 +765,9 @@ extern void pgstat_execute_transactional_drops(int ndrops, struct xl_xact_stats_
extern void pgstat_report_wal(bool force);
extern PgStat_WalStats *pgstat_fetch_stat_wal(void);
+/* Helpers for maintaining the LSNTimeline */
+extern void pgstat_wal_update_lsntimeline(TimestampTz time, XLogRecPtr lsn);
+
/*
* Variables in pgstat.c
--
2.37.2
[text/x-patch] v3-0001-Record-LSN-at-postmaster-startup.patch (2.4K, ../../CAAKRu_bw7Pgw8Mi9LJrBkFvPPHgvVjPphrT8ugbzs-2V0f+1Rw@mail.gmail.com/4-v3-0001-Record-LSN-at-postmaster-startup.patch)
download | inline diff:
From 1348109617ce772835336ea8e8a9781407f6060d Mon Sep 17 00:00:00 2001
From: Melanie Plageman <[email protected]>
Date: Tue, 5 Dec 2023 07:29:39 -0500
Subject: [PATCH v3 1/5] Record LSN at postmaster startup
The insert_lsn at postmaster startup can be used along with PgStartTime
as seed values for a timeline mapping LSNs to time. Future commits will
add such a structure for LSN <-> time conversions. A start LSN allows
for such conversions before even inserting a value into the timeline.
The current time and current insert LSN can be used along with
PgStartTime and PgStartLSN.
This is WIP, as I'm not sure if I did this in the right place.
---
src/backend/access/transam/xlog.c | 2 ++
src/backend/postmaster/postmaster.c | 1 +
src/include/utils/builtins.h | 3 +++
3 files changed, 6 insertions(+)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index c1162d55bff..3fea9f4c31f 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -146,6 +146,8 @@ bool XLOG_DEBUG = false;
int wal_segment_size = DEFAULT_XLOG_SEG_SIZE;
+XLogRecPtr PgStartLSN = InvalidXLogRecPtr;
+
/*
* Number of WAL insertion locks to use. A higher value allows more insertions
* to happen concurrently, but adds some CPU overhead to flushing the WAL,
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index df945a5ac4d..9e5cad60549 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -1440,6 +1440,7 @@ PostmasterMain(int argc, char *argv[])
* Remember postmaster startup time
*/
PgStartTime = GetCurrentTimestamp();
+ PgStartLSN = GetXLogInsertRecPtr();
/*
* Report postmaster status in the postmaster.pid file, to allow pg_ctl to
diff --git a/src/include/utils/builtins.h b/src/include/utils/builtins.h
index 359c570f23e..16a7a058bc7 100644
--- a/src/include/utils/builtins.h
+++ b/src/include/utils/builtins.h
@@ -17,6 +17,7 @@
#include "fmgr.h"
#include "nodes/nodes.h"
#include "utils/fmgrprotos.h"
+#include "access/xlogdefs.h"
/* Sign + the most decimal digits an 8-byte number could have */
#define MAXINT8LEN 20
@@ -85,6 +86,8 @@ extern void generate_operator_clause(fmStringInfo buf,
Oid opoid,
const char *rightop, Oid rightoptype);
+extern PGDLLIMPORT XLogRecPtr PgStartLSN;
+
/* varchar.c */
extern int bpchartruelen(char *s, int len);
--
2.37.2
[text/x-patch] v3-0004-Bgwriter-maintains-global-LSNTimeline.patch (1.3K, ../../CAAKRu_bw7Pgw8Mi9LJrBkFvPPHgvVjPphrT8ugbzs-2V0f+1Rw@mail.gmail.com/5-v3-0004-Bgwriter-maintains-global-LSNTimeline.patch)
download | inline diff:
From 6204555c6d59035cba9f850c676d0b1f530c6f43 Mon Sep 17 00:00:00 2001
From: Melanie Plageman <[email protected]>
Date: Wed, 27 Dec 2023 16:32:40 -0500
Subject: [PATCH v3 4/5] Bgwriter maintains global LSNTimeline
Insert new LSN, time pairs to the global LSNTimeline stored in
PgStat_WalStats in the background writer's main loop. This ensures that
new values are added to the timeline in a regular manner.
---
src/backend/postmaster/bgwriter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 6364b16261f..4b4d5db60bb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -272,6 +272,7 @@ BackgroundWriterMain(void)
{
TimestampTz timeout = 0;
TimestampTz now = GetCurrentTimestamp();
+ XLogRecPtr current_lsn = GetLastImportantRecPtr();
timeout = TimestampTzPlusMilliseconds(last_snapshot_ts,
LOG_SNAPSHOT_INTERVAL_MS);
@@ -284,10 +285,11 @@ BackgroundWriterMain(void)
* the end of the record.
*/
if (now >= timeout &&
- last_snapshot_lsn <= GetLastImportantRecPtr())
+ last_snapshot_lsn <= current_lsn)
{
last_snapshot_lsn = LogStandbySnapshot();
last_snapshot_ts = now;
+ pgstat_wal_update_lsntimeline(now, current_lsn);
}
}
--
2.37.2
[text/x-patch] v3-0002-Add-LSNTimeline-for-converting-LSN-time.patch (10.5K, ../../CAAKRu_bw7Pgw8Mi9LJrBkFvPPHgvVjPphrT8ugbzs-2V0f+1Rw@mail.gmail.com/6-v3-0002-Add-LSNTimeline-for-converting-LSN-time.patch)
download | inline diff:
From 800b0610f430f965e9216a374afe638bbec7bb6f Mon Sep 17 00:00:00 2001
From: Melanie Plageman <[email protected]>
Date: Wed, 27 Dec 2023 16:40:27 -0500
Subject: [PATCH v3 2/5] Add LSNTimeline for converting LSN <-> time
Add a new structure, LSNTimeline, consisting of LSNTimes -- each an LSN,
time pair. Each LSNTime can represent multiple logical LSN, time pairs,
referred to as members. LSN <-> time conversions can be done using
linear interpolation with two LSNTimes on the LSNTimeline.
This commit does not add a global instance of LSNTimeline. It adds the
structures and functions needed to maintain and access such a timeline.
---
src/backend/utils/activity/pgstat_wal.c | 224 ++++++++++++++++++++++++
src/include/pgstat.h | 44 +++++
src/tools/pgindent/typedefs.list | 2 +
3 files changed, 270 insertions(+)
diff --git a/src/backend/utils/activity/pgstat_wal.c b/src/backend/utils/activity/pgstat_wal.c
index 1a3c0e1a669..96e84319f6f 100644
--- a/src/backend/utils/activity/pgstat_wal.c
+++ b/src/backend/utils/activity/pgstat_wal.c
@@ -17,8 +17,12 @@
#include "postgres.h"
+#include "access/xlog.h"
#include "utils/pgstat_internal.h"
#include "executor/instrument.h"
+#include "utils/builtins.h"
+#include "utils/timestamp.h"
+#include "utils/pg_lsn.h"
PgStat_PendingWalStats PendingWalStats = {0};
@@ -32,6 +36,12 @@ PgStat_PendingWalStats PendingWalStats = {0};
static WalUsage prevWalUsage;
+static void lsntime_merge(LSNTime *target, LSNTime *src);
+static void lsntime_insert(LSNTimeline *timeline, TimestampTz time, XLogRecPtr lsn);
+
+XLogRecPtr estimate_lsn_at_time(const LSNTimeline *timeline, TimestampTz time);
+TimestampTz estimate_time_at_lsn(const LSNTimeline *timeline, XLogRecPtr lsn);
+
/*
* Calculate how much WAL usage counters have increased and update
* shared WAL and IO statistics.
@@ -184,3 +194,217 @@ pgstat_wal_snapshot_cb(void)
sizeof(pgStatLocal.snapshot.wal));
LWLockRelease(&stats_shmem->lock);
}
+
+/*
+ * Set *target to be the earlier of *target or *src.
+ */
+static void
+lsntime_merge(LSNTime *target, LSNTime *src)
+{
+ LSNTime result;
+ uint64 new_members = target->members + src->members;
+
+ if (target->time < src->time)
+ result = *target;
+ else if (src->time < target->time)
+ result = *src;
+ else if (target->lsn < src->lsn)
+ result = *target;
+ else if (src->lsn < target->lsn)
+ result = *src;
+ else
+ result = *target;
+
+ *target = result;
+ target->members = new_members;
+ src->members = 1;
+}
+
+static int
+lsntime_merge_target(LSNTimeline *timeline)
+{
+ /* Don't merge if free space available */
+ Assert(timeline->length == LSNTIMELINE_VOLUME);
+
+ for (int i = timeline->length; i-- > 0;)
+ {
+ /*
+ * An array element can represent up to twice the number of members
+ * represented by the preceding array element.
+ */
+ if (timeline->data[i].members < (2 * timeline->data[i - 1].members))
+ return i;
+ }
+
+ /* Should not be reachable or we are out of space */
+ Assert(false);
+}
+
+/*
+ * Insert a new LSNTime into the LSNTimeline in the first available element,
+ * or, if there are no empty elements, insert it into the element at index 0,
+ * merge the logical members of two old buckets and move the intervening
+ * elements down by one.
+ */
+void
+lsntime_insert(LSNTimeline *timeline, TimestampTz time,
+ XLogRecPtr lsn)
+{
+ int merge_target;
+ LSNTime entrant = {.lsn = lsn,.time = time,.members = 1};
+
+ if (timeline->length < LSNTIMELINE_VOLUME)
+ {
+ /*
+ * The new entry should exceed the most recent entry to ensure time
+ * moves forward on the timeline.
+ */
+ Assert(timeline->length == 0 ||
+ (lsn >= timeline->data[LSNTIMELINE_VOLUME - timeline->length].lsn &&
+ time >= timeline->data[LSNTIMELINE_VOLUME - timeline->length].time));
+
+ /*
+ * If there are unfilled elements in the timeline, then insert the
+ * passed-in LSNTime into the tail of the array.
+ */
+ timeline->length++;
+ timeline->data[LSNTIMELINE_VOLUME - timeline->length] = entrant;
+ return;
+ }
+
+ /*
+ * If all elements in the timeline represent at least one member, merge
+ * the oldest element whose membership is < 2x its predecessor with its
+ * preceding member. Then shift all elements preceding these two elements
+ * down by one and insert the passed-in LSNTime at array index 0.
+ */
+ merge_target = lsntime_merge_target(timeline);
+ Assert(merge_target >= 0 && merge_target < timeline->length);
+ lsntime_merge(&timeline->data[merge_target], &timeline->data[merge_target - 1]);
+ memmove(&timeline->data[1], &timeline->data[0], sizeof(LSNTime) * merge_target - 1);
+ timeline->data[0] = entrant;
+}
+
+/*
+ * Translate time to a LSN using the provided timeline. The timeline will not
+ * be modified.
+ */
+XLogRecPtr
+estimate_lsn_at_time(const LSNTimeline *timeline, TimestampTz time)
+{
+ XLogRecPtr result;
+ int64 time_elapsed,
+ lsns_elapsed;
+ LSNTime start = {.time = PgStartTime,.lsn = PgStartLSN};
+ LSNTime end = {.time = GetCurrentTimestamp(),.lsn = GetXLogInsertRecPtr()};
+
+ /*
+ * If the provided time is before DB startup, the best we can do is return
+ * the start LSN.
+ */
+ if (time < start.time)
+ return start.lsn;
+
+ /*
+ * If the provided time is after now, the current LSN is our best
+ * estimate.
+ */
+ if (time >= end.time)
+ return end.lsn;
+
+ /*
+ * Loop through the timeline. Stop at the first LSNTime earlier than our
+ * target time. This LSNTime will be our interpolation start point. If
+ * there's an LSNTime later than that, then that will be our interpolation
+ * end point.
+ */
+ for (int i = LSNTIMELINE_VOLUME - timeline->length; i < LSNTIMELINE_VOLUME; i++)
+ {
+ if (timeline->data[i].time > time)
+ continue;
+
+ start = timeline->data[i];
+ if (i > 0)
+ end = timeline->data[i - 1];
+ goto stop;
+ }
+
+ /*
+ * If we exhausted the timeline, then use its earliest LSNTime as our
+ * interpolation end point.
+ */
+ if (timeline->length > 0)
+ end = timeline->data[timeline->length - 1];
+
+stop:
+ Assert(end.time > start.time);
+ Assert(end.lsn > start.lsn);
+ time_elapsed = end.time - start.time;
+ Assert(time_elapsed != 0);
+ lsns_elapsed = end.lsn - start.lsn;
+ Assert(lsns_elapsed != 0);
+ result = (double) (time - start.time) / time_elapsed * lsns_elapsed + start.lsn;
+ return Max(result, 0);
+}
+
+/*
+ * Translate lsn to a time using the provided timeline. The timeline will not
+ * be modified.
+ */
+TimestampTz
+estimate_time_at_lsn(const LSNTimeline *timeline, XLogRecPtr lsn)
+{
+ int64 time_elapsed,
+ lsns_elapsed;
+ TimestampTz result;
+ LSNTime start = {.time = PgStartTime,.lsn = PgStartLSN};
+ LSNTime end = {.time = GetCurrentTimestamp(),.lsn = GetXLogInsertRecPtr()};
+
+ /*
+ * If the LSN is before DB startup, the best we can do is return that
+ * time.
+ */
+ if (lsn <= start.lsn)
+ return start.time;
+
+ /*
+ * If the target LSN is after the current insert LSN, the current time is
+ * our best estimate.
+ */
+ if (lsn >= end.lsn)
+ return end.time;
+
+ /*
+ * Loop through the timeline. Stop at the first LSNTime earlier than our
+ * target LSN. This LSNTime will be our interpolation start point. If
+ * there's an LSNTime later than that, then that will be our interpolation
+ * end point.
+ */
+ for (int i = LSNTIMELINE_VOLUME - timeline->length; i < LSNTIMELINE_VOLUME; i++)
+ {
+ if (timeline->data[i].lsn > lsn)
+ continue;
+
+ start = timeline->data[i];
+ if (i > 0)
+ end = timeline->data[i - 1];
+ goto stop;
+ }
+
+ /*
+ * If we exhausted the timeline, then use its earliest LSNTime as our
+ * interpolation end point.
+ */
+ if (timeline->length > 0)
+ end = timeline->data[timeline->length - 1];
+
+stop:
+ Assert(end.time > start.time);
+ Assert(end.lsn > start.lsn);
+ time_elapsed = end.time - start.time;
+ Assert(time_elapsed != 0);
+ lsns_elapsed = end.lsn - start.lsn;
+ Assert(lsns_elapsed != 0);
+ result = (double) (lsn - start.lsn) / lsns_elapsed * time_elapsed + start.time;
+ return Max(result, 0);
+}
diff --git a/src/include/pgstat.h b/src/include/pgstat.h
index 2136239710e..1926ddb00ed 100644
--- a/src/include/pgstat.h
+++ b/src/include/pgstat.h
@@ -11,6 +11,7 @@
#ifndef PGSTAT_H
#define PGSTAT_H
+#include "access/xlogdefs.h"
#include "datatype/timestamp.h"
#include "portability/instr_time.h"
#include "postmaster/pgarch.h" /* for MAX_XFN_CHARS */
@@ -428,6 +429,49 @@ typedef struct PgStat_StatTabEntry
PgStat_Counter autoanalyze_count;
} PgStat_StatTabEntry;
+/*
+ * The elements of an LSNTimeline. Each LSNTime represents one or more time,
+ * LSN pairs. The LSN is typically the insert LSN recorded at the time. Members
+ * is the number of logical members -- each a time, LSN pair -- represented in
+ * the LSNTime.
+ */
+typedef struct LSNTime
+{
+ TimestampTz time;
+ XLogRecPtr lsn;
+ uint64 members;
+} LSNTime;
+
+#define LSNTIMELINE_VOLUME 64
+/*
+ * A timeline consists of LSNTimes from most to least recent. The array is
+ * filled from end to start before the contents of any elements are merged.
+ * Once the LSNTimeline length == volume (the array is full), old elements are
+ * merged to make space for new elements at index 0. When merging logical
+ * members, each element of the array in the timeline may represent twice as
+ * many logical members as the preceding element.
+ *
+ * This gives more recent times greater precision than less recent ones. An
+ * array of size 64 and an unsigned 64-bit number for the number of members
+ * should provide sufficient capacity without accounting for what to do when
+ * all elements of the array are at capacity.
+ *
+ * After every element has at least one logical member, when a new LSNTime is
+ * inserted, the oldest array element whose logical membership is < 2x its
+ * predecessor is the merge target. Its preceding element is merged into it.
+ * Then all of the intervening elements are moved down by one and the new
+ * LSNTime is inserted at index 0.
+ *
+ * Merging two elements is combining their members and assigning the lesser
+ * LSNTime. Use the timeline for LSN <-> time conversion using linear
+ * interpolation.
+ */
+typedef struct LSNTimeline
+{
+ int length;
+ LSNTime data[LSNTIMELINE_VOLUME];
+} LSNTimeline;
+
typedef struct PgStat_WalStats
{
PgStat_Counter wal_records;
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index d808aad8b05..aef83230836 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -1525,6 +1525,8 @@ LogicalTapeSet
LsnReadQueue
LsnReadQueueNextFun
LsnReadQueueNextStatus
+LSNTime
+LSNTimeline
LtreeGistOptions
LtreeSignature
MAGIC
--
2.37.2
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: Add LSN <-> time conversion functionality
2024-02-16 20:41 Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
2024-02-22 02:45 ` Re: Add LSN <-> time conversion functionality Melanie Plageman <[email protected]>
@ 2024-03-18 14:02 ` Daniel Gustafsson <[email protected]>
2024-03-18 17:46 ` Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
1 sibling, 1 reply; 250+ messages in thread
From: Daniel Gustafsson @ 2024-03-18 14:02 UTC (permalink / raw)
To: Melanie Plageman <[email protected]>; +Cc: Tomas Vondra <[email protected]>; pgsql-hackers; Robert Haas <[email protected]>; Andres Freund <[email protected]>
> On 22 Feb 2024, at 03:45, Melanie Plageman <[email protected]> wrote:
> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
> <[email protected]> wrote:
>> - Not sure why we need 0001. Just so that the "estimate" functions in
>> 0002 have a convenient "start" point? Surely we could look at the
>> current LSNTimeline data and use the oldest value, or (if there's no
>> data) use the current timestamp/LSN?
>
> When there are 0 or 1 entries in the timeline you'll get an answer
> that could be very off if you just return the current timestamp or
> LSN. I guess that is okay?
I don't think that's a huge problem at such a young "lsn-age", but I might be
missing something.
>> - I wonder what happens if we lose the data - we know that if people
>> reset statistics for whatever reason (or just lose them because of a
>> crash, or because they're on a replica), bad things happen to
>> autovacuum. What's the (expected) impact on pruning?
>
> This is an important question. Because stats aren't crashsafe, we
> could return very inaccurate numbers for some time/LSN values if we
> crash. I don't actually know what we could do about that. When I use
> the LSNTimeline for the freeze heuristic it is less of an issue
> because the freeze heuristic has a fallback strategy when there aren't
> enough stats to do its calculations. But other users of this
> LSNTimeline will simply get highly inaccurate results (I think?). Is
> there anything we could do about this? It seems bad.
A complication with this over stats is that we can't recompute this in case of
a crash/corruption issue. The simple solution is to consider this unlogged
data and start fresh at every unclean shutdown, but I have a feeling that won't
be good enough for basing heuristics on?
> Andres had brought up something at some point about, what if the
> database is simply turned off for awhile and then turned back on. Even
> if you cleanly shut down, will there be "gaps" in the timeline? I
> think that could be okay, but it is something to think about.
The gaps would represent reality, so there is nothing wrong per se with gaps,
but if they inflate the interval of a bucket which in turns impact the
precision of the results then that can be a problem.
> Just a note, all of my comments could use a lot of work, but I want to
> get consensus on the algorithm before I make sure and write about it
> in a perfect way.
I'm not sure "a lot of work" is accurate, they seem pretty much there to me,
but I think that an illustration of running through the algorithm in an
ascii-art array would be helpful.
Reading through this I think such a function has merits, not only for your
usecase but other heuristic based work and quite possibly systems debugging.
While the bucketing algorithm is a clever algorithm for degrading precision for
older entries without discarding them, I do fear that we'll risk ending up with
answers like "somewhere between in the past and even further in the past".
I've been playing around with various compression algorithms for packing the
buckets such that we can retain precision for longer. Since you were aiming to
work on other patches leading up to the freeze, let's pick this up again once
things calm down.
When compiling I got this warning for lsntime_merge_target:
pgstat_wal.c:242:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
1 warning generated.
The issue seems to be that the can't-really-happen path is protected with an
Assertion, which is a no-op for production builds. I think we should handle
the error rather than rely on testing catching it (since if it does happen even
though it can't, it's going to be when it's for sure not tested). Returning an
invalid array subscript like -1 and testing for it in lsntime_insert, with an
elog(WARNING..), seems enough.
- last_snapshot_lsn <= GetLastImportantRecPtr())
+ last_snapshot_lsn <= current_lsn)
I think we should delay extracting the LSN with GetLastImportantRecPtr until we
know that we need it, to avoid taking locks in this codepath unless needed.
I've attached a diff with the above suggestions which applies on op of your
patchset.
--
Daniel Gustafsson
commit 908f3bb511450f05980ba01d42c909cc9ef8007a
Author: Daniel Gustafsson <[email protected]>
Date: Thu Mar 14 14:32:15 2024 +0100
Code review hackery
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 7d9ad9046f..115204f708 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -267,7 +267,7 @@ BackgroundWriterMain(void)
{
TimestampTz timeout = 0;
TimestampTz now = GetCurrentTimestamp();
- XLogRecPtr current_lsn = GetLastImportantRecPtr();
+ XLogRecPtr current_lsn;
timeout = TimestampTzPlusMilliseconds(last_snapshot_ts,
LOG_SNAPSHOT_INTERVAL_MS);
@@ -279,12 +279,15 @@ BackgroundWriterMain(void)
* start of a record, whereas last_snapshot_lsn points just past
* the end of the record.
*/
- if (now >= timeout &&
- last_snapshot_lsn <= current_lsn)
+ if (now >= timeout)
{
- last_snapshot_lsn = LogStandbySnapshot();
- last_snapshot_ts = now;
- pgstat_wal_update_lsntimeline(now, current_lsn);
+ current_lsn = GetLastImportantRecPtr();
+ if (last_snapshot_lsn <= current_lsn)
+ {
+ last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_ts = now;
+ pgstat_wal_update_lsntimeline(now, current_lsn);
+ }
}
}
diff --git a/src/backend/utils/activity/pgstat_wal.c b/src/backend/utils/activity/pgstat_wal.c
index 0a7b545fd2..90afec580b 100644
--- a/src/backend/utils/activity/pgstat_wal.c
+++ b/src/backend/utils/activity/pgstat_wal.c
@@ -238,7 +238,7 @@ lsntime_merge_target(LSNTimeline *timeline)
}
/* Should not be reachable or we are out of space */
- Assert(false);
+ return -1;
}
/*
@@ -280,7 +280,12 @@ lsntime_insert(LSNTimeline *timeline, TimestampTz time,
* down by one and insert the passed-in LSNTime at array index 0.
*/
merge_target = lsntime_merge_target(timeline);
- Assert(merge_target >= 0 && merge_target < timeline->length);
+ if (merge_target < 0)
+ {
+ elog(WARNING, "unable to insert LSN in LSN timeline, merge failed");
+ return;
+ }
+ Assert(merge_target < timeline->length);
lsntime_merge(&timeline->data[merge_target], &timeline->data[merge_target - 1]);
memmove(&timeline->data[1], &timeline->data[0], sizeof(LSNTime) * merge_target - 1);
timeline->data[0] = entrant;
Attachments:
[text/plain] review.txt (2.3K, ../../[email protected]/2-review.txt)
download | inline diff:
commit 908f3bb511450f05980ba01d42c909cc9ef8007a
Author: Daniel Gustafsson <[email protected]>
Date: Thu Mar 14 14:32:15 2024 +0100
Code review hackery
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 7d9ad9046f..115204f708 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -267,7 +267,7 @@ BackgroundWriterMain(void)
{
TimestampTz timeout = 0;
TimestampTz now = GetCurrentTimestamp();
- XLogRecPtr current_lsn = GetLastImportantRecPtr();
+ XLogRecPtr current_lsn;
timeout = TimestampTzPlusMilliseconds(last_snapshot_ts,
LOG_SNAPSHOT_INTERVAL_MS);
@@ -279,12 +279,15 @@ BackgroundWriterMain(void)
* start of a record, whereas last_snapshot_lsn points just past
* the end of the record.
*/
- if (now >= timeout &&
- last_snapshot_lsn <= current_lsn)
+ if (now >= timeout)
{
- last_snapshot_lsn = LogStandbySnapshot();
- last_snapshot_ts = now;
- pgstat_wal_update_lsntimeline(now, current_lsn);
+ current_lsn = GetLastImportantRecPtr();
+ if (last_snapshot_lsn <= current_lsn)
+ {
+ last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_ts = now;
+ pgstat_wal_update_lsntimeline(now, current_lsn);
+ }
}
}
diff --git a/src/backend/utils/activity/pgstat_wal.c b/src/backend/utils/activity/pgstat_wal.c
index 0a7b545fd2..90afec580b 100644
--- a/src/backend/utils/activity/pgstat_wal.c
+++ b/src/backend/utils/activity/pgstat_wal.c
@@ -238,7 +238,7 @@ lsntime_merge_target(LSNTimeline *timeline)
}
/* Should not be reachable or we are out of space */
- Assert(false);
+ return -1;
}
/*
@@ -280,7 +280,12 @@ lsntime_insert(LSNTimeline *timeline, TimestampTz time,
* down by one and insert the passed-in LSNTime at array index 0.
*/
merge_target = lsntime_merge_target(timeline);
- Assert(merge_target >= 0 && merge_target < timeline->length);
+ if (merge_target < 0)
+ {
+ elog(WARNING, "unable to insert LSN in LSN timeline, merge failed");
+ return;
+ }
+ Assert(merge_target < timeline->length);
lsntime_merge(&timeline->data[merge_target], &timeline->data[merge_target - 1]);
memmove(&timeline->data[1], &timeline->data[0], sizeof(LSNTime) * merge_target - 1);
timeline->data[0] = entrant;
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: Add LSN <-> time conversion functionality
2024-02-16 20:41 Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
2024-02-22 02:45 ` Re: Add LSN <-> time conversion functionality Melanie Plageman <[email protected]>
2024-03-18 14:02 ` Re: Add LSN <-> time conversion functionality Daniel Gustafsson <[email protected]>
@ 2024-03-18 17:46 ` Tomas Vondra <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Tomas Vondra @ 2024-03-18 17:46 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; Melanie Plageman <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]>; Andres Freund <[email protected]>
On 3/18/24 15:02, Daniel Gustafsson wrote:
>> On 22 Feb 2024, at 03:45, Melanie Plageman <[email protected]> wrote:
>> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
>> <[email protected]> wrote:
>
>>> - Not sure why we need 0001. Just so that the "estimate" functions in
>>> 0002 have a convenient "start" point? Surely we could look at the
>>> current LSNTimeline data and use the oldest value, or (if there's no
>>> data) use the current timestamp/LSN?
>>
>> When there are 0 or 1 entries in the timeline you'll get an answer
>> that could be very off if you just return the current timestamp or
>> LSN. I guess that is okay?
>
> I don't think that's a huge problem at such a young "lsn-age", but I might be
> missing something.
>
>>> - I wonder what happens if we lose the data - we know that if people
>>> reset statistics for whatever reason (or just lose them because of a
>>> crash, or because they're on a replica), bad things happen to
>>> autovacuum. What's the (expected) impact on pruning?
>>
>> This is an important question. Because stats aren't crashsafe, we
>> could return very inaccurate numbers for some time/LSN values if we
>> crash. I don't actually know what we could do about that. When I use
>> the LSNTimeline for the freeze heuristic it is less of an issue
>> because the freeze heuristic has a fallback strategy when there aren't
>> enough stats to do its calculations. But other users of this
>> LSNTimeline will simply get highly inaccurate results (I think?). Is
>> there anything we could do about this? It seems bad.
>
Do we have something to calculate a sufficiently good "average" to use
as a default, if we don't have a better value? For example, we know the
timestamp of the last checkpoint, and we know the LSN, right? Maybe if
we're sufficiently far from the checkpoint, we could use that.
Or maybe checkpoint_timeout / max_wal_size would be enough to calculate
some default value?
I wonder how long it takes until LSNTimeline gives us sufficiently good
data for all LSNs we need. That is, if we lose this, how long it takes
until we get enough data to do good decisions?
Why don't we simply WAL-log this in some trivial way? It's pretty small,
so if we WAL-log this once in a while (after a merge happens), that
should not be a problem.
Or a different idea - if we lost the data, but commit_ts is enabled,
can't we "simply" walk commit_ts and feed LSN/timestamp into the
timeline? I guess we don't want to walk 2B transactions, but even just
sampling some recent transactions might be enough, no?
> A complication with this over stats is that we can't recompute this in case of
> a crash/corruption issue. The simple solution is to consider this unlogged
> data and start fresh at every unclean shutdown, but I have a feeling that won't
> be good enough for basing heuristics on?
>
>> Andres had brought up something at some point about, what if the
>> database is simply turned off for awhile and then turned back on. Even
>> if you cleanly shut down, will there be "gaps" in the timeline? I
>> think that could be okay, but it is something to think about.
>
> The gaps would represent reality, so there is nothing wrong per se with gaps,
> but if they inflate the interval of a bucket which in turns impact the
> precision of the results then that can be a problem.
>
Well, I think the gaps are a problem in the sense that they disappear
once we start merging the buckets. But maybe that's fine, if we're only
interested in approximate data.
>> Just a note, all of my comments could use a lot of work, but I want to
>> get consensus on the algorithm before I make sure and write about it
>> in a perfect way.
>
> I'm not sure "a lot of work" is accurate, they seem pretty much there to me,
> but I think that an illustration of running through the algorithm in an
> ascii-art array would be helpful.
>
+1
>
> Reading through this I think such a function has merits, not only for your
> usecase but other heuristic based work and quite possibly systems debugging.
>
> While the bucketing algorithm is a clever algorithm for degrading precision for
> older entries without discarding them, I do fear that we'll risk ending up with
> answers like "somewhere between in the past and even further in the past".
> I've been playing around with various compression algorithms for packing the
> buckets such that we can retain precision for longer. Since you were aiming to
> work on other patches leading up to the freeze, let's pick this up again once
> things calm down.
>
I guess this ambiguity is pretty inherent to a structure that does not
keep all the data, and gradually reduces the resolution for old stuff.
But my understanding was that's sufficient for the freezing patch.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: Add LSN <-> time conversion functionality
2024-02-16 20:41 Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
2024-02-22 02:45 ` Re: Add LSN <-> time conversion functionality Melanie Plageman <[email protected]>
@ 2024-03-18 17:29 ` Tomas Vondra <[email protected]>
1 sibling, 0 replies; 250+ messages in thread
From: Tomas Vondra @ 2024-03-18 17:29 UTC (permalink / raw)
To: Melanie Plageman <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Daniel Gustafsson <[email protected]>
On 2/22/24 03:45, Melanie Plageman wrote:
> Thanks so much for reviewing!
>
> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
> <[email protected]> wrote:
>>
>> When I first read this, I immediately started wondering if this might
>> use the commit timestamp stuff we already have. Because for each commit
>> we already store the LSN and commit timestamp, right? But I'm not sure
>> that would be a good match - the commit_ts serves a very special purpose
>> of mapping XID => (LSN, timestamp), I don't see how to make it work for
>> (LSN=>timestmap) and (timestamp=>LSN) very easily.
>
> I took a look at the code in commit_ts.c, and I really don't see a way
> of reusing any of this commit<->timestamp infrastructure for
> timestamp<->LSN mappings.
>
>> As for the inner workings of the patch, my understanding is this:
>>
>> - "LSNTimeline" consists of "LSNTime" entries representing (LSN,ts)
>> points, but those points are really "buckets" that grow larger and
>> larger for older periods of time.
>
> Yes, they are buckets in the sense that they represent multiple values
> but each contains a single LSNTime value which is the minimum of all
> the LSNTimes we "merged" into that single array element. In order to
> represent a range of time, you need to use two array elements. The
> linear interpolation from time <-> LSN is all done with two elements.
>
>> - AFAIK each entry represent an interval of time, and the next (older)
>> interval is twice as long, right? So the first interval is 1 second,
>> then 2 seconds, 4 seconds, 8 seconds, ...
>>
>> - But I don't understand how the LSNTimeline entries are "aging" and get
>> less accurate, while the "current" bucket is short. lsntime_insert()
>> seems to simply move to the next entry, but doesn't that mean we insert
>> the entries into larger and larger buckets?
>
> Because the earlier array elements can represent fewer logical members
> than later ones and because elements are merged into the next element
> when space runs out, later array elements will contain older data and
> more of it, so those "ranges" will be larger. But, after thinking
> about it and also reading your feedback, I realized my algorithm was
> silly because it starts merging logical members before it has even
> used the whole array.
>
> The attached v3 has a new algorithm. Now, LSNTimes are added from the
> end of the array forward until all array elements have at least one
> logical member (array length == volume). Once array length == volume,
> new LSNTimes will result in merging logical members in existing
> elements. We want to merge older members because those can be less
> precise. So, the number of logical members per array element will
> always monotonically increase starting from the beginning of the array
> (which contains the most recent data) and going to the end. We want to
> use all the available space in the array. That means that each LSNTime
> insertion will always result in a single merge. We want the timeline
> to be inclusive of the oldest data, so merging means taking the
> smaller value of two LSNTime values. I had to pick a rule for choosing
> which elements to merge. So, I choose the merge target as the oldest
> element whose logical membership is < 2x its predecessor. I merge the
> merge target's predecessor into the merge target. Then I move all of
> the intervening elements down 1. Then I insert the new LSNTime at
> index 0.
>
I can't help but think about t-digest [1], which also merges data into
variable-sized buckets (called centroids, which is a pair of values,
just like LSNTime). But the merging is driven by something called "scale
function" which I found like a pretty nice approach to this, and it
yields some guarantees regarding accuracy. I wonder if we could do
something similar here ...
The t-digest is a way to approximate quantiles, and the default scale
function is optimized for best accuracy on the extremes (close to 0.0
and 1.0), but it's possible to use scale functions that optimize only
for accuracy close to 1.0.
This may be misguided, but I see similarity between quantiles and what
LSNTimeline does - timestamps are ordered, and quantiles close to 0.0
are "old timestamps" while quantiles close to 1.0 are "now".
And t-digest also defines a pretty efficient algorithm to merge data in
a way that gradually combines older "buckets" into larger ones.
>> - The comments never really spell what amount of time the entries cover
>> / how granular it is. My understanding is it's simply measured in number
>> of entries added, which is assumed to be constant and drive by
>> bgwriter_delay, right? Which is 200ms by default. Which seems fine, but
>> isn't the hibernation (HIBERNATE_FACTOR) going to mess with it?
>>
>> Is there some case where bgwriter would just loop without sleeping,
>> filling the timeline much faster? (I can't think of any, but ...)
>
> bgwriter will wake up when there are buffers to flush, which is likely
> correlated with there being new LSNs. So, actually it seems like it
> might work well to rely on only filling the timeline when there are
> things for bgwriter to do.
>
>> - The LSNTimeline comment claims an array of size 64 is large enough to
>> not need to care about filling it, but maybe it should briefly explain
>> why we can never fill it (I guess 2^64 is just too many).
>
> The new structure fits a different number of members. I have yet to
> calculate that number, but it should be explained in the comments once
> I do.
>
> For example, if we made an LSNTimeline with volume 4, once every
> element had one LSNTime and we needed to start merging, the following
> is how many logical members each element would have after each of four
> merges:
> 1111
> 1112
> 1122
> 1114
> 1124
> So, if we store the number of members as an unsigned 64-bit int and we
> have an LSNTimeline with volume 64, what is the maximum number of
> members can we store if we hold all of the invariants described in my
> algorithm above (we only merge when required, every element holds < 2x
> the number of logical members as its predecessor, we do exactly one
> merge every insertion [when required], membership must monotonically
> increase [choose the oldest element meeting the criteria when deciding
> what to merge])?
>
I guess that should be enough for (2^64-1) logical members, because it's
a sequence 1, 2, 4, 8, ..., 2^63. Seems enough.
But now that I think about it, does it make sense to do the merging
based on the number of logical members? Shouldn't this really be driven
by the "length" of the time interval the member covers?
>> - I don't quite understand why 0005 adds the functions to pageinspect.
>> This has nothing to do with pages, right?
>
> You're right. I just couldn't think of a good place to put the
> functions. In version 3, I just put the SQL functions in pgstat_wal.c
> and made them generally available (i.e. not in a contrib module). I
> haven't added docs back yet. But perhaps a section near the docs
> describing pg_xact_commit_timestamp() [1]? I wasn't sure if I should
> put the SQL function source code in pgstatfuncs.c -- I kind of prefer
> it in pgstat_wal.c but there are no other SQL functions there.
>
OK, pgstat_wal seems like a good place.
>> - Not sure why we need 0001. Just so that the "estimate" functions in
>> 0002 have a convenient "start" point? Surely we could look at the
>> current LSNTimeline data and use the oldest value, or (if there's no
>> data) use the current timestamp/LSN?
>
> When there are 0 or 1 entries in the timeline you'll get an answer
> that could be very off if you just return the current timestamp or
> LSN. I guess that is okay?
>
>> - I wonder what happens if we lose the data - we know that if people
>> reset statistics for whatever reason (or just lose them because of a
>> crash, or because they're on a replica), bad things happen to
>> autovacuum. What's the (expected) impact on pruning?
>
> This is an important question. Because stats aren't crashsafe, we
> could return very inaccurate numbers for some time/LSN values if we
> crash. I don't actually know what we could do about that. When I use
> the LSNTimeline for the freeze heuristic it is less of an issue
> because the freeze heuristic has a fallback strategy when there aren't
> enough stats to do its calculations. But other users of this
> LSNTimeline will simply get highly inaccurate results (I think?). Is
> there anything we could do about this? It seems bad.
>
> Andres had brought up something at some point about, what if the
> database is simply turned off for awhile and then turned back on. Even
> if you cleanly shut down, will there be "gaps" in the timeline? I
> think that could be okay, but it is something to think about.
>
>> - What about a SRF function that outputs the whole LSNTimeline? Would be
>> useful for debugging / development, I think. (Just a suggestion).
>
> Good idea! I've added this. Though, maybe there was a simpler way to
> implement than I did.
>
Thanks. I'll take a look.
> Just a note, all of my comments could use a lot of work, but I want to
> get consensus on the algorithm before I make sure and write about it
> in a perfect way.
>
Makes sense, as long as the comments are sufficiently clear. It's hard
to reach consensus on something not explained clearly enough.
regards
[1]
https://github.com/tdunning/t-digest/blob/main/docs/t-digest-paper/histo.pdf
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 250+ messages in thread
* improve performance of pg_dump with many sequences
@ 2024-05-03 02:51 Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-05-03 02:51 UTC (permalink / raw)
To: pgsql-hackers
Similar to 'pg_dump --binary-upgrade' [0], we can speed up pg_dump with
many sequences by gathering the required information in a single query
instead of two queries per sequence. The attached patches are
works-in-progress, but here are the results I see on my machine for
'pg_dump --schema-only --binary-upgrade' with a million sequences:
HEAD : 6m22.809s
[0] : 1m54.701s
[0] + attached : 0m38.233s
I'm not sure I have all the details correct in 0003, and we might want to
separate the table into two tables which are only populated when the
relevant section is dumped. Furthermore, the query in 0003 is a bit goofy
because it needs to dance around a bug reported elsewhere [1].
[0] https://postgr.es/m/20240418041712.GA3441570%40nathanxps13
[1] https://postgr.es/m/20240501005730.GA594666%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-09 19:11 ` Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-09 19:11 UTC (permalink / raw)
To: pgsql-hackers
rebased
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-10 20:08 ` Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Euler Taveira @ 2024-07-10 20:08 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; pgsql-hackers
On Tue, Jul 9, 2024, at 4:11 PM, Nathan Bossart wrote:
> rebased
Nice improvement. The numbers for a realistic scenario (10k sequences) are
for i in `seq 1 10000`; do echo "CREATE SEQUENCE s$i;"; done > /tmp/s.sql
master:
real 0m1,141s
user 0m0,056s
sys 0m0,147s
patched:
real 0m0,410s
user 0m0,045s
sys 0m0,103s
You are changing internal representation from char to int64. Is the main goal to
validate catalog data? What if there is a new sequence data type whose
representation is not an integer?
This code path is adding zero byte to the last position of the fixed string. I
suggest that the zero byte is added to the position after the string length.
Assert(strlen(PQgetvalue(res, 0, 0)) < sizeof(seqtype));
strncpy(seqtype, PQgetvalue(res, 0, 0), sizeof(seqtype));
seqtype[sizeof(seqtype) - 1] = '\0';
Something like
l = strlen(PQgetvalue(res, 0, 0));
Assert(l < sizeof(seqtype));
strncpy(seqtype, PQgetvalue(res, 0, 0), l);
seqtype[l] = '\0';
Another suggestion is to use a constant for seqtype
char seqtype[MAX_SEQNAME_LEN];
and simplify the expression:
size_t seqtype_sz = sizeof(((SequenceItem *) 0)->seqtype);
If you are not planning to apply 0003, make sure you fix collectSequences() to
avoid versions less than 10. Move this part to 0002.
@@ -17233,11 +17235,24 @@ collectSequences(Archive *fout)
PGresult *res;
const char *query;
+ if (fout->remoteVersion < 100000)
+ return;
+
Since you apply a fix for pg_sequence_last_value function, you can simplify the
query in 0003. CASE is not required.
I repeated the same test but not applying 0003.
patched (0001 and 0002):
real 0m0,290s
user 0m0,038s
sys 0m0,104s
I'm not sure if 0003 is worth. Maybe if you have another table like you
suggested.
--
Euler Taveira
EDB https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
@ 2024-07-10 22:05 ` Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-10 22:05 UTC (permalink / raw)
To: Euler Taveira <[email protected]>; +Cc: pgsql-hackers
On Wed, Jul 10, 2024 at 05:08:56PM -0300, Euler Taveira wrote:
> Nice improvement. The numbers for a realistic scenario (10k sequences) are
Thanks for taking a look!
> You are changing internal representation from char to int64. Is the main goal to
> validate catalog data? What if there is a new sequence data type whose
> representation is not an integer?
IIRC 0001 was primarily intended to reduce the amount of memory needed for
the sorted table. Regarding a new sequence data type, I'm assuming we'll
have much bigger fish to fry if we do that (e.g., pg_sequence uses int8 for
the values), and I'd hope that adjusting this code wouldn't be too
difficult, anyway.
> This code path is adding zero byte to the last position of the fixed string. I
> suggest that the zero byte is added to the position after the string length.
I'm not following why that would be a better approach. strncpy() will add
a NUL to the end of the string unless it doesn't fit in the buffer, in
which case we'll add our own via "seqtype[sizeof(seqtype) - 1] = '\0'".
Furthermore, the compiler can determine the position where the NUL should
be placed, whereas placing it at the end of the copied string requires a
runtime strlen().
> l = strlen(PQgetvalue(res, 0, 0));
> Assert(l < sizeof(seqtype));
> strncpy(seqtype, PQgetvalue(res, 0, 0), l);
> seqtype[l] = '\0';
I think the strncpy() should really be limited to the size of the seqtype
buffer. IMHO an Assert is not sufficient.
> If you are not planning to apply 0003, make sure you fix collectSequences() to
> avoid versions less than 10. Move this part to 0002.
Yeah, no need to create the table if we aren't going to use it.
> Since you apply a fix for pg_sequence_last_value function, you can simplify the
> query in 0003. CASE is not required.
Unfortunately, I think we have to keep this workaround since older minor
releases of PostgreSQL don't have the fix.
> patched (0001 and 0002):
> real 0m0,290s
> user 0m0,038s
> sys 0m0,104s
>
> I'm not sure if 0003 is worth. Maybe if you have another table like you
> suggested.
What pg_dump command did you test here? Did you dump the sequence data, or
was this --schema-only?
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-11 02:52 ` Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Euler Taveira @ 2024-07-11 02:52 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
On Wed, Jul 10, 2024, at 7:05 PM, Nathan Bossart wrote:
> I'm not following why that would be a better approach. strncpy() will add
> a NUL to the end of the string unless it doesn't fit in the buffer, in
> which case we'll add our own via "seqtype[sizeof(seqtype) - 1] = '\0'".
> Furthermore, the compiler can determine the position where the NUL should
> be placed, whereas placing it at the end of the copied string requires a
> runtime strlen().
Nevermind, you are copying the whole buffer (n = sizeof(seqtype)).
> Unfortunately, I think we have to keep this workaround since older minor
> releases of PostgreSQL don't have the fix.
Hmm. Right.
> What pg_dump command did you test here? Did you dump the sequence data, or
> was this --schema-only?
time pg_dump -f - -s -d postgres
--
Euler Taveira
EDB https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
@ 2024-07-12 02:09 ` Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-12 02:09 UTC (permalink / raw)
To: Euler Taveira <[email protected]>; +Cc: pgsql-hackers
On Wed, Jul 10, 2024 at 11:52:33PM -0300, Euler Taveira wrote:
> On Wed, Jul 10, 2024, at 7:05 PM, Nathan Bossart wrote:
>> Unfortunately, I think we have to keep this workaround since older minor
>> releases of PostgreSQL don't have the fix.
>
> Hmm. Right.
On second thought, maybe we should just limit this improvement to the minor
releases with the fix so that we _can_ get rid of the workaround. Or we
could use the hacky workaround only for versions with the bug.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-16 21:36 ` Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-16 21:36 UTC (permalink / raw)
To: Euler Taveira <[email protected]>; +Cc: pgsql-hackers
On Thu, Jul 11, 2024 at 09:09:17PM -0500, Nathan Bossart wrote:
> On second thought, maybe we should just limit this improvement to the minor
> releases with the fix so that we _can_ get rid of the workaround. Or we
> could use the hacky workaround only for versions with the bug.
Here is a new version of the patch set. The main differences are 1) we no
longer gather the sequence data for schema-only dumps and 2) 0003 uses a
simplified query for dumps on v18 and newer. I considered also using a
slightly simplified query for dumps on versions with the
unlogged-sequences-on-standbys fix, but I felt that wasn't worth the extra
code.
Unfortunately, I've also discovered a problem with 0003.
pg_sequence_last_value() returns NULL when is_called is false, in which
case we assume last_value == seqstart, which is, sadly, bogus due to
commands like ALTER SEQUENCE [RE]START WITH. AFAICT there isn't an easy
way around this. We could either create a giant query that gathers the
information from all sequences in the database, or we could introduce a new
function in v18 that returns everything we need (which would only help for
upgrades _from_ v18). Assuming I'm not missing a better option, I think
the latter is the better choice, and I still think it's worth doing even
though it probably won't help anyone for ~2.5 years.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-17 02:30 ` Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Michael Paquier @ 2024-07-17 02:30 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Euler Taveira <[email protected]>; pgsql-hackers
On Tue, Jul 16, 2024 at 04:36:15PM -0500, Nathan Bossart wrote:
> Unfortunately, I've also discovered a problem with 0003.
> pg_sequence_last_value() returns NULL when is_called is false, in which
> case we assume last_value == seqstart, which is, sadly, bogus due to
> commands like ALTER SEQUENCE [RE]START WITH. AFAICT there isn't an easy
> way around this. We could either create a giant query that gathers the
> information from all sequences in the database, or we could introduce a new
> function in v18 that returns everything we need (which would only help for
> upgrades _from_ v18). Assuming I'm not missing a better option, I think
> the latter is the better choice, and I still think it's worth doing even
> though it probably won't help anyone for ~2.5 years.
Yeah, I have bumped on the same issue. In the long term, I also think
that we'd better have pg_sequence_last_value() return a row with
is_called and the value scanned. As you say, it won't help except
when upgrading from versions of Postgres that are at least to v18,
assuming that this change gets in the tree, but that would be much
better in the long term and time flies fast.
See 0001 as of this area:
https://www.postgresql.org/message-id/ZnPIUPMmp5TzBPC2%40paquier.xyz
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
@ 2024-07-17 03:23 ` Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-17 03:23 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Euler Taveira <[email protected]>; pgsql-hackers
On Wed, Jul 17, 2024 at 11:30:04AM +0900, Michael Paquier wrote:
> Yeah, I have bumped on the same issue. In the long term, I also think
> that we'd better have pg_sequence_last_value() return a row with
> is_called and the value scanned. As you say, it won't help except
> when upgrading from versions of Postgres that are at least to v18,
> assuming that this change gets in the tree, but that would be much
> better in the long term and time flies fast.
AFAICT pg_sequence_last_value() is basically an undocumented internal
function only really intended for use by the pg_sequences system view, so
changing the function like this for v18 might not be out of the question.
Otherwise, I think we'd have to create a strikingly similar function with
slightly different behavior, which would be a bizarre place to end up.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-17 18:48 ` Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-17 18:48 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Euler Taveira <[email protected]>; pgsql-hackers
On Tue, Jul 16, 2024 at 10:23:08PM -0500, Nathan Bossart wrote:
> On Wed, Jul 17, 2024 at 11:30:04AM +0900, Michael Paquier wrote:
>> Yeah, I have bumped on the same issue. In the long term, I also think
>> that we'd better have pg_sequence_last_value() return a row with
>> is_called and the value scanned. As you say, it won't help except
>> when upgrading from versions of Postgres that are at least to v18,
>> assuming that this change gets in the tree, but that would be much
>> better in the long term and time flies fast.
>
> AFAICT pg_sequence_last_value() is basically an undocumented internal
> function only really intended for use by the pg_sequences system view, so
> changing the function like this for v18 might not be out of the question.
> Otherwise, I think we'd have to create a strikingly similar function with
> slightly different behavior, which would be a bizarre place to end up.
On second thought, I worry that this change might needlessly complicate the
pg_sequences system view. Maybe we should just add a
pg_sequence_get_tuple() function that returns everything in
FormData_pg_sequence_data for a given sequence OID...
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-17 18:59 ` Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2024-07-17 18:59 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> On second thought, I worry that this change might needlessly complicate the
> pg_sequences system view. Maybe we should just add a
> pg_sequence_get_tuple() function that returns everything in
> FormData_pg_sequence_data for a given sequence OID...
Uh ... why do we need a function, rather than just
select * from pg_sequence
?
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2024-07-17 19:05 ` Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-17 19:05 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
On Wed, Jul 17, 2024 at 02:59:26PM -0400, Tom Lane wrote:
> Nathan Bossart <[email protected]> writes:
>> On second thought, I worry that this change might needlessly complicate the
>> pg_sequences system view. Maybe we should just add a
>> pg_sequence_get_tuple() function that returns everything in
>> FormData_pg_sequence_data for a given sequence OID...
>
> Uh ... why do we need a function, rather than just
>
> select * from pg_sequence
We can use that for dumpSequence(), but dumpSequenceData() requires
information from the sequence tuple itself. Right now, we query each
sequence relation individually for that data, and I'm trying to find a way
to cut down on those round trips.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-17 19:11 ` Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2024-07-17 19:11 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> On Wed, Jul 17, 2024 at 02:59:26PM -0400, Tom Lane wrote:
>> Uh ... why do we need a function, rather than just
>> select * from pg_sequence
> We can use that for dumpSequence(), but dumpSequenceData() requires
> information from the sequence tuple itself. Right now, we query each
> sequence relation individually for that data, and I'm trying to find a way
> to cut down on those round trips.
Ah, I confused FormData_pg_sequence_data with FormData_pg_sequence.
Sorry for the noise.
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2024-07-18 03:45 ` Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-18 03:45 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Here is an attempt at adding a new function that returns the sequence tuple
and using that to avoid querying each sequence relation individually in
dumpSequenceData().
If we instead wanted to change pg_sequence_last_value() to return both
is_called and last_value, I think we could modify the pg_sequences system
view to use a LATERAL subquery, i.e.,
SELECT
...
CASE
WHEN L.is_called THEN L.last_value
ELSE NULL
END AS last_value
FROM pg_sequence S
...
JOIN LATERAL pg_sequence_last_value(S.seqrelid) L ON true
...
That doesn't seem so bad, and it'd avoid an extra pg_proc entry, but it
would probably break anything that calls pg_sequence_last_value() directly.
Thoughts?
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-18 03:58 ` Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2024-07-18 03:58 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> Here is an attempt at adding a new function that returns the sequence tuple
> and using that to avoid querying each sequence relation individually in
> dumpSequenceData().
Didn't read the patch yet, but ...
> If we instead wanted to change pg_sequence_last_value() to return both
> is_called and last_value, I think we could modify the pg_sequences system
> view to use a LATERAL subquery, i.e.,
> ...
> That doesn't seem so bad, and it'd avoid an extra pg_proc entry, but it
> would probably break anything that calls pg_sequence_last_value() directly.
> Thoughts?
... one more pg_proc entry is pretty cheap. I think we should leave
pg_sequence_last_value alone. We don't know if anyone is depending
on it, and de-optimizing the pg_sequences view doesn't seem like a
win either.
... okay, I lied, I looked at the patch. Why are you testing
+ if (pg_class_aclcheck(relid, GetUserId(), ACL_SELECT | ACL_USAGE) == ACLCHECK_OK &&
? This is a substitute for a SELECT from the sequence and it seems
like it ought to demand exactly the same privilege as SELECT.
(If you want to get more technical, USAGE allows nextval() which
gives strictly less information than what this exposes; that's why
we're here after all.) So there is a difference in the privilege
levels, which is another reason for not combining this with
pg_sequence_last_value.
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2024-07-18 18:22 ` Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-18 18:22 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
On Wed, Jul 17, 2024 at 11:58:21PM -0400, Tom Lane wrote:
> ... okay, I lied, I looked at the patch. Why are you testing
>
> + if (pg_class_aclcheck(relid, GetUserId(), ACL_SELECT | ACL_USAGE) == ACLCHECK_OK &&
>
> ? This is a substitute for a SELECT from the sequence and it seems
> like it ought to demand exactly the same privilege as SELECT.
> (If you want to get more technical, USAGE allows nextval() which
> gives strictly less information than what this exposes; that's why
> we're here after all.) So there is a difference in the privilege
> levels, which is another reason for not combining this with
> pg_sequence_last_value.
Oh, that's a good point. I wrongly assumed the privilege checks would be
the same as pg_sequence_last_value(). I fixed this in v5.
I also polished the rest of the patches a bit. Among other things, I
created an enum for the sequence data types to avoid the hacky strncpy()
stuff, which was causing weird CI failures [0].
[0] https://cirrus-ci.com/task/4614801962303488
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-18 20:29 ` Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-18 20:29 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
I fixed a compiler warning on Windows in v6 of the patch set. Sorry for
the noise.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-24 18:36 ` Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-24 18:36 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
I ran Euler's tests again on the v6 patch set.
for i in `seq 1 10000`; do psql postgres -c "CREATE SEQUENCE s$i;"; done
time pg_dump -f - -s -d postgres > /dev/null
HEAD: 0.607s
0001 + 0002: 0.094s
all patches: 0.094s
Barring additional feedback, I am planning to commit these patches early
next week.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2024-07-31 15:19 ` Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2024-07-31 15:19 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Committed.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2025-12-29 17:26 ` Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2025-12-29 17:26 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> Committed.
In the no-good-deed-goes-unpunished department: pg_dump's use
of pg_get_sequence_data() (nee pg_sequence_read_tuple()) is
evidently responsible for the complaint in bug #19365 [1]
that pg_dump can no longer survive concurrent sequence drops.
Given that that function already silently returns NULLs if the
sequence isn't readable for other reasons, I think it'd be
sane to make it silently return NULL if the sequence isn't
there anymore. Unfortunately, that looks like it'd require
nontrivial restructuring of init_sequence().
Or maybe we could make it not use init_sequence()? For the moment
a plain try_relation_open and check that it's a sequence should do,
but I'm not sure how that'd fit into people's plans for future
improvement of the sequence API.
There are other reasons not to like use of init_sequence in this
code path, too. pg_dump's session will build a SeqTable entry for
every sequence in the database, which there could be a lot of,
and it will acquire RowExclusiveLock on every sequence and hold
that to the end of the dump, which seems likely to be troublesome
from a concurrency standpoint. Since pg_get_sequence_data is a
read-only operation this lock level feels wrong.
BTW, I'm unconvinced that pg_dump behaves sanely when this function
does return nulls. I think the ideal thing would be for it to skip
issuing setval(), but right now it looks like it will issue one with
garbage values.
regards, tom lane
[1] https://www.postgresql.org/message-id/19365-6245240d8b926327%40postgresql.org
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2026-01-07 23:06 ` Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2026-01-07 23:06 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
I'm still looking into this, but here are some preliminary thoughts.
On Mon, Dec 29, 2025 at 12:26:01PM -0500, Tom Lane wrote:
> In the no-good-deed-goes-unpunished department: pg_dump's use
> of pg_get_sequence_data() (nee pg_sequence_read_tuple()) is
> evidently responsible for the complaint in bug #19365 [1]
> that pg_dump can no longer survive concurrent sequence drops.
This seems to be reproducible on older versions. With a well-timed sleep
right before dumpSequenceData()'s pre-v18 query, I can produce a
relation-does-not-exist error with a concurrent sequence drop. Perhaps v18
made this easier to reach, but given it moved the sequence tuple access to
collectSequences()'s query, I'm not sure why that would be.
> BTW, I'm unconvinced that pg_dump behaves sanely when this function
> does return nulls. I think the ideal thing would be for it to skip
> issuing setval(), but right now it looks like it will issue one with
> garbage values.
Before v18, pg_dump just ERRORs due to insufficient privileges on a
sequence. IMHO that makes sense. If you ask pg_dump to dump something you
don't have privileges on, I'd expect it to error instead of silently
skipping it.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2026-01-07 23:13 ` Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2026-01-07 23:13 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> Before v18, pg_dump just ERRORs due to insufficient privileges on a
> sequence. IMHO that makes sense. If you ask pg_dump to dump something you
> don't have privileges on, I'd expect it to error instead of silently
> skipping it.
That would be a fine argument were it not that collectSequences()
tries to vacuum up the data for every sequence in the DB, whether
the user has asked to dump them all or not. In other places in
pg_dump, we avoid such problems by restricting which tables we
ask for data about ... but not here.
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2026-01-07 23:27 ` Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2026-01-07 23:27 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
On Wed, Jan 07, 2026 at 06:13:48PM -0500, Tom Lane wrote:
> Nathan Bossart <[email protected]> writes:
>> Before v18, pg_dump just ERRORs due to insufficient privileges on a
>> sequence. IMHO that makes sense. If you ask pg_dump to dump something you
>> don't have privileges on, I'd expect it to error instead of silently
>> skipping it.
>
> That would be a fine argument were it not that collectSequences()
> tries to vacuum up the data for every sequence in the DB, whether
> the user has asked to dump them all or not. In other places in
> pg_dump, we avoid such problems by restricting which tables we
> ask for data about ... but not here.
I meant that we could teach pg_dump to error in dumpSequenceData() if it
sees nulls for the sequence in question.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2026-01-08 00:24 ` Tom Lane <[email protected]>
2026-01-08 17:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2026-01-08 00:24 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> On Wed, Jan 07, 2026 at 06:13:48PM -0500, Tom Lane wrote:
>> That would be a fine argument were it not that collectSequences()
>> tries to vacuum up the data for every sequence in the DB, whether
>> the user has asked to dump them all or not.
> I meant that we could teach pg_dump to error in dumpSequenceData() if it
> sees nulls for the sequence in question.
Ah, gotcha; I thought you were talking about changing
pg_get_sequence_data() to throw an error instead of returning nulls.
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2026-01-08 17:36 ` Nathan Bossart <[email protected]>
2026-01-08 18:19 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2026-01-08 17:36 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
On Wed, Jan 07, 2026 at 07:24:52PM -0500, Tom Lane wrote:
> Nathan Bossart <[email protected]> writes:
>> On Wed, Jan 07, 2026 at 06:13:48PM -0500, Tom Lane wrote:
>>> That would be a fine argument were it not that collectSequences()
>>> tries to vacuum up the data for every sequence in the DB, whether
>>> the user has asked to dump them all or not.
>
>> I meant that we could teach pg_dump to error in dumpSequenceData() if it
>> sees nulls for the sequence in question.
>
> Ah, gotcha; I thought you were talking about changing
> pg_get_sequence_data() to throw an error instead of returning nulls.
Here is a patch that does this along with what you described upthread,
i.e., teaching pg_get_sequence_data to return nulls for missing sequences.
Apparently pg_dump still runs through dumpSequenceData() for schema-only
dumps, which is a problem for this patch. I've taught it to immediately
return for schema-only dumps to evade this problem. That seems like a win
for older versions, too, as they will no longer run useless queries.
I believe this helps the reporter's case, as their problem involves dumping
one schema while dropping another, which v18 indeed makes worse because (as
you mentioned) we gather data for all sequences in the database.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 17:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2026-01-08 18:19 ` Tom Lane <[email protected]>
2026-01-08 19:34 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2026-01-08 18:19 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> Here is a patch that does this along with what you described upthread,
> i.e., teaching pg_get_sequence_data to return nulls for missing sequences.
> Apparently pg_dump still runs through dumpSequenceData() for schema-only
> dumps, which is a problem for this patch. I've taught it to immediately
> return for schema-only dumps to evade this problem. That seems like a win
> for older versions, too, as they will no longer run useless queries.
> I believe this helps the reporter's case, as their problem involves dumping
> one schema while dropping another, which v18 indeed makes worse because (as
> you mentioned) we gather data for all sequences in the database.
Looks plausible to me. (I didn't test, just read the code.)
One nitpicky point is that try_sequence_open() will still error out
if it is given an OID that is a non-sequence relation. I think it'd
be more desirable for it to close the relation again and return NULL.
That's probably insignificant for pg_dump's usage, because we could
only hit the case with very improbable OID wraparound timing. But
I think our experience with catalog-inspection functions similar to
pg_get_sequence_data is that it's usually better to return NULL than
throw an error.
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 17:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 18:19 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2026-01-08 19:34 ` Nathan Bossart <[email protected]>
2026-01-08 19:54 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Nathan Bossart @ 2026-01-08 19:34 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
On Thu, Jan 08, 2026 at 01:19:39PM -0500, Tom Lane wrote:
> One nitpicky point is that try_sequence_open() will still error out
> if it is given an OID that is a non-sequence relation. I think it'd
> be more desirable for it to close the relation again and return NULL.
> That's probably insignificant for pg_dump's usage, because we could
> only hit the case with very improbable OID wraparound timing. But
> I think our experience with catalog-inspection functions similar to
> pg_get_sequence_data is that it's usually better to return NULL than
> throw an error.
Hm. That makes sense, but both try_table_open and try_index_open error for
wrong relkinds. I could change all of the try_*_open functions to return
NULL in that case, or I could just open-code the relkind check in
pg_get_sequence_data after try_relation_open (and have it return NULL for
non-sequences). I'm leaning towards the latter, if for no other reason
than it might be slightly nicer for back-patching (e.g., smaller, no new
extern functions).
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 17:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 18:19 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 19:34 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
@ 2026-01-08 19:54 ` Tom Lane <[email protected]>
2026-01-09 16:17 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
0 siblings, 1 reply; 250+ messages in thread
From: Tom Lane @ 2026-01-08 19:54 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
Nathan Bossart <[email protected]> writes:
> Hm. That makes sense, but both try_table_open and try_index_open error for
> wrong relkinds. I could change all of the try_*_open functions to return
> NULL in that case, or I could just open-code the relkind check in
> pg_get_sequence_data after try_relation_open (and have it return NULL for
> non-sequences). I'm leaning towards the latter, if for no other reason
> than it might be slightly nicer for back-patching (e.g., smaller, no new
> extern functions).
WFM.
regards, tom lane
^ permalink raw reply [nested|flat] 250+ messages in thread
* Re: improve performance of pg_dump with many sequences
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 17:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 18:19 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 19:34 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 19:54 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
@ 2026-01-09 16:17 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 250+ messages in thread
From: Nathan Bossart @ 2026-01-09 16:17 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Euler Taveira <[email protected]>; pgsql-hackers
On Thu, Jan 08, 2026 at 02:54:53PM -0500, Tom Lane wrote:
> WFM.
Thanks, committed.
--
nathan
^ permalink raw reply [nested|flat] 250+ messages in thread
end of thread, other threads:[~2026-01-09 16:17 UTC | newest]
Thread overview: 250+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v39 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v44 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v41 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v40 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v57 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v43 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v42 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v38 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v57 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2024-02-16 20:41 Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
2024-02-22 02:45 ` Re: Add LSN <-> time conversion functionality Melanie Plageman <[email protected]>
2024-03-18 14:02 ` Re: Add LSN <-> time conversion functionality Daniel Gustafsson <[email protected]>
2024-03-18 17:46 ` Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
2024-03-18 17:29 ` Re: Add LSN <-> time conversion functionality Tomas Vondra <[email protected]>
2024-05-03 02:51 improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-09 19:11 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-10 20:08 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-10 22:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-11 02:52 ` Re: improve performance of pg_dump with many sequences Euler Taveira <[email protected]>
2024-07-12 02:09 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-16 21:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 02:30 ` Re: improve performance of pg_dump with many sequences Michael Paquier <[email protected]>
2024-07-17 03:23 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:48 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 18:59 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-17 19:05 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-17 19:11 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 03:45 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 03:58 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2024-07-18 18:22 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-18 20:29 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-24 18:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2024-07-31 15:19 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2025-12-29 17:26 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:06 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-07 23:13 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-07 23:27 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 00:24 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 17:36 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 18:19 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-08 19:34 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[email protected]>
2026-01-08 19:54 ` Re: improve performance of pg_dump with many sequences Tom Lane <[email protected]>
2026-01-09 16:17 ` Re: improve performance of pg_dump with many sequences Nathan Bossart <[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