agora inbox for [email protected]
help / color / mirror / Atom feed[PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
25+ messages / 3 participants
[nested] [flat]
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate
@ 2024-08-14 14:29 Nathan Bossart <[email protected]>
2024-08-14 14:38 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate SAMEER KUMAR <[email protected]>
0 siblings, 1 reply; 25+ messages in thread
From: Nathan Bossart @ 2024-08-14 14:29 UTC (permalink / raw)
To: SAMEER KUMAR <[email protected]>; +Cc: pgsql-hackers
On Thu, Jul 25, 2024 at 11:13:39AM +0800, SAMEER KUMAR wrote:
> While preparing for my presentation on PostgreSQL Wait Events at
> PgConf India, I was trying to understand *IPC:XactGroupUpdate* in more
> detail. PostgreSQL documentation [1] mentions:
>
>> A process is waiting for the group leader to update the transaction status at the end of a _parallel operation_.
>
> I looked at `TransactionGroupUpdateXidStatus` in PostgreSQL code (`clog.c`)
> Line `481` [2] sets this wait event.
>
> And after reading the code, my understanding is - It does not
> necessarily need to be a "_parallel operation_". Or maybe I am just
> misinterpreting "parallel operation" in this context. But it is
> possible for other users to confuse it with the parallel query (and
> parallel workers) feature.
>
> [...]
>
> We can add more clarity on what this wait event means. A similar
> change should be done for `ProcArrayGroupUpdate` to indicate that the
> wait event is a result of concurrent backend processes trying to clear
> the transaction id (instead of saying "parallel operation").
Both of these wait events had descriptions similar to what you are
proposing when they were first introduced (commits d4116a7 and baaf272),
but they were changed to the current wording by commit 3048898. I skimmed
through the thread for the latter commit [0] but didn't see anything that
explained why it was changed.
[0] https://postgr.es/m/21247.1589296570%40sss.pgh.pa.us
--
nathan
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate
2024-08-14 14:29 Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
@ 2024-08-14 14:38 ` SAMEER KUMAR <[email protected]>
2024-08-14 20:00 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
0 siblings, 1 reply; 25+ messages in thread
From: SAMEER KUMAR @ 2024-08-14 14:38 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
Thanks for responding.
On Wed, Aug 14, 2024 at 10:29 PM Nathan Bossart <[email protected]>
wrote:
> On Thu, Jul 25, 2024 at 11:13:39AM +0800, SAMEER KUMAR wrote:
> > While preparing for my presentation on PostgreSQL Wait Events at
> > PgConf India, I was trying to understand *IPC:XactGroupUpdate* in more
> > detail. PostgreSQL documentation [1] mentions:
> >
> >> A process is waiting for the group leader to update the transaction
> status at the end of a _parallel operation_.
> >
> > I looked at `TransactionGroupUpdateXidStatus` in PostgreSQL code
> (`clog.c`)
> > Line `481` [2] sets this wait event.
> >
> > And after reading the code, my understanding is - It does not
> > necessarily need to be a "_parallel operation_". Or maybe I am just
> > misinterpreting "parallel operation" in this context. But it is
> > possible for other users to confuse it with the parallel query (and
> > parallel workers) feature.
> >
> > [...]
> >
> > We can add more clarity on what this wait event means. A similar
> > change should be done for `ProcArrayGroupUpdate` to indicate that the
> > wait event is a result of concurrent backend processes trying to clear
> > the transaction id (instead of saying "parallel operation").
>
> Both of these wait events had descriptions similar to what you are
> proposing when they were first introduced (commits d4116a7 and baaf272),
> but they were changed to the current wording by commit 3048898. I skimmed
> through the thread for the latter commit [0] but didn't see anything that
> explained why it was changed.
>
Yes, while reviewing the history of changes, I too noticed the same. The
documentation of older versions (v12 [1]) still has old descriptions.
>
> [0] https://postgr.es/m/21247.1589296570%40sss.pgh.pa.us
>
> --
> nathan
>
[1]
https://www.postgresql.org/docs/12/monitoring-stats.html#WAIT-EVENT-TABLE
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate
2024-08-14 14:29 Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
2024-08-14 14:38 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate SAMEER KUMAR <[email protected]>
@ 2024-08-14 20:00 ` Nathan Bossart <[email protected]>
2024-08-15 03:25 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate SAMEER KUMAR <[email protected]>
0 siblings, 1 reply; 25+ messages in thread
From: Nathan Bossart @ 2024-08-14 20:00 UTC (permalink / raw)
To: SAMEER KUMAR <[email protected]>; +Cc: pgsql-hackers
On Wed, Aug 14, 2024 at 10:38:49PM +0800, SAMEER KUMAR wrote:
> Yes, while reviewing the history of changes, I too noticed the same. The
> documentation of older versions (v12 [1]) still has old descriptions.
After reading the related threads and code, I'm inclined to agree that this
is a mistake, or at least that the current wording is likely to mislead
folks into thinking it has something to do with parallel query. I noticed
that your patch changed a few things in the description, but IMHO we should
keep the fix focused, i.e., just replace "end of a parallel operation" with
"transaction end." I've attached a modified version of the patch with this
change.
--
nathan
From e23d495cae2d48e5d52810afff083e2e94df786b Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Wed, 14 Aug 2024 14:44:01 -0500
Subject: [PATCH v2 1/1] Fix a couple of wait event descriptions.
Author: Sameer Kumar
Discussion: https://postgr.es/m/CAGPeHmh6UMrKQHKCmX%2B5vV5TH9P%3DKw9en3k68qEem6J%3DyrZPUA%40mail.gmail.com
Backpatch-through: 13
---
src/backend/utils/activity/wait_event_names.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index d10ca723dc..8efb4044d6 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -143,7 +143,7 @@ MULTIXACT_CREATION "Waiting for a multixact creation to complete."
PARALLEL_BITMAP_SCAN "Waiting for parallel bitmap scan to become initialized."
PARALLEL_CREATE_INDEX_SCAN "Waiting for parallel <command>CREATE INDEX</command> workers to finish heap scan."
PARALLEL_FINISH "Waiting for parallel workers to finish computing."
-PROCARRAY_GROUP_UPDATE "Waiting for the group leader to clear the transaction ID at end of a parallel operation."
+PROCARRAY_GROUP_UPDATE "Waiting for the group leader to clear the transaction ID at transaction end."
PROC_SIGNAL_BARRIER "Waiting for a barrier event to be processed by all backends."
PROMOTE "Waiting for standby promotion."
RECOVERY_CONFLICT_SNAPSHOT "Waiting for recovery conflict resolution for a vacuum cleanup."
@@ -158,7 +158,7 @@ SYNC_REP "Waiting for confirmation from a remote server during synchronous repli
WAL_RECEIVER_EXIT "Waiting for the WAL receiver to exit."
WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for streaming replication."
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
-XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at transaction end."
ABI_compatibility:
--
2.39.3 (Apple Git-146)
Attachments:
[text/plain] v2-0001-Fix-a-couple-of-wait-event-descriptions.patch (2.1K, ../../Zr0MzxPtCL16NWk8@nathan/2-v2-0001-Fix-a-couple-of-wait-event-descriptions.patch)
download | inline diff:
From e23d495cae2d48e5d52810afff083e2e94df786b Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Wed, 14 Aug 2024 14:44:01 -0500
Subject: [PATCH v2 1/1] Fix a couple of wait event descriptions.
Author: Sameer Kumar
Discussion: https://postgr.es/m/CAGPeHmh6UMrKQHKCmX%2B5vV5TH9P%3DKw9en3k68qEem6J%3DyrZPUA%40mail.gmail.com
Backpatch-through: 13
---
src/backend/utils/activity/wait_event_names.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index d10ca723dc..8efb4044d6 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -143,7 +143,7 @@ MULTIXACT_CREATION "Waiting for a multixact creation to complete."
PARALLEL_BITMAP_SCAN "Waiting for parallel bitmap scan to become initialized."
PARALLEL_CREATE_INDEX_SCAN "Waiting for parallel <command>CREATE INDEX</command> workers to finish heap scan."
PARALLEL_FINISH "Waiting for parallel workers to finish computing."
-PROCARRAY_GROUP_UPDATE "Waiting for the group leader to clear the transaction ID at end of a parallel operation."
+PROCARRAY_GROUP_UPDATE "Waiting for the group leader to clear the transaction ID at transaction end."
PROC_SIGNAL_BARRIER "Waiting for a barrier event to be processed by all backends."
PROMOTE "Waiting for standby promotion."
RECOVERY_CONFLICT_SNAPSHOT "Waiting for recovery conflict resolution for a vacuum cleanup."
@@ -158,7 +158,7 @@ SYNC_REP "Waiting for confirmation from a remote server during synchronous repli
WAL_RECEIVER_EXIT "Waiting for the WAL receiver to exit."
WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for streaming replication."
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
-XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at transaction end."
ABI_compatibility:
--
2.39.3 (Apple Git-146)
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate
2024-08-14 14:29 Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
2024-08-14 14:38 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate SAMEER KUMAR <[email protected]>
2024-08-14 20:00 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
@ 2024-08-15 03:25 ` SAMEER KUMAR <[email protected]>
0 siblings, 0 replies; 25+ messages in thread
From: SAMEER KUMAR @ 2024-08-15 03:25 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
On Thu, Aug 15, 2024 at 4:00 AM Nathan Bossart <[email protected]>
wrote:
> On Wed, Aug 14, 2024 at 10:38:49PM +0800, SAMEER KUMAR wrote:
> > Yes, while reviewing the history of changes, I too noticed the same. The
> > documentation of older versions (v12 [1]) still has old descriptions.
>
> After reading the related threads and code, I'm inclined to agree that this
> is a mistake, or at least that the current wording is likely to mislead
> folks into thinking it has something to do with parallel query. I noticed
> that your patch changed a few things in the description, but IMHO we should
> keep the fix focused, i.e., just replace "end of a parallel operation" with
> "transaction end." I've attached a modified version of the patch with this
> change.
>
Thanks for the feedback Nathan.
I think it is important to indicate that the group leader is responsible
for clearing the transaction ID/transaction status of other backends
(including this one).
If you suggest that we keep it simple, I don't see any other issues with
your patch.
>
> --
> nathan
>
^ permalink raw reply [nested|flat] 25+ messages in thread
end of thread, other threads:[~2024-08-15 03:25 UTC | newest]
Thread overview: 25+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2024-08-14 14:29 Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
2024-08-14 14:38 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate SAMEER KUMAR <[email protected]>
2024-08-14 20:00 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate Nathan Bossart <[email protected]>
2024-08-15 03:25 ` Re: Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate SAMEER KUMAR <[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