pgsql: Move RecoveryLockList into a hash table.
Move RecoveryLockList into a hash table. Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a40cff8956e842f737739d93a7b160f0b4a03d13 Modified Files -- src/backend/storage/ipc/standby.c | 175 -- 1 file changed, 92 insertions(+), 83 deletions(-)
pgsql: Move RecoveryLockList into a hash table.
Move RecoveryLockList into a hash table. Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/88554c0911018c1c60423fbb60557626142dec10 Modified Files -- src/backend/storage/ipc/standby.c | 164 -- 1 file changed, 87 insertions(+), 77 deletions(-)
pgsql: Move RecoveryLockList into a hash table.
Move RecoveryLockList into a hash table. Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7bcda60d41cb920193e9d56a3b03583d7998c635 Modified Files -- src/backend/storage/ipc/standby.c | 164 -- 1 file changed, 87 insertions(+), 77 deletions(-)
pgsql: Move RecoveryLockList into a hash table.
Move RecoveryLockList into a hash table. Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/35750a38b7ab6e30aa2ee6eb7765ebd2172dd7c5 Modified Files -- src/backend/storage/ipc/standby.c | 164 -- 1 file changed, 87 insertions(+), 77 deletions(-)
pgsql: Move RecoveryLockList into a hash table.
Move RecoveryLockList into a hash table. Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c4ccbcc1a2a17d547537ccecd9e856cb083c2ff7 Modified Files -- src/backend/storage/ipc/standby.c | 165 -- 1 file changed, 88 insertions(+), 77 deletions(-)
pgsql: Move RecoveryLockList into a hash table.
Move RecoveryLockList into a hash table. Standbys frequently need to release all locks held by a given xid. Instead of searching one big list linearly, let's create one list per xid and put them in a hash table, so we can find what we need in O(1) time. Earlier analysis and a prototype were done by David Rowley, though this isn't his patch. Back-patch all the way. Author: Thomas Munro Diagnosed-by: David Rowley, Andres Freund Reviewed-by: Andres Freund, Tom Lane, Robert Haas Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/12f7d91994d15d362384be46eec92498bdc001c6 Modified Files -- src/backend/storage/ipc/standby.c | 165 -- 1 file changed, 88 insertions(+), 77 deletions(-)
pgsql: Reword SPI_ERROR_TRANSACTION errors in PL/pgSQL
Reword SPI_ERROR_TRANSACTION errors in PL/pgSQL The previous message for SPI_ERROR_TRANSACTION claimed "cannot begin/end transactions in PL/pgSQL", but that is no longer true. Nevertheless, the error can still happen, so reword the messages. The error cases in exec_prepare_plan() could never happen, so remove them. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c9301deb9bf86aaf9144a66026bc121a3eededee Modified Files -- .../plpgsql/src/expected/plpgsql_transaction.out | 16 +++- src/pl/plpgsql/src/pl_exec.c | 29 +++--- src/pl/plpgsql/src/sql/plpgsql_transaction.sql | 14 ++- 3 files changed, 32 insertions(+), 27 deletions(-)
pgsql: Add PGTYPESchar_free() to avoid cross-module problems on Windows
Add PGTYPESchar_free() to avoid cross-module problems on Windows. On Windows, it is sometimes important for corresponding malloc() and free() calls to be made from the same DLL, since some build options can result in multiple allocators being active at the same time. For that reason we already provided PQfreemem(). This commit adds a similar function for freeing string results allocated by the pgtypes library. Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3566873f21909397561418fab22c98332fa8b72a Modified Files -- doc/src/sgml/ecpg.sgml | 24 +-- src/interfaces/ecpg/include/Makefile | 2 +- src/interfaces/ecpg/include/pgtypes.h | 17 + src/interfaces/ecpg/include/pgtypes_date.h | 1 + src/interfaces/ecpg/include/pgtypes_interval.h | 1 + src/interfaces/ecpg/include/pgtypes_numeric.h | 2 + src/interfaces/ecpg/include/pgtypes_timestamp.h| 1 + src/interfaces/ecpg/pgtypeslib/common.c| 10 +++ src/interfaces/ecpg/pgtypeslib/exports.txt | 1 + .../ecpg/test/expected/pgtypeslib-dt_test.c| 84 +++--- .../ecpg/test/expected/pgtypeslib-dt_test2.c | 12 ++-- .../ecpg/test/expected/pgtypeslib-num_test.c | 10 +-- .../ecpg/test/expected/pgtypeslib-num_test2.c | 26 +++ .../ecpg/test/expected/preproc-outofscope.c| 2 + src/interfaces/ecpg/test/expected/sql-sqlda.c | 4 +- src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc| 84 +++--- src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc | 12 ++-- src/interfaces/ecpg/test/pgtypeslib/num_test.pgc | 10 +-- src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc | 26 +++ src/interfaces/ecpg/test/sql/sqlda.pgc | 2 +- 20 files changed, 192 insertions(+), 139 deletions(-)
pgsql: Add PGTYPESchar_free() to avoid cross-module problems on Windows
Add PGTYPESchar_free() to avoid cross-module problems on Windows. On Windows, it is sometimes important for corresponding malloc() and free() calls to be made from the same DLL, since some build options can result in multiple allocators being active at the same time. For that reason we already provided PQfreemem(). This commit adds a similar function for freeing string results allocated by the pgtypes library. Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b5b973ef0ba736c7c002f0907014d3115471644e Modified Files -- doc/src/sgml/ecpg.sgml | 24 +-- src/interfaces/ecpg/include/Makefile | 2 +- src/interfaces/ecpg/include/pgtypes.h | 17 + src/interfaces/ecpg/include/pgtypes_date.h | 1 + src/interfaces/ecpg/include/pgtypes_interval.h | 1 + src/interfaces/ecpg/include/pgtypes_numeric.h | 2 + src/interfaces/ecpg/include/pgtypes_timestamp.h| 1 + src/interfaces/ecpg/pgtypeslib/common.c| 10 +++ src/interfaces/ecpg/pgtypeslib/exports.txt | 1 + .../ecpg/test/expected/pgtypeslib-dt_test.c| 84 +++--- .../ecpg/test/expected/pgtypeslib-dt_test2.c | 12 ++-- .../ecpg/test/expected/pgtypeslib-num_test.c | 10 +-- .../ecpg/test/expected/pgtypeslib-num_test2.c | 26 +++ .../ecpg/test/expected/preproc-outofscope.c| 2 + src/interfaces/ecpg/test/expected/sql-sqlda.c | 4 +- src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc| 84 +++--- src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc | 12 ++-- src/interfaces/ecpg/test/pgtypeslib/num_test.pgc | 10 +-- src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc | 26 +++ src/interfaces/ecpg/test/sql/sqlda.pgc | 2 +- 20 files changed, 192 insertions(+), 139 deletions(-)
pgsql: Add PGTYPESchar_free() to avoid cross-module problems on Windows
Add PGTYPESchar_free() to avoid cross-module problems on Windows. On Windows, it is sometimes important for corresponding malloc() and free() calls to be made from the same DLL, since some build options can result in multiple allocators being active at the same time. For that reason we already provided PQfreemem(). This commit adds a similar function for freeing string results allocated by the pgtypes library. Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/db05d0b906be6dbf194ce594e0a0777ebdaf7e93 Modified Files -- doc/src/sgml/ecpg.sgml | 24 +-- src/interfaces/ecpg/include/Makefile | 2 +- src/interfaces/ecpg/include/pgtypes.h | 17 + src/interfaces/ecpg/include/pgtypes_date.h | 1 + src/interfaces/ecpg/include/pgtypes_interval.h | 1 + src/interfaces/ecpg/include/pgtypes_numeric.h | 2 + src/interfaces/ecpg/include/pgtypes_timestamp.h| 1 + src/interfaces/ecpg/pgtypeslib/common.c| 10 +++ src/interfaces/ecpg/pgtypeslib/exports.txt | 1 + .../ecpg/test/expected/pgtypeslib-dt_test.c| 84 +++--- .../ecpg/test/expected/pgtypeslib-dt_test2.c | 12 ++-- .../ecpg/test/expected/pgtypeslib-num_test.c | 10 +-- .../ecpg/test/expected/pgtypeslib-num_test2.c | 26 +++ .../ecpg/test/expected/preproc-outofscope.c| 2 + src/interfaces/ecpg/test/expected/sql-sqlda.c | 4 +- src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc| 84 +++--- src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc | 12 ++-- src/interfaces/ecpg/test/pgtypeslib/num_test.pgc | 10 +-- src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc | 26 +++ src/interfaces/ecpg/test/sql/sqlda.pgc | 2 +- 20 files changed, 192 insertions(+), 139 deletions(-)
pgsql: Add PGTYPESchar_free() to avoid cross-module problems on Windows
Add PGTYPESchar_free() to avoid cross-module problems on Windows. On Windows, it is sometimes important for corresponding malloc() and free() calls to be made from the same DLL, since some build options can result in multiple allocators being active at the same time. For that reason we already provided PQfreemem(). This commit adds a similar function for freeing string results allocated by the pgtypes library. Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/edabd8f5a4249b95db7421722f88e156c10c8a8e Modified Files -- doc/src/sgml/ecpg.sgml | 24 +-- src/interfaces/ecpg/include/Makefile | 2 +- src/interfaces/ecpg/include/pgtypes.h | 17 + src/interfaces/ecpg/include/pgtypes_date.h | 1 + src/interfaces/ecpg/include/pgtypes_interval.h | 1 + src/interfaces/ecpg/include/pgtypes_numeric.h | 2 + src/interfaces/ecpg/include/pgtypes_timestamp.h| 1 + src/interfaces/ecpg/pgtypeslib/common.c| 10 +++ src/interfaces/ecpg/pgtypeslib/exports.txt | 1 + .../ecpg/test/expected/pgtypeslib-dt_test.c| 84 +++--- .../ecpg/test/expected/pgtypeslib-dt_test2.c | 12 ++-- .../ecpg/test/expected/pgtypeslib-num_test.c | 10 +-- .../ecpg/test/expected/pgtypeslib-num_test2.c | 26 +++ .../ecpg/test/expected/preproc-outofscope.c| 2 + src/interfaces/ecpg/test/expected/sql-sqlda.c | 4 +- src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc| 84 +++--- src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc | 12 ++-- src/interfaces/ecpg/test/pgtypeslib/num_test.pgc | 10 +-- src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc | 26 +++ src/interfaces/ecpg/test/sql/sqlda.pgc | 2 +- 20 files changed, 192 insertions(+), 139 deletions(-)
pgsql: Add PGTYPESchar_free() to avoid cross-module problems on Windows
Add PGTYPESchar_free() to avoid cross-module problems on Windows. On Windows, it is sometimes important for corresponding malloc() and free() calls to be made from the same DLL, since some build options can result in multiple allocators being active at the same time. For that reason we already provided PQfreemem(). This commit adds a similar function for freeing string results allocated by the pgtypes library. Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3bc19d0d263c32c225a391e5275d6ba24dbc423c Modified Files -- doc/src/sgml/ecpg.sgml | 24 +-- src/interfaces/ecpg/include/Makefile | 2 +- src/interfaces/ecpg/include/pgtypes.h | 17 + src/interfaces/ecpg/include/pgtypes_date.h | 1 + src/interfaces/ecpg/include/pgtypes_interval.h | 1 + src/interfaces/ecpg/include/pgtypes_numeric.h | 2 + src/interfaces/ecpg/include/pgtypes_timestamp.h| 1 + src/interfaces/ecpg/pgtypeslib/common.c| 10 +++ src/interfaces/ecpg/pgtypeslib/exports.txt | 1 + .../ecpg/test/expected/pgtypeslib-dt_test.c| 84 +++--- .../ecpg/test/expected/pgtypeslib-dt_test2.c | 12 ++-- .../ecpg/test/expected/pgtypeslib-num_test.c | 10 +-- .../ecpg/test/expected/pgtypeslib-num_test2.c | 26 +++ .../ecpg/test/expected/preproc-outofscope.c| 2 + src/interfaces/ecpg/test/expected/sql-sqlda.c | 4 +- src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc| 84 +++--- src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc | 12 ++-- src/interfaces/ecpg/test/pgtypeslib/num_test.pgc | 10 +-- src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc | 26 +++ src/interfaces/ecpg/test/sql/sqlda.pgc | 2 +- 20 files changed, 192 insertions(+), 139 deletions(-)
pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
Increase upper limit for vacuum_cleanup_index_scale_factor Upper limits for vacuum_cleanup_index_scale_factor GUC and reloption were initially set to 100.0 in 857f9c36. However, after further discussion, it appears that some users like to disable B-tree cleanup index scan completely (assuming there are no deleted pages). vacuum_cleanup_index_scale_factor is used barely to protect against stalled index statistics. And after detailed consideration it appears that risk of stalled index statistics is low. And it would be nice to allow advanced users setting higher values of vacuum_cleanup_index_scale_factor. So, set upper limit for these GUC and reloption to DBL_MAX. Author: Alexander Korotkov Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAC8Q8tJCb%3DgxhzcV7T6ctx7PY-Ux1oA-AsTJc6cAVNsQiYcCzA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ca33a885bf892a7fa34020a2620c83ccec3cdd7 Modified Files -- doc/src/sgml/config.sgml | 2 +- src/backend/access/common/reloptions.c| 2 +- src/backend/access/nbtree/nbtree.c| 8 +--- src/backend/utils/misc/guc.c | 2 +- src/test/regress/expected/btree_index.out | 2 +- 5 files changed, 9 insertions(+), 7 deletions(-)
Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
On Tue, Jun 26, 2018 at 3:35 PM Alexander Korotkov wrote: > vacuum_cleanup_index_scale_factor is used barely to protect against > stalled index statistics. And after detailed consideration it appears > that risk of stalled index statistics is low. And it would be nice to > allow advanced users setting higher values of > vacuum_cleanup_index_scale_factor. So, set upper limit for these > GUC and reloption to DBL_MAX. BTW, this line looks cumbersome. +DETAIL: Valid values are between "0.00" and "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00". It's not something introduced by this patch, because other reloptions behave the same. Should we change output format for real reloption boundaries to '%g' (as guc.c does). It looks much better. ERROR: -1 is outside the valid range for parameter "random_page_cost" (0 .. 1.79769e+308) -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
On Tue, Jun 26, 2018 at 3:59 PM Alexander Korotkov wrote: > > On Tue, Jun 26, 2018 at 3:35 PM Alexander Korotkov > wrote: > > vacuum_cleanup_index_scale_factor is used barely to protect against > > stalled index statistics. And after detailed consideration it appears > > that risk of stalled index statistics is low. And it would be nice to > > allow advanced users setting higher values of > > vacuum_cleanup_index_scale_factor. So, set upper limit for these > > GUC and reloption to DBL_MAX. > > BTW, this line looks cumbersome. > > +DETAIL: Valid values are between "0.00" and > "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00". > > It's not something introduced by this patch, because other reloptions > behave the same. Should we change output format for real reloption > boundaries to '%g' (as guc.c does). It looks much better. > > ERROR: -1 is outside the valid range for parameter "random_page_cost" > (0 .. 1.79769e+308) See attached patch changing output format for reloption real boundaries from "%f" to "%g". -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company change-reloption-real-boundaries-output-format.patch Description: Binary data
pgsql: Allow direct lookups of AppendRelInfo by child relid
Allow direct lookups of AppendRelInfo by child relid find_appinfos_by_relids had quite a large overhead when the number of items in the append_rel_list was high, as it had to trawl through the append_rel_list looking for AppendRelInfos belonging to the given childrelids. Since there can only be a single AppendRelInfo for each child rel, it seems much better to store an array in PlannerInfo which indexes these by child relid, making the function O(1) rather than O(N). This function was only called once inside the planner, so just replace that call with a lookup to the new array. find_childrel_appendrelinfo is now unused and thus removed. This fixes a planner performance regression new to v11 reported by Thomas Reiss. Author: David Rowley Reported-by: Thomas Reiss Reviewed-by: Ashutosh Bapat Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/94dd7a4b-5e50-0712-911d-2278e055c...@dalibo.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7d872c91a3f9d49b56117557cdbb0c3d4c620687 Modified Files -- src/backend/optimizer/plan/planmain.c | 6 +++ src/backend/optimizer/plan/planner.c | 4 ++ src/backend/optimizer/prep/prepunion.c | 29 +++--- src/backend/optimizer/util/relnode.c | 70 +++--- src/include/nodes/relation.h | 10 + src/include/optimizer/pathnode.h | 3 +- 6 files changed, 74 insertions(+), 48 deletions(-)
pgsql: Fix documentation bug related to backup history file.
Fix documentation bug related to backup history file. The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626174752.0ce505e3.nag...@sraoss.co.jp Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c2f8f3f7d628c74317959a2cfe71fea05575 Modified Files -- doc/src/sgml/backup.sgml| 2 +- doc/src/sgml/high-availability.sgml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix documentation bug related to backup history file.
Fix documentation bug related to backup history file. The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626174752.0ce505e3.nag...@sraoss.co.jp Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/09879f7536350e53ca21319b80430fb244bddfe7 Modified Files -- doc/src/sgml/backup.sgml| 2 +- doc/src/sgml/high-availability.sgml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix documentation bug related to backup history file.
Fix documentation bug related to backup history file. The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626174752.0ce505e3.nag...@sraoss.co.jp Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ef2deca1b77ebcbd554eaa8dfcd5e653ea67593b Modified Files -- doc/src/sgml/backup.sgml| 2 +- doc/src/sgml/high-availability.sgml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix documentation bug related to backup history file.
Fix documentation bug related to backup history file. The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626174752.0ce505e3.nag...@sraoss.co.jp Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d06d92cd2d5e3c3dd893ee0d82d14d1f8adbc82b Modified Files -- doc/src/sgml/backup.sgml| 2 +- doc/src/sgml/high-availability.sgml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix documentation bug related to backup history file.
Fix documentation bug related to backup history file. The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626174752.0ce505e3.nag...@sraoss.co.jp Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4765ac0570730c66fdeb2eb43b0b4e68653b4247 Modified Files -- doc/src/sgml/backup.sgml| 2 +- doc/src/sgml/high-availability.sgml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix documentation bug related to backup history file.
Fix documentation bug related to backup history file. The backup history file has been no longer necessary for recovery since the version 9.0. It's now basically just for informational purpose. But previously the documentations still described that a recovery requests the backup history file to proceed. The commit fixes this documentation bug. Back-patch to all supported versions. Author: Yugo Nagata Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626174752.0ce505e3.nag...@sraoss.co.jp Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/833397e73e2e8d8e37aa38b31e00320161bb6ff8 Modified Files -- doc/src/sgml/backup.sgml| 2 +- doc/src/sgml/high-availability.sgml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Enable failure to rename a partitioned index
Enable failure to rename a partitioned index Concurrently with partitioned index development (commit 8b08f7d4820f), the code to handle failure to rename indexes was refactored (commit 8b9e9644dc6a). Turns out that that particular case was untested, which naturally led it to be broken. Add tests and the missing code line. Co-authored-by: David Rowley Co-authored-by: Álvaro Herrera Reported-by: Rajkumar Raghuwanshi Discussion: https://postgr.es/m/cakcux6mfyms3ox0ywjoiwigsekhjf-1zdetcehfbd0mscuz...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/040da42367a5de448ddecf6ee7c09f73580a6b28 Modified Files -- src/backend/catalog/objectaddress.c | 1 + src/test/regress/expected/alter_table.out| 18 ++ src/test/regress/expected/object_address.out | 11 +-- src/test/regress/sql/alter_table.sql | 15 +++ src/test/regress/sql/object_address.sql | 5 + 5 files changed, 48 insertions(+), 2 deletions(-)
Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
Alexander Korotkov writes: > BTW, this line looks cumbersome. > +DETAIL: Valid values are between "0.00" and > "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00". > It's not something introduced by this patch, because other reloptions > behave the same. Should we change output format for real reloption > boundaries to '%g' (as guc.c does). It looks much better. > ERROR: -1 is outside the valid range for parameter "random_page_cost" > (0 .. 1.79769e+308) %g, unmodified, is a bad idea because it loses a lot of precision in some cases (due to the assumption that nobody cares about more than six digits). Maybe you could fix that by using %.15g or some such, but... I think that the original patch to use DBL_MAX was itself a bad idea and should be rethought. It creates (what is in principle) a platform-dependent limit, for no adequate justification. Why not just set it to 1e9 or 1e10 or some such? regards, tom lane
pgsql: Remove obsolete comment block in nbtsort.c.
Remove obsolete comment block in nbtsort.c. Building a new nbtree index through incremental insertions would always be slower than our actual approach of sorting using tuplesort, assembling leaf pages from tuplesort output, and writing and WAL-logging whole pages. Remove a comment block from the Berkeley days claiming that incremental insertions might be slightly faster with presorted input. Discussion: https://postgr.es/m/CAH2-WzmKs4mLAoFgJ3yHMRYc849efc=dw+pnrb3neog2ojo...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cdc2693a11b341043f33e1efc36debe0348fb361 Modified Files -- src/backend/access/nbtree/nbtsort.c | 9 - 1 file changed, 9 deletions(-)
Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
On Tue, Jun 26, 2018 at 7:00 PM Tom Lane wrote: > > Alexander Korotkov writes: > > BTW, this line looks cumbersome. > > > +DETAIL: Valid values are between "0.00" and > > "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00". > > > It's not something introduced by this patch, because other reloptions > > behave the same. Should we change output format for real reloption > > boundaries to '%g' (as guc.c does). It looks much better. > > ERROR: -1 is outside the valid range for parameter "random_page_cost" > > (0 .. 1.79769e+308) > > %g, unmodified, is a bad idea because it loses a lot of precision > in some cases (due to the assumption that nobody cares about more > than six digits). Maybe you could fix that by using %.15g or some > such, but... > > I think that the original patch to use DBL_MAX was itself a bad idea > and should be rethought. It creates (what is in principle) a > platform-dependent limit, for no adequate justification. Why not > just set it to 1e9 or 1e10 or some such? Yes, I see that it was a bad idea, because many of buildfarm member are turning red... I choose DBL_MAX for the sake of uniformity, because we're currently using DBL_MAX for floating point GUCs and reloptions, which allows large values. But we didn't test them for overflow yet... So, let's switch to 1e10 limit? Patch is attached. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company vacuum_cleanup_index_scale_factor-max-3.patch Description: Binary data
pgsql: Correct a comment on logtape.c's leader tape.
Correct a comment on logtape.c's leader tape. randomAccess parallel tuplesorts are disallowed because the leader would try to write to its own leader tape, not because the leader would try to write to a worker tape directly. Cleanup from commit 9da0cc35284. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aefb0a382c10877867d831afe8a292aa355c5a68 Modified Files -- src/backend/utils/sort/logtape.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: |--- gitweb/email subject limit -----------------|-------------|
|--- gitweb/email subject limit -|-| doc: PG 11 relnotes: remove channel binding from major features Also move to the source code section, and expand the paragraph Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a89357e2f7839f5bc0815f4cf9e565cd3ad7a185 Modified Files -- doc/src/sgml/release-11.sgml | 59 ++-- 1 file changed, 29 insertions(+), 30 deletions(-)
bad commit line
On Tue, Jun 26, 2018 at 06:32:01PM +, Bruce Momjian wrote: > |--- gitweb/email subject limit -|-| Oops, sorry for the line above. I modified my script to remove it, but it seems it did not work. --- > > doc: PG 11 relnotes: remove channel binding from major features > > Also move to the source code section, and expand the paragraph > > Branch > -- > master > > Details > --- > https://git.postgresql.org/pg/commitdiff/a89357e2f7839f5bc0815f4cf9e565cd3ad7a185 > > Modified Files > -- > doc/src/sgml/release-11.sgml | 59 ++-- > 1 file changed, 29 insertions(+), 30 deletions(-) > -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
pgsql: Fix upper limit for vacuum_cleanup_index_scale_factor
Fix upper limit for vacuum_cleanup_index_scale_factor 6ca33a88 sets upper limit for vacuum_cleanup_index_scale_factor to DBL_MAX. DBL_MAX appears to be platform-dependent. That causes many buildfarm animals to fail, because we check boundaries of vacuum_cleanup_index_scale_factor in regression tests. This commit changes upper limit from DBL_MAX to just "large enough" limit, which was arbitrary selected as 1e10. Author: Alexander Korotkov Reported-by: Tom Lane, Darafei Praliaskouski Discussion: https://postgr.es/m/CAPpHfdvewmr4PcpRjrkstoNn1n2_6dL-iHRB21CCfZ0efZdBTg%40mail.gmail.com Discussion: https://postgr.es/m/CAC8Q8tLYFOpKNaPS_E7V8KtPdE%3D_TnAn16t%3DA3LuL%3DXjfOO-BQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4d54543efa5eb074ead4d0fadb2af4161c943044 Modified Files -- doc/src/sgml/config.sgml | 3 ++- src/backend/access/common/reloptions.c| 2 +- src/backend/utils/misc/guc.c | 2 +- src/test/regress/expected/btree_index.out | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-)
pgsql: Fix "base" snapshot handling in logical decoding
Fix "base" snapshot handling in logical decoding Two closely related bugs are fixed. First, xmin of logical slots was advanced too early. During xl_running_xacts processing, xmin of the slot was set to the oldest running xid in the record, but that's wrong: actually, snapshots which will be used for not-yet-replayed transactions might consider older txns as running too, so we need to keep xmin back for them. The problem wasn't noticed earlier because DDL which allows to delete tuple (set xmax) while some another not-yet-committed transaction looks at it is pretty rare, if not unique: e.g. all forms of ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock conflicting with any inserts. The included test case (test_decoding's oldest_xmin) uses ALTER of a composite type, which doesn't have such interlocking. To deal with this, we must be able to quickly retrieve oldest xmin (oldest running xid among all assigned snapshots) from ReorderBuffer. To fix, add another list of ReorderBufferTXNs to the reorderbuffer, where transactions are sorted by base-snapshot-LSN. This is slightly different from the existing (sorted by first-LSN) list, because a transaction can have an earlier LSN but a later Xmin, if its first record does not obtain an xmin (eg. xl_xact_assignment). Note this new list doesn't fully replace the existing txn list: we still need that one to prevent WAL recycling. The second issue concerns SnapBuilder snapshots and subtransactions. SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a transaction that is known to be a subtxn, which is good in the common case that the top-level transaction already has one (no point in doing so), but a bug otherwise. To fix, arrange to transfer the snapshot from the subtxn to its top-level txn as soon as the kinship gets known. test_decoding's snapshot_transfer verifies this. Also, fix a minor memory leak: refcount of toplevel's old base snapshot was not decremented when the snapshot is transferred from child. Liberally sprinkle code comments, and rewrite a few existing ones. This part is my (Álvaro's) contribution to this commit, as I had to write all those comments in order to understand the existing code and Arseny's patch. Reported-by: Arseny Sher Diagnosed-by: Arseny Sher Co-authored-by: Arseny Sher Co-authored-by: Álvaro Herrera Reviewed-by: Antonin Houska Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/962313558f956e04e6871a96c57c2f1db3c685d1 Modified Files -- contrib/test_decoding/Makefile | 3 +- contrib/test_decoding/expected/oldest_xmin.out | 27 ++ .../test_decoding/expected/snapshot_transfer.out | 49 contrib/test_decoding/specs/oldest_xmin.spec | 37 +++ contrib/test_decoding/specs/snapshot_transfer.spec | 42 +++ src/backend/replication/logical/reorderbuffer.c| 303 +++-- src/backend/replication/logical/snapbuild.c| 29 +- src/include/replication/reorderbuffer.h| 22 +- 8 files changed, 409 insertions(+), 103 deletions(-)
pgsql: Fix "base" snapshot handling in logical decoding
Fix "base" snapshot handling in logical decoding Two closely related bugs are fixed. First, xmin of logical slots was advanced too early. During xl_running_xacts processing, xmin of the slot was set to the oldest running xid in the record, but that's wrong: actually, snapshots which will be used for not-yet-replayed transactions might consider older txns as running too, so we need to keep xmin back for them. The problem wasn't noticed earlier because DDL which allows to delete tuple (set xmax) while some another not-yet-committed transaction looks at it is pretty rare, if not unique: e.g. all forms of ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock conflicting with any inserts. The included test case (test_decoding's oldest_xmin) uses ALTER of a composite type, which doesn't have such interlocking. To deal with this, we must be able to quickly retrieve oldest xmin (oldest running xid among all assigned snapshots) from ReorderBuffer. To fix, add another list of ReorderBufferTXNs to the reorderbuffer, where transactions are sorted by base-snapshot-LSN. This is slightly different from the existing (sorted by first-LSN) list, because a transaction can have an earlier LSN but a later Xmin, if its first record does not obtain an xmin (eg. xl_xact_assignment). Note this new list doesn't fully replace the existing txn list: we still need that one to prevent WAL recycling. The second issue concerns SnapBuilder snapshots and subtransactions. SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a transaction that is known to be a subtxn, which is good in the common case that the top-level transaction already has one (no point in doing so), but a bug otherwise. To fix, arrange to transfer the snapshot from the subtxn to its top-level txn as soon as the kinship gets known. test_decoding's snapshot_transfer verifies this. Also, fix a minor memory leak: refcount of toplevel's old base snapshot was not decremented when the snapshot is transferred from child. Liberally sprinkle code comments, and rewrite a few existing ones. This part is my (Álvaro's) contribution to this commit, as I had to write all those comments in order to understand the existing code and Arseny's patch. Reported-by: Arseny Sher Diagnosed-by: Arseny Sher Co-authored-by: Arseny Sher Co-authored-by: Álvaro Herrera Reviewed-by: Antonin Houska Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b767b3f2e5b7aadb53c67cb2a2d7ded8e0825193 Modified Files -- contrib/test_decoding/Makefile | 3 +- contrib/test_decoding/expected/oldest_xmin.out | 27 ++ .../test_decoding/expected/snapshot_transfer.out | 49 contrib/test_decoding/specs/oldest_xmin.spec | 37 +++ contrib/test_decoding/specs/snapshot_transfer.spec | 42 +++ src/backend/replication/logical/reorderbuffer.c| 304 +++-- src/backend/replication/logical/snapbuild.c| 29 +- src/include/replication/reorderbuffer.h| 22 +- 8 files changed, 409 insertions(+), 104 deletions(-)
pgsql: Fix "base" snapshot handling in logical decoding
Fix "base" snapshot handling in logical decoding Two closely related bugs are fixed. First, xmin of logical slots was advanced too early. During xl_running_xacts processing, xmin of the slot was set to the oldest running xid in the record, but that's wrong: actually, snapshots which will be used for not-yet-replayed transactions might consider older txns as running too, so we need to keep xmin back for them. The problem wasn't noticed earlier because DDL which allows to delete tuple (set xmax) while some another not-yet-committed transaction looks at it is pretty rare, if not unique: e.g. all forms of ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock conflicting with any inserts. The included test case (test_decoding's oldest_xmin) uses ALTER of a composite type, which doesn't have such interlocking. To deal with this, we must be able to quickly retrieve oldest xmin (oldest running xid among all assigned snapshots) from ReorderBuffer. To fix, add another list of ReorderBufferTXNs to the reorderbuffer, where transactions are sorted by base-snapshot-LSN. This is slightly different from the existing (sorted by first-LSN) list, because a transaction can have an earlier LSN but a later Xmin, if its first record does not obtain an xmin (eg. xl_xact_assignment). Note this new list doesn't fully replace the existing txn list: we still need that one to prevent WAL recycling. The second issue concerns SnapBuilder snapshots and subtransactions. SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a transaction that is known to be a subtxn, which is good in the common case that the top-level transaction already has one (no point in doing so), but a bug otherwise. To fix, arrange to transfer the snapshot from the subtxn to its top-level txn as soon as the kinship gets known. test_decoding's snapshot_transfer verifies this. Also, fix a minor memory leak: refcount of toplevel's old base snapshot was not decremented when the snapshot is transferred from child. Liberally sprinkle code comments, and rewrite a few existing ones. This part is my (Álvaro's) contribution to this commit, as I had to write all those comments in order to understand the existing code and Arseny's patch. Reported-by: Arseny Sher Diagnosed-by: Arseny Sher Co-authored-by: Arseny Sher Co-authored-by: Álvaro Herrera Reviewed-by: Antonin Houska Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f49a80c481f74fa81407dce8e51dea6956cb64f8 Modified Files -- contrib/test_decoding/Makefile | 3 +- contrib/test_decoding/expected/oldest_xmin.out | 27 ++ .../test_decoding/expected/snapshot_transfer.out | 49 contrib/test_decoding/specs/oldest_xmin.spec | 37 +++ contrib/test_decoding/specs/snapshot_transfer.spec | 42 +++ src/backend/replication/logical/reorderbuffer.c| 304 +++-- src/backend/replication/logical/snapbuild.c| 29 +- src/include/replication/reorderbuffer.h| 22 +- 8 files changed, 409 insertions(+), 104 deletions(-)
pgsql: Fix "base" snapshot handling in logical decoding
Fix "base" snapshot handling in logical decoding Two closely related bugs are fixed. First, xmin of logical slots was advanced too early. During xl_running_xacts processing, xmin of the slot was set to the oldest running xid in the record, but that's wrong: actually, snapshots which will be used for not-yet-replayed transactions might consider older txns as running too, so we need to keep xmin back for them. The problem wasn't noticed earlier because DDL which allows to delete tuple (set xmax) while some another not-yet-committed transaction looks at it is pretty rare, if not unique: e.g. all forms of ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock conflicting with any inserts. The included test case (test_decoding's oldest_xmin) uses ALTER of a composite type, which doesn't have such interlocking. To deal with this, we must be able to quickly retrieve oldest xmin (oldest running xid among all assigned snapshots) from ReorderBuffer. To fix, add another list of ReorderBufferTXNs to the reorderbuffer, where transactions are sorted by base-snapshot-LSN. This is slightly different from the existing (sorted by first-LSN) list, because a transaction can have an earlier LSN but a later Xmin, if its first record does not obtain an xmin (eg. xl_xact_assignment). Note this new list doesn't fully replace the existing txn list: we still need that one to prevent WAL recycling. The second issue concerns SnapBuilder snapshots and subtransactions. SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a transaction that is known to be a subtxn, which is good in the common case that the top-level transaction already has one (no point in doing so), but a bug otherwise. To fix, arrange to transfer the snapshot from the subtxn to its top-level txn as soon as the kinship gets known. test_decoding's snapshot_transfer verifies this. Also, fix a minor memory leak: refcount of toplevel's old base snapshot was not decremented when the snapshot is transferred from child. Liberally sprinkle code comments, and rewrite a few existing ones. This part is my (Álvaro's) contribution to this commit, as I had to write all those comments in order to understand the existing code and Arseny's patch. Reported-by: Arseny Sher Diagnosed-by: Arseny Sher Co-authored-by: Arseny Sher Co-authored-by: Álvaro Herrera Reviewed-by: Antonin Houska Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4cb6f783773edd9731751da74ef424aa8c0deb4f Modified Files -- contrib/test_decoding/Makefile | 3 +- contrib/test_decoding/expected/oldest_xmin.out | 27 ++ .../test_decoding/expected/snapshot_transfer.out | 49 contrib/test_decoding/specs/oldest_xmin.spec | 37 +++ contrib/test_decoding/specs/snapshot_transfer.spec | 42 +++ src/backend/replication/logical/reorderbuffer.c| 303 +++-- src/backend/replication/logical/snapbuild.c| 29 +- src/include/replication/reorderbuffer.h| 22 +- 8 files changed, 409 insertions(+), 103 deletions(-)
pgsql: Fix "base" snapshot handling in logical decoding
Fix "base" snapshot handling in logical decoding Two closely related bugs are fixed. First, xmin of logical slots was advanced too early. During xl_running_xacts processing, xmin of the slot was set to the oldest running xid in the record, but that's wrong: actually, snapshots which will be used for not-yet-replayed transactions might consider older txns as running too, so we need to keep xmin back for them. The problem wasn't noticed earlier because DDL which allows to delete tuple (set xmax) while some another not-yet-committed transaction looks at it is pretty rare, if not unique: e.g. all forms of ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock conflicting with any inserts. The included test case (test_decoding's oldest_xmin) uses ALTER of a composite type, which doesn't have such interlocking. To deal with this, we must be able to quickly retrieve oldest xmin (oldest running xid among all assigned snapshots) from ReorderBuffer. To fix, add another list of ReorderBufferTXNs to the reorderbuffer, where transactions are sorted by base-snapshot-LSN. This is slightly different from the existing (sorted by first-LSN) list, because a transaction can have an earlier LSN but a later Xmin, if its first record does not obtain an xmin (eg. xl_xact_assignment). Note this new list doesn't fully replace the existing txn list: we still need that one to prevent WAL recycling. The second issue concerns SnapBuilder snapshots and subtransactions. SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a transaction that is known to be a subtxn, which is good in the common case that the top-level transaction already has one (no point in doing so), but a bug otherwise. To fix, arrange to transfer the snapshot from the subtxn to its top-level txn as soon as the kinship gets known. test_decoding's snapshot_transfer verifies this. Also, fix a minor memory leak: refcount of toplevel's old base snapshot was not decremented when the snapshot is transferred from child. Liberally sprinkle code comments, and rewrite a few existing ones. This part is my (Álvaro's) contribution to this commit, as I had to write all those comments in order to understand the existing code and Arseny's patch. Reported-by: Arseny Sher Diagnosed-by: Arseny Sher Co-authored-by: Arseny Sher Co-authored-by: Álvaro Herrera Reviewed-by: Antonin Houska Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/da10d6a8a94eec016fa072d007bced9159a28d39 Modified Files -- contrib/test_decoding/Makefile | 3 +- contrib/test_decoding/expected/oldest_xmin.out | 27 ++ .../test_decoding/expected/snapshot_transfer.out | 49 contrib/test_decoding/specs/oldest_xmin.spec | 37 +++ contrib/test_decoding/specs/snapshot_transfer.spec | 42 +++ src/backend/replication/logical/reorderbuffer.c| 304 +++-- src/backend/replication/logical/snapbuild.c| 29 +- src/include/replication/reorderbuffer.h| 22 +- 8 files changed, 409 insertions(+), 104 deletions(-)
pgsql: Cosmetic improvements for faster column addition.
Cosmetic improvements for faster column addition. Changed the name of few structure members for the sake of clarity and removed spurious whitespace. Reported-by: Amit Kapila Author: Amit Kapila, based on suggestion by Andrew Dunstan Reviewed-by: Alvaro Herrera Discussion: https://postgr.es/m/CAA4eK1K2znsFpC+NQ9A4vxT4uDxADN4RmvHX0L6Y=ahvo9g...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8121ab88e7dfe6ebe56c58257733354cb85f092c Modified Files -- src/backend/access/common/heaptuple.c | 21 ++--- src/backend/access/common/tupdesc.c | 18 +- src/backend/utils/cache/relcache.c| 10 +- src/include/access/tupdesc_details.h | 5 ++--- 4 files changed, 26 insertions(+), 28 deletions(-)
pgsql: doc: Document some nuances of logical replication of TRUNCATE
doc: Document some nuances of logical replication of TRUNCATE Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c9d6a45724d642a00bd2b4c0f082cf4e1eb76e29 Modified Files -- doc/src/sgml/logical-replication.sgml | 16 1 file changed, 16 insertions(+)
pgsql: Fix whitespace
Fix whitespace Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0fcf5e0e6e7a353f862504da0a321f148ad2de03 Modified Files -- src/test/perl/TestLib.pm| 4 ++-- src/tools/perlcheck/find_perl_files | 3 +-- src/tools/perlcheck/perlcriticrc| 1 - 3 files changed, 3 insertions(+), 5 deletions(-)
pgsql: doc: Improve wording and fix whitespace
doc: Improve wording and fix whitespace Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae5ed75ed4a951c58ec6a76362241b6ac32be61c Modified Files -- doc/src/sgml/logical-replication.sgml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove duplicated return statement from llvmjit code.
Remove duplicated return statement from llvmjit code. The duplicated return clearly doesn't make sense / isn't reachable. Likely introduced by me (Andres), while revising the code. Author: Rushabh Lathia Discussion: https://postgr.es/m/CAGPqQf2raxWOcbuTP36M1rEF3=rfo7od29k3psdyhmee5sw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/986070872ffaae5d9d0e39eddcc952bc261982a2 Modified Files -- src/backend/jit/llvm/llvmjit.c | 1 - 1 file changed, 1 deletion(-)
pgsql: Change pqformat.h's integer handling functions to take unsigned
Change pqformat.h's integer handling functions to take unsigned integers. As added in 1de09ad8eb1fa673ee7899d6dfbb2b49ba204818 the new functions all accept signed integers as parameters. That's not great, because it's perfectly reasonable to call them with unsigned parameters. Unfortunately unsigned to signed conversion is not well defined, when exceeding the range of the signed value. That's presently not a practical issue in postgres (among other reasons because we force gcc's hand with -fwrapv). But it's clearly not quite right. Thus change the signatures to accept unsigned integers instead, signed to unsigned conversion is always well defined. Also change the backward compat pq_sendint() - while it's deprecated it seems better to be consistent. Per discussion between Andrew Gierth, Michael Paquier, Alvaro Herrera and Tom Lane. Reported-By: Andrew Gierth Author: Andres Freund Discussion: https://postgr.es/m/87r2m10zm2@news-spur.riddles.org.uk Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/42121790ca9b27e01fd0471fdac28ec4a381eaee Modified Files -- src/include/libpq/pqformat.h | 82 ++-- 1 file changed, 41 insertions(+), 41 deletions(-)
