[COMMITTERS] pgsql: Changed ecpg parser to allow RETURNING clauses without attached
Changed ecpg parser to allow RETURNING clauses without attached C variables. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ea0ca75d5d14e0c98782a2188405685af4a475a0 Modified Files -- src/interfaces/ecpg/preproc/ecpg.trailer | 7 +-- src/interfaces/ecpg/preproc/ecpg.type| 1 + src/interfaces/ecpg/preproc/parse.pl | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant. Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=r...@mail.gmail.com Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e3335ec0b6a6e037e30cb133f5ffc08c2e6a9a0c Modified Files -- config/perl.m4 | 6 -- configure| 2 +- src/tools/msvc/MSBuildProject.pm | 9 ++--- src/tools/msvc/Mkvcbuild.pm | 5 +++-- src/tools/msvc/VCBuildProject.pm | 10 ++ 5 files changed, 12 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant. Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=r...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5a5c2feca3fd858e70ea348822595547e6fa6c15 Modified Files -- config/perl.m4 | 6 -- configure| 2 +- src/tools/msvc/MSBuildProject.pm | 9 ++--- src/tools/msvc/Mkvcbuild.pm | 5 +++-- src/tools/msvc/VCBuildProject.pm | 10 ++ 5 files changed, 12 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant. Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=r...@mail.gmail.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01de7ea85378798f2ce5da93fc5ebf5c81c2453f Modified Files -- config/perl.m4 | 6 -- configure| 2 +- src/tools/msvc/MSBuildProject.pm | 9 ++--- src/tools/msvc/Mkvcbuild.pm | 5 +++-- src/tools/msvc/VCBuildProject.pm | 10 ++ 5 files changed, 12 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant. Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=r...@mail.gmail.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/25169b948e1376832f502d4899af3c3ff7f7570d Modified Files -- config/perl.m4 | 6 -- configure| 2 +- src/tools/msvc/MSBuildProject.pm | 9 ++--- src/tools/msvc/Mkvcbuild.pm | 5 +++-- src/tools/msvc/VCBuildProject.pm | 10 ++ 5 files changed, 12 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant. Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=r...@mail.gmail.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1621a75531c873e48b6edd370ba70d020cbec538 Modified Files -- config/perl.m4 | 6 -- configure| 2 +- src/tools/msvc/MSBuildProject.pm | 9 ++--- src/tools/msvc/Mkvcbuild.pm | 5 +++-- src/tools/msvc/VCBuildProject.pm | 10 ++ 5 files changed, 12 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant. Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=r...@mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3883be3eae9741f7d99862ea0be1657f6dc3e92a Modified Files -- config/perl.m4 | 6 -- configure| 2 +- src/tools/msvc/MSBuildProject.pm | 9 ++--- src/tools/msvc/Mkvcbuild.pm | 5 +++-- src/tools/msvc/VCBuildProject.pm | 10 ++ 5 files changed, 12 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Fix logical replication protocol doc detail
doc: Fix logical replication protocol doc detail Author: Masahiko Sawada Reported-by: Kyle Conroy Bug: #14775 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/79e5de690efce6e7aaa9c60e10389a8bc58c1617 Modified Files -- doc/src/sgml/protocol.sgml | 10 ++ 1 file changed, 10 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix typo
Fix typo Author: Masahiko Sawada Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7f1bb1d7346b67a62e8ec59f79f8284cb7fb4394 Modified Files -- src/backend/commands/sequence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle elog(FATAL) during ROLLBACK more robustly.
Handle elog(FATAL) during ROLLBACK more robustly. Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/877ey7bmun@ansel.ydns.eu Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5b6289c1e07dc45f09c3169a189e60d2fcaec2b3 Modified Files -- src/backend/access/transam/xact.c | 23 ++- src/backend/utils/mmgr/portalmem.c | 30 ++ 2 files changed, 44 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle elog(FATAL) during ROLLBACK more robustly.
Handle elog(FATAL) during ROLLBACK more robustly. Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/877ey7bmun@ansel.ydns.eu Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/daafb11ff539da49506aa363034efc0026a5ab66 Modified Files -- src/backend/access/transam/xact.c | 23 ++- src/backend/utils/mmgr/portalmem.c | 30 ++ 2 files changed, 44 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle elog(FATAL) during ROLLBACK more robustly.
Handle elog(FATAL) during ROLLBACK more robustly. Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/877ey7bmun@ansel.ydns.eu Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/51684bad9fece45714152f831f64e304b9dcd8ea Modified Files -- src/backend/access/transam/xact.c | 23 ++- src/backend/utils/mmgr/portalmem.c | 30 ++ 2 files changed, 44 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle elog(FATAL) during ROLLBACK more robustly.
Handle elog(FATAL) during ROLLBACK more robustly. Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/877ey7bmun@ansel.ydns.eu Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cd184273ba9dd2020539685593edb9c0c8e8689d Modified Files -- src/backend/access/transam/xact.c | 23 ++- src/backend/utils/mmgr/portalmem.c | 30 ++ 2 files changed, 44 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle elog(FATAL) during ROLLBACK more robustly.
Handle elog(FATAL) during ROLLBACK more robustly. Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/877ey7bmun@ansel.ydns.eu Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/624b6f328a1b8d0ee21023543ca63552c98a300e Modified Files -- src/backend/access/transam/xact.c | 23 ++- src/backend/utils/mmgr/portalmem.c | 30 ++ 2 files changed, 44 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle elog(FATAL) during ROLLBACK more robustly.
Handle elog(FATAL) during ROLLBACK more robustly. Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/877ey7bmun@ansel.ydns.eu Branch -- REL9_2_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8ae41ceae82bced88dbe8ac713248a1cd1de33c9 Modified Files -- src/backend/access/transam/xact.c | 23 ++- src/backend/utils/mmgr/portalmem.c | 30 ++ 2 files changed, 44 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Final pgindent + perltidy run for v10.
Final pgindent + perltidy run for v10. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/21d304dfedb4f26d0d6587d9ac39b1b5c499bb55 Modified Files -- src/backend/access/hash/hashpage.c | 8 +- src/backend/access/transam/slru.c | 2 +- src/backend/catalog/namespace.c| 14 +- src/backend/catalog/partition.c| 6 +- src/backend/commands/copy.c| 3 +- src/backend/commands/subscriptioncmds.c| 3 +- src/backend/commands/tablecmds.c | 4 +- src/backend/commands/trigger.c | 14 +- src/backend/commands/vacuumlazy.c | 10 +- src/backend/executor/execProcnode.c| 6 +- src/backend/executor/nodeModifyTable.c | 8 +- src/backend/libpq/be-secure-openssl.c | 5 +- src/backend/optimizer/geqo/geqo_cx.c | 2 +- src/backend/optimizer/geqo/geqo_ox1.c | 2 +- src/backend/optimizer/geqo/geqo_ox2.c | 2 +- src/backend/optimizer/geqo/geqo_px.c | 2 +- src/backend/optimizer/geqo/geqo_recombination.c| 2 +- src/backend/parser/parse_utilcmd.c | 4 +- src/backend/replication/logical/launcher.c | 11 +- src/backend/replication/logical/origin.c | 6 +- src/backend/replication/logical/snapbuild.c| 6 +- src/backend/replication/slot.c | 6 +- src/backend/replication/syncrep.c | 8 +- src/backend/storage/ipc/procarray.c| 4 +- src/backend/utils/adt/ruleutils.c | 4 +- src/bin/pg_ctl/t/001_start_stop.pl | 6 +- src/bin/pg_dump/compress_io.c | 2 +- src/bin/pg_dump/pg_backup_tar.c| 2 +- src/bin/pg_dump/pg_dump.c | 8 +- src/bin/pg_dump/t/002_pg_dump.pl | 201 ++--- src/bin/pg_rewind/libpq_fetch.c| 8 +- src/include/commands/trigger.h | 9 +- src/include/nodes/execnodes.h | 4 +- src/include/optimizer/geqo_recombination.h | 14 +- src/test/perl/PostgresNode.pm | 5 +- src/test/perl/TestLib.pm | 1 + src/test/recovery/t/001_stream_rep.pl | 54 +++--- src/test/recovery/t/006_logical_decoding.pl| 6 +- src/test/recovery/t/007_sync_rep.pl| 2 +- src/test/recovery/t/009_twophase.pl| 23 +-- .../recovery/t/010_logical_decoding_timelines.pl | 3 +- src/test/subscription/t/001_rep_changes.pl | 27 +-- src/tools/msvc/Mkvcbuild.pm| 6 +- src/tools/msvc/vcregress.pl| 4 +- src/tools/pgindent/pgindent| 11 +- src/tools/pgindent/typedefs.list | 8 +- 46 files changed, 273 insertions(+), 273 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Branch refs/heads/REL_10_STABLE was created
Branch refs/heads/REL_10_STABLE was created. View: https://git.postgresql.org/pg/shortlog/refs/heads/REL_10_STABLE -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Stamp HEAD as 11devel.
Stamp HEAD as 11devel. Note that we no longer require any manual adjustments to shared-library minor version numbers, cf commit a3bce17ef. So this should be everything. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9f14dc393bd441dd9251bea2a5a3ad7f889b03c5 Modified Files -- configure| 18 +- configure.in | 2 +- doc/bug.template | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- src/tools/git_changelog | 2 +- src/tools/version_stamp.pl | 2 +- 8 files changed, 23 insertions(+), 23 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Expand coverage of parallel gather merge a bit.
Expand coverage of parallel gather merge a bit. Previously paths reaching heap_compare_slots weren't covered. Author: Rushabh Lathia Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAGPqQf3C+3PBujb+7m=ceWeii4-vBY=xs99ljzrpkpefvzj...@mail.gmail.com https://postgr.es/m/27200.1502482...@sss.pgh.pa.us Backpatch: 10, where gather merge was introduced Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d2bc501573d98ff5541271dca94fb5f7a004ecbf Modified Files -- src/test/regress/expected/select_parallel.out | 69 +-- src/test/regress/sql/select_parallel.sql | 14 -- 2 files changed, 65 insertions(+), 18 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Expand coverage of parallel gather merge a bit.
Expand coverage of parallel gather merge a bit. Previously paths reaching heap_compare_slots weren't covered. Author: Rushabh Lathia Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAGPqQf3C+3PBujb+7m=ceWeii4-vBY=xs99ljzrpkpefvzj...@mail.gmail.com https://postgr.es/m/27200.1502482...@sss.pgh.pa.us Backpatch: 10, where gather merge was introduced Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ee5572e051955ef4570f95413dc6cddb4df51d50 Modified Files -- src/test/regress/expected/select_parallel.out | 69 +-- src/test/regress/sql/select_parallel.sql | 14 -- 2 files changed, 65 insertions(+), 18 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Add a --load-via-partition-root option.
pg_dump: Add a --load-via-partition-root option. Rushabh Lathia, reviewed and somewhat revised by me. Testing by Rajkumar Raghuwanshi. Discussion: http://postgr.es/m/CAGPqQf0C1he087bz9xRBOGZBuESYz9X=fp8ca_g+tfhgaff...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/23d7680d04b958de327be96ffdde8f024140d50e Modified Files -- doc/src/sgml/ref/pg_dump.sgml| 15 doc/src/sgml/ref/pg_dumpall.sgml | 15 src/bin/pg_dump/common.c | 51 ++- src/bin/pg_dump/pg_backup.h | 1 + src/bin/pg_dump/pg_dump.c| 76 ++-- src/bin/pg_dump/pg_dumpall.c | 5 +++ 6 files changed, 145 insertions(+), 18 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
