pgsql: Add some not null constraints to catalogs
Add some not null constraints to catalogs Use BKI_FORCE_NOT_NULL on some catalog field declarations that are never null (according to the source code that accesses them). Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9b39b799db781642dd0c1424c28e827d19663e20 Modified Files -- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_attrdef.h | 4 ++-- src/include/catalog/pg_default_acl.h | 2 +- src/include/catalog/pg_policy.h | 2 +- src/include/catalog/pg_rewrite.h | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-)
pgsql: Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY i
Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items. The archive should show a dependency on the item's table, but it failed to include one. This could cause failures in parallel restore due to emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring the table's data. In practice the odds of a problem seem low, since you would typically need to have set FORCE ROW LEVEL SECURITY as well, and you'd also need a very high --jobs count to have any chance of this happening. That probably explains the lack of field reports. Still, it's a bug, so back-patch to 9.5 where RLS was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0f3dd76f527deb81ee5ba60048df04c598c93960 Modified Files -- src/bin/pg_dump/pg_dump.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY i
Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items. The archive should show a dependency on the item's table, but it failed to include one. This could cause failures in parallel restore due to emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring the table's data. In practice the odds of a problem seem low, since you would typically need to have set FORCE ROW LEVEL SECURITY as well, and you'd also need a very high --jobs count to have any chance of this happening. That probably explains the lack of field reports. Still, it's a bug, so back-patch to 9.5 where RLS was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/173df4cd36dfc8cbb36de908cea6bd03b13c0cb8 Modified Files -- src/bin/pg_dump/pg_dump.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY i
Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items. The archive should show a dependency on the item's table, but it failed to include one. This could cause failures in parallel restore due to emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring the table's data. In practice the odds of a problem seem low, since you would typically need to have set FORCE ROW LEVEL SECURITY as well, and you'd also need a very high --jobs count to have any chance of this happening. That probably explains the lack of field reports. Still, it's a bug, so back-patch to 9.5 where RLS was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3998e55af0505458e99b11bb0b77bb528e647696 Modified Files -- src/bin/pg_dump/pg_dump.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY i
Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items. The archive should show a dependency on the item's table, but it failed to include one. This could cause failures in parallel restore due to emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring the table's data. In practice the odds of a problem seem low, since you would typically need to have set FORCE ROW LEVEL SECURITY as well, and you'd also need a very high --jobs count to have any chance of this happening. That probably explains the lack of field reports. Still, it's a bug, so back-patch to 9.5 where RLS was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cbdca00bef59ee204313fe8f0e4f36bc804a38aa Modified Files -- src/bin/pg_dump/pg_dump.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY i
Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items. The archive should show a dependency on the item's table, but it failed to include one. This could cause failures in parallel restore due to emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring the table's data. In practice the odds of a problem seem low, since you would typically need to have set FORCE ROW LEVEL SECURITY as well, and you'd also need a very high --jobs count to have any chance of this happening. That probably explains the lack of field reports. Still, it's a bug, so back-patch to 9.5 where RLS was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c5e235ff8ad0f4907a736a6440dc4be6f939e65c Modified Files -- src/bin/pg_dump/pg_dump.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix snapshot leak warning for some procedures
Fix snapshot leak warning for some procedures The problem arises with the combination of CALL with output parameters and doing a COMMIT inside the procedure. When a CALL has output parameters, the portal uses the strategy PORTAL_UTIL_SELECT instead of PORTAL_MULTI_QUERY. Using PORTAL_UTIL_SELECT causes the portal's snapshot to be registered with the current resource owner (portal->holdSnapshot); see 9ee1cf04ab6bcefe03a11837b53f29ca9dc24c7a for the reason. Normally, PortalDrop() unregisters the snapshot. If not, then ResourceOwnerRelease() will print a warning about a snapshot leak on transaction commit. A transaction commit normally drops all portals (PreCommit_Portals()), except the active portal. So in case of the active portal, we need to manually release the snapshot to avoid the warning. Reported-by: Prabhat Sahu Reviewed-by: Jonathan S. Katz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7a3b7bbfded3142aaa8edae2dbc88999568cc1cd Modified Files -- src/backend/utils/mmgr/portalmem.c | 14 -- .../plpgsql/src/expected/plpgsql_transaction.out | 30 ++ src/pl/plpgsql/src/sql/plpgsql_transaction.sql | 25 ++ 3 files changed, 67 insertions(+), 2 deletions(-)
pgsql: Fix snapshot leak warning for some procedures
Fix snapshot leak warning for some procedures The problem arises with the combination of CALL with output parameters and doing a COMMIT inside the procedure. When a CALL has output parameters, the portal uses the strategy PORTAL_UTIL_SELECT instead of PORTAL_MULTI_QUERY. Using PORTAL_UTIL_SELECT causes the portal's snapshot to be registered with the current resource owner (portal->holdSnapshot); see 9ee1cf04ab6bcefe03a11837b53f29ca9dc24c7a for the reason. Normally, PortalDrop() unregisters the snapshot. If not, then ResourceOwnerRelease() will print a warning about a snapshot leak on transaction commit. A transaction commit normally drops all portals (PreCommit_Portals()), except the active portal. So in case of the active portal, we need to manually release the snapshot to avoid the warning. Reported-by: Prabhat Sahu Reviewed-by: Jonathan S. Katz Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2657d4ea66c775c3334181722115be2d6128c5cd Modified Files -- src/backend/utils/mmgr/portalmem.c | 14 -- .../plpgsql/src/expected/plpgsql_transaction.out | 30 ++ src/pl/plpgsql/src/sql/plpgsql_transaction.sql | 25 ++ 3 files changed, 67 insertions(+), 2 deletions(-)
pgsql: Code review for simplehash.h.
Code review for simplehash.h. Fix reference to non-existent file in comment. Add SH_ prefix to the EMPTY and IN_USE tokens, to reduce likelihood of collisions with unrelated macros. Add include guards around the function definitions that are not "parameterized", so the header can be used again in the same translation unit. Undefine SH_EQUAL macro where other "parameter" macros are undefined, for the same reason. Author: Thomas Munro Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAEepm%3D1LdXZ3mMTM8tHt_b%3DK1kREit%3Dp8sikesak%3DkzHHM07Nw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ee0e2745c2f2c8ac47250dde718ac712686a79aa Modified Files -- src/include/lib/simplehash.h | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-)
