pgsql: Add static assertion that RELSEG_SIZE fits in an int.
Add static assertion that RELSEG_SIZE fits in an int. Our configure script intended to ensure this, but it supposed that expr(1) would report an error for integer overflow. Maybe that was true when the code was written (commit 3c6248a82 of 2008-05-02), but all the modern expr's I tried will deliver bigger-than-int32 results without complaint. Moreover, if you use --with-segsize-blocks then there's no check at all. Ideally we'd add a test in configure itself to check that the value fits in int, but to do that we'd need to suppose that test(1) handles bigger-than-int32 numbers correctly. Probably modern ones do, but that's an assumption I could do without; and I'm not too trusting about meson either. Instead, let's install a static assertion, so that even people who ignore all the compiler warnings you get from such values will be forced to confront the fact that it won't work. This has been hazardous for awhile, but given that we hadn't heard a complaint about it till now, I don't feel a need to back-patch. Reported-by: Casey Shobe Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/92cf557ffae436235cfa3bbba1265b5807a68ef2 Modified Files -- src/backend/storage/smgr/md.c | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/40dc710a61aa5112b98cdd3d4caca51bd148ffb0 Modified Files -- src/bin/pg_dump/pg_backup_archiver.h | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c865f5b9f090bc1325f5667b11f883a46f5d96dd Modified Files -- src/bin/pg_dump/compress_gzip.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33276cd0272efd72e098840a5f3d3c6b795214c1 Modified Files -- src/bin/pg_dump/pg_backup_archiver.h | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8b9924bce7290cd21e816c13f964fe3ba362f526 Modified Files -- src/bin/pg_dump/pg_backup_archiver.h | 10 ++ 1 file changed, 10 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa1fcd087e5f709505aa0b9e15c1f3a0ce8b826c Modified Files -- src/bin/pg_dump/compress_gzip.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2efca163399ba1be4c2991635960ed509f6e7cfd Modified Files -- src/bin/pg_dump/compress_gzip.c | 9 + 1 file changed, 9 insertions(+)
pgsql: Don't rely on zlib's gzgetc() macro.
Don't rely on zlib's gzgetc() macro. It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec99589. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/277dec6514728e2d0d87c1279dd5e0afbf897428 Modified Files -- src/bin/pg_dump/compress_gzip.c | 9 + 1 file changed, 9 insertions(+)
pgsql: pg_checksums: Use new routine to retrieve data of PG_VERSION
pg_checksums: Use new routine to retrieve data of PG_VERSION Previously, attempting to use pg_checksums on a cluster with a control file whose version does not match with what thetool is able to support would lead to the following error: pg_checksums: error: pg_control CRC value is incorrect This is confusing, because it would look like the control file is corrupted. However, the contents of the control file are correct, pg_checksums not being able to understand how the past control file is shaped. This commit adds a check based on PG_VERSION, using the facility added by cd0be131ba6f, using the same error message as some of the other frontend tools. A note is added in the documentation about the major version requirement. Author: Michael Banck Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a7c30422004ae757909ed831fd8eea453022f969 Modified Files -- doc/src/sgml/ref/pg_checksums.sgml | 4 src/bin/pg_checksums/pg_checksums.c | 17 + 2 files changed, 21 insertions(+)
pgsql: pg_dump: Remove unnecessary code for security labels on extensio
pg_dump: Remove unnecessary code for security labels on extensions. Commit d9572c4e3b4 added extension support and made pg_dump attempt to dump security labels on extensions. However, security labels on extensions are not actually supported, so this code was unnecessary. This commit removes it. Suggested-by: Jian He Author: Fujii Masao Reviewed-by: Jian He Discussion: https://postgr.es/m/CACJufxF8=z0v=888nkkeothq+jc4exutfi91bf0ffjgfszt...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/762faf702c6f7292bd02705553078700d92c15f1 Modified Files -- src/bin/pg_dump/pg_dump.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-)
