pgsql: Allow using the updated tuple while moving it to a different par
Allow using the updated tuple while moving it to a different partition. An update that causes the tuple to be moved to a different partition was missing out on re-constructing the to-be-updated tuple, based on the latest tuple in the update chain. Instead, it's simply deleting the latest tuple and inserting a new tuple in the new partition based on the old tuple. Commit 2f17844104 didn't consider this case, so some of the updates were getting lost. In passing, change the argument order for output parameter in ExecDelete and add some commentary about it. Reported-by: Pavan Deolasee Author: Amit Khandekar, with minor changes by me Reviewed-by: Dilip Kumar, Amit Kapila and Alvaro Herrera Backpatch-through: 11 Discussion: https://postgr.es/m/CAJ3gD9fRbEzDqdeDq1jxqZUb47kJn+tQ7=bcgjc8quqksdv...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0527df732beb8c2d584c7e4ea5aeb05cf92e14a2 Modified Files -- src/backend/commands/trigger.c | 22 ++- src/backend/executor/execReplication.c | 2 +- src/backend/executor/nodeModifyTable.c | 73 +++-- src/include/commands/trigger.h | 3 +- .../isolation/expected/partition-key-update-4.out | 60 + src/test/isolation/isolation_schedule | 1 + .../isolation/specs/partition-key-update-4.spec| 76 ++ 7 files changed, 214 insertions(+), 23 deletions(-)
pgsql: Allow using the updated tuple while moving it to a different par
Allow using the updated tuple while moving it to a different partition. An update that causes the tuple to be moved to a different partition was missing out on re-constructing the to-be-updated tuple, based on the latest tuple in the update chain. Instead, it's simply deleting the latest tuple and inserting a new tuple in the new partition based on the old tuple. Commit 2f17844104 didn't consider this case, so some of the updates were getting lost. In passing, change the argument order for output parameter in ExecDelete and add some commentary about it. Reported-by: Pavan Deolasee Author: Amit Khandekar, with minor changes by me Reviewed-by: Dilip Kumar, Amit Kapila and Alvaro Herrera Backpatch-through: 11 Discussion: https://postgr.es/m/CAJ3gD9fRbEzDqdeDq1jxqZUb47kJn+tQ7=bcgjc8quqksdv...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/40ca70ebcc9d0bc1c02937b27c44b2766617e790 Modified Files -- src/backend/commands/trigger.c | 22 ++- src/backend/executor/execReplication.c | 2 +- src/backend/executor/nodeModifyTable.c | 73 +++-- src/include/commands/trigger.h | 3 +- .../isolation/expected/partition-key-update-4.out | 60 + src/test/isolation/isolation_schedule | 1 + .../isolation/specs/partition-key-update-4.spec| 76 ++ 7 files changed, 214 insertions(+), 23 deletions(-)
Re: pgsql: Allow using the updated tuple while moving it to a different par
On Thu, Jul 12, 2018 at 07:33:54AM +, Amit Kapila wrote: > Allow using the updated tuple while moving it to a different partition. > > An update that causes the tuple to be moved to a different partition was > missing out on re-constructing the to-be-updated tuple, based on the latest > tuple in the update chain. Instead, it's simply deleting the latest tuple > and inserting a new tuple in the new partition based on the old tuple. > Commit 2f17844104 didn't consider this case, so some of the updates were > getting lost. > > In passing, change the argument order for output parameter in ExecDelete > and add some commentary about it. Looks unrelated, but flaviventris (a snake?) has just complained: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2018-07-12%2007%3A36%3A01 -- Michael signature.asc Description: PGP signature
Re: pgsql: Allow using the updated tuple while moving it to a different par
On Thu, Jul 12, 2018 at 1:29 PM, Michael Paquier wrote: > On Thu, Jul 12, 2018 at 07:33:54AM +, Amit Kapila wrote: >> Allow using the updated tuple while moving it to a different partition. >> >> An update that causes the tuple to be moved to a different partition was >> missing out on re-constructing the to-be-updated tuple, based on the latest >> tuple in the update chain. Instead, it's simply deleting the latest tuple >> and inserting a new tuple in the new partition based on the old tuple. >> Commit 2f17844104 didn't consider this case, so some of the updates were >> getting lost. >> >> In passing, change the argument order for output parameter in ExecDelete >> and add some commentary about it. > > Looks unrelated, but flaviventris (a snake?) has just complained: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2018-07-12%2007%3A36%3A01 > Yeah, I am confused as to how this commit can lead to that failure. Anyway, just to clarify my understanding, it seems that master node has executed an Insert statement (INSERT INTO replayed(val) SELECT coalesce(max(val),0) + 1 AS newval FROM replayed RETURNING val) and waiting for standby to sync up. In the meantime, some background process (probably walsender ?) crashed. Are you seeing anything different? Any other clue? By the way, I could see the same (appears to be same) failure in other buildfarm (skink, serinus, etc.) logs in some previous runs: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-11-30%2008%3A47%3A34 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2018-05-18%2020%3A14%3A01 -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
pgsql: Add regression test for system catalog toast tables
Add regression test for system catalog toast tables For the moment, this just records which system catalogs have toast tables right now. Future patches will possibly change that set. from Tom Lane via Joe Conway Discussion: https://www.postgresql.org/message-id/flat/84ddff04-f122-784b-b6c5-353680449...@joeconway.com/ Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ecd6b4342ad9f867e62979e85efa8fdb5fc904e5 Modified Files -- src/test/regress/expected/misc_sanity.out | 67 +++ src/test/regress/sql/misc_sanity.sql | 15 +++ 2 files changed, 82 insertions(+)
pgsql: Improve two error messages
Improve two error messages Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8e599897ca20fe31cb58fad0b401d7e317235024 Modified Files -- src/backend/parser/parse_utilcmd.c | 2 +- src/bin/pg_upgrade/check.c | 6 -- 2 files changed, 5 insertions(+), 3 deletions(-)
pgsql: Doc: clarify release note text about v11's new window function f
Doc: clarify release note text about v11's new window function features. Jonathan S. Katz Discussion: https://postgr.es/m/30468663-e67d-4753-8269-7e6a4001a...@excoventures.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/11a3aeeb5e174a3681f674e7e5ec9bbbc6430394 Modified Files -- doc/src/sgml/release-11.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Doc: update documentation for requirement of ORDER BY in GROUPS
Doc: update documentation for requirement of ORDER BY in GROUPS mode. Commit ff4f88916 adjusted the code to enforce the SQL spec's requirement that a window using GROUPS mode must have an ORDER BY clause. But I missed that the documentation explicitly said you didn't have to have one. Also minor wordsmithing in the window-function section of select.sgml. Per Masahiko Sawada, though I didn't use his patch. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/663060e8c3832ea8388e4ae128420f76680e5fe9 Modified Files -- doc/src/sgml/ref/select.sgml | 6 +++--- doc/src/sgml/syntax.sgml | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-)
pgsql: Doc: update documentation for requirement of ORDER BY in GROUPS
Doc: update documentation for requirement of ORDER BY in GROUPS mode. Commit ff4f88916 adjusted the code to enforce the SQL spec's requirement that a window using GROUPS mode must have an ORDER BY clause. But I missed that the documentation explicitly said you didn't have to have one. Also minor wordsmithing in the window-function section of select.sgml. Per Masahiko Sawada, though I didn't use his patch. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e0cd0ea4f93c3644f09f7723206d8d003a97ee4a Modified Files -- doc/src/sgml/ref/select.sgml | 6 +++--- doc/src/sgml/syntax.sgml | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-)
pgsql: Doc: clarify release note text about v11's new window function f
Doc: clarify release note text about v11's new window function features. Jonathan S. Katz Discussion: https://postgr.es/m/30468663-e67d-4753-8269-7e6a4001a...@excoventures.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/510421c45fb41869969a708a8c03c12798a724ec Modified Files -- doc/src/sgml/release-11.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix FK checks of TRUNCATE involving partitioned tables
Fix FK checks of TRUNCATE involving partitioned tables When truncating a table that is referenced by foreign keys in partitioned tables, the check to ensure the referencing table are also truncated spuriously failed. This is because it was relying on relhastriggers as a proxy for the table having FKs, and that's wrong for partitioned tables. Fix it to consider such tables separately. There may be a better way ... but this code is pretty inefficient already. Author: Álvaro Herrera Reviewed-by: Michael Paquiër Discussion: https://postgr.es/m/20180711000624.zmeizicibxeehhsg@alvherre.pgsql Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/727196ced2423008bb25d7775c4e3b7fca063c8b Modified Files -- src/backend/catalog/heap.c | 7 +++- src/backend/commands/tablecmds.c | 2 +- src/test/regress/expected/truncate.out | 75 ++ src/test/regress/sql/truncate.sql | 47 + 4 files changed, 128 insertions(+), 3 deletions(-)
pgsql: Fix FK checks of TRUNCATE involving partitioned tables
Fix FK checks of TRUNCATE involving partitioned tables When truncating a table that is referenced by foreign keys in partitioned tables, the check to ensure the referencing table are also truncated spuriously failed. This is because it was relying on relhastriggers as a proxy for the table having FKs, and that's wrong for partitioned tables. Fix it to consider such tables separately. There may be a better way ... but this code is pretty inefficient already. Author: Álvaro Herrera Reviewed-by: Michael Paquiër Discussion: https://postgr.es/m/20180711000624.zmeizicibxeehhsg@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd073d8f7043d047c024f0f213c0e9c31b9c0505 Modified Files -- src/backend/catalog/heap.c | 7 +++- src/backend/commands/tablecmds.c | 2 +- src/test/regress/expected/truncate.out | 75 ++ src/test/regress/sql/truncate.sql | 47 + 4 files changed, 128 insertions(+), 3 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f38d5a27373ff281f2eb62a156d058e57cfac96e Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/632b4ae92dc6fb92149e94290760b50744e0bd35 Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/93532dbb5d91280400d337197752f4f91f29349f Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2e7a25c1dcb7acb9d1138934cade1f1a7e6fe690 Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5593280e203d0f7d93dea1f1387e0a7948a2d3af Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aacdf9a06966d57bb8f6968a41e0690a31d35a51 Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation. Explain that you can use any integer expression for the "count" in pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only allow a constant. Remove the duplicate version of this para under MOVE. I don't see a good reason to maintain two identical paras when we just said that MOVE works exactly like FETCH. Per Pavel Stehule, though I didn't use his text. Discussion: https://postgr.es/m/cafj8pracvsxcndugx43bok1e3nnpbqny7neotln42af+8my...@mail.gmail.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b4900835d63cf0c56ab97b7b666d6407d3d98c22 Modified Files -- doc/src/sgml/plpgsql.sgml | 24 doc/src/sgml/ref/fetch.sgml | 2 +- 2 files changed, 5 insertions(+), 21 deletions(-)
pgsql: Reset shmem_exit_inprogress after shmem_exit()
Reset shmem_exit_inprogress after shmem_exit() In ad9a274778d2d88c46b90309212b92ee7fdf9afe, shmem_exit_inprogress was introduced. But we need to reset it after shmem_exit(), because unlike the similar proc_exit(), shmem_exit() can also be called for cleanup when the process will not exit. Reported-by: Andrew Gierth Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/39035a52894a419ae1b905adfdb0bad72ee19a36 Modified Files -- src/backend/storage/ipc/ipc.c | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Reset shmem_exit_inprogress after shmem_exit()
Reset shmem_exit_inprogress after shmem_exit() In ad9a274778d2d88c46b90309212b92ee7fdf9afe, shmem_exit_inprogress was introduced. But we need to reset it after shmem_exit(), because unlike the similar proc_exit(), shmem_exit() can also be called for cleanup when the process will not exit. Reported-by: Andrew Gierth Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5e6e2c8773dd8e3037d9195452dc5e423367e1b0 Modified Files -- src/backend/storage/ipc/ipc.c | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Clean up temporary WAL segments after an instance crash
Clean up temporary WAL segments after an instance crash Temporary WAL segments are created in pg_wal and named as xlogtemp.pid before being renamed to the real deal when creating a new segment. If an instance crashes after the temporary segment is created and before the rename is done, then the server would finish with unremovable data. After an instance crash, scan pg_wal and remove any such segments. With repetitive unlucky crashes this would contribute to disk bloat and presents risks of ENOSPC especially with max_wal_size close to the maximum allowed. Author: Michael Paquier Reviewed-by: Yugo Nagata, Heikki Linnakangas Discussion: https://postgr.es/m/20180514054955.gf1...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5fc1008e8a8b9e96ac75b4db5dd9ad2b99a9c8b2 Modified Files -- src/backend/access/transam/xlog.c | 52 +-- 1 file changed, 45 insertions(+), 7 deletions(-)
Re: pgsql: Allow using the updated tuple while moving it to a different par
Amit Kapila writes:
> On Thu, Jul 12, 2018 at 1:29 PM, Michael Paquier wrote:
>> Looks unrelated, but flaviventris (a snake?) has just complained:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2018-07-12%2007%3A36%3A01
> Yeah, I am confused as to how this commit can lead to that failure.
It didn't; looks like just a random failure to me. The test is timing
out:
ok 26 - catalog xmin of cascaded slot still null with hs_feedback reset
# re-enabling hot_standby_feedback and disabling while stopped
### Reloading node "standby_2"
# Running: pg_ctl -D
/home/bf/build/buildfarm-flaviventris/HEAD/pgsql.build/src/test/recovery/tmp_check/t_001_stream_rep_standby_2_data/pgdata
reload
server signaled
Waiting for replication conn standby_1's replay_lsn to pass '0/30A1720' on
master
done
Waiting for replication conn standby_2's replay_lsn to pass '0/30A1720' on
standby_1
done
### Stopping node "standby_2" using mode fast
# Running: pg_ctl -D
/home/bf/build/buildfarm-flaviventris/HEAD/pgsql.build/src/test/recovery/tmp_check/t_001_stream_rep_standby_2_data/pgdata
-m fast stop
waiting for server to shut down done
server stopped
# No postmaster PID for node "standby_2"
#
Timed out waiting for slot xmins to advance at t/001_stream_rep.pl line 157.
This looks to me like it's probably a low-probability timing problem in
the test script itself. The relevant part of the script is
$node_master->safe_psql('postgres', qq[INSERT INTO tab_int VALUES (11000);]);
replay_check();
$node_standby_2->safe_psql('postgres',
'ALTER SYSTEM SET hot_standby_feedback = off;');
$node_standby_2->stop;
($xmin, $catalog_xmin) =
get_slot_xmins($node_standby_1, $slotname_2, "xmin IS NOT NULL");
isnt($xmin, '', 'xmin of cascaded slot non-null with postgres shut down');
where the failure is occurring because get_slot_xmins() never sees the
expected state. I'm suspicious that this is happening because the script
is making no attempt to ensure the relative timing of events on the three
servers --- notably, issuing a "reload" does nothing to guarantee that
the server has actually seen and responded to the parameter change.
As an extreme case, I can reproduce the failure exactly with this:
diff --git a/src/test/recovery/t/001_stream_rep.pl
b/src/test/recovery/t/001_stream_rep.pl
index a0d3e8f..0824184 100644
--- a/src/test/recovery/t/001_stream_rep.pl
+++ b/src/test/recovery/t/001_stream_rep.pl
@@ -286,7 +286,7 @@ is($catalog_xmin, '',
note "re-enabling hot_standby_feedback and disabling while stopped";
$node_standby_2->safe_psql('postgres',
'ALTER SYSTEM SET hot_standby_feedback = on;');
-$node_standby_2->reload;
+# $node_standby_2->reload;
$node_master->safe_psql('postgres', qq[INSERT INTO tab_int VALUES (11000);]);
replay_check();
so I'm thinking that what we're seeing is an effect of the second standby
sometimes being too slow to turn on hot_standby_feedback.
We could maybe hack around that with a short "sleep" in this script, but
a less cruddy solution would be to change PostgresNode::reload so that
it somehow waits for the server to process the reload signal.
regards, tom lane
pgsql: Fix argument of pg_create_logical_replication_slot for slot name
Fix argument of pg_create_logical_replication_slot for slot name All attributes and arguments using a slot name map to the data type "name", but this function has been using "text". This is cosmetic, as even if text is used then the slot name would be truncated to 64 characters anyway and stored as such. The documentation already said so and the function already assumed that the argument was of this type when fetching its value. Bump catalog version. Author: Sawada Masahiko Discussion: https://postgr.es/m/CAD21AoADYz_-eAqH5AVFaCaojcRgwpo9PW=u8kgtmys63ob...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ce89ad0fa07d98e20380867811a5269ee36d45c7 Modified Files -- src/backend/catalog/system_views.sql | 2 +- src/backend/replication/slotfuncs.c | 2 +- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_proc.dat | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
pgsql: Add pg_dump --on-conflict-do-nothing option.
Add pg_dump --on-conflict-do-nothing option. When dumping INSERT statements, optionally add ON CONFLICT DO NOTHING. Author: Surafel Temesgen Reviewed-by: Takeshi Ideriha, Nico Williams, Dilip Kumar Discussion: https://postgr.es/m/CALAY4q-PQ9cOEzs2%2BQHK5ObfF_4QbmBaYXbZx6BGGN66Q-n8FA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/387a5cfb94f041ffe18d03ccc4063c626bb4b73e Modified Files -- doc/src/sgml/ref/pg_dump.sgml| 12 doc/src/sgml/ref/pg_dumpall.sgml | 12 src/bin/pg_dump/pg_backup.h | 1 + src/bin/pg_dump/pg_dump.c| 11 ++- src/bin/pg_dump/pg_dumpall.c | 5 + src/bin/pg_dump/t/001_basic.pl | 7 ++- 6 files changed, 46 insertions(+), 2 deletions(-)
pgsql: Accept invalidation messages in InitializeSessionUserId().
Accept invalidation messages in InitializeSessionUserId(). If the authentication method modified the system catalogs through a separate database connection (say, to create a new role on the fly), make sure syscache sees the changes before we try to find the user. Author: Thomas Munro Reviewed-by: Tom Lane, Andres Freund Discussion: https://postgr.es/m/CAEepm%3D3_h0_cgmz5PMyab4xk_OFrg6G5VCN%3DnF4chFXM9iFOqA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e8d9caa436db2931613d7cb4a4a8b3933d5f6ded Modified Files -- src/backend/utils/init/miscinit.c | 8 1 file changed, 8 insertions(+)
