pgsql: Avoid direct C access to possibly-null pg_subscription_rel.srsub
Avoid direct C access to possibly-null pg_subscription_rel.srsublsn. This coding technique is unsafe, since we'd be accessing off the end of the tuple if the field is null. SIGSEGV is pretty improbable, but perhaps not impossible. Also, returning garbage for the LSN doesn't seem like a great idea, even if callers aren't looking at it today. Also update docs to point out explicitly that pg_subscription.subslotname and pg_subscription_rel.srsublsn can be null. Perhaps we should mark these two fields BKI_FORCE_NULL, so that they'd be correctly labeled in databases that are initdb'd in the future. But we can't force that for existing databases, and on balance it's not too clear that having a mix of different catalog contents in the field would be wise. Apply to v10 (where this code came in) through v12. Already fixed in v13 and HEAD. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ae3d40b0cdc6bff33ad3caf5e8766b85ebe24168 Modified Files -- doc/src/sgml/catalogs.sgml| 9 ++--- src/backend/catalog/pg_subscription.c | 18 -- src/include/catalog/pg_subscription_rel.h | 13 +++-- 3 files changed, 33 insertions(+), 7 deletions(-)
pgsql: Avoid direct C access to possibly-null pg_subscription_rel.srsub
Avoid direct C access to possibly-null pg_subscription_rel.srsublsn. This coding technique is unsafe, since we'd be accessing off the end of the tuple if the field is null. SIGSEGV is pretty improbable, but perhaps not impossible. Also, returning garbage for the LSN doesn't seem like a great idea, even if callers aren't looking at it today. Also update docs to point out explicitly that pg_subscription.subslotname and pg_subscription_rel.srsublsn can be null. Perhaps we should mark these two fields BKI_FORCE_NULL, so that they'd be correctly labeled in databases that are initdb'd in the future. But we can't force that for existing databases, and on balance it's not too clear that having a mix of different catalog contents in the field would be wise. Apply to v10 (where this code came in) through v12. Already fixed in v13 and HEAD. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b7103bbe34aa3d66f4618d0abdee5d3107ea8f91 Modified Files -- doc/src/sgml/catalogs.sgml| 9 ++--- src/backend/catalog/pg_subscription.c | 18 -- src/include/catalog/pg_subscription_rel.h | 13 +++-- 3 files changed, 33 insertions(+), 7 deletions(-)
pgsql: Avoid direct C access to possibly-null pg_subscription_rel.srsub
Avoid direct C access to possibly-null pg_subscription_rel.srsublsn. This coding technique is unsafe, since we'd be accessing off the end of the tuple if the field is null. SIGSEGV is pretty improbable, but perhaps not impossible. Also, returning garbage for the LSN doesn't seem like a great idea, even if callers aren't looking at it today. Also update docs to point out explicitly that pg_subscription.subslotname and pg_subscription_rel.srsublsn can be null. Perhaps we should mark these two fields BKI_FORCE_NULL, so that they'd be correctly labeled in databases that are initdb'd in the future. But we can't force that for existing databases, and on balance it's not too clear that having a mix of different catalog contents in the field would be wise. Apply to v10 (where this code came in) through v12. Already fixed in v13 and HEAD. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/99b0c5da3e10a9f64ed2790ed34d8de3075edb20 Modified Files -- doc/src/sgml/catalogs.sgml| 9 ++--- src/backend/catalog/pg_subscription.c | 18 -- src/include/catalog/pg_subscription_rel.h | 13 +++-- 3 files changed, 33 insertions(+), 7 deletions(-)
pgsql: Assert that we don't insert nulls into attnotnull catalog column
Assert that we don't insert nulls into attnotnull catalog columns. The executor checks for this error, and so does the bootstrap catalog loader, but we never checked for it in retail catalog manipulations. The folly of that has now been exposed, so let's add assertions checking it. Checking in CatalogTupleInsert[WithInfo] and CatalogTupleUpdate[WithInfo] should be enough to cover this. Back-patch to v10; the aforesaid functions didn't exist before that, and it didn't seem worth adapting the patch to the oldest branches. But given the risk of JIT crashes, I think we certainly need this as far back as v11. Pre-v13, we have to explicitly exclude pg_subscription.subslotname and pg_subscription_rel.srsublsn from the checks, since they are mismarked. (Even if we change our mind about applying BKI_FORCE_NULL in the branch tips, it doesn't seem wise to have assertions that would fire in existing databases.) Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3e66019f15549d3e1e13da665b2549684061d630 Modified Files -- doc/src/sgml/bki.sgml | 5 + src/backend/catalog/indexing.c | 45 ++ 2 files changed, 46 insertions(+), 4 deletions(-)
pgsql: Assert that we don't insert nulls into attnotnull catalog column
Assert that we don't insert nulls into attnotnull catalog columns. The executor checks for this error, and so does the bootstrap catalog loader, but we never checked for it in retail catalog manipulations. The folly of that has now been exposed, so let's add assertions checking it. Checking in CatalogTupleInsert[WithInfo] and CatalogTupleUpdate[WithInfo] should be enough to cover this. Back-patch to v10; the aforesaid functions didn't exist before that, and it didn't seem worth adapting the patch to the oldest branches. But given the risk of JIT crashes, I think we certainly need this as far back as v11. Pre-v13, we have to explicitly exclude pg_subscription.subslotname and pg_subscription_rel.srsublsn from the checks, since they are mismarked. (Even if we change our mind about applying BKI_FORCE_NULL in the branch tips, it doesn't seem wise to have assertions that would fire in existing databases.) Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb71329ad6fcd81dd3fcfb1f21308ccb64f7a834 Modified Files -- src/backend/catalog/indexing.c | 57 ++ 1 file changed, 57 insertions(+)
pgsql: Assert that we don't insert nulls into attnotnull catalog column
Assert that we don't insert nulls into attnotnull catalog columns. The executor checks for this error, and so does the bootstrap catalog loader, but we never checked for it in retail catalog manipulations. The folly of that has now been exposed, so let's add assertions checking it. Checking in CatalogTupleInsert[WithInfo] and CatalogTupleUpdate[WithInfo] should be enough to cover this. Back-patch to v10; the aforesaid functions didn't exist before that, and it didn't seem worth adapting the patch to the oldest branches. But given the risk of JIT crashes, I think we certainly need this as far back as v11. Pre-v13, we have to explicitly exclude pg_subscription.subslotname and pg_subscription_rel.srsublsn from the checks, since they are mismarked. (Even if we change our mind about applying BKI_FORCE_NULL in the branch tips, it doesn't seem wise to have assertions that would fire in existing databases.) Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bca409e5b160f81ccd980bef2aeb32f8b731b0fd Modified Files -- doc/src/sgml/bki.sgml | 5 + src/backend/catalog/indexing.c | 45 ++ 2 files changed, 46 insertions(+), 4 deletions(-)
pgsql: Assert that we don't insert nulls into attnotnull catalog column
Assert that we don't insert nulls into attnotnull catalog columns. The executor checks for this error, and so does the bootstrap catalog loader, but we never checked for it in retail catalog manipulations. The folly of that has now been exposed, so let's add assertions checking it. Checking in CatalogTupleInsert[WithInfo] and CatalogTupleUpdate[WithInfo] should be enough to cover this. Back-patch to v10; the aforesaid functions didn't exist before that, and it didn't seem worth adapting the patch to the oldest branches. But given the risk of JIT crashes, I think we certainly need this as far back as v11. Pre-v13, we have to explicitly exclude pg_subscription.subslotname and pg_subscription_rel.srsublsn from the checks, since they are mismarked. (Even if we change our mind about applying BKI_FORCE_NULL in the branch tips, it doesn't seem wise to have assertions that would fire in existing databases.) Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f451029db85acc9dd9856715e5490ade59fda229 Modified Files -- doc/src/sgml/bki.sgml | 5 +--- src/backend/catalog/indexing.c | 57 ++ 2 files changed, 58 insertions(+), 4 deletions(-)
pgsql: Assert that we don't insert nulls into attnotnull catalog column
Assert that we don't insert nulls into attnotnull catalog columns. The executor checks for this error, and so does the bootstrap catalog loader, but we never checked for it in retail catalog manipulations. The folly of that has now been exposed, so let's add assertions checking it. Checking in CatalogTupleInsert[WithInfo] and CatalogTupleUpdate[WithInfo] should be enough to cover this. Back-patch to v10; the aforesaid functions didn't exist before that, and it didn't seem worth adapting the patch to the oldest branches. But given the risk of JIT crashes, I think we certainly need this as far back as v11. Pre-v13, we have to explicitly exclude pg_subscription.subslotname and pg_subscription_rel.srsublsn from the checks, since they are mismarked. (Even if we change our mind about applying BKI_FORCE_NULL in the branch tips, it doesn't seem wise to have assertions that would fire in existing databases.) Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/43ef3c4c360a10226732b62ab3b2097cdf089dce Modified Files -- doc/src/sgml/bki.sgml | 5 +--- src/backend/catalog/indexing.c | 57 ++ 2 files changed, 58 insertions(+), 4 deletions(-)
pgsql: Be more careful about marking catalog columns NOT NULL by defaul
Be more careful about marking catalog columns NOT NULL by default. The bug fixed in commit 72eab84a5 would not have occurred if initdb had a less surprising rule about which columns should be marked NOT NULL by default. Let's make that rule be strictly that the column must be fixed-width and its predecessors must be fixed-width and NOT NULL, removing the hacky and unsafe exceptions for oidvector and int2vector. Since we do still want all existing oidvector and int2vector columns to be marked NOT NULL, we have to put BKI_FORCE_NOT_NULL labels on them. But making this less magic and more documented seems like a good idea, even if it's a shade more verbose. I didn't bump catversion since the initial catalog contents are not actually changed by this patch. Note however that the contents of postgres.bki do change, and feeding an old copy of that to a new backend will produce wrong results. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fc032bed2fb809ee69eaf2fece349f65274c876f Modified Files -- doc/src/sgml/bki.sgml | 3 ++- src/backend/bootstrap/bootstrap.c | 17 +-- src/backend/catalog/genbki.pl | 33 -- src/include/catalog/genbki.h | 4 ++-- src/include/catalog/pg_index.h | 10 + src/include/catalog/pg_partitioned_table.h | 14 - src/include/catalog/pg_proc.h | 2 +- src/include/catalog/pg_statistic_ext.h | 2 +- src/include/catalog/pg_trigger.h | 3 ++- 9 files changed, 46 insertions(+), 42 deletions(-)
pgsql: Minor glossary tweaks
Minor glossary tweaks Add "(process)" qualifier to two terms, remove self-reference in one term. Author: Jürgen Purtz Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ac25e7b039d5eacb8eb8fcc856a7ba4f14136b50 Modified Files -- doc/src/sgml/glossary.sgml | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-)
pgsql: Minor glossary tweaks
Minor glossary tweaks Add "(process)" qualifier to two terms, remove self-reference in one term. Author: Jürgen Purtz Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a0b2d583db9f040e2c156570b741e46bc33c6aec Modified Files -- doc/src/sgml/glossary.sgml | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-)
pgsql: Glossary: Add term "base backup"
Glossary: Add term "base backup" Author: Jürgen Purtz Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/606c3845988ddd9497cbbbf6fc559b91c76ed65d Modified Files -- doc/src/sgml/glossary.sgml | 13 + 1 file changed, 13 insertions(+)
pgsql: Avoid C99-ism in pre-v12 branches.
Avoid C99-ism in pre-v12 branches. Per buildfarm (I need to figure out why my own compiler did not whine about this). Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/22b96f883fe2a454476b4d5fd69ee46b15889169 Modified Files -- src/backend/catalog/indexing.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Avoid C99-ism in pre-v12 branches.
Avoid C99-ism in pre-v12 branches. Per buildfarm (I need to figure out why my own compiler did not whine about this). Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a00dbfaeed4017bca695a3e77d0f6264ba94a4c1 Modified Files -- src/backend/catalog/indexing.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Weaken type-OID-matching checks in array_recv and record_recv.
Weaken type-OID-matching checks in array_recv and record_recv. Rather than always insisting on an exact match of the type OID in the data to the element type or column type we expect, complain only when both OIDs fall within the manually-assigned range. This acknowledges the reality that user-defined types don't have stable OIDs, while still preserving some of the mistake-detection value of the old test. (It's not entirely clear whether to error if one OID is manually assigned and the other isn't. But perhaps that case could arise in cross-version cases where a former extension type has been imported into core, so I let it pass.) This change allows us to remove the prohibition on binary transfer of user-defined arrays and composites in the recently-landed support for binary logical replication (commit 9de77b545). We can just unconditionally drop that check, since if the client has asked for binary transfer it must be >= v14 and must have this change. Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=hbif5nfmj+d5dkoczp6...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/670c0a1d474bf296dbcc1d6de912d4841f2ed643 Modified Files -- src/backend/replication/logical/proto.c | 17 ++--- src/backend/utils/adt/arrayfuncs.c | 29 + src/backend/utils/adt/rowtypes.c| 28 3 files changed, 51 insertions(+), 23 deletions(-)
pgsql: Add nbtree Valgrind buffer lock checks.
Add nbtree Valgrind buffer lock checks. Holding just a buffer pin (with no buffer lock) on an nbtree buffer/page provides very weak guarantees, especially compared to heapam, where it's often safe to read a page while only holding a buffer pin. This commit has Valgrind enforce the following rule: it is never okay to access an nbtree buffer without holding both a pin and a lock on the buffer. A draft version of this patch detected questionable code that was cleaned up by commits fa7ff642 and 7154aa16. The code in question used to access an nbtree buffer page's special/opaque area with no buffer lock (only a buffer pin). This practice (which isn't obviously unsafe) is hereby formally disallowed in nbtree. There doesn't seem to be any reason to allow it, and banning it keeps things simple for Valgrind. The new checks are implemented by adding custom nbtree client requests (located in LockBuffer() wrapper functions); these requests are "superimposed" on top of the generic bufmgr.c Valgrind client requests added by commit 1e0dfd16. No custom resource management cleanup code is needed to undo the effects of marking buffers as non-accessible under this scheme. Author: Peter Geoghegan Reviewed-By: Anastasia Lubennikova, Georgios Kokolatos Discussion: https://postgr.es/m/CAH2-WzkLgyN3zBvRZ1pkNJThC=xi_0gpwrub_45eexlh1+k...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4a70f829d86cb8dbd68f561720e6329f5e818c94 Modified Files -- src/backend/access/nbtree/nbtinsert.c | 2 +- src/backend/access/nbtree/nbtpage.c | 145 +- src/backend/access/nbtree/nbtree.c| 5 +- src/backend/access/nbtree/nbtsearch.c | 23 +++--- src/backend/access/nbtree/nbtutils.c | 4 +- src/backend/storage/buffer/bufmgr.c | 23 +- src/include/access/nbtree.h | 4 + src/include/pg_config_manual.h| 8 +- 8 files changed, 170 insertions(+), 44 deletions(-)
pgsql: neqjoinsel must now pass through collation to eqjoinsel.
neqjoinsel must now pass through collation to eqjoinsel. Since commit 044c99bc5, eqjoinsel passes the passed-in collation to any operators it invokes. However, neqjoinsel failed to pass on whatever collation it got, so that if we invoked a collation-dependent operator via that code path, we'd get "could not determine which collation to use for string comparison" or the like. Per report from Justin Pryzby. Back-patch to v12, like the previous commit. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/171633ff5d8e21ceda5d824f3c9f13aa18a78505 Modified Files -- src/backend/utils/adt/selfuncs.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-)
pgsql: neqjoinsel must now pass through collation to eqjoinsel.
neqjoinsel must now pass through collation to eqjoinsel. Since commit 044c99bc5, eqjoinsel passes the passed-in collation to any operators it invokes. However, neqjoinsel failed to pass on whatever collation it got, so that if we invoked a collation-dependent operator via that code path, we'd get "could not determine which collation to use for string comparison" or the like. Per report from Justin Pryzby. Back-patch to v12, like the previous commit. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bd0d893aa7aa303d7f344e267a9d3e53b0219491 Modified Files -- src/backend/utils/adt/selfuncs.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-)
pgsql: neqjoinsel must now pass through collation to eqjoinsel.
neqjoinsel must now pass through collation to eqjoinsel. Since commit 044c99bc5, eqjoinsel passes the passed-in collation to any operators it invokes. However, neqjoinsel failed to pass on whatever collation it got, so that if we invoked a collation-dependent operator via that code path, we'd get "could not determine which collation to use for string comparison" or the like. Per report from Justin Pryzby. Back-patch to v12, like the previous commit. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cc4dd2a7af13b4759cd76074a932c8cf24e32bb2 Modified Files -- src/backend/utils/adt/selfuncs.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-)
pgsql: Fix comment in sha2.h
Fix comment in sha2.h An incorrect reference to SHA-1 was present. Author: Daniel Gustafsson Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e47c2602aa4d35a4e3eb6ada40454c6c0f1279bf Modified Files -- src/include/common/sha2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix conversion table generator scripts.
Fix conversion table generator scripts. convutils.pm used implicit conversion of undefined value to integer zero. Some of conversion scripts are susceptible to regexp greediness. Fix, avoiding whitespace changes in the output. Also update ICU URLs that moved. No need to back-patch, because the output of these scripts is also in the source tree so we shouldn't need to rerun them on back-branches. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/CA%2BhUKGJ7SEGLbj%3D%3DTQCcyKRA9aqj8%2B6L%3DexSq1y25TA%3DWxLziQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a5073871ea655e37759f22f30c4c70359ad9759b Modified Files -- src/backend/utils/mb/Unicode/Makefile | 2 +- .../utils/mb/Unicode/UCS_to_EUC_JIS_2004.pl| 7 +-- src/backend/utils/mb/Unicode/UCS_to_EUC_JP.pl | 3 +- .../utils/mb/Unicode/UCS_to_SHIFT_JIS_2004.pl | 7 +-- src/backend/utils/mb/Unicode/convutils.pm | 62 -- 5 files changed, 44 insertions(+), 37 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9e108984fb35d8f9e2c2bffa10c0034f9161e802 Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eceb415c6ff0eb2494f90397433a966a182f3908 Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dbf17ca1bfab1aec5783a1768d784875fb73a603 Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5bfd0936b46082e7c3265d83313d12e3608f8093 Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/35e142202b14fa12f8edbd7e58b33c39d3c03c62 Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e0cb8282d61411300c593e18237e50f3d26a825e Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
pgsql: Fix corner case with PGP decompression in pgcrypto
Fix corner case with PGP decompression in pgcrypto A compressed stream may end with an empty packet, and PGP decompression finished before reading this empty packet in the remaining stream. This caused a failure in pgcrypto, handling this case as corrupted data. This commit makes sure to consume such extra data, avoiding a failure when decompression the entire stream. This corner case was reproducible with a data length of 16kB, and existed since its introduction in e94dd6a. A cheap regression test is added to cover this case. Thanks to Jeff Janes for the extra investigation. Reported-by: Frank Gagnepain Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bba2e66aec4c8af4ad8b3be0d7cde1a97c974a00 Modified Files -- contrib/pgcrypto/expected/pgp-compression.out | 30 +++ contrib/pgcrypto/pgp-compress.c | 22 ++-- contrib/pgcrypto/sql/pgp-compression.sql | 21 +++ 3 files changed, 62 insertions(+), 11 deletions(-)
