public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Remove PROC_IN_ANALYZE
39+ messages / 8 participants
[nested] [flat]
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* [PATCH] Remove PROC_IN_ANALYZE
@ 2020-08-05 22:57 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw)
---
src/backend/commands/analyze.c | 13 +------------
src/include/storage/proc.h | 3 +--
src/include/storage/procarray.h | 7 -------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 924ef37c81..e0fa73ba79 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation,
}
/*
- * OK, let's do it. First let other backends know I'm in ANALYZE.
+ * OK, let's do it. First, initialize progress reporting.
*/
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags |= PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE,
RelationGetRelid(onerel));
@@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation,
relation_close(onerel, NoLock);
pgstat_progress_end_command();
-
- /*
- * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel,
- * because the vacuum flag is cleared by the end-of-xact code.
- */
- LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
- MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE;
- LWLockRelease(ProcArrayLock);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index b20e2ad4f6..5ceb2494ba 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -52,7 +52,6 @@ struct XidCache
*/
#define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */
#define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */
-#define PROC_IN_ANALYZE 0x04 /* currently running analyze */
#define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */
#define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical
* decoding outside xact */
@@ -60,7 +59,7 @@ struct XidCache
/* flags reset at EOXact */
#define PROC_VACUUM_STATE_MASK \
- (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND)
+ (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND)
/*
* We allow a small number of "weak" relation locks (AccessShareLock,
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..01040d76e1 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -29,8 +29,6 @@
*/
#define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy
* vacuum */
-#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running
- * analyze */
#define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical
* decoding outside xact */
@@ -42,7 +40,6 @@
* have no corresponding PROC flag equivalent.
*/
#define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \
- PROCARRAY_ANALYZE_FLAG | \
PROCARRAY_LOGICAL_DECODING_FLAG)
/* Use the following flags as an input "flags" to GetOldestXmin function */
@@ -50,10 +47,6 @@
#define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG
/* Ignore vacuum backends */
#define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG
-/* Ignore analyze backends */
-#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG
-/* Ignore both vacuum and analyze backends */
-#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG
extern Size ProcArrayShmemSize(void);
extern void CreateSharedProcArray(void);
--
2.20.1
--Kj7319i9nmIyA2yE--
^ permalink raw reply [nested|flat] 39+ messages in thread
* An incorrect check in get_memoize_path
@ 2025-04-07 07:50 Richard Guo <[email protected]>
0 siblings, 2 replies; 39+ messages in thread
From: Richard Guo @ 2025-04-07 07:50 UTC (permalink / raw)
To: Pg Hackers <[email protected]>
While reviewing another patch [1], I noticed an incorrect check in
get_memoize_path.
if (extra->inner_unique &&
(inner_path->param_info == NULL ||
bms_num_members(inner_path->param_info->ppi_serials) <
list_length(extra->restrictlist)))
return NULL;
This check is to ensure that, for unique joins, all the restriction
clauses are parameterized to enable the use of Memoize nodes.
However, ppi_clauses includes join clauses available from all outer
rels, not just the current outer rel, while extra->restrictlist only
includes the restriction clauses for the current join. This means the
check could pass even if a restriction clause isn't parameterized, as
long as another join clause, which doesn't belong to the current join,
is included in ppi_clauses. It's not very hard to construct a query
that exposes this issue.
create table t (a int, b int);
explain (costs off)
select * from t t0 left join
(t t1 left join t t2 on t1.a = t2.a
join lateral
(select distinct on (a, b) a, b, t0.a+t1.a+t2.a as x from t t3 offset 0) t3
on t1.a = t3.a and coalesce(t2.b) = t3.b)
on t0.b = t3.b;
QUERY PLAN
---------------------------------------------------------
Nested Loop Left Join
-> Seq Scan on t t0
-> Nested Loop
Join Filter: (COALESCE(t2.b) = t3.b)
-> Hash Left Join
Hash Cond: (t1.a = t2.a)
-> Seq Scan on t t1
-> Hash
-> Seq Scan on t t2
-> Subquery Scan on t3
Filter: ((t0.b = t3.b) AND (t1.a = t3.a))
-> Unique
-> Sort
Sort Key: t3_1.a, t3_1.b
-> Seq Scan on t t3_1
(15 rows)
Consider the join to t3. It is a unique join, and not all of its
restriction clauses are parameterized. Despite this, the check still
passes.
Interestingly, although the check passes, no Memoize nodes are added
on top of t3's paths because paraminfo_get_equal_hashops insists that
all ppi_clauses must satisfy clause_sides_match_join (though I
actually question whether this is necessary, but that's a separate
issue). However, this does not justify the check being correct.
Hence, I propose the attached patch for the fix.
BTW, there is a XXX comment there saying that maybe we can make the
remaining join quals part of the inner scan's filter instead of the
join filter. I don't think this is possible in all cases. In the
above query, 'coalesce(t2.b) = t3.b' cannot be made part of t3's scan
filter, according to join_clause_is_movable_into. So I removed that
comment in the patch while we're here.
Any thoughts?
[1] https://postgr.es/m/[email protected]
Thanks
Richard
Attachments:
[application/octet-stream] v1-0001-Fix-an-incorrect-check-in-get_memoize_path.patch (1.5K, ../../CAMbWs4-8JPouj=wBDj4DhK-WO4+Xdx=A2jbjvvyyTBQneJ1=BQ@mail.gmail.com/2-v1-0001-Fix-an-incorrect-check-in-get_memoize_path.patch)
download | inline diff:
From f1664f031f98ac20b4d810eeb960fd3ad7f3abad Mon Sep 17 00:00:00 2001
From: Richard Guo <[email protected]>
Date: Mon, 7 Apr 2025 16:34:17 +0900
Subject: [PATCH v1] Fix an incorrect check in get_memoize_path
---
src/backend/optimizer/path/joinpath.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 18891ce9156..14ed9daeca8 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -748,16 +748,22 @@ get_memoize_path(PlannerInfo *root, RelOptInfo *innerrel,
*
* Lateral vars needn't be considered here as they're not considered when
* determining if the join is unique.
- *
- * XXX this could be enabled if the remaining join quals were made part of
- * the inner scan's filter instead of the join filter. Maybe it's worth
- * considering doing that?
*/
- if (extra->inner_unique &&
- (inner_path->param_info == NULL ||
- bms_num_members(inner_path->param_info->ppi_serials) <
- list_length(extra->restrictlist)))
- return NULL;
+ if (extra->inner_unique)
+ {
+ Bitmapset *ppi_serials;
+
+ if (inner_path->param_info == NULL)
+ return NULL;
+
+ ppi_serials = inner_path->param_info->ppi_serials;
+
+ foreach_node(RestrictInfo, rinfo, extra->restrictlist)
+ {
+ if (!bms_is_member(rinfo->rinfo_serial, ppi_serials))
+ return NULL;
+ }
+ }
/*
* We can't use a memoize node if there are volatile functions in the
--
2.43.0
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: An incorrect check in get_memoize_path
@ 2025-04-08 06:32 Richard Guo <[email protected]>
parent: Richard Guo <[email protected]>
1 sibling, 0 replies; 39+ messages in thread
From: Richard Guo @ 2025-04-08 06:32 UTC (permalink / raw)
To: Andrei Lepikhov <[email protected]>; +Cc: Pg Hackers <[email protected]>
On Mon, Apr 7, 2025 at 9:54 PM Andrei Lepikhov <[email protected]> wrote:
> On 4/7/25 09:50, Richard Guo wrote:
> > Consider the join to t3. It is a unique join, and not all of its
> > restriction clauses are parameterized. Despite this, the check still
> > passes.
> At the same time I think term 'Incorrect' is not good unless you show an
> example where data returned is not consistent to the expected.
> I think this inequality check has worked in couple with the
> get_equal_hashops.
Do you mean this check is designed to work in conjunction with the
clause_sides_match_join check in paraminfo_get_equal_hashops? I would
consider this a very poor design. The purpose of this check is simply
to verify whether all restriction clauses are parameterized. I don't
understand why it needs to depend on paraminfo_get_equal_hashops in
such an unexpected way to function correctly. I can't see any
advantage to this design, other than that it's prone to bugs.
Moreover, in the case where not all restriction clauses are
parameterized, why waste CPU cycles running all the code after the
check only for paraminfo_get_equal_hashops to catch it later?
Additionally, I couldn't find any comments explaining this unusual
behavior, either in the check itself or in paraminfo_get_equal_hashops.
Thanks
Richard
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: An incorrect check in get_memoize_path
@ 2025-04-14 06:49 Richard Guo <[email protected]>
parent: Richard Guo <[email protected]>
1 sibling, 1 reply; 39+ messages in thread
From: Richard Guo @ 2025-04-14 06:49 UTC (permalink / raw)
To: Pg Hackers <[email protected]>
On Mon, Apr 7, 2025 at 4:50 PM Richard Guo <[email protected]> wrote:
> Hence, I propose the attached patch for the fix.
>
> BTW, there is a XXX comment there saying that maybe we can make the
> remaining join quals part of the inner scan's filter instead of the
> join filter. I don't think this is possible in all cases. In the
> above query, 'coalesce(t2.b) = t3.b' cannot be made part of t3's scan
> filter, according to join_clause_is_movable_into. So I removed that
> comment in the patch while we're here.
>
> Any thoughts?
Here is an updated patch with a commit message. Regarding
backporting, I'm inclined not to, given the lack of field reports.
Any objections to pushing it?
Thanks
Richard
Attachments:
[application/octet-stream] v2-0001-Fix-an-incorrect-check-in-get_memoize_path.patch (3.0K, ../../CAMbWs49nbDOBo_0H6crjewDv=HxtA84rrv-70R+_yhAZom06gQ@mail.gmail.com/2-v2-0001-Fix-an-incorrect-check-in-get_memoize_path.patch)
download | inline diff:
From 7a4e7eec3061270942423713169dce070187548c Mon Sep 17 00:00:00 2001
From: Richard Guo <[email protected]>
Date: Mon, 7 Apr 2025 16:34:17 +0900
Subject: [PATCH v2] Fix an incorrect check in get_memoize_path
Memoize typically marks cache entries as complete after fully scanning
the inner side of a join. However, in the case of unique joins, we
skip to the next outer tuple as soon as the first matching inner tuple
is found, leaving no opportunity to scan the inner side to completion.
To work around that, we mark cache entries as complete after fetching
the first matching inner tuple in unique joins.
This approach is only safe when all of the join's restriction clauses
are parameterized; otherwise, there is no guarantee that reading just
one tuple from the inner side is sufficient.
Currently, we check for this by verifying that the number of clauses
in ppi_clauses is no less than the number of the join's restriction
clauses. However, this check isn't entirely reliable, as ppi_clauses
includes join clauses available from all outer rels, not just the
current outer rel. This means the check could pass even if a
restriction clause isn't parameterized, as long as another join
clause, which doesn't belong to the current join, is included in
ppi_clauses.
To fix this, we explicitly check whether each restriction clause of
the current join is present in ppi_clauses.
While we're here, remove the XXX comment from the modified code, as
it's not justified; in certain cases, it's not possible to move a join
clause to the inner side.
This is arguably a bugfix, but no backpatch given the lack of field
reports.
Author: Richard Guo <[email protected]>
Discussion: https://postgr.es/m/CAMbWs4-8JPouj=wBDj4DhK-WO4+Xdx=A2jbjvvyyTBQneJ1=BQ@mail.gmail.com
---
src/backend/optimizer/path/joinpath.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 18891ce9156..14ed9daeca8 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -748,16 +748,22 @@ get_memoize_path(PlannerInfo *root, RelOptInfo *innerrel,
*
* Lateral vars needn't be considered here as they're not considered when
* determining if the join is unique.
- *
- * XXX this could be enabled if the remaining join quals were made part of
- * the inner scan's filter instead of the join filter. Maybe it's worth
- * considering doing that?
*/
- if (extra->inner_unique &&
- (inner_path->param_info == NULL ||
- bms_num_members(inner_path->param_info->ppi_serials) <
- list_length(extra->restrictlist)))
- return NULL;
+ if (extra->inner_unique)
+ {
+ Bitmapset *ppi_serials;
+
+ if (inner_path->param_info == NULL)
+ return NULL;
+
+ ppi_serials = inner_path->param_info->ppi_serials;
+
+ foreach_node(RestrictInfo, rinfo, extra->restrictlist)
+ {
+ if (!bms_is_member(rinfo->rinfo_serial, ppi_serials))
+ return NULL;
+ }
+ }
/*
* We can't use a memoize node if there are volatile functions in the
--
2.43.0
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: An incorrect check in get_memoize_path
@ 2025-04-16 02:11 Richard Guo <[email protected]>
parent: Richard Guo <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Richard Guo @ 2025-04-16 02:11 UTC (permalink / raw)
To: wenhui qiu <[email protected]>; +Cc: Andrei Lepikhov <[email protected]>; Pg Hackers <[email protected]>
On Mon, Apr 14, 2025 at 8:08 PM wenhui qiu <[email protected]> wrote:
> No objections.It's a pity that the postgresql18 version has been code-frozen
v18 is now in feature freeze, but not code freeze, so bug fixes are
still allowed. I've pushed this patch after adding the "Reviewed-by"
tags.
Thanks
Richard
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-02-18 07:16 Shinya Kato <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Shinya Kato @ 2026-02-18 07:16 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
On Sat, Nov 15, 2025 at 2:05 AM Nathan Bossart <[email protected]> wrote:
> I don't know about you, but I start getting antsy around a quarter tank.
> In any case, I'm told that even 40M transactions aren't enough time to
> react these days. Attached are a few patches to enhance the wraparound
> warnings.
Thank you for the patch!
> * 0001 adds a "percent remaining" detail message to the existing WARNING.
> The idea is that "1.86% of transaction IDs" is both easier to understand
> and better indicates urgency than "39985967 transactions".
I like this idea and this is helpful information for DBA. 0001 looks good to me.
> * 0002 bumps the warning limit from 40M to 100M to give folks some more
> time to react.
I don't have a strong opinion on whether 100M is the right value, but
I noticed a documentation issue in 0002.
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
DETAIL: Approximately 1.86% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide
VACUUM in that database.
</programlisting>
In maintenance.sgml, above "39985967" and "1.86%" should be updated.
> * 0003 adds an early warning system for when fewer than 500M transactions
> remain. This system sends a LOG only to the server log every 1M
> transactions. The hope is that this gets someone's attention sooner
> without flooding the application and server log.
I'm not sure 0003 is worth the added complexity. It adds a new field
to TransamVariablesData and a modulo check in GetNewTransactionId(),
which is a hot path. DBAs who need early warning can already monitor
age(datfrozenxid) with more flexible thresholds.
--
Best regards,
Shinya Kato
NTT OSS Center
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-03-03 20:31 Nathan Bossart <[email protected]>
parent: Shinya Kato <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Nathan Bossart @ 2026-03-03 20:31 UTC (permalink / raw)
To: Shinya Kato <[email protected]>; +Cc: pgsql-hackers
On Wed, Feb 18, 2026 at 04:16:16PM +0900, Shinya Kato wrote:
> On Sat, Nov 15, 2025 at 2:05 AM Nathan Bossart <[email protected]> wrote:
>> I don't know about you, but I start getting antsy around a quarter tank.
>> In any case, I'm told that even 40M transactions aren't enough time to
>> react these days. Attached are a few patches to enhance the wraparound
>> warnings.
>
> Thank you for the patch!
Thanks for reviewing.
> I don't have a strong opinion on whether 100M is the right value, but
> I noticed a documentation issue in 0002.
>
> <programlisting>
> WARNING: database "mydb" must be vacuumed within 39985967 transactions
> DETAIL: Approximately 1.86% of transaction IDs are available for use.
> HINT: To avoid XID assignment failures, execute a database-wide
> VACUUM in that database.
> </programlisting>
>
> In maintenance.sgml, above "39985967" and "1.86%" should be updated.
Fixed.
> I'm not sure 0003 is worth the added complexity. It adds a new field
> to TransamVariablesData and a modulo check in GetNewTransactionId(),
> which is a hot path. DBAs who need early warning can already monitor
> age(datfrozenxid) with more flexible thresholds.
Yeah, looking at this one again, I'm less sure it's worth pursuing. I've
removed it.
--
nathan
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-03-06 22:15 Nathan Bossart <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Nathan Bossart @ 2026-03-06 22:15 UTC (permalink / raw)
To: Shinya Kato <[email protected]>; +Cc: pgsql-hackers
Barring additional feedback or objections, I'm planning to commit this in
the next week or two.
--
nathan
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-03-09 12:08 wenhui qiu <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: wenhui qiu @ 2026-03-09 12:08 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Shinya Kato <[email protected]>; pgsql-hackers
Hi Nathan Bossart
> Barring additional feedback or objections, I'm planning to commit this in
> the next week or two.
Thank you for working on this. The path LGTM,But I have a small request,There
are many reasons why the table's age can’t be frozen. Now have a path that
can report the reason to users(https://commitfest.postgresql.org/patch/6188/).
Would you be interested in reviewing it? I think we should tell users the
root cause of why the age can’t be reduced, so they can clearly understand
where the issue is.I think we should not only tell users that the XID is
close to wraparound, but also report why this causes the table‘s age to be
unable to freeze.
Thanks
On Sat, Mar 7, 2026 at 6:15 AM Nathan Bossart <[email protected]>
wrote:
> Barring additional feedback or objections, I'm planning to commit this in
> the next week or two.
>
> --
> nathan
>
>
>
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-03-20 19:16 Nathan Bossart <[email protected]>
parent: wenhui qiu <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Nathan Bossart @ 2026-03-20 19:16 UTC (permalink / raw)
To: wenhui qiu <[email protected]>; +Cc: Shinya Kato <[email protected]>; pgsql-hackers
On Mon, Mar 09, 2026 at 08:08:54PM +0800, wenhui qiu wrote:
> Thank you for working on this. The path LGTM,...
Thanks for looking. Committed.
> ...But I have a small request,There
> are many reasons why the table's age can’t be frozen. Now have a path that
> can report the reason to users(https://commitfest.postgresql.org/patch/6188/).
> Would you be interested in reviewing it? I think we should tell users the
> root cause of why the age can’t be reduced, so they can clearly understand
> where the issue is.I think we should not only tell users that the XID is
> close to wraparound, but also report why this causes the table‘s age to be
> unable to freeze.
Thanks for alerting me to this patch.
--
nathan
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-19 18:13 Fujii Masao <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Fujii Masao @ 2026-06-19 18:13 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
On Sat, Mar 21, 2026 at 4:16 AM Nathan Bossart <[email protected]> wrote:
>
> On Mon, Mar 09, 2026 at 08:08:54PM +0800, wenhui qiu wrote:
> > Thank you for working on this. The path LGTM,...
>
> Thanks for looking. Committed.
Thanks for working on this feature! I have one comment.
ereport(WARNING,
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - xid),
+ errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ (double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
errhint("To avoid transaction ID assignment failures, execute a
database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared
transactions, or drop stale replication slots.")));
The new DETAIL messages for XID and MultiXactId wraparound warnings
seem misleading.
The percentage is calculated as (xidWrapLimit - xid) divided by half
of the ID space. This represents the remaining ID space before wraparound,
not the percentage of IDs that are still available for use. Since
PostgreSQL stops assigning new XIDs/MultiXactIds at the stop limit
before reaching the wraparound limit, the current wording could be
interpreted as overstating how many IDs remain usable.
So, how about changing the wording to match the calculation? For example:
Approximately XX.XX% of transaction ID space remains before wraparound.
and similarly for MultiXactIds.
Regards,
--
Fujii Masao
Attachments:
[application/octet-stream] v1-0001-Clarify-wraparound-warning-percentage-messages.patch (7.2K, ../../CAHGQGwHWZTsR6bjdfpa+pOkBPjoXXm2LuJ+5nh+CvdyqEASHcQ@mail.gmail.com/2-v1-0001-Clarify-wraparound-warning-percentage-messages.patch)
download | inline diff:
From 37d758c78186e6848026a659ca1b35f94c49c248 Mon Sep 17 00:00:00 2001
From: "masao.fujii" <[email protected]'s-MacBook-Pro>
Date: Sat, 20 Jun 2026 02:33:37 +0900
Subject: [PATCH v1] Clarify wraparound warning percentage messages
Commit e646450e609 added DETAIL messages for XID and MultiXactId
wraparound warnings describing the reported percentage as the IDs
available for use. However, the percentage is actually calculated from
the remaining distance to the wraparound limit, not the stop limit
where new IDs are refused. As a result, the wording could be
misinterpreted as meaning that the reported percentage of IDs can still
be allocated.
Update the wording to clarify that the reported percentage represents
the remaining ID space before wraparound.
---
doc/src/sgml/maintenance.sgml | 2 +-
src/backend/access/transam/multixact.c | 8 ++++----
src/backend/access/transam/varsup.c | 8 ++++----
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index e341f165efd..a5a779e2e62 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -674,7 +674,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<programlisting>
WARNING: database "mydb" must be vacuumed within 99985967 transactions
-DETAIL: Approximately 4.66% of transaction IDs are available for use.
+DETAIL: Approximately 4.66% of transaction ID space remains before wraparound.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 10cbc0d76bd..079f5967e74 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -1070,7 +1070,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
multiWrapLimit - result,
oldest_datname,
multiWrapLimit - result),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - result) / (MaxMultiXactId / 2) * 100),
errhint("Execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -1081,7 +1081,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
multiWrapLimit - result,
oldest_datoid,
multiWrapLimit - result),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - result) / (MaxMultiXactId / 2) * 100),
errhint("Execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -2208,7 +2208,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiWrapLimit - curMulti,
oldest_datname,
multiWrapLimit - curMulti),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - curMulti) / (MaxMultiXactId / 2) * 100),
errhint("To avoid MultiXactId assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -2219,7 +2219,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiWrapLimit - curMulti,
oldest_datoid,
multiWrapLimit - curMulti),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - curMulti) / (MaxMultiXactId / 2) * 100),
errhint("To avoid MultiXactId assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index dc5e32d86f3..e0b280665cf 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -166,7 +166,7 @@ GetNewTransactionId(bool isSubXact)
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - xid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -175,7 +175,7 @@ GetNewTransactionId(bool isSubXact)
(errmsg("database with OID %u must be vacuumed within %u transactions",
oldest_datoid,
xidWrapLimit - xid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -485,7 +485,7 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - curXid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - curXid) / (MaxTransactionId / 2) * 100),
errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -494,7 +494,7 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
(errmsg("database with OID %u must be vacuumed within %u transactions",
oldest_datoid,
xidWrapLimit - curXid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - curXid) / (MaxTransactionId / 2) * 100),
errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
--
2.53.0
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-19 18:43 Nathan Bossart <[email protected]>
parent: Fujii Masao <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Nathan Bossart @ 2026-06-19 18:43 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
On Sat, Jun 20, 2026 at 03:13:23AM +0900, Fujii Masao wrote:
> The percentage is calculated as (xidWrapLimit - xid) divided by half
> of the ID space. This represents the remaining ID space before wraparound,
> not the percentage of IDs that are still available for use. Since
> PostgreSQL stops assigning new XIDs/MultiXactIds at the stop limit
> before reaching the wraparound limit, the current wording could be
> interpreted as overstating how many IDs remain usable.
>
> So, how about changing the wording to match the calculation? For example:
>
> Approximately XX.XX% of transaction ID space remains before wraparound.
>
> and similarly for MultiXactIds.
That seems reasonable to me, thanks.
--
nathan
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-20 11:54 Fujii Masao <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Fujii Masao @ 2026-06-20 11:54 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
On Sat, Jun 20, 2026 at 3:43 AM Nathan Bossart <[email protected]> wrote:
>
> On Sat, Jun 20, 2026 at 03:13:23AM +0900, Fujii Masao wrote:
> > The percentage is calculated as (xidWrapLimit - xid) divided by half
> > of the ID space. This represents the remaining ID space before wraparound,
> > not the percentage of IDs that are still available for use. Since
> > PostgreSQL stops assigning new XIDs/MultiXactIds at the stop limit
> > before reaching the wraparound limit, the current wording could be
> > interpreted as overstating how many IDs remain usable.
> >
> > So, how about changing the wording to match the calculation? For example:
> >
> > Approximately XX.XX% of transaction ID space remains before wraparound.
> >
> > and similarly for MultiXactIds.
>
> That seems reasonable to me, thanks.
Thanks for the review!
While reading the related log messages again, I noticed that in three of
the four XID wraparound warnings in varsup.c, the HINT still uses "XID"
while the DETAIL message uses "transaction ID". Commit edee0c621de
updated the remaining warning to use "transaction ID",
but seems to have missed the other three. Since using different terms
for the same thing in the DETAIL and HINT messages seems
inconsistent, I included the following changes in the patch. Or would
it be better to do this in a separate patch?
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains
before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide
VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a
database-wide VACUUM in that database.\n"
I also updated the comments in
src/test/modules/xid_wraparound/t/002_limits.pl, which contain
examples of the XID wraparound warnings.
Attached is the updated patch.
While making these changes, I also noticed that although commit
edee0c621de updated the runtime XID wraparound messages to use
"transaction IDs", the corresponding examples and text in
maintenance.sgml still use the older "XID" terminology. I therefore
created an additional patch (0002) to update the documentation to
match the current messages. I think this should be backpatched to v17.
Thought?
Regards,
--
Fujii Masao
Attachments:
[application/octet-stream] v2-0001-Clarify-wraparound-warning-percentage-messages.patch (8.5K, ../../CAHGQGwHTN-Xc5iDtbzNSjfxuab5Y9qAArw8cB4PrrDJpZ+1fgA@mail.gmail.com/2-v2-0001-Clarify-wraparound-warning-percentage-messages.patch)
download | inline diff:
From 011fa9d25af818d79c22b7159c3788dd294a1b09 Mon Sep 17 00:00:00 2001
From: "masao.fujii" <[email protected]'s-MacBook-Pro>
Date: Sat, 20 Jun 2026 19:49:58 +0900
Subject: [PATCH v2 1/2] Clarify wraparound warning percentage messages
Commit e646450e609 added DETAIL messages for XID and MultiXactId
wraparound warnings describing the reported percentage as the IDs
available for use. However, the percentage is actually calculated from
the remaining distance to the wraparound limit, not the stop limit
where new IDs are refused. As a result, the wording could be
misinterpreted as meaning that the reported percentage of IDs can still
be allocated.
Update the wording to clarify that the reported percentage represents
the remaining ID space before wraparound.
Also update the related XID warning hints to use "transaction ID"
terminology consistently.
---
doc/src/sgml/maintenance.sgml | 2 +-
src/backend/access/transam/multixact.c | 8 ++++----
src/backend/access/transam/varsup.c | 14 +++++++-------
src/test/modules/xid_wraparound/t/002_limits.pl | 3 ++-
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index e341f165efd..a5a779e2e62 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -674,7 +674,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<programlisting>
WARNING: database "mydb" must be vacuumed within 99985967 transactions
-DETAIL: Approximately 4.66% of transaction IDs are available for use.
+DETAIL: Approximately 4.66% of transaction ID space remains before wraparound.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 10cbc0d76bd..079f5967e74 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -1070,7 +1070,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
multiWrapLimit - result,
oldest_datname,
multiWrapLimit - result),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - result) / (MaxMultiXactId / 2) * 100),
errhint("Execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -1081,7 +1081,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
multiWrapLimit - result,
oldest_datoid,
multiWrapLimit - result),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - result) / (MaxMultiXactId / 2) * 100),
errhint("Execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -2208,7 +2208,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiWrapLimit - curMulti,
oldest_datname,
multiWrapLimit - curMulti),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - curMulti) / (MaxMultiXactId / 2) * 100),
errhint("To avoid MultiXactId assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -2219,7 +2219,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiWrapLimit - curMulti,
oldest_datoid,
multiWrapLimit - curMulti),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactId space remains before wraparound.",
(double) (multiWrapLimit - curMulti) / (MaxMultiXactId / 2) * 100),
errhint("To avoid MultiXactId assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index dc5e32d86f3..cb68d8fa974 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -166,7 +166,7 @@ GetNewTransactionId(bool isSubXact)
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - xid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -175,9 +175,9 @@ GetNewTransactionId(bool isSubXact)
(errmsg("database with OID %u must be vacuumed within %u transactions",
oldest_datoid,
xidWrapLimit - xid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
}
@@ -485,18 +485,18 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - curXid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - curXid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
else
ereport(WARNING,
(errmsg("database with OID %u must be vacuumed within %u transactions",
oldest_datoid,
xidWrapLimit - curXid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains before wraparound.",
(double) (xidWrapLimit - curXid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
}
}
diff --git a/src/test/modules/xid_wraparound/t/002_limits.pl b/src/test/modules/xid_wraparound/t/002_limits.pl
index 86632a8d510..29d071a677b 100644
--- a/src/test/modules/xid_wraparound/t/002_limits.pl
+++ b/src/test/modules/xid_wraparound/t/002_limits.pl
@@ -70,7 +70,8 @@ $node->safe_psql('postgres',
# the warning:
#
# WARNING: database "postgres" must be vacuumed within 3000024 transactions
-# HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
+# DETAIL: Approximately 0.14% of transaction ID space remains before wraparound.
+# HINT: To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.
# You might also need to commit or roll back old prepared transactions, or drop stale replication slots.
my $stderr;
my $warn_limit = 0;
--
2.53.0
[application/octet-stream] v2-0002-doc-Update-wraparound-examples-to-say-transaction.patch (2.2K, ../../CAHGQGwHTN-Xc5iDtbzNSjfxuab5Y9qAArw8cB4PrrDJpZ+1fgA@mail.gmail.com/3-v2-0002-doc-Update-wraparound-examples-to-say-transaction.patch)
download | inline diff:
From 6d1a0eb207cca2e70516fdffb60be7689ba4b8d7 Mon Sep 17 00:00:00 2001
From: "masao.fujii" <[email protected]'s-MacBook-Pro>
Date: Sat, 20 Jun 2026 19:50:03 +0900
Subject: [PATCH v2 2/2] doc: Update wraparound examples to say transaction IDs
Commit edee0c621de changed the runtime XID wraparound messages to
use "transaction IDs" terminology, but the corresponding
examples and text in maintenance.sgml still used the older XID wording.
Update those documentation examples into line with the current runtime
messages.
Backpatch to v17, where the runtime messages were changed.
---
doc/src/sgml/maintenance.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index a5a779e2e62..8043fb36625 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -675,18 +675,18 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<programlisting>
WARNING: database "mydb" must be vacuumed within 99985967 transactions
DETAIL: Approximately 4.66% of transaction ID space remains before wraparound.
-HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
+HINT: To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
(A manual <command>VACUUM</command> should fix the problem, as suggested by the
hint; but note that the <command>VACUUM</command> should be performed by a
superuser, else it will fail to process system catalogs, which prevent it from
being able to advance the database's <structfield>datfrozenxid</structfield>.)
- If these warnings are ignored, the system will refuse to assign new XIDs once
+ If these warnings are ignored, the system will refuse to assign new transaction IDs once
there are fewer than three million transactions left until wraparound:
<programlisting>
-ERROR: database is not accepting commands that assign new XIDs to avoid wraparound data loss in database "mydb"
+ERROR: database is not accepting commands that assign new transaction IDs to avoid wraparound data loss in database "mydb"
HINT: Execute a database-wide VACUUM in that database.
</programlisting>
--
2.53.0
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-24 04:47 Bharath Rupireddy <[email protected]>
parent: Fujii Masao <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Bharath Rupireddy @ 2026-06-24 04:47 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Nathan Bossart <[email protected]>; wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
Hi,
On Sat, Jun 20, 2026 at 4:54 AM Fujii Masao <[email protected]> wrote:
>
> While making these changes, I also noticed that although commit
> edee0c621de updated the runtime XID wraparound messages to use
> "transaction IDs", the corresponding examples and text in
> maintenance.sgml still use the older "XID" terminology. I therefore
> created an additional patch (0002) to update the documentation to
> match the current messages. I think this should be backpatched to v17.
>
> Thought?
I happened to quickly review these patches. TBH, "transaction ID
space" and "MultiXactId space" seem a bit confusing because of the
word "space" - it reads fine without it. Is there a specific reason
for this wording?
Also, why not use "multixact IDs" instead of "MultiXactId"? The latter
reads like an internal structure name or such that might confuse users
reading the docs or error messages.
How about something like the following?
+ errdetail("Approximately %.2f%% of multixact IDs remain before wraparound.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-24 12:53 Fujii Masao <[email protected]>
parent: Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Fujii Masao @ 2026-06-24 12:53 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Nathan Bossart <[email protected]>; wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
On Wed, Jun 24, 2026 at 1:47 PM Bharath Rupireddy
<[email protected]> wrote:
> I happened to quickly review these patches.
Thanks for the review!
> TBH, "transaction ID
> space" and "MultiXactId space" seem a bit confusing because of the
> word "space" - it reads fine without it. Is there a specific reason
> for this wording?
I was thinking "space" was appropriate here because the message is intended
to express the percentage remaining before wraparound in the ID range.
The documentation also uses expressions such as "normal XID space is ...".
But I'm not a native English speaker, so this wording might be wrong.
> Also, why not use "multixact IDs" instead of "MultiXactId"? The latter
> reads like an internal structure name or such that might confuse users
> reading the docs or error messages.
I left "MultiXactId" unchanged because several existing log messages
use that term. I don't have any strong objection to changing it to
"multixact ID", which is already used in the documentation. However, if
we do that, I think it's better update all log messages that use
"MultiXactId" for consistency, probably as a separate patch. That seems
more like a v20 item to me, though.
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-25 17:19 Bharath Rupireddy <[email protected]>
parent: Fujii Masao <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Bharath Rupireddy @ 2026-06-25 17:19 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Nathan Bossart <[email protected]>; wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
Hi,
On Wed, Jun 24, 2026 at 5:53 AM Fujii Masao <[email protected]> wrote:
>
> > TBH, "transaction ID
> > space" and "MultiXactId space" seem a bit confusing because of the
> > word "space" - it reads fine without it. Is there a specific reason
> > for this wording?
>
> I was thinking "space" was appropriate here because the message is intended
> to express the percentage remaining before wraparound in the ID range.
> The documentation also uses expressions such as "normal XID space is ...".
The use there is referring to the whole set of transaction IDs and how
one can visualize the use of them - so "XID space" in that context
seems fine to me.
But the wraparound warnings read better when they say how many more
transaction IDs are left:
+ errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
> > Also, why not use "multixact IDs" instead of "MultiXactId"? The latter
> > reads like an internal structure name or such that might confuse users
> > reading the docs or error messages.
>
> I left "MultiXactId" unchanged because several existing log messages
> use that term. I don't have any strong objection to changing it to
> "multixact ID", which is already used in the documentation. However, if
> we do that, I think it's better update all log messages that use
> "MultiXactId" for consistency, probably as a separate patch. That seems
> more like a v20 item to me, though.
I'm fine to leave "MultiXactIds" as-is - IMHO, it's not worth the cycles.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-26 00:51 Fujii Masao <[email protected]>
parent: Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Fujii Masao @ 2026-06-26 00:51 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Nathan Bossart <[email protected]>; wenhui qiu <[email protected]>; Shinya Kato <[email protected]>; pgsql-hackers
On Fri, Jun 26, 2026 at 2:19 AM Bharath Rupireddy
<[email protected]> wrote:
> The use there is referring to the whole set of transaction IDs and how
> one can visualize the use of them - so "XID space" in that context
> seems fine to me.
>
> But the wraparound warnings read better when they say how many more
> transaction IDs are left:
>
> + errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
> + errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
Okay, I've updated the patches as suggested. The updated patches are attached.
Regards,
--
Fujii Masao
Attachments:
[application/octet-stream] v3-0001-Clarify-wraparound-warning-percentage-messages.patch (8.4K, ../../CAHGQGwHHPzYw2qbtwdkmyC+3pLW1aT1p6gUKx4WWhANiJhob2g@mail.gmail.com/2-v3-0001-Clarify-wraparound-warning-percentage-messages.patch)
download | inline diff:
From 60833ae74d510e6b4f447905da260433f4546569 Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Fri, 26 Jun 2026 09:11:03 +0900
Subject: [PATCH v3 1/2] Clarify wraparound warning percentage messages
Commit e646450e609 added DETAIL messages for XID and MultiXactId
wraparound warnings describing the reported percentage as the IDs
available for use. However, the percentage is actually calculated from
the remaining distance to the wraparound limit, not the stop limit
where new IDs are refused. As a result, the wording could be
misinterpreted as meaning that the reported percentage of IDs can still
be allocated.
Update the wording to clarify that the reported percentage represents
the remaining IDs before wraparound.
Also update the related XID warning hints to use "transaction ID"
terminology consistently.
---
doc/src/sgml/maintenance.sgml | 2 +-
src/backend/access/transam/multixact.c | 8 ++++----
src/backend/access/transam/varsup.c | 14 +++++++-------
src/test/modules/xid_wraparound/t/002_limits.pl | 3 ++-
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index e341f165efd..2932ba6a30a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -674,7 +674,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<programlisting>
WARNING: database "mydb" must be vacuumed within 99985967 transactions
-DETAIL: Approximately 4.66% of transaction IDs are available for use.
+DETAIL: Approximately 4.66% of transaction IDs remain before wraparound.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 10cbc0d76bd..7ce615c3eb9 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -1070,7 +1070,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
multiWrapLimit - result,
oldest_datname,
multiWrapLimit - result),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
(double) (multiWrapLimit - result) / (MaxMultiXactId / 2) * 100),
errhint("Execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -1081,7 +1081,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
multiWrapLimit - result,
oldest_datoid,
multiWrapLimit - result),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
(double) (multiWrapLimit - result) / (MaxMultiXactId / 2) * 100),
errhint("Execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -2208,7 +2208,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiWrapLimit - curMulti,
oldest_datname,
multiWrapLimit - curMulti),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
(double) (multiWrapLimit - curMulti) / (MaxMultiXactId / 2) * 100),
errhint("To avoid MultiXactId assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -2219,7 +2219,7 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiWrapLimit - curMulti,
oldest_datoid,
multiWrapLimit - curMulti),
- errdetail("Approximately %.2f%% of MultiXactIds are available for use.",
+ errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
(double) (multiWrapLimit - curMulti) / (MaxMultiXactId / 2) * 100),
errhint("To avoid MultiXactId assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index dc5e32d86f3..d61fe68210e 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -166,7 +166,7 @@ GetNewTransactionId(bool isSubXact)
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - xid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
@@ -175,9 +175,9 @@ GetNewTransactionId(bool isSubXact)
(errmsg("database with OID %u must be vacuumed within %u transactions",
oldest_datoid,
xidWrapLimit - xid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
(double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
}
@@ -485,18 +485,18 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
(errmsg("database \"%s\" must be vacuumed within %u transactions",
oldest_datname,
xidWrapLimit - curXid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
(double) (xidWrapLimit - curXid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
else
ereport(WARNING,
(errmsg("database with OID %u must be vacuumed within %u transactions",
oldest_datoid,
xidWrapLimit - curXid),
- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
(double) (xidWrapLimit - curXid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.\n"
"You might also need to commit or roll back old prepared transactions, or drop stale replication slots.")));
}
}
diff --git a/src/test/modules/xid_wraparound/t/002_limits.pl b/src/test/modules/xid_wraparound/t/002_limits.pl
index 86632a8d510..236bea2588c 100644
--- a/src/test/modules/xid_wraparound/t/002_limits.pl
+++ b/src/test/modules/xid_wraparound/t/002_limits.pl
@@ -70,7 +70,8 @@ $node->safe_psql('postgres',
# the warning:
#
# WARNING: database "postgres" must be vacuumed within 3000024 transactions
-# HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
+# DETAIL: Approximately 0.14% of transaction IDs remain before wraparound.
+# HINT: To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.
# You might also need to commit or roll back old prepared transactions, or drop stale replication slots.
my $stderr;
my $warn_limit = 0;
--
2.53.0
[application/octet-stream] v3-0002-doc-Update-wraparound-examples-to-say-transaction.patch (2.2K, ../../CAHGQGwHHPzYw2qbtwdkmyC+3pLW1aT1p6gUKx4WWhANiJhob2g@mail.gmail.com/3-v3-0002-doc-Update-wraparound-examples-to-say-transaction.patch)
download | inline diff:
From 27d395abaad4e8d9c2220245e7b5101d5e65b4d6 Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Fri, 26 Jun 2026 08:33:10 +0900
Subject: [PATCH v3 2/2] doc: Update wraparound examples to say transaction IDs
Commit edee0c621de changed the runtime XID wraparound messages to
use "transaction IDs" terminology, but the corresponding
examples and text in maintenance.sgml still used the older XID wording.
Update those documentation examples into line with the current runtime
messages.
Backpatch to v17, where the runtime messages were changed.
---
doc/src/sgml/maintenance.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 2932ba6a30a..add170e5737 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -675,18 +675,18 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<programlisting>
WARNING: database "mydb" must be vacuumed within 99985967 transactions
DETAIL: Approximately 4.66% of transaction IDs remain before wraparound.
-HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
+HINT: To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
(A manual <command>VACUUM</command> should fix the problem, as suggested by the
hint; but note that the <command>VACUUM</command> should be performed by a
superuser, else it will fail to process system catalogs, which prevent it from
being able to advance the database's <structfield>datfrozenxid</structfield>.)
- If these warnings are ignored, the system will refuse to assign new XIDs once
+ If these warnings are ignored, the system will refuse to assign new transaction IDs once
there are fewer than three million transactions left until wraparound:
<programlisting>
-ERROR: database is not accepting commands that assign new XIDs to avoid wraparound data loss in database "mydb"
+ERROR: database is not accepting commands that assign new transaction IDs to avoid wraparound data loss in database "mydb"
HINT: Execute a database-wide VACUUM in that database.
</programlisting>
--
2.53.0
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-26 01:55 Kyotaro Horiguchi <[email protected]>
parent: Fujii Masao <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Kyotaro Horiguchi @ 2026-06-26 01:55 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; pgsql-hackers
Hello,
At Fri, 26 Jun 2026 09:51:16 +0900, Fujii Masao <[email protected]> wrote in
> On Fri, Jun 26, 2026 at 2:19 AM Bharath Rupireddy
> <[email protected]> wrote:
> > The use there is referring to the whole set of transaction IDs and how
> > one can visualize the use of them - so "XID space" in that context
> > seems fine to me.
> >
> > But the wraparound warnings read better when they say how many more
> > transaction IDs are left:
> >
> > + errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
> > + errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",
>
> Okay, I've updated the patches as suggested. The updated patches are attached.
I'm not sure I'm following this correctly, but the explanation above
sounded to me as if the warning should report the number of IDs
remaining before wraparound, e.g. "Approximately N MultiXactIds remain
before wraparound", so I'm a bit confused by the proposed wording.
> + errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
The attached patch adopts that wording. However, I'm not sure how to
interpret it. The value is still expressed as a percentage, but it is
no longer clear what that percentage is relative to.
Whichever approach we choose, I think the wording should be explicit.
If the value is reported as a percentage, then something like "x.xx%
of MultiXactId space remains" seems clearer to me. If it is reported
as a count, then "N MultiXactIds remain" would make more sense.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-26 18:06 Nathan Bossart <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 39+ messages in thread
From: Nathan Bossart @ 2026-06-26 18:06 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; pgsql-hackers
On Fri, Jun 26, 2026 at 10:55:39AM +0900, Kyotaro Horiguchi wrote:
> I'm not sure I'm following this correctly, but the explanation above
> sounded to me as if the warning should report the number of IDs
> remaining before wraparound, e.g. "Approximately N MultiXactIds remain
> before wraparound", so I'm a bit confused by the proposed wording.
We already report the number of IDs remaining in the WARNING message. In
v19, I've added a DETAIL message that also reports the percentage
remaining, with the hope that it makes the urgency clearer.
>> + errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
>
> The attached patch adopts that wording. However, I'm not sure how to
> interpret it. The value is still expressed as a percentage, but it is
> no longer clear what that percentage is relative to.
>
> Whichever approach we choose, I think the wording should be explicit.
> If the value is reported as a percentage, then something like "x.xx%
> of MultiXactId space remains" seems clearer to me. If it is reported
> as a count, then "N MultiXactIds remain" would make more sense.
I find both "percentage of IDs remaining" and "percentage of ID space
remaining" equally clear and have no strong opinion on the matter.
--
nathan
^ permalink raw reply [nested|flat] 39+ messages in thread
* Re: enhance wraparound warnings
@ 2026-06-26 22:18 Bharath Rupireddy <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 0 replies; 39+ messages in thread
From: Bharath Rupireddy @ 2026-06-26 22:18 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; [email protected]; [email protected]; [email protected]; pgsql-hackers
Hi,
On Fri, Jun 26, 2026 at 11:06 AM Nathan Bossart
<[email protected]> wrote:
>
> On Fri, Jun 26, 2026 at 10:55:39AM +0900, Kyotaro Horiguchi wrote:
> > I'm not sure I'm following this correctly, but the explanation above
> > sounded to me as if the warning should report the number of IDs
> > remaining before wraparound, e.g. "Approximately N MultiXactIds remain
> > before wraparound", so I'm a bit confused by the proposed wording.
>
> We already report the number of IDs remaining in the WARNING message. In
> v19, I've added a DETAIL message that also reports the percentage
> remaining, with the hope that it makes the urgency clearer.
Yes. For example: WARNING: database "mydb" must be vacuumed within
99985967 transactions
> >> + errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
> >
> > The attached patch adopts that wording. However, I'm not sure how to
> > interpret it. The value is still expressed as a percentage, but it is
> > no longer clear what that percentage is relative to.
> >
> > Whichever approach we choose, I think the wording should be explicit.
> > If the value is reported as a percentage, then something like "x.xx%
> > of MultiXactId space remains" seems clearer to me. If it is reported
> > as a count, then "N MultiXactIds remain" would make more sense.
>
> I find both "percentage of IDs remaining" and "percentage of ID space
> remaining" equally clear and have no strong opinion on the matter.
My initial comment was that "IDs remaining" reads more naturally to me
than "ID space remaining," but I'm happy to go with the majority here.
IMHO, no need to spend more cycles on this.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 39+ messages in thread
end of thread, other threads:[~2026-06-26 22:18 UTC | newest]
Thread overview: 39+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]>
2025-04-07 07:50 An incorrect check in get_memoize_path Richard Guo <[email protected]>
2025-04-08 06:32 ` Re: An incorrect check in get_memoize_path Richard Guo <[email protected]>
2025-04-14 06:49 ` Re: An incorrect check in get_memoize_path Richard Guo <[email protected]>
2025-04-16 02:11 ` Re: An incorrect check in get_memoize_path Richard Guo <[email protected]>
2026-02-18 07:16 Re: enhance wraparound warnings Shinya Kato <[email protected]>
2026-03-03 20:31 ` Re: enhance wraparound warnings Nathan Bossart <[email protected]>
2026-03-06 22:15 ` Re: enhance wraparound warnings Nathan Bossart <[email protected]>
2026-03-09 12:08 ` Re: enhance wraparound warnings wenhui qiu <[email protected]>
2026-03-20 19:16 ` Re: enhance wraparound warnings Nathan Bossart <[email protected]>
2026-06-19 18:13 ` Re: enhance wraparound warnings Fujii Masao <[email protected]>
2026-06-19 18:43 ` Re: enhance wraparound warnings Nathan Bossart <[email protected]>
2026-06-20 11:54 ` Re: enhance wraparound warnings Fujii Masao <[email protected]>
2026-06-24 04:47 ` Re: enhance wraparound warnings Bharath Rupireddy <[email protected]>
2026-06-24 12:53 ` Re: enhance wraparound warnings Fujii Masao <[email protected]>
2026-06-25 17:19 ` Re: enhance wraparound warnings Bharath Rupireddy <[email protected]>
2026-06-26 00:51 ` Re: enhance wraparound warnings Fujii Masao <[email protected]>
2026-06-26 01:55 ` Re: enhance wraparound warnings Kyotaro Horiguchi <[email protected]>
2026-06-26 18:06 ` Re: enhance wraparound warnings Nathan Bossart <[email protected]>
2026-06-26 22:18 ` Re: enhance wraparound warnings Bharath Rupireddy <[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