pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Revert "Allow parallel workers to cope with a newly-created sess 7+ messages / 1 participants [nested] [flat]
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit 97380d4803d1f9188a1436c6fe7ecd7db285c55c. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5f851b8bd070c599e537cc8a09a237b2a42f2fbc Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit 48536305370acd75c6264fcefec7fae7af8c5440. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/afbf32fa1aa87f710b623cbdf746c55b4799574e Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit 216201027d90e99a0a2b2d2efba85dc0aac94c62. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/33c5baff66bd90c96a4ce8da4884d2c0c2b0eb35 Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit 849326e49a5dd56941eb8fb4699130c301bff303. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/33187ab5984fcbb4afc0999e478b3e965c4262ab Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit 68855c03878c0c90227e24533ca40127da3578cd. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/41fb45a482a4643e5ed44aa66f52f1512cb57ce3 Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit f5f30c22ed69fb37b896c4d4546b2ab823c3fd61. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/e6a9637488e2673efb87f8ead657789e9889fb17 Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Revert "Allow parallel workers to cope with a newly-created sess @ 2024-08-01 00:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2024-08-01 00:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Revert "Allow parallel workers to cope with a newly-created session user ID." This reverts commit 5887dd4894db5ac1c6411615160555ac6e57e49b. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap. Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/630b81d5cc00fa8bf1cb7e861a3778ed3080e621 Modified Files -------------- src/backend/access/transam/parallel.c | 12 ++++-------- src/backend/commands/variable.c | 10 ++-------- src/test/regress/expected/select_parallel.out | 18 ------------------ src/test/regress/sql/select_parallel.sql | 9 --------- 4 files changed, 6 insertions(+), 43 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-08-01 00:57 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us> 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us> 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us> 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us> 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us> 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us> 2024-08-01 00:57 pgsql: Revert "Allow parallel workers to cope with a newly-created sess Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox