{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":47821226,"defaultBranch":"master","name":"postgres","ownerLogin":"jesperpedersen","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2015-12-11T10:46:41.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/229465?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1688145906.0","currentOid":""},"activityList":{"items":[{"before":"84f08f2215754cd03feaa82bbdf10fc114458b26","after":"7c655a04a2dc84b59ed6dce97bd38b79e734ecca","ref":"refs/heads/master","pushedAt":"2024-06-11T03:36:45.000Z","pushType":"push","commitsCount":118,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix meson uuid header check so it works with MSVC\n\nThe OSSP uuid.h file includes unistd.h, so to use it with MSVC we need to\ninclude the postgres include directories so it picks up our version of\nthat in src/include/port/win32_msvc. Adjust the meson test accordingly.","shortMessageHtmlLink":"Fix meson uuid header check so it works with MSVC"}},{"before":"52ea653aa9d867be70b2d86fe8310dde48507b6a","after":"f1f6ded66897efbf2ee520a8213a43251398ddf2","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-06-10T08:54:14.000Z","pushType":"push","commitsCount":26,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Tighten test_predtest's input checks, and improve error messages.\n\ntest_predtest() neglected to consider the possibility that\nSPI_plan_get_cached_plan would return NULL.  This led to a core\ndump if the input (incorrectly) contains more than one SQL\ncommand.\n\nWhile here, let's expend more than zero effort on the error\nmessage for this case and nearby ones.\n\nPer (half of) bug #18483 from Alexander Kozhemyakin.\nBack-patch to all supported branches, not because this is\nvery significant (it's merely test scaffolding) but to make\nour world a bit safer for fuzz testing.\n\nDiscussion: https://postgr.es/m/18483-30bfff42de238000@postgresql.org","shortMessageHtmlLink":"Tighten test_predtest's input checks, and improve error messages."}},{"before":"6e29963edd55cfc038304322049d8fe697580f2c","after":"2eba27571edcce56ac04838792e79cb23fe179d4","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-06-10T08:52:21.000Z","pushType":"push","commitsCount":22,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Tighten test_predtest's input checks, and improve error messages.\n\ntest_predtest() neglected to consider the possibility that\nSPI_plan_get_cached_plan would return NULL.  This led to a core\ndump if the input (incorrectly) contains more than one SQL\ncommand.\n\nWhile here, let's expend more than zero effort on the error\nmessage for this case and nearby ones.\n\nPer (half of) bug #18483 from Alexander Kozhemyakin.\nBack-patch to all supported branches, not because this is\nvery significant (it's merely test scaffolding) but to make\nour world a bit safer for fuzz testing.\n\nDiscussion: https://postgr.es/m/18483-30bfff42de238000@postgresql.org","shortMessageHtmlLink":"Tighten test_predtest's input checks, and improve error messages."}},{"before":"d39337021e12d569e3241a605120f010f77b9e22","after":"5f200ab5749a0813c48b45b217b273abeb2fdc52","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-06-10T08:51:36.000Z","pushType":"push","commitsCount":18,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Tighten test_predtest's input checks, and improve error messages.\n\ntest_predtest() neglected to consider the possibility that\nSPI_plan_get_cached_plan would return NULL.  This led to a core\ndump if the input (incorrectly) contains more than one SQL\ncommand.\n\nWhile here, let's expend more than zero effort on the error\nmessage for this case and nearby ones.\n\nPer (half of) bug #18483 from Alexander Kozhemyakin.\nBack-patch to all supported branches, not because this is\nvery significant (it's merely test scaffolding) but to make\nour world a bit safer for fuzz testing.\n\nDiscussion: https://postgr.es/m/18483-30bfff42de238000@postgresql.org","shortMessageHtmlLink":"Tighten test_predtest's input checks, and improve error messages."}},{"before":"2728677923d2a025575dee4a24580e3e899c5615","after":"d8062ead3d8382febf15194383199ac9ace94038","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-06-10T08:49:01.000Z","pushType":"push","commitsCount":17,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Tighten test_predtest's input checks, and improve error messages.\n\ntest_predtest() neglected to consider the possibility that\nSPI_plan_get_cached_plan would return NULL.  This led to a core\ndump if the input (incorrectly) contains more than one SQL\ncommand.\n\nWhile here, let's expend more than zero effort on the error\nmessage for this case and nearby ones.\n\nPer (half of) bug #18483 from Alexander Kozhemyakin.\nBack-patch to all supported branches, not because this is\nvery significant (it's merely test scaffolding) but to make\nour world a bit safer for fuzz testing.\n\nDiscussion: https://postgr.es/m/18483-30bfff42de238000@postgresql.org","shortMessageHtmlLink":"Tighten test_predtest's input checks, and improve error messages."}},{"before":"82c87af7a0ac97ec6e99277f2deb4ee55e347e1e","after":"157b1e6b41b4a1f4bdb3166c791bb3a103abd8c4","ref":"refs/heads/REL_12_STABLE","pushedAt":"2024-05-13T07:42:19.000Z","pushType":"push","commitsCount":44,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix recursive RECORD-returning plpython functions.\n\nIf we recursed to a new call of the same function, with a different\ncoldeflist (AS clause), it would fail because the inner call would\noverwrite the outer call's idea of what to return.  This is vaguely\nlike 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:\nit's just that we computed the actual output rowtype at the start of\nthe call, and saved it in the per-procedure data structure.  We can\nfix it at basically zero cost by doing the computation at the end\nof each call instead of the start.\n\nIt's not clear that there's any real-world use-case for such a\nfunction, but given that it doesn't cost anything to fix,\nit'd be silly not to.\n\nPer report from Andreas Karlsson.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se","shortMessageHtmlLink":"Fix recursive RECORD-returning plpython functions."}},{"before":"b99dc6694ca64d8e5bd5ee2b0c6bdbbb8cdf4c99","after":"2728677923d2a025575dee4a24580e3e899c5615","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-05-13T07:35:24.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix recursive RECORD-returning plpython functions.\n\nIf we recursed to a new call of the same function, with a different\ncoldeflist (AS clause), it would fail because the inner call would\noverwrite the outer call's idea of what to return.  This is vaguely\nlike 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:\nit's just that we computed the actual output rowtype at the start of\nthe call, and saved it in the per-procedure data structure.  We can\nfix it at basically zero cost by doing the computation at the end\nof each call instead of the start.\n\nIt's not clear that there's any real-world use-case for such a\nfunction, but given that it doesn't cost anything to fix,\nit'd be silly not to.\n\nPer report from Andreas Karlsson.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se","shortMessageHtmlLink":"Fix recursive RECORD-returning plpython functions."}},{"before":"d1a2a93766b0a27eb4ffecdb63ed3879088dbfbe","after":"d39337021e12d569e3241a605120f010f77b9e22","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-05-13T07:33:19.000Z","pushType":"push","commitsCount":86,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix recursive RECORD-returning plpython functions.\n\nIf we recursed to a new call of the same function, with a different\ncoldeflist (AS clause), it would fail because the inner call would\noverwrite the outer call's idea of what to return.  This is vaguely\nlike 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:\nit's just that we computed the actual output rowtype at the start of\nthe call, and saved it in the per-procedure data structure.  We can\nfix it at basically zero cost by doing the computation at the end\nof each call instead of the start.\n\nIt's not clear that there's any real-world use-case for such a\nfunction, but given that it doesn't cost anything to fix,\nit'd be silly not to.\n\nPer report from Andreas Karlsson.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se","shortMessageHtmlLink":"Fix recursive RECORD-returning plpython functions."}},{"before":"b9f687f5abaf40c13fed59fe08014116a8344102","after":"6e29963edd55cfc038304322049d8fe697580f2c","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-05-13T07:31:10.000Z","pushType":"push","commitsCount":171,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix recursive RECORD-returning plpython functions.\n\nIf we recursed to a new call of the same function, with a different\ncoldeflist (AS clause), it would fail because the inner call would\noverwrite the outer call's idea of what to return.  This is vaguely\nlike 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:\nit's just that we computed the actual output rowtype at the start of\nthe call, and saved it in the per-procedure data structure.  We can\nfix it at basically zero cost by doing the computation at the end\nof each call instead of the start.\n\nIt's not clear that there's any real-world use-case for such a\nfunction, but given that it doesn't cost anything to fix,\nit'd be silly not to.\n\nPer report from Andreas Karlsson.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se","shortMessageHtmlLink":"Fix recursive RECORD-returning plpython functions."}},{"before":"05ffe9398b758bbb8d30cc76e9bbc638dab2d477","after":"52ea653aa9d867be70b2d86fe8310dde48507b6a","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-05-13T07:28:02.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix recursive RECORD-returning plpython functions.\n\nIf we recursed to a new call of the same function, with a different\ncoldeflist (AS clause), it would fail because the inner call would\noverwrite the outer call's idea of what to return.  This is vaguely\nlike 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:\nit's just that we computed the actual output rowtype at the start of\nthe call, and saved it in the per-procedure data structure.  We can\nfix it at basically zero cost by doing the computation at the end\nof each call instead of the start.\n\nIt's not clear that there's any real-world use-case for such a\nfunction, but given that it doesn't cost anything to fix,\nit'd be silly not to.\n\nPer report from Andreas Karlsson.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se","shortMessageHtmlLink":"Fix recursive RECORD-returning plpython functions."}},{"before":"93582974315174d544592185d797a2b44696d1e5","after":"84f08f2215754cd03feaa82bbdf10fc114458b26","ref":"refs/heads/master","pushedAt":"2024-05-08T12:25:21.000Z","pushType":"push","commitsCount":168,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"doc: Improve order of options on pg_upgrade reference page\n\nPut the new long-only options in a location that is consistent with\nthe existing long-only options and also the --help output.","shortMessageHtmlLink":"doc: Improve order of options on pg_upgrade reference page"}},{"before":"1de09959977375a9d7b878dff502da1e4f04a761","after":"b99dc6694ca64d8e5bd5ee2b0c6bdbbb8cdf4c99","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-05-08T12:14:09.000Z","pushType":"push","commitsCount":66,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Ensure that \"pg_restore -l\" reports dependent TOC entries correctly.\n\nIf -l was specified together with selective-restore options such as -n\nor -N, dependent TOC entries such as comments would be omitted from\nthe listing, even when an actual restore would have selected them.\nThis happened because PrintTOCSummary neglected to update the te->reqs\nmarking of the entry they depended on.\n\nPer report from Justin Pryzby.  This has been wrong since 0d4e6ed30\ntaught _tocEntryRequired to sometimes look at the \"reqs\" marking of\nother TOC entries, so back-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023","shortMessageHtmlLink":"Ensure that \"pg_restore -l\" reports dependent TOC entries correctly."}},{"before":"8cea358b128fea93c8360c9521dcf954775a38ca","after":"05ffe9398b758bbb8d30cc76e9bbc638dab2d477","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-05-07T19:29:23.000Z","pushType":"push","commitsCount":33,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Stamp 16.3.","shortMessageHtmlLink":"Stamp 16.3."}},{"before":"a85e3ba1c9482dd04bec11588a5169a3430939af","after":"8cea358b128fea93c8360c9521dcf954775a38ca","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-04-15T14:01:41.000Z","pushType":"push","commitsCount":12,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Use the correct PG_DETOAST_DATUM macro in BRIN\n\nCommit 6bcda4a721 replaced PG_DETOAST_DATUM with PG_DETOAST_DATUM_PACKED\nin two BRIN output functions, for minmax-multi and bloom opclasses. But\nthis is incorrect - the code is accessing the data through structs that\nalready include a 4B header, so the detoast needs to match that. But the\nPACKED macro may keep the 1B header, which means the struct fields will\npoint to incorrect data.\n\nBackpatch-through: 16\nDiscussion: https://postgr.es/m/1df00a66-db5a-4e66-809a-99b386a06d86%40enterprisedb.com","shortMessageHtmlLink":"Use the correct PG_DETOAST_DATUM macro in BRIN"}},{"before":"44a4cca9913bae8557c31207adb97b94e6e60603","after":"93582974315174d544592185d797a2b44696d1e5","ref":"refs/heads/master","pushedAt":"2024-04-14T09:33:17.000Z","pushType":"push","commitsCount":235,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"freespace: Don't return blocks past the end of the main fork.\n\nGetPageWithFreeSpace() callers assume the returned block exists in the\nmain fork, failing with \"could not read block\" errors if that doesn't\nhold.  Make that assumption reliable now.  It hadn't been guaranteed,\ndue to the weak WAL and data ordering of participating components.  Most\noperations on the fsm fork are not WAL-logged.  Relation extension is\nnot WAL-logged.  Hence, an fsm-fork block on disk can reference a\nmain-fork block that no WAL record has initialized.  That could happen\nafter an OS crash, a replica promote, or a PITR restore.  wal_log_hints\nmakes the trouble easier to hit; a replica promote or PITR ending just\nafter a relevant fsm-fork FPI_FOR_HINT may yield this broken state.  The\nv16 RelationAddBlocks() mechanism also makes the trouble easier to hit,\nsince it bulk-extends even without extension lock waiters.  Commit\n917dc7d2393ce680dea7a59418be9ff341df3c14 stopped trouble around\ntruncation, but vectors involving PageIsNew() pages remained.\n\nThis implementation adds a RelationGetNumberOfBlocks() call when the\ncached relation size doesn't confirm a block exists.  We've been unable\nto identify a benchmark that slows materially, but this may show up as\nadditional time in lseek().  An alternative without that overhead would\nbe a new ReadBufferMode such that ReadBufferExtended() returns NULL\nafter a 0-byte read, with all other errors handled normally.  However,\neach GetFreeIndexPage() caller would then need code for the return-NULL\ncase.  Back-patch to v14, due to earlier versions not caching relation\nsize and the absence of a pre-v16 problem report.\n\nRonan Dunklau.  Reported by Ronan Dunklau.\n\nDiscussion: https://postgr.es/m/1878547.tdWV9SEqCh%40aivenlaptop","shortMessageHtmlLink":"freespace: Don't return blocks past the end of the main fork."}},{"before":"a30a305584b81fd25eb890337ebec53acfbdc96b","after":"a85e3ba1c9482dd04bec11588a5169a3430939af","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-04-09T09:28:06.000Z","pushType":"push","commitsCount":48,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"In psql, avoid leaking a PGresult after a query is cancelled.\n\nAfter a query cancel, the tail end of ExecQueryAndProcessResults\ntook care to clear any not-yet-read PGresults; but it forgot about\nthe one it has already read.  There would only be such a result\nwhen handling a multi-command string made with \"\\;\", so that you'd\nhave to cancel an earlier command in such a string to reach the\nbug at all.  Even then, there would only be leakage of a single\nPGresult per cancel, so it's not surprising nobody noticed this.\nBut a leak is a leak.\n\nNoted while re-reviewing 90f517821, but this is independent of that:\nit dates to 7844c9918.  Back-patch to v15 where that came in.","shortMessageHtmlLink":"In psql, avoid leaking a PGresult after a query is cancelled."}},{"before":"655dc310460c601d434d05339b7fa46ed97675b3","after":"44a4cca9913bae8557c31207adb97b94e6e60603","ref":"refs/heads/master","pushedAt":"2024-03-27T15:40:55.000Z","pushType":"push","commitsCount":289,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Adjust documentation for syncfs().\n\nCommit 8c16ad3b43 created a new appendix for syncfs(), which is\nexcessive for such a small amount of content.  This commit moves\nthe description of the caveats to be aware of when using syncfs()\nback to the documentation for recovery_init_sync_method.  The\ndocumentation for the other utilities with syncfs() support now\ndirects readers to recovery_init_sync_method for information about\nthese caveats.\n\nReported-by: Peter Eisentraut, Robert Haas\nSuggested-by: Robert Haas\nReviewed-by: Robert Haas\nDiscussion: https://postgr.es/m/42804669-7063-1320-ed37-3226d5f1067d%40eisentraut.org\nDiscussion: https://postgr.es/m/CA%2BTgmobUiqKr%2BZMCLc5Qap-sXBnjfGUU%2BZBmzYEjUuWyjsGr1g%40mail.gmail.com","shortMessageHtmlLink":"Adjust documentation for syncfs()."}},{"before":"e81e617f3273b74c8eb46f7a7c51387509bc8d8c","after":"82c87af7a0ac97ec6e99277f2deb4ee55e347e1e","ref":"refs/heads/REL_12_STABLE","pushedAt":"2024-03-15T09:13:11.000Z","pushType":"push","commitsCount":80,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Make INSERT-from-multiple-VALUES-rows handle domain target columns.\n\nCommit a3c7a993d fixed some cases involving target columns that are\narrays or composites by applying transformAssignedExpr to the VALUES\nentries, and then stripping off any assignment ArrayRefs or\nFieldStores that the transformation added.  But I forgot about domains\nover arrays or composites :-(.  Such cases would either fail with\nsurprising complaints about mismatched datatypes, or insert unexpected\ncoercions that could lead to odd results.  To fix, extend the\nstripping logic to get rid of CoerceToDomain if it's atop an ArrayRef\nor FieldStore.\n\nWhile poking at this, I realized that there's a poorly documented and\nnot-at-all-tested behavior nearby: we coerce each VALUES column to\nthe domain type separately, and rely on the rewriter to merge those\noperations so that the domain constraints are checked only once.\nIf that merging did not happen, it's entirely possible that we'd get\nunexpected domain constraint failures due to checking a\npartially-updated container value.  There's no bug there, but while\nwe're here let's improve the commentary about it and add some test\ncases that explicitly exercise that behavior.\n\nPer bug #18393 from Pablo Kharo.  Back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/18393-65fedb1a0de9260d@postgresql.org","shortMessageHtmlLink":"Make INSERT-from-multiple-VALUES-rows handle domain target columns."}},{"before":"4eb261165d1294f590c7c279a8825e73abe57ecd","after":"a30a305584b81fd25eb890337ebec53acfbdc96b","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-03-01T19:08:03.000Z","pushType":"push","commitsCount":26,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix integer underflow in shared memory debugging\n\ndsa_dump would print a large negative number instead of zero for\nsegment bin 0.  Fix by explicitly checking for underflow and add\nspecial case for bin 0. Backpatch to all supported versions.\n\nAuthor: Ian Ilyasov <ianilyasov@outlook.com>\nReviewed-by: Robert Haas <robertmhaas@gmail.com>\nDiscussion: https://postgr.es/m/GV1P251MB1004E0D09D117D3CECF9256ECD502@GV1P251MB1004.EURP251.PROD.OUTLOOK.COM\nBackpatch-through: v12","shortMessageHtmlLink":"Fix integer underflow in shared memory debugging"}},{"before":"9f133763961e280d8ba692bcad0b061b861e9138","after":"655dc310460c601d434d05339b7fa46ed97675b3","ref":"refs/heads/master","pushedAt":"2024-03-01T19:07:45.000Z","pushType":"push","commitsCount":95,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Simplify pg_enc2gettext_tbl[] with C99-designated initializer syntax\n\nThis commit switches pg_enc2gettext_tbl[] in encnames.c to use a\nC99-designated initializer syntax.\n\npg_bind_textdomain_codeset() is simplified so as it is possible to do\na direct lookup at the gettext() array with a value of the enum pg_enc\nrather than doing a loop through all its elements, as long as the\nencoding value provided by GetDatabaseEncoding() is in the correct range\nof supported encoding values.  Note that PG_MULE_INTERNAL gains a value\nin the array, pointing to NULL.\n\nAuthor: Jelte Fennema-Nio\nDiscussion: https://postgr.es/m/CAGECzQT3caUbcCcszNewCCmMbCuyP7XNAm60J3ybd6PN5kH2Dw@mail.gmail.com","shortMessageHtmlLink":"Simplify pg_enc2gettext_tbl[] with C99-designated initializer syntax"}},{"before":"075df6b2080b13e0a5adc88737b7c24417a873c1","after":"9f133763961e280d8ba692bcad0b061b861e9138","ref":"refs/heads/master","pushedAt":"2024-02-15T14:39:56.000Z","pushType":"push","commitsCount":181,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Pull up ANY-SUBLINK with the necessary lateral support.\n\nFor ANY-SUBLINK, we adopted a two-stage pull-up approach to handle\ndifferent types of scenarios. In the first stage, the sublink is pulled up\nas a subquery. Because of this, when writing this code, we did not have\nthe ability to perform lateral joins, and therefore, we were unable to\npull up Var with varlevelsup=1. Now that we have the ability to use\nlateral joins, we can eliminate this limitation.\n\nAuthor: Andy Fan <zhihui.fan1213@gmail.com>\nAuthor: Tom Lane <tgl@sss.pgh.pa.us>\nReviewed-by: Tom Lane <tgl@sss.pgh.pa.us>\nReviewed-by: Richard Guo <guofenglinux@gmail.com>\nReviewed-by: Alena Rybakina <lena.ribackina@yandex.ru>\nReviewed-by: Andrey Lepikhov <a.lepikhov@postgrespro.ru>","shortMessageHtmlLink":"Pull up ANY-SUBLINK with the necessary lateral support."}},{"before":"10912f7d4ff0e343e714a1703752c0d8c5b71306","after":"1de09959977375a9d7b878dff502da1e4f04a761","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-02-15T14:37:54.000Z","pushType":"push","commitsCount":76,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"doc: Remove links to further reading from pgcrypto docs\n\nThe pgcrypto docs contained a set of links for useful reading and\ntechnical references. These sets of links were however not actively\ncurated and had stale content and dead links. Rather than investing\ntime into maintining these, this removes them altogether since there\nare lots of resources online which are actively maintained.\n\nBackpatch to all supported versions since these links have been in\nthe docs for a long time.\n\nReported-by: Hanefi Onaldi <hanefi.onaldi@microsoft.com>\nReviewed-by: Magnus Hagander <magnus@hagander.net>\nReviewed-by: Tom Lane <tgl@sss.pgh.pa.us>\nDiscussion: https://postgr.es/m/170774255387.3279713.2822272755998870925@wrigleys.postgresql.org\nBackpatch-through: v12","shortMessageHtmlLink":"doc: Remove links to further reading from pgcrypto docs"}},{"before":"e13205a5e4ad0fb75110a25f81654511303566f8","after":"4eb261165d1294f590c7c279a8825e73abe57ecd","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-02-10T01:20:32.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Remove race condition in pg_get_expr().\n\nSince its introduction, pg_get_expr() has intended to silently\nreturn NULL if called with an invalid relation OID, as can happen\nwhen scanning the catalogs concurrently with relation drops.\nHowever, there is a race condition: we check validity of the OID\nat the start, but it could get dropped just afterward, leading to\nfailures.  This is the cause of some intermittent instability we're\nseeing in a proposed new test case, and presumably it's a hazard in\nthe field as well.\n\nWe can fix this by AccessShareLock-ing the target relation for the\nduration of pg_get_expr().  Since we don't require any permissions\non the target relation, this is semantically a bit undesirable.  But\nit turns out that the set_relation_column_names() subroutine already\ntakes a transient AccessShareLock on that relation, and has done since\ncommit 2ffa740be in 2012.  Given the lack of complaints about that, it\nseems like there should be no harm in holding the lock a bit longer.\n\nBack-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/31ddcc01-a71b-4e8c-9948-01d1c47293ca@eisentraut.org","shortMessageHtmlLink":"Remove race condition in pg_get_expr()."}},{"before":"c5c5832600e9dfa4f690d1f4af536c3fd6d5d7e9","after":"d1a2a93766b0a27eb4ffecdb63ed3879088dbfbe","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-02-09T00:40:24.000Z","pushType":"push","commitsCount":222,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Stamp 14.11.","shortMessageHtmlLink":"Stamp 14.11."}},{"before":"edbd1b41ab5bd4be06dbebb3c60149f7910d7c5c","after":"e13205a5e4ad0fb75110a25f81654511303566f8","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-02-09T00:39:58.000Z","pushType":"push","commitsCount":28,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"doc: Remove superfluous bracket in synopsis\n\nCommit 9c08aea6a30 accidentally added one too many end brackets\nin the synopsis for CREATE DATABASE .. strategy = strat. Fix by\nremoving. Backpatch to v15 where it was introduced.\n\nReported-by: tim.needham2@gmail.com\nDiscussion: https://postgr.es/m/170734160862.3279712.810853722572951776@wrigleys.postgresql.org\nBackpatch-through: v15","shortMessageHtmlLink":"doc: Remove superfluous bracket in synopsis"}},{"before":"5b5318c387451e3eb89eddb4574e57a61297102f","after":"edbd1b41ab5bd4be06dbebb3c60149f7910d7c5c","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-01-29T03:12:27.000Z","pushType":"push","commitsCount":11,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Add more LOG messages when starting and ending recovery from a backup\n\nThree LOG messages are added in the recovery code paths, providing\ninformation that can be useful to track corruption issues depending on\nthe state of the cluster, telling that:\n- Recovery has started from a backup_label.\n- Recovery is restarting from a backup start LSN, without a\nbackup_label.\n- Recovery has completed from a backup.\n\nThis was originally applied on HEAD as of 1d35f705e191, and there is\nconsensus that this can be useful for older versions.  This applies\ncleanly down to 15, so do it down to this version for now (older\nversions have heavily refactored the WAL recovery paths, making the\nchange less straight-forward to do).\n\nAuthor: Andres Freund\nReviewed-by: David Steele, Laurenz Albe, Michael Paquier\nDiscussion: https://postgr.es/m/20231117041811.vz4vgkthwjnwp2pp@awork3.anarazel.de\nBackpatch-through: 15","shortMessageHtmlLink":"Add more LOG messages when starting and ending recovery from a backup"}},{"before":"d02cceb85cf1a46a36c36825dd8266a30aed134f","after":"5b5318c387451e3eb89eddb4574e57a61297102f","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-01-20T19:44:01.000Z","pushType":"push","commitsCount":33,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix buildfarm error from commit 5c31669058.\n\nSkip test when not using unix domain sockets.\n\nDiscussion: https://postgr.es/m/CALDaNm29-8OozsBWo9H6DN_Tb_3yA1QjRJput-KhaN8ncDJtJA@mail.gmail.com\nBackpatch-through: 16","shortMessageHtmlLink":"Fix buildfarm error from commit <a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/jesperpedersen/postgres/commit/5c31669058b5550b4b3d623c07bc4203c11b8316/hovercard\" href=\"https://github.com/jesperpedersen/postgres/commit/5c31669058b5550b4b3d623c07bc4203c11b8316\"><tt>5c31669</tt></a>."}},{"before":"8c852ba9a4347c4778cc610ad5a9cb50ea701b5c","after":"075df6b2080b13e0a5adc88737b7c24417a873c1","ref":"refs/heads/master","pushedAt":"2024-01-20T19:43:38.000Z","pushType":"push","commitsCount":1099,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Add planner support functions for range operators <@ and @>.\n\nThese support functions will transform expressions with constant\nrange values into direct comparisons on the range bound values,\nwhich are frequently better-optimizable.  The transformation is\nskipped however if it would require double evaluation of a\nvolatile or expensive element expression.\n\nAlong the way, add the range opfamily OID to range typcache entries,\nsince load_rangetype_info has to compute that anyway and it seems\nsilly to duplicate the work later.\n\nKim Johan Andersson and Jian He, reviewed by Laurenz Albe\n\nDiscussion: https://postgr.es/m/94f64d1f-b8c0-b0c5-98bc-0793a34e0851@kimmet.dk","shortMessageHtmlLink":"Add planner support functions for range operators &lt;@ and @&gt;."}},{"before":"8ca56620caffd6a1761eebd6a9498235321f222b","after":"d02cceb85cf1a46a36c36825dd8266a30aed134f","ref":"refs/heads/REL_16_STABLE","pushedAt":"2023-12-28T06:59:03.000Z","pushType":"push","commitsCount":20,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Doc: specify aclitem syntax more clearly.\n\nThe previous wording here relied solely on an example to explain\naclitem output format.  Add an actual syntax synopsis and\nexplanation of the elements to make it clearer.\n\nDavid Johnston and Tom Lane, per gripe from Eugen Konkov.\n\nDiscussion: https://postgr.es/m/170326116972.1876499.18357820037829248593@wrigleys.postgresql.org","shortMessageHtmlLink":"Doc: specify aclitem syntax more clearly."}},{"before":"c58a41605ffabe8e4184b4c3b2d919638cd3357d","after":"e81e617f3273b74c8eb46f7a7c51387509bc8d8c","ref":"refs/heads/REL_12_STABLE","pushedAt":"2023-12-11T09:54:52.000Z","pushType":"push","commitsCount":924,"pusher":{"login":"jesperpedersen","name":"Jesper Pedersen","path":"/jesperpedersen","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/229465?s=80&v=4"},"commit":{"message":"Fix an undetected deadlock due to apply worker.\n\nThe apply worker needs to update the state of the subscription tables to\n'READY' during the synchronization phase which requires locking the\ncorresponding subscription. The apply worker also waits for the\nsubscription tables to reach the 'SYNCDONE' state after holding the locks\non the subscription and the wait is done using WaitLatch. The 'SYNCDONE'\nstate is changed by tablesync workers again by locking the corresponding\nsubscription. Both the state updates use AccessShareLock mode to lock the\nsubscription, so they can't block each other. However, a backend can\nsimultaneously try to acquire a lock on the same subscription using\nAccessExclusiveLock mode to alter the subscription. Now, the backend's\nwait on a lock can sneak in between the apply worker and table sync worker\ncausing deadlock.\n\nIn other words, apply_worker waits for tablesync worker which waits for\nbackend, and backend waits for apply worker. This is not detected by the\ndeadlock detector because apply worker uses WaitLatch.\n\nThe fix is to release existing locks in apply worker before it starts to\nwait for tablesync worker to change the state.\n\nReported-by: Tomas Vondra\nAuthor: Shlok Kyal\nReviewed-by: Amit Kapila, Peter Smith\nBackpatch-through: 12\nDiscussion: https://postgr.es/m/d291bb50-12c4-e8af-2af2-7bb9bb4d8e3e@enterprisedb.com","shortMessageHtmlLink":"Fix an undetected deadlock due to apply worker."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEYcCFdwA","startCursor":null,"endCursor":null}},"title":"Activity · jesperpedersen/postgres"}