{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":927442,"defaultBranch":"master","name":"postgres","ownerLogin":"postgres","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2010-09-21T11:35:45.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/177543?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1699399352.0","currentOid":""},"activityList":{"items":[{"before":"70cadfba0c70b25922d0739a9e09d24f0efd7f46","after":"1ee22d1e87b3c442928abe9535d6b2bf8460fc67","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-04-30T19:23:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Disallow converting a table to a view within an outer SQL command.\n\nWe have long disallowed all forms of ALTER TABLE if the table is\nalready opened by some outer SQL command in the same session.\nThis has the same purpose as obtaining AccessExclusiveLock, but\nsince a session's own locks don't conflict the lock only blocks use\nof the table by other sessions, not our own.  Without this check,\nthe ALTER might confuse the outer SQL command since any previous\ninspection of the table would potentially become invalid.\n\nHowever, the RelisBecomingView code path in DefineQueryRewrite never\ngot that memo, and assumed that AccessExclusiveLock is sufficient\nfor performing something morally equivalent to a rather invasive\nALTER TABLE.  Unsurprisingly, this can confuse an outer command\nthat is trying to do something with the table.\n\nThis was submitted as a security issue, but the security team\nhas been unable to identify any consequence worse than a null\npointer dereference (from trying to access rd_tableam methods\nthat the relation no longer has).  Therefore, in accordance\nwith our usual policy, it's not security material and should\njust be fixed as a routine bug.\n\nFix by disallowing the operation if the table is open locally,\nexactly as ALTER TABLE does it.\n\nPer an anonymous security researcher, via Bundesamt für Sicherheit\nin der Informationstechnik.\n\nPatch v12-v15 only.  In v16 and later, we removed this code\naltogether (cf. commit b23cd185f), so that there's no issue.","shortMessageHtmlLink":"Disallow converting a table to a view within an outer SQL command."}},{"before":"2ca19aa8165c6bec84c1d527fc5f3100c2161b1a","after":"51189f98a9fc88a63ae6a9635da8adb427f9958c","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-04-30T19:23:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Disallow converting a table to a view within an outer SQL command.\n\nWe have long disallowed all forms of ALTER TABLE if the table is\nalready opened by some outer SQL command in the same session.\nThis has the same purpose as obtaining AccessExclusiveLock, but\nsince a session's own locks don't conflict the lock only blocks use\nof the table by other sessions, not our own.  Without this check,\nthe ALTER might confuse the outer SQL command since any previous\ninspection of the table would potentially become invalid.\n\nHowever, the RelisBecomingView code path in DefineQueryRewrite never\ngot that memo, and assumed that AccessExclusiveLock is sufficient\nfor performing something morally equivalent to a rather invasive\nALTER TABLE.  Unsurprisingly, this can confuse an outer command\nthat is trying to do something with the table.\n\nThis was submitted as a security issue, but the security team\nhas been unable to identify any consequence worse than a null\npointer dereference (from trying to access rd_tableam methods\nthat the relation no longer has).  Therefore, in accordance\nwith our usual policy, it's not security material and should\njust be fixed as a routine bug.\n\nFix by disallowing the operation if the table is open locally,\nexactly as ALTER TABLE does it.\n\nPer an anonymous security researcher, via Bundesamt für Sicherheit\nin der Informationstechnik.\n\nPatch v12-v15 only.  In v16 and later, we removed this code\naltogether (cf. commit b23cd185f), so that there's no issue.","shortMessageHtmlLink":"Disallow converting a table to a view within an outer SQL command."}},{"before":"f222349c4ec061705e121548d2fe646b4d03ccdf","after":"56d30fb10d5ce5e2d8b432eeaca8ecf2fc2a6900","ref":"refs/heads/REL_12_STABLE","pushedAt":"2024-04-30T19:23:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Disallow converting a table to a view within an outer SQL command.\n\nWe have long disallowed all forms of ALTER TABLE if the table is\nalready opened by some outer SQL command in the same session.\nThis has the same purpose as obtaining AccessExclusiveLock, but\nsince a session's own locks don't conflict the lock only blocks use\nof the table by other sessions, not our own.  Without this check,\nthe ALTER might confuse the outer SQL command since any previous\ninspection of the table would potentially become invalid.\n\nHowever, the RelisBecomingView code path in DefineQueryRewrite never\ngot that memo, and assumed that AccessExclusiveLock is sufficient\nfor performing something morally equivalent to a rather invasive\nALTER TABLE.  Unsurprisingly, this can confuse an outer command\nthat is trying to do something with the table.\n\nThis was submitted as a security issue, but the security team\nhas been unable to identify any consequence worse than a null\npointer dereference (from trying to access rd_tableam methods\nthat the relation no longer has).  Therefore, in accordance\nwith our usual policy, it's not security material and should\njust be fixed as a routine bug.\n\nFix by disallowing the operation if the table is open locally,\nexactly as ALTER TABLE does it.\n\nPer an anonymous security researcher, via Bundesamt für Sicherheit\nin der Informationstechnik.\n\nPatch v12-v15 only.  In v16 and later, we removed this code\naltogether (cf. commit b23cd185f), so that there's no issue.","shortMessageHtmlLink":"Disallow converting a table to a view within an outer SQL command."}},{"before":"7c5915c4b16c965124a36615ec54cca501a212a9","after":"bf379b555c06034bcd1be384cc145d8264213f41","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-04-30T19:23:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Disallow converting a table to a view within an outer SQL command.\n\nWe have long disallowed all forms of ALTER TABLE if the table is\nalready opened by some outer SQL command in the same session.\nThis has the same purpose as obtaining AccessExclusiveLock, but\nsince a session's own locks don't conflict the lock only blocks use\nof the table by other sessions, not our own.  Without this check,\nthe ALTER might confuse the outer SQL command since any previous\ninspection of the table would potentially become invalid.\n\nHowever, the RelisBecomingView code path in DefineQueryRewrite never\ngot that memo, and assumed that AccessExclusiveLock is sufficient\nfor performing something morally equivalent to a rather invasive\nALTER TABLE.  Unsurprisingly, this can confuse an outer command\nthat is trying to do something with the table.\n\nThis was submitted as a security issue, but the security team\nhas been unable to identify any consequence worse than a null\npointer dereference (from trying to access rd_tableam methods\nthat the relation no longer has).  Therefore, in accordance\nwith our usual policy, it's not security material and should\njust be fixed as a routine bug.\n\nFix by disallowing the operation if the table is open locally,\nexactly as ALTER TABLE does it.\n\nPer an anonymous security researcher, via Bundesamt für Sicherheit\nin der Informationstechnik.\n\nPatch v12-v15 only.  In v16 and later, we removed this code\naltogether (cf. commit b23cd185f), so that there's no issue.","shortMessageHtmlLink":"Disallow converting a table to a view within an outer SQL command."}},{"before":"f6ab942f5de003f37b88580154ebb614655d7e11","after":"d12b4ba1bd3eedd862064cf1dad5ff107c5cba90","ref":"refs/heads/master","pushedAt":"2024-04-30T14:45:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Fix one more portability shortcoming in new test_pg_dump test.\n\nIf the bootstrap superuser's name requires quoting, regroleout\nwill supply double quotes ... but the result of CURRENT_USER\nis just the literal name.  Apply quote_ident() to ensure a match.\n\nPer Andrew Dunstan's off-list investigation of buildfarm member\nprion's failures.","shortMessageHtmlLink":"Fix one more portability shortcoming in new test_pg_dump test."}},{"before":"449cdcd486bfc6864e4fa6784cc1526a94fe69db","after":"f6ab942f5de003f37b88580154ebb614655d7e11","ref":"refs/heads/master","pushedAt":"2024-04-30T10:24:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"doc: Remove one example related to pg_input_error_info()\n\nThis slightly bloated the contents of the function table for this entry,\nwithout really bringing extra value.\n\nPer discussion with Jian He and David G. Johnston.\n\nDiscussion: https://postgr.es/m/CACJufxGdyoBJQMSxwdxNK=k8M5WUth5FDFd4Wq_K4f7+1J2xuQ@mail.gmail.com","shortMessageHtmlLink":"doc: Remove one example related to pg_input_error_info()"}},{"before":"259c96fa8f78c0446eba1880850ea6fbe5092120","after":"449cdcd486bfc6864e4fa6784cc1526a94fe69db","ref":"refs/heads/master","pushedAt":"2024-04-30T09:14:27.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Stabilize regression tests introduced by 259c96fa8f\n\nAdd the ORDER BY clause to new queries to avoid ordering ambiguity.\n\nPer buildfarm member rorqual.","shortMessageHtmlLink":"Stabilize regression tests introduced by <a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/259c96fa8f78c0446eba1880850ea6fbe5092120/hovercard\" href=\"https://github.com/postgres/postgres/commit/259c96fa8f78c0446eba1880850ea6fbe5092120\"><tt>259c96f</tt></a>"}},{"before":"5bcbe9813bf91bcf14ef3a580162f1600dd3d1d4","after":"259c96fa8f78c0446eba1880850ea6fbe5092120","ref":"refs/heads/master","pushedAt":"2024-04-30T09:01:05.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Inherit parent's AM for partition MERGE/SPLIT operations\n\nThis commit makes new partitions created by ALTER TABLE ... SPLIT PARTITION\nand ALTER TABLE ... MERGE PARTITIONS commands inherit the paret table access\nmethod.\n\nReported-by: Alexander Lakhin\nDiscussion: https://postgr.es/m/84ada05b-be5c-473e-6d1c-ebe5dd21b190%40gmail.com\nReviewed-by: Pavel Borisov","shortMessageHtmlLink":"Inherit parent's AM for partition MERGE/SPLIT operations"}},{"before":"b7dc5da1969cb0756739feb393eea51a8265ca04","after":"5bcbe9813bf91bcf14ef3a580162f1600dd3d1d4","ref":"refs/heads/master","pushedAt":"2024-04-30T05:26:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Fix compilation on OpenSSL 1.0.2 and LibreSSL\n\nSSL_AD_NO_APPLICATION_PROTOCOL was introduced in OpenSSL 1.1.0.\n\nWhile we're at it, add a link to the related OpenSSL github issue to\nthe comment.\n\nPer buildfarm and Tom Lane.\n\nDiscussion: https://www.postgresql.org/message-id/1452995.1714433552@sss.pgh.pa.us","shortMessageHtmlLink":"Fix compilation on OpenSSL 1.0.2 and LibreSSL"}},{"before":"900d1144256a63250a2e326567b636ee3220b731","after":"b7dc5da1969cb0756739feb393eea51a8265ca04","ref":"refs/heads/master","pushedAt":"2024-04-30T03:32:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Force COLLATE \"C\" to stabilize ordering, redux.\n\nDavid Rowley correctly pointed out that I'd collat-ified only\none of the two troublesome queries.  Definitely not my day.\n\nDiscussion: https://postgr.es/m/CAApHDvo8pMk5WWFAqwGzuQ-Xh+957W61io_OsCP0oUzqCCODTg@mail.gmail.com","shortMessageHtmlLink":"Force COLLATE \"C\" to stabilize ordering, redux."}},{"before":"9d9ece4c16dbbaf3b9d60c2fe201b8e99a407be3","after":"900d1144256a63250a2e326567b636ee3220b731","ref":"refs/heads/master","pushedAt":"2024-04-30T01:36:24.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Force COLLATE \"C\" to stabilize ordering in new test_pg_dump queries.\n\nShould have thought of the need for this.\n\n(Local testing suggests that we may still not be out of the\nwoods, but certainly this much is needed.)\n\nPer buildfarm and David Rowley.\n\nDiscussion: https://postgr.es/m/CAApHDvo8pMk5WWFAqwGzuQ-Xh+957W61io_OsCP0oUzqCCODTg@mail.gmail.com","shortMessageHtmlLink":"Force COLLATE \"C\" to stabilize ordering in new test_pg_dump queries."}},{"before":"b0c5b215dace219ecf3b42cc2eb90abf7fd7a582","after":"9d9ece4c16dbbaf3b9d60c2fe201b8e99a407be3","ref":"refs/heads/master","pushedAt":"2024-04-30T00:23:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Fix test case from b0c5b215d.\n\nI'd not checked that this iteration of the test actually worked\nwith a bootstrap superuser not named 'postgres'.  It didn't,\nbecause the coercion rules for CASE caused us to try to cast\nthe 'postgres' literal to regrole.  Mea culpa.\n\nPer buildfarm (via Alexander Korotkov)\n\nDiscussion: https://postgr.es/m/CAPpHfdsV=iTvH6B858hnH1bLgewYH6cdTnO_eOOw9EOa8kehkA@mail.gmail.com","shortMessageHtmlLink":"Fix test case from <a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/b0c5b215dace219ecf3b42cc2eb90abf7fd7a582/hovercard\" href=\"https://github.com/postgres/postgres/commit/b0c5b215dace219ecf3b42cc2eb90abf7fd7a582\"><tt>b0c5b21</tt></a>."}},{"before":"534287403914cc9760db98f7320ac4e92f5d416e","after":"b0c5b215dace219ecf3b42cc2eb90abf7fd7a582","ref":"refs/heads/master","pushedAt":"2024-04-29T23:46:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Allow meson builds to run test_pg_dump test in installcheck mode.\n\nThis had been disabled because the test \"doesn't delete its user\".\nIt doesn't seem like a great idea for the meson tests to act\ndifferently from the makefile tests, though, and the makefiles\nhad no such exception (which is how come only copperhead noticed\nthe problem just fixed in 534287403).  In any case, the premise\nis false since 936e3fa37, so let's remove the restriction.\n\nDiscussion: https://postgr.es/m/2857513.1713733688@sss.pgh.pa.us","shortMessageHtmlLink":"Allow meson builds to run test_pg_dump test in installcheck mode."}},{"before":"dd0183469bb779247c96e86c2272dca7ff4ec9e7","after":"534287403914cc9760db98f7320ac4e92f5d416e","ref":"refs/heads/master","pushedAt":"2024-04-29T23:26:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Fix failure to track role dependencies of pg_init_privs entries.\n\nIf an ACL recorded in pg_init_privs mentions a non-pinned role,\nthat reference must also be noted in pg_shdepend so that we know\nthat the role can't go away without removing the ACL reference.\nOtherwise, DROP ROLE could succeed and leave dangling entries\nbehind, which is what's causing the recent upgrade-check failures\non buildfarm member copperhead.\n\nThis has been wrong since pg_init_privs was introduced, but it's\nescaped notice because typical pg_init_privs entries would only\nmention the bootstrap superuser (pinned) or at worst the owner\nof the extension (who can't go away before the extension does).\n\nWe lack even a representation of such a role reference for\npg_shdepend.  My first thought for a solution was entries listing\npg_init_privs in classid, but that doesn't work because then there's\nnoplace to put the granted-on object's classid.  Rather than adding\na new column to pg_shdepend, let's add a new deptype code\nSHARED_DEPENDENCY_INITACL.  Much of the associated boilerplate\ncode can be cribbed from code for SHARED_DEPENDENCY_ACL.\n\nA lot of the bulk of this patch just stems from the new need to pass\nthe object's owner ID to recordExtensionInitPriv, so that we can\nconsult it while updating pg_shdepend.  While many callers have that\nat hand already, a few places now need to fetch the owner ID of an\narbitrary privilege-bearing object.  For that, we assume that there\nis a catcache on the relevant catalog's OID column, which is an\nassumption already made in ExecGrant_common so it seems okay here.\n\nWe do need an entirely new routine RemoveRoleFromInitPriv to perform\ncleanup of pg_init_privs ACLs during DROP OWNED BY.  It's analogous\nto RemoveRoleFromObjectACL, but we can't share logic because that\nfunction operates by building a command parsetree and invoking\nexisting GRANT/REVOKE infrastructure.  There is of course no SQL\ncommand that would update pg_init_privs entries when we're not in\nprocess of creating their extension, so we need a routine that can\ndo the updates directly.\n\ncatversion bump because this changes the expected contents of\npg_shdepend.  For the same reason, there's no hope of back-patching\nthis, even though it fixes a longstanding bug.  Fortunately, the\ncase where it's a problem seems to be near nonexistent in the field.\nIf it weren't for the buildfarm breakage, I'd have been content to\nleave this for v18.\n\nPatch by me; thanks to Daniel Gustafsson for review and discussion.\n\nDiscussion: https://postgr.es/m/1745535.1712358659@sss.pgh.pa.us","shortMessageHtmlLink":"Fix failure to track role dependencies of pg_init_privs entries."}},{"before":"617a23927249c78f23ef005aaa78b508570f4cc8","after":"2ca19aa8165c6bec84c1d527fc5f3100c2161b1a","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-04-29T17:30:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Close race condition between datfrozen and relfrozen updates.\n\nvac_update_datfrozenxid() did multiple loads of relfrozenxid and\nrelminmxid from buffer memory, and it assumed each would get the same\nvalue.  Not so if a concurrent vac_update_relstats() did an inplace\nupdate.  Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same\nkind of bug in vac_truncate_clog().  Today's bug could cause the\nrel-level field and XIDs in the rel's rows to precede the db-level\nfield.  A cluster having such values should VACUUM affected tables.\nBack-patch to v12 (all supported versions).\n\nDiscussion: https://postgr.es/m/20240423003956.e7.nmisch@google.com","shortMessageHtmlLink":"Close race condition between datfrozen and relfrozen updates."}},{"before":"440b6251b75220bd28c063f50f5031f2004758f6","after":"70cadfba0c70b25922d0739a9e09d24f0efd7f46","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-04-29T17:30:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Close race condition between datfrozen and relfrozen updates.\n\nvac_update_datfrozenxid() did multiple loads of relfrozenxid and\nrelminmxid from buffer memory, and it assumed each would get the same\nvalue.  Not so if a concurrent vac_update_relstats() did an inplace\nupdate.  Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same\nkind of bug in vac_truncate_clog().  Today's bug could cause the\nrel-level field and XIDs in the rel's rows to precede the db-level\nfield.  A cluster having such values should VACUUM affected tables.\nBack-patch to v12 (all supported versions).\n\nDiscussion: https://postgr.es/m/20240423003956.e7.nmisch@google.com","shortMessageHtmlLink":"Close race condition between datfrozen and relfrozen updates."}},{"before":"9b41d1d634aa9a3a36a21c5624b25c8475fd51ee","after":"7c5915c4b16c965124a36615ec54cca501a212a9","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-04-29T17:30:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Close race condition between datfrozen and relfrozen updates.\n\nvac_update_datfrozenxid() did multiple loads of relfrozenxid and\nrelminmxid from buffer memory, and it assumed each would get the same\nvalue.  Not so if a concurrent vac_update_relstats() did an inplace\nupdate.  Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same\nkind of bug in vac_truncate_clog().  Today's bug could cause the\nrel-level field and XIDs in the rel's rows to precede the db-level\nfield.  A cluster having such values should VACUUM affected tables.\nBack-patch to v12 (all supported versions).\n\nDiscussion: https://postgr.es/m/20240423003956.e7.nmisch@google.com","shortMessageHtmlLink":"Close race condition between datfrozen and relfrozen updates."}},{"before":"b19255ca66f74fe9f8d0372db7d644d0bb4d6ac9","after":"92685c389d5416f87553bfb80205d79d5670a695","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-04-29T17:30:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Close race condition between datfrozen and relfrozen updates.\n\nvac_update_datfrozenxid() did multiple loads of relfrozenxid and\nrelminmxid from buffer memory, and it assumed each would get the same\nvalue.  Not so if a concurrent vac_update_relstats() did an inplace\nupdate.  Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same\nkind of bug in vac_truncate_clog().  Today's bug could cause the\nrel-level field and XIDs in the rel's rows to precede the db-level\nfield.  A cluster having such values should VACUUM affected tables.\nBack-patch to v12 (all supported versions).\n\nDiscussion: https://postgr.es/m/20240423003956.e7.nmisch@google.com","shortMessageHtmlLink":"Close race condition between datfrozen and relfrozen updates."}},{"before":"17a834a04d5a60aedd6899488a53d939d525fb16","after":"dd0183469bb779247c96e86c2272dca7ff4ec9e7","ref":"refs/heads/master","pushedAt":"2024-04-29T17:30:46.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Avoid repeating loads of frozen ID values.\n\nRepeating loads of inplace-updated fields tends to cause bugs like the\none from the previous commit.  While there's no bug to fix in these code\nsites, adopt the load-once style.  This improves the chance of future\ncopy/paste finding the safe style.\n\nDiscussion: https://postgr.es/m/20240423003956.e7.nmisch@google.com","shortMessageHtmlLink":"Avoid repeating loads of frozen ID values."}},{"before":"cb0ccefa03d351d9c643362ac77fca7dadd9fc42","after":"f222349c4ec061705e121548d2fe646b4d03ccdf","ref":"refs/heads/REL_12_STABLE","pushedAt":"2024-04-29T17:30:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Close race condition between datfrozen and relfrozen updates.\n\nvac_update_datfrozenxid() did multiple loads of relfrozenxid and\nrelminmxid from buffer memory, and it assumed each would get the same\nvalue.  Not so if a concurrent vac_update_relstats() did an inplace\nupdate.  Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same\nkind of bug in vac_truncate_clog().  Today's bug could cause the\nrel-level field and XIDs in the rel's rows to precede the db-level\nfield.  A cluster having such values should VACUUM affected tables.\nBack-patch to v12 (all supported versions).\n\nDiscussion: https://postgr.es/m/20240423003956.e7.nmisch@google.com","shortMessageHtmlLink":"Close race condition between datfrozen and relfrozen updates."}},{"before":"7e61e4cc7cfcf2a34f063094aeab01fdba7b65f6","after":"17a834a04d5a60aedd6899488a53d939d525fb16","ref":"refs/heads/master","pushedAt":"2024-04-29T15:14:31.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Reject SSL connection if ALPN is used but there's no common protocol\n\nIf the client supports ALPN but tries to use some other protocol, like\nHTTPS, reject the connection in the server. That is surely a confusion\nof some sort. Furthermore, the ALPN RFC 7301 says:\n\n> In the event that the server supports no protocols that the client\n> advertises, then the server SHALL respond with a fatal\n> \"no_application_protocol\" alert.\n\nThis commit makes the server follow that advice.\n\nIn the client, specifically check for the OpenSSL error code for the\n\"no_application_protocol\" alert. Otherwise you got a cryptic \"SSL\nerror: SSL error code 167773280\" error if you tried to connect to a\nnon-PostgreSQL server that rejects the connection with\n\"no_application_protocol\". ERR_reason_error_string() returns NULL for\nthat code, which frankly seems like an OpenSSL bug to me, but we can\neasily print a better message ourselves.\n\nReported-by: Jacob Champion\nDiscussion: https://www.postgresql.org/message-id/6aedcaa5-60f3-49af-a857-2c76ba55a1f3@iki.fi","shortMessageHtmlLink":"Reject SSL connection if ALPN is used but there's no common protocol"}},{"before":"3c184092651b0b15ca1207c154ab3fd055e1e9fe","after":"7e61e4cc7cfcf2a34f063094aeab01fdba7b65f6","ref":"refs/heads/master","pushedAt":"2024-04-29T12:12:06.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Make two-phase tests of ECPG and main suite more concurrent-proof\n\nThe ECPG and main 2PC tests have been using rather-generic names for the\nprepared transactions they generate.  This commit switches the 2PC\ntransactions to use more complex GIDs, reducing the risk of naming\nconflicts.\n\nThe main 2PC tests also include scans of pg_prepared_xacts that do not\napply filters on the GID of the prepared transactions, making it\npossible to fail the test when any 2PC transaction runs concurrently.\nThe CI has been able to see such failures with an installcheck\nrunning the ECPG and the main regression test suites in parallel.  The\nqueries on pg_prepared_xacts gain quals to only look after the GIDs\ngenerated locally.\n\nThe race is very hard to reproduce, so no backbatch is done for now.\n\nReported-by: Richard Guo\nDiscussion: https://postgr.es/m/CAMbWs4-mWCGbbE_bne5=AfqjYGDaUZmjCw2+soLjrdNA0xUDFw@mail.gmail.com","shortMessageHtmlLink":"Make two-phase tests of ECPG and main suite more concurrent-proof"}},{"before":"592a2283721f7143999364ef487f2b4993f5161d","after":"3c184092651b0b15ca1207c154ab3fd055e1e9fe","ref":"refs/heads/master","pushedAt":"2024-04-29T09:27:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"libpq: If ALPN is not used, make PQsslAttribute(conn, \"alpn\") == \"\"\n\nThe documentation says that PQsslAttribute(conn, \"alpn\") returns an\nempty string if ALPN is not used, but the code actually returned\nNULL. Fix the code to match the documentation.\n\nReported-by: Michael Paquier\nDiscussion: https://www.postgresql.org/message-id/ZideNHji0G4gxmc3@paquier.xyz","shortMessageHtmlLink":"libpq: If ALPN is not used, make PQsslAttribute(conn, \"alpn\") == \"\""}},{"before":"5c9f35fc48ea99e59300a267e090e3eafd1b3b0e","after":"592a2283721f7143999364ef487f2b4993f5161d","ref":"refs/heads/master","pushedAt":"2024-04-29T09:11:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Revert \"Add GUC backtrace_on_internal_error\"\n\nThis reverts commit a740b213d4b4d3360ad0cac696e47e5ec0eb8864.\n\nSubsequent discussion showed that there was interest in a more general\nfacility to configure when server log events would produce backtraces,\nand this existing limited way couldn't be extended in a compatible\nway.  So the consensus was to revert this for PostgreSQL 17 and\nreconsider this topic for PostgreSQL 18.\n\nDiscussion: https://www.postgresql.org/message-id/flat/CAGECzQTChkvn5Xj772LB3%3Dxo2x_LcaO5O0HQvXqobm1xVp6%2B4w%40mail.gmail.com#764bcdbb73e162787e1ad984935e51e3","shortMessageHtmlLink":"Revert \"Add GUC backtrace_on_internal_error\""}},{"before":"42b041243c00fb20023c983357e7f1ffd3710fff","after":"5c9f35fc48ea99e59300a267e090e3eafd1b3b0e","ref":"refs/heads/master","pushedAt":"2024-04-28T19:59:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Fix documentation and comments on what happens after GSS rejection\n\nThe paragraph in the docs and the comment applied to\nsslnegotiaton=direct, but not sslnegotiation=requiredirect. In\n'requiredirect' mode, negotiated SSL is never used. Move the paragraph\nin the docs under the description of 'direct' mode, and rephrase it.\n\nAlso the comment's reference to reusing a plaintext connection was\nbogus. Authentication failure in plaintext mode only happens after\nsending the startup packet, so the connection cannot be reused.\n\nReported-by: Jacob Champion\nDiscussion: https://www.postgresql.org/message-id/CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com","shortMessageHtmlLink":"Fix documentation and comments on what happens after GSS rejection"}},{"before":"4019285c064028fbf613f0e43766416a63b826db","after":"42b041243c00fb20023c983357e7f1ffd3710fff","ref":"refs/heads/master","pushedAt":"2024-04-28T18:34:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Throw a more on-point error for functions depending on columns.\n\nALTER COLUMN TYPE wasn't expecting to find any pg_proc objects\ndepending on the column whose type is to be altered.  That indeed\nwasn't possible when this code was written, but it is possible\nsince we introduced new-style SQL function bodies.\n\nIt's about as difficult to fix this case as it is to fix dependent\nviews, and we've been punting on those for years, so I don't feel\ntoo awful about punting for functions too.  (I sure wouldn't risk\nback-patching such code.)  So just throw a more user-facing error.\nAlso, adjust some of the existing comments to reflect that these\nare all pretty much the same issue.\n\n(This patch also fixes it so we will tolerate finding such a\ndependency during ALTER COLUMN SET EXPRESSION; in that, we need\nnot do anything to the function, so no error is wanted.  That\nproblem is new in HEAD.)\n\nPer bug #18449 from Alexander Lakhin.  Back-patch to v14 where\nwe added new-style SQL functions.\n\nDiscussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org","shortMessageHtmlLink":"Throw a more on-point error for functions depending on columns."}},{"before":"1748379b636152b6633498c6488fd98aa015bc99","after":"617a23927249c78f23ef005aaa78b508570f4cc8","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-04-28T18:34:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Throw a more on-point error for functions depending on columns.\n\nALTER COLUMN TYPE wasn't expecting to find any pg_proc objects\ndepending on the column whose type is to be altered.  That indeed\nwasn't possible when this code was written, but it is possible\nsince we introduced new-style SQL function bodies.\n\nIt's about as difficult to fix this case as it is to fix dependent\nviews, and we've been punting on those for years, so I don't feel\ntoo awful about punting for functions too.  (I sure wouldn't risk\nback-patching such code.)  So just throw a more user-facing error.\nAlso, adjust some of the existing comments to reflect that these\nare all pretty much the same issue.\n\n(This patch also fixes it so we will tolerate finding such a\ndependency during ALTER COLUMN SET EXPRESSION; in that, we need\nnot do anything to the function, so no error is wanted.  That\nproblem is new in HEAD.)\n\nPer bug #18449 from Alexander Lakhin.  Back-patch to v14 where\nwe added new-style SQL functions.\n\nDiscussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org","shortMessageHtmlLink":"Throw a more on-point error for functions depending on columns."}},{"before":"e6e3ee5b7e2346c19824b391bcd1fcc30baee2ec","after":"9b41d1d634aa9a3a36a21c5624b25c8475fd51ee","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-04-28T18:34:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Throw a more on-point error for functions depending on columns.\n\nALTER COLUMN TYPE wasn't expecting to find any pg_proc objects\ndepending on the column whose type is to be altered.  That indeed\nwasn't possible when this code was written, but it is possible\nsince we introduced new-style SQL function bodies.\n\nIt's about as difficult to fix this case as it is to fix dependent\nviews, and we've been punting on those for years, so I don't feel\ntoo awful about punting for functions too.  (I sure wouldn't risk\nback-patching such code.)  So just throw a more user-facing error.\nAlso, adjust some of the existing comments to reflect that these\nare all pretty much the same issue.\n\n(This patch also fixes it so we will tolerate finding such a\ndependency during ALTER COLUMN SET EXPRESSION; in that, we need\nnot do anything to the function, so no error is wanted.  That\nproblem is new in HEAD.)\n\nPer bug #18449 from Alexander Lakhin.  Back-patch to v14 where\nwe added new-style SQL functions.\n\nDiscussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org","shortMessageHtmlLink":"Throw a more on-point error for functions depending on columns."}},{"before":"3752e3d210287787a881ae3c68da019aa86f414e","after":"b19255ca66f74fe9f8d0372db7d644d0bb4d6ac9","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-04-28T18:34:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Throw a more on-point error for functions depending on columns.\n\nALTER COLUMN TYPE wasn't expecting to find any pg_proc objects\ndepending on the column whose type is to be altered.  That indeed\nwasn't possible when this code was written, but it is possible\nsince we introduced new-style SQL function bodies.\n\nIt's about as difficult to fix this case as it is to fix dependent\nviews, and we've been punting on those for years, so I don't feel\ntoo awful about punting for functions too.  (I sure wouldn't risk\nback-patching such code.)  So just throw a more user-facing error.\nAlso, adjust some of the existing comments to reflect that these\nare all pretty much the same issue.\n\n(This patch also fixes it so we will tolerate finding such a\ndependency during ALTER COLUMN SET EXPRESSION; in that, we need\nnot do anything to the function, so no error is wanted.  That\nproblem is new in HEAD.)\n\nPer bug #18449 from Alexander Lakhin.  Back-patch to v14 where\nwe added new-style SQL functions.\n\nDiscussion: https://postgr.es/m/18449-f8248467aaa294d5@postgresql.org","shortMessageHtmlLink":"Throw a more on-point error for functions depending on columns."}},{"before":"6189a0d3795e10b32753eb7ae3d155429b8fd4cd","after":"1748379b636152b6633498c6488fd98aa015bc99","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-04-28T17:42:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"postgres-mirror","name":"Postgres Mirrorbot","path":"/postgres-mirror","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/368201?s=80&v=4"},"commit":{"message":"Detect more overflows in timestamp[tz]_pl_interval.\n\nIn commit 25cd2d640 I (tgl) opined that \"The additions of the months\nand microseconds fields could also overflow, of course.  However,\nI believe we need no additional checks there; the existing range\nchecks should catch such cases\".  This is demonstrably wrong however\nfor the microseconds field, and given that discovery it seems prudent\nto be paranoid about the months addition as well.\n\nReport and patch by Joseph Koshakow.  As before, back-patch to all\nsupported branches.  (However, the test case doesn't work before\nv15 because we didn't allow wider-than-int32 numbers in interval\nliterals.  A variant test could probably be built that fits within\nthat restriction, but it didn't seem worth the trouble.)\n\nDiscussion: https://postgr.es/m/CAAvxfHf77sRHKoEzUw9_cMYSpbpNS2C+J_+8Dq4+0oi8iKopeA@mail.gmail.com","shortMessageHtmlLink":"Detect more overflows in timestamp[tz]_pl_interval."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEPlqowgA","startCursor":null,"endCursor":null}},"title":"Activity · postgres/postgres"}