pgsql: pg_dump: Refactor dumpDatabase()
pg_dump: Refactor dumpDatabase() Rearrange the version-dependent pieces in the new more modular style. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/56a3e848c74730cde15278266b757f4262948763 Modified Files -- src/bin/pg_dump/pg_dump.c | 39 +-- 1 file changed, 13 insertions(+), 26 deletions(-)
pgsql: Allow special SKIP LOCKED condition in Assert()
Allow special SKIP LOCKED condition in Assert() Under concurrency, it is possible for two sessions to be merrily locking and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the while a third session attempts to lock it, miserably fails at it, and then contemplates life, the universe and everything only to eventually fail an assertion that said bit is not set. Before SKIP LOCKED that was indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified it. This bug is as old as time itself, and even older, if you think time begins with the oldest supported branch. Therefore, backpatch to all supported branches. Author: Simon Riggs Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f185f35a83d980033824c3522b7b97ab1c2de71e Modified Files -- src/backend/access/heap/heapam.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Allow special SKIP LOCKED condition in Assert()
Allow special SKIP LOCKED condition in Assert() Under concurrency, it is possible for two sessions to be merrily locking and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the while a third session attempts to lock it, miserably fails at it, and then contemplates life, the universe and everything only to eventually fail an assertion that said bit is not set. Before SKIP LOCKED that was indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified it. This bug is as old as time itself, and even older, if you think time begins with the oldest supported branch. Therefore, backpatch to all supported branches. Author: Simon Riggs Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/28cd57416eb7cb6642eb23bd8acbf2f41ce76844 Modified Files -- src/backend/access/heap/heapam.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Allow special SKIP LOCKED condition in Assert()
Allow special SKIP LOCKED condition in Assert() Under concurrency, it is possible for two sessions to be merrily locking and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the while a third session attempts to lock it, miserably fails at it, and then contemplates life, the universe and everything only to eventually fail an assertion that said bit is not set. Before SKIP LOCKED that was indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified it. This bug is as old as time itself, and even older, if you think time begins with the oldest supported branch. Therefore, backpatch to all supported branches. Author: Simon Riggs Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0...@mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6b681cd056bb8c821f8853463938070ce0dade8f Modified Files -- src/backend/access/heap/heapam.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Allow special SKIP LOCKED condition in Assert()
Allow special SKIP LOCKED condition in Assert() Under concurrency, it is possible for two sessions to be merrily locking and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the while a third session attempts to lock it, miserably fails at it, and then contemplates life, the universe and everything only to eventually fail an assertion that said bit is not set. Before SKIP LOCKED that was indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified it. This bug is as old as time itself, and even older, if you think time begins with the oldest supported branch. Therefore, backpatch to all supported branches. Author: Simon Riggs Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/026a93727c85704cb885a2d83c87a576b4fe2c86 Modified Files -- src/backend/access/heap/heapam.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Allow special SKIP LOCKED condition in Assert()
Allow special SKIP LOCKED condition in Assert() Under concurrency, it is possible for two sessions to be merrily locking and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the while a third session attempts to lock it, miserably fails at it, and then contemplates life, the universe and everything only to eventually fail an assertion that said bit is not set. Before SKIP LOCKED that was indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified it. This bug is as old as time itself, and even older, if you think time begins with the oldest supported branch. Therefore, backpatch to all supported branches. Author: Simon Riggs Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f66885bec0df509ee9b604a83c17dbd7eb9959b1 Modified Files -- src/backend/access/heap/heapam.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Allow special SKIP LOCKED condition in Assert()
Allow special SKIP LOCKED condition in Assert() Under concurrency, it is possible for two sessions to be merrily locking and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the while a third session attempts to lock it, miserably fails at it, and then contemplates life, the universe and everything only to eventually fail an assertion that said bit is not set. Before SKIP LOCKED that was indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified it. This bug is as old as time itself, and even older, if you think time begins with the oldest supported branch. Therefore, backpatch to all supported branches. Author: Simon Riggs Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/29f9fb8fe87005b2a75bd8ad2bc3d1f3ac0e9561 Modified Files -- src/backend/access/heap/heapam.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Fix silly mistake in Assert
Fix silly mistake in Assert Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/67a8cb5cbfffa9f104a5965a2152e5256dd2be2c Modified Files -- src/backend/access/heap/heapam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix silly mistake in Assert
Fix silly mistake in Assert Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33fdd9f854f8db263d96e2916aa67325b8b26992 Modified Files -- src/backend/access/heap/heapam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix silly mistake in Assert
Fix silly mistake in Assert Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b63851a45635299929301a849327c392da3c1a34 Modified Files -- src/backend/access/heap/heapam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix silly mistake in Assert
Fix silly mistake in Assert Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f9db153c282de599a7d5ae2694f50fe10fba8461 Modified Files -- src/backend/access/heap/heapam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix silly mistake in Assert
Fix silly mistake in Assert Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/397b43948861155893da0f04b4de8e7ff021636f Modified Files -- src/backend/access/heap/heapam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Fix silly mistake in Assert
Fix silly mistake in Assert Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a8282425f6b6db19a07dcb634b5a670d0289c95 Modified Files -- src/backend/access/heap/heapam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Remove redundant initialization of BrinMemTuple.
Remove redundant initialization of BrinMemTuple. brin_new_memtuple already did this, so there's no need for initialize_brin_buildstate to do it again. Richard Guo, reviewed by Bharath Rupireddy Discussion: https://postgr.es/m/CAMbWs4-kYYpKNOdiWtsCZ3jbkFFj4nhOVH22JH7dsrMYX=a...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/913a03ec29abcb6c20e5941e5f3ac0578619cd3e Modified Files -- src/backend/access/brin/brin.c | 2 -- 1 file changed, 2 deletions(-)
pgsql: Reduce relcache access in WAL sender streaming logical changes
Reduce relcache access in WAL sender streaming logical changes get_rel_sync_entry(), which is called each time a change needs to be logically replicated, is a rather hot code path in the WAL sender sending logical changes. This code path was doing a relcache access on relkind and relpartition for each logical change, but we only need to know this information when building or re-building the cached information for a relation. Some measurements prove that this is noticeable in perf profiles, particularly when attempting to replicate changes from relations that are not published as these cause less overhead in the WAL sender, delaying further the replication of changes for relations that are published. Issue introduced in 83fd453. Author: Hou Zhijie Reviewed-by: Kyotaro Horiguchi, Euler Taveira Discussion: https://postgr.es/m/os0pr01mb5716e863aa9e591c1f010f7a94...@os0pr01mb5716.jpnprd01.prod.outlook.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ce16088bfed97f982f66a9dc17b8364df289e4d Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Reduce relcache access in WAL sender streaming logical changes
Reduce relcache access in WAL sender streaming logical changes get_rel_sync_entry(), which is called each time a change needs to be logically replicated, is a rather hot code path in the WAL sender sending logical changes. This code path was doing a relcache access on relkind and relpartition for each logical change, but we only need to know this information when building or re-building the cached information for a relation. Some measurements prove that this is noticeable in perf profiles, particularly when attempting to replicate changes from relations that are not published as these cause less overhead in the WAL sender, delaying further the replication of changes for relations that are published. Issue introduced in 83fd453. Author: Hou Zhijie Reviewed-by: Kyotaro Horiguchi, Euler Taveira Discussion: https://postgr.es/m/os0pr01mb5716e863aa9e591c1f010f7a94...@os0pr01mb5716.jpnprd01.prod.outlook.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5ddfebded41f7754b3c4fc1b576ca33736efcab6 Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Reduce relcache access in WAL sender streaming logical changes
Reduce relcache access in WAL sender streaming logical changes get_rel_sync_entry(), which is called each time a change needs to be logically replicated, is a rather hot code path in the WAL sender sending logical changes. This code path was doing a relcache access on relkind and relpartition for each logical change, but we only need to know this information when building or re-building the cached information for a relation. Some measurements prove that this is noticeable in perf profiles, particularly when attempting to replicate changes from relations that are not published as these cause less overhead in the WAL sender, delaying further the replication of changes for relations that are published. Issue introduced in 83fd453. Author: Hou Zhijie Reviewed-by: Kyotaro Horiguchi, Euler Taveira Discussion: https://postgr.es/m/os0pr01mb5716e863aa9e591c1f010f7a94...@os0pr01mb5716.jpnprd01.prod.outlook.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3f8062bcf7f9fdc5b0f9dac41cbe62204969ebd1 Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
