{"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":"e9b7aee27283e65bd8819cd7a081dbe79eb1c1a3","after":"70353e463cd32ad3368fc1020c3acde5ee9fb476","ref":"refs/heads/master","pushedAt":"2024-05-17T15:42:04.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":"Sync typedefs.list with buildfarm, for real this time.\n\nIn commit da256a4a7, I manually added some typedef names to the\nbuildfarm-generated list so as not to cause any formatting regressions\ncompared to the prior manually-updated list.\n\nAbout half of the additions were injection-point-related names.\nIt turns out that those were missing because none of the buildfarm\nanimals contributing typedef lists were building with\n--enable-injection-points. I rectified that on my animal sifaka,\nand now those are in the list available from the buildfarm.\n\nThe other half were typedefs that didn't show up in the generated list\nbecause our method for collecting that doesn't catch names that are\nnot used to declare any C variables or fields. Such a typedef name\ndoesn't really add a lot of value, so we decided to get rid of them,\nand that's now been done in commits 110eb4aef and be5942aee. (Note:\nI'm pretty sure there are some remaining cases of that, but we've\nalready accepted the ensuing odd formatting of the typedef declaration\nitself. The present fixes only dealt with typedefs that had been\nmanually added to typedefs.list during the v17 development cycle.)\n\nHence, we can now install a verbatim copy of the buildfarm's list\nand not have it affect anything. The only change is to add\nInjectionPointCallback, which I'd omitted from da256a4a7 because\nit chanced not to affect any pgindent decisions.\n\nDiscussion: https://postgr.es/m/1919000.1715815925@sss.pgh.pa.us","shortMessageHtmlLink":"Sync typedefs.list with buildfarm, for real this time."}},{"before":"3566fc0150acd569079a90a65c4d2a2b501e067f","after":"bcd2be0c2f7e494597ad02a69127c82478369b07","ref":"refs/heads/REL_12_STABLE","pushedAt":"2024-05-17T12:30: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":"Refuse upgrades from pre-9.0 clusters\n\nCommit 695b4a113ab added a dependency on retrieving oldestxid from\npg_control, which only exists in 9.0 and onwards, but the check for\n8.4 as the oldest version was retained. Since there has been few if\nany complaints of 8.4 upgrades not working, fix by setting 9.0 as\nthe oldest version supported rather than resurrecting 8.4 support.\n\nBackpatch to all supported versions.\n\nReviewed-by: Tom Lane \nDiscussion: https://postgr.es/m/1973418.1657040382@sss.pgh.pa.us\nBackpatch-through: v12","shortMessageHtmlLink":"Refuse upgrades from pre-9.0 clusters"}},{"before":"9489f3c6e8cdee1c193c511b523ef9c20deed208","after":"b030697d36d5c40d02f80194589e569eacca5dbf","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-05-17T12:30:20.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":"Refuse upgrades from pre-9.0 clusters\n\nCommit 695b4a113ab added a dependency on retrieving oldestxid from\npg_control, which only exists in 9.0 and onwards, but the check for\n8.4 as the oldest version was retained. Since there has been few if\nany complaints of 8.4 upgrades not working, fix by setting 9.0 as\nthe oldest version supported rather than resurrecting 8.4 support.\n\nBackpatch to all supported versions.\n\nReviewed-by: Tom Lane \nDiscussion: https://postgr.es/m/1973418.1657040382@sss.pgh.pa.us\nBackpatch-through: v12","shortMessageHtmlLink":"Refuse upgrades from pre-9.0 clusters"}},{"before":"01e98e0cdd36167f01b6d618486897eea1cfd09d","after":"ccf3408cff539d21256f14a350dd156c8bee05ef","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-05-17T12:29:19.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":"Refuse upgrades from pre-9.0 clusters\n\nCommit 695b4a113ab added a dependency on retrieving oldestxid from\npg_control, which only exists in 9.0 and onwards, but the check for\n8.4 as the oldest version was retained. Since there has been few if\nany complaints of 8.4 upgrades not working, fix by setting 9.0 as\nthe oldest version supported rather than resurrecting 8.4 support.\n\nBackpatch to all supported versions.\n\nReviewed-by: Tom Lane \nDiscussion: https://postgr.es/m/1973418.1657040382@sss.pgh.pa.us\nBackpatch-through: v12","shortMessageHtmlLink":"Refuse upgrades from pre-9.0 clusters"}},{"before":"17974ec259463869bb6bb4885d46847422fbc9ec","after":"e9b7aee27283e65bd8819cd7a081dbe79eb1c1a3","ref":"refs/heads/master","pushedAt":"2024-05-17T11:54:47.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":"A few follow-up fixes for GUC name quoting\n\nFixups for 17974ec259: Some messages were missed (and some were new\nsince the patch was originally proposed), and there was a typo\nintroduced.","shortMessageHtmlLink":"A few follow-up fixes for GUC name quoting"}},{"before":"be5942aee7a012ce7f30bc7a6617903127f29e89","after":"17974ec259463869bb6bb4885d46847422fbc9ec","ref":"refs/heads/master","pushedAt":"2024-05-17T09:50:59.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":"Revise GUC names quoting in messages again\n\nAfter further review, we want to move in the direction of always\nquoting GUC names in error messages, rather than the previous (PG16)\nwildly mixed practice or the intermittent (mid-PG17) idea of doing\nthis depending on how possibly confusing the GUC name is.\n\nThis commit applies appropriate quotes to (almost?) all mentions of\nGUC names in error messages. It partially supersedes a243569bf65 and\n8d9978a7176, which had moved things a bit in the opposite direction\nbut which then were abandoned in a partial state.\n\nAuthor: Peter Smith \nDiscussion: https://www.postgresql.org/message-id/flat/CAHut%2BPv-kSN8SkxSdoHano_wPubqcg5789ejhCDZAcLFceBR-w%40mail.gmail.com","shortMessageHtmlLink":"Revise GUC names quoting in messages again"}},{"before":"110eb4aefbad683c8f512ee8a7168d1718353baa","after":"be5942aee7a012ce7f30bc7a6617903127f29e89","ref":"refs/heads/master","pushedAt":"2024-05-17T05:40:08.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":"Remove unused typedefs\n\nThere were a few typedefs that were never used to define a variable or\nfield. This had the effect that the buildfarm's typedefs.list would\nnot include them, and so they would need to be re-added manually to\nkeep the overall pgindent result perfectly clean.\n\nWe can easily get rid of these typedefs to avoid the issue. In a few\ncases, we just let the enum or struct stand on its own without a\ntypedef around it. In one case, an enum was abused to define flag\nbits; that's better done with macro definitions.\n\nThis fixes all the remaining issues with missing entries in the\nbuildfarm's typedefs.list.\n\nReviewed-by: Tom Lane \nDiscussion: https://www.postgresql.org/message-id/1919000.1715815925@sss.pgh.pa.us","shortMessageHtmlLink":"Remove unused typedefs"}},{"before":"372700cf3067254317e7e8060662f8fac11500d5","after":"110eb4aefbad683c8f512ee8a7168d1718353baa","ref":"refs/heads/master","pushedAt":"2024-05-17T03:31:45.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":"Remove enum WaitEventExtension\n\nThis enum was used to determine the first ID to use when assigning a\ncustom wait event for extensions, which is always 1. It was kept so\nas it would be possible to add new in-core wait events in the category\n\"Extension\". There is no such thing currently, so let's remove this\nenum until a case justifying it pops up. This makes the code simpler\nand easier to understand.\n\nThis has as effect to switch back autoprewarm.c to use PG_WAIT_EXTENSION\nrather than WAIT_EVENT_EXTENSION, on par with v16 and older stable\nbranches.\n\nThinko in c9af05465307.\n\nReported-by: Peter Eisentraut\nDiscussion: https://postgr.es/m/195c6c45-abce-4331-be6a-e87724e1d060@eisentraut.org","shortMessageHtmlLink":"Remove enum WaitEventExtension"}},{"before":"b284513752529652344ce496df3b844b797dd6b4","after":"01e98e0cdd36167f01b6d618486897eea1cfd09d","ref":"refs/heads/REL_14_STABLE","pushedAt":"2024-05-16T21:15:58.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 about DROP DATABASE FORCE process termination rights.\n\nSpecifically, it terminates a background worker even if the caller\ncouldn't terminate the background worker with pg_terminate_backend().\nCommit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update\nthis. Back-patch to v13, which introduced DROP DATABASE FORCE.\n\nReviewed by Amit Kapila. Reported by Kirill Reshke.\n\nDiscussion: https://postgr.es/m/20240429212756.60.nmisch@google.com","shortMessageHtmlLink":"Fix documentation about DROP DATABASE FORCE process termination rights."}},{"before":"a3e6c6f929912f928fa405909d17bcbf0c1b03ee","after":"372700cf3067254317e7e8060662f8fac11500d5","ref":"refs/heads/master","pushedAt":"2024-05-16T21:15:58.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 about DROP DATABASE FORCE process termination rights.\n\nSpecifically, it terminates a background worker even if the caller\ncouldn't terminate the background worker with pg_terminate_backend().\nCommit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update\nthis. Back-patch to v13, which introduced DROP DATABASE FORCE.\n\nReviewed by Amit Kapila. Reported by Kirill Reshke.\n\nDiscussion: https://postgr.es/m/20240429212756.60.nmisch@google.com","shortMessageHtmlLink":"Fix documentation about DROP DATABASE FORCE process termination rights."}},{"before":"0ae05c18e0bf740e6457e710f9323e75f6619c35","after":"382284519e141d41f7dc021d6a5fccd5888af8a1","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-05-16T21:15:58.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 about DROP DATABASE FORCE process termination rights.\n\nSpecifically, it terminates a background worker even if the caller\ncouldn't terminate the background worker with pg_terminate_backend().\nCommit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update\nthis. Back-patch to v13, which introduced DROP DATABASE FORCE.\n\nReviewed by Amit Kapila. Reported by Kirill Reshke.\n\nDiscussion: https://postgr.es/m/20240429212756.60.nmisch@google.com","shortMessageHtmlLink":"Fix documentation about DROP DATABASE FORCE process termination rights."}},{"before":"e6fc3b70df906868df36517c2c7c5a38725e1451","after":"484b9587370ecb0325bfc30ca435697f9f52acc6","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-05-16T21:15:58.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 about DROP DATABASE FORCE process termination rights.\n\nSpecifically, it terminates a background worker even if the caller\ncouldn't terminate the background worker with pg_terminate_backend().\nCommit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update\nthis. Back-patch to v13, which introduced DROP DATABASE FORCE.\n\nReviewed by Amit Kapila. Reported by Kirill Reshke.\n\nDiscussion: https://postgr.es/m/20240429212756.60.nmisch@google.com","shortMessageHtmlLink":"Fix documentation about DROP DATABASE FORCE process termination rights."}},{"before":"2e2b2d076ab62c7850aaca65d1b575f602a9ce6d","after":"9489f3c6e8cdee1c193c511b523ef9c20deed208","ref":"refs/heads/REL_13_STABLE","pushedAt":"2024-05-16T21:15:58.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 about DROP DATABASE FORCE process termination rights.\n\nSpecifically, it terminates a background worker even if the caller\ncouldn't terminate the background worker with pg_terminate_backend().\nCommit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update\nthis. Back-patch to v13, which introduced DROP DATABASE FORCE.\n\nReviewed by Amit Kapila. Reported by Kirill Reshke.\n\nDiscussion: https://postgr.es/m/20240429212756.60.nmisch@google.com","shortMessageHtmlLink":"Fix documentation about DROP DATABASE FORCE process termination rights."}},{"before":"fb5718f35ff667104ab0b9dace3a238113666237","after":"a3e6c6f929912f928fa405909d17bcbf0c1b03ee","ref":"refs/heads/master","pushedAt":"2024-05-16T15:06:05.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":"BitmapHeapScan: Remove incorrect assert and reset field\n\n04e72ed617be pushed the skip fetch optimization (allowing bitmap heap\nscans to operate like index-only scans if none of the underlying data is\nneeded) into heap AM implementations of bitmap table scan callbacks.\n\n04e72ed617be added an assert that all tuples in blocks eligible for the\noptimization had been NULL-filled and emitted by the end of the scan.\nThis assert is incorrect when not all tuples need be scanned to execute\nthe query; for example: a join in which not all inner tuples need to be\nscanned before skipping to the next outer tuple.\n\nRemove the assert and reset the field on which it previously asserted to\navoid incorrectly emitting NULL-filled tuples from a previous scan on\nrescan.\n\nAuthor: Melanie Plageman\nReviewed-by: Tomas Vondra, Michael Paquier, Alvaro Herrera\nReported-by: Melanie Plageman\nReproduced-by: Tomas Vondra, Richard Guo\nDiscussion: https://postgr.es/m/CAMbWs48orzZVXa7-vP9Nt7vQWLTE04Qy4PePaLQYsVNQgo6qRg%40mail.gmail.com","shortMessageHtmlLink":"BitmapHeapScan: Remove incorrect assert and reset field"}},{"before":"8ba346283335f7ee5bac2e904c2daad49a204c7c","after":"fb5718f35ff667104ab0b9dace3a238113666237","ref":"refs/heads/master","pushedAt":"2024-05-16T14:22:09.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":"Remove option to fall back from direct to postgres SSL negotiation\n\nThere were three problems with the sslnegotiation options:\n\n1. The sslmode=prefer and sslnegotiation=requiredirect combination was\nsomewhat dangerous, as you might unintentionally fall back to\nplaintext authentication when connecting to a pre-v17 server.\n\n2. There was an asymmetry between 'postgres' and 'direct'\noptions. 'postgres' meant \"try only traditional negotiation\", while\n'direct' meant \"try direct first, and fall back to traditional\nnegotiation if it fails\". That was apparent only if you knew that the\n'requiredirect' mode also exists.\n\n3. The \"require\" word in 'requiredirect' suggests that it's somehow\nmore strict or more secure, similar to sslmode. However, I don't\nconsider direct SSL connections to be a security feature.\n\nTo address these problems:\n\n- Only allow sslnegotiation='direct' if sslmode='require' or\nstronger. And for the record, Jacob and Robert felt that we should do\nthat (or have sslnegotiation='direct' imply sslmode='require') anyway,\nregardless of the first issue.\n\n- Remove the 'direct' mode that falls back to traditional negotiation,\nand rename what was called 'requiredirect' to 'direct' instead. In\nother words, there is no \"try both methods\" option anymore, 'postgres'\nnow means the traditional negotiation and 'direct' means a direct SSL\nconnection.\n\nReviewed-by: Jelte Fennema-Nio, Robert Haas, Jacob Champion\nDiscussion: https://www.postgresql.org/message-id/d3b1608a-a1b6-4eda-9ec5-ddb3e4375808%40iki.fi","shortMessageHtmlLink":"Remove option to fall back from direct to postgres SSL negotiation"}},{"before":"fa65a022db26bc446fb67ce1d7ac543fa4bb72e4","after":"8ba346283335f7ee5bac2e904c2daad49a204c7c","ref":"refs/heads/master","pushedAt":"2024-05-16T12:55: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":"Document that increasing max_connections uses more resources.\n\nRoberto Mello\n\nDiscussion: http://postgr.es/m/CAKz==bJBCWrvN77fmuZ2XqD3jazWEb=E80AA4Yv9C9tQ61YDdQ@mail.gmail.com","shortMessageHtmlLink":"Document that increasing max_connections uses more resources."}},{"before":"94af84f00c5fd3ea840759d85a73204d64e28248","after":"fa65a022db26bc446fb67ce1d7ac543fa4bb72e4","ref":"refs/heads/master","pushedAt":"2024-05-16T12:40:31.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: use true|false rather than on|off for \"failover\" option\n\nThe CREATE SUBSCRIPTION documentation mentions \"false\" is the default\noption, so let's use true|false rather than on|off in the text which\ntalks about this option in the ALTER SUBSCRIPTION page.\n\nThe other boolean options mentioned in create_subscription.sgml use true\nand false so it makes sense to be consistent with these. The \"failover\"\noption is new to v17.\n\nAuthor: Peter Smith\nDiscussion: https://postgr.es/m/CAHut+Ps-RqrggaJU5w85BbeQzw9CLmmLgADVJoJ=xx_4D5CWvw@mail.gmail.com","shortMessageHtmlLink":"Doc: use true|false rather than on|off for \"failover\" option"}},{"before":"8aee330af55d8a759b2b73f5a771d9d34a7b887f","after":"94af84f00c5fd3ea840759d85a73204d64e28248","ref":"refs/heads/master","pushedAt":"2024-05-16T09:38:08.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":"pg_amcheck: Put new options in consistent order in --help and man page","shortMessageHtmlLink":"pg_amcheck: Put new options in consistent order in --help and man page"}},{"before":"f6ebb418317a1e84be46e7e7b02a26d8c44984de","after":"8aee330af55d8a759b2b73f5a771d9d34a7b887f","ref":"refs/heads/master","pushedAt":"2024-05-16T06:34:45.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 temporal primary keys and foreign keys\n\nThis feature set did not handle empty ranges correctly, and it's now\ntoo late for PostgreSQL 17 to fix it.\n\nThe following commits are reverted:\n\n 6db4598fcb8 Add stratnum GiST support function\n 46a0cd4cefb Add temporal PRIMARY KEY and UNIQUE constraints\n 86232a49a43 Fix comment on gist_stratnum_btree\n 030e10ff1a3 Rename pg_constraint.conwithoutoverlaps to conperiod\n a88c800deb6 Use daterange and YMD in without_overlaps tests instead of tsrange.\n 5577a71fb0c Use half-open interval notation in without_overlaps tests\n 34768ee3616 Add temporal FOREIGN KEY contraints\n 482e108cd38 Add test for REPLICA IDENTITY with a temporal key\n c3db1f30cba doc: clarify PERIOD and WITHOUT OVERLAPS in CREATE TABLE\n 144c2ce0cc7 Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexes\n\nDiscussion: https://www.postgresql.org/message-id/d0b64a7a-dfe4-4b84-a906-c7dedfa40a3e@eisentraut.org","shortMessageHtmlLink":"Revert temporal primary keys and foreign keys"}},{"before":"a8010d03e1f30c657b6c868fa857c7b8b53c3fbc","after":"f6ebb418317a1e84be46e7e7b02a26d8c44984de","ref":"refs/heads/master","pushedAt":"2024-05-16T02:54:56.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 PG 17 relnotes: wording adjustments\n\nReported-by: jian he\n\nDiscussion: https://postgr.es/m/CACJufxHTJBqDmBC4iPgte_xd4aMgONRm680Ji5m5gCA8+YEmJg@mail.gmail.com\n\nCo-authored-by: jian he\n\nBackpatch-through: master","shortMessageHtmlLink":"doc PG 17 relnotes: wording adjustments"}},{"before":"4dd29b683334739168f60df520dcc9218b6fead7","after":"a8010d03e1f30c657b6c868fa857c7b8b53c3fbc","ref":"refs/heads/master","pushedAt":"2024-05-16T02:48:26.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 PG 17 relnotes: add item about vacuum storage/limits/WAL\n\nReported-by: Alvaro Herrera\n\nDiscussion: https://postgr.es/m/202405150838.sg5ddcexyyf4@alvherre.pgsql\n\nBackpatch-through: master","shortMessageHtmlLink":"doc PG 17 relnotes: add item about vacuum storage/limits/WAL"}},{"before":"0de37b51065bc5b5848d65a9bb6f932ef392374f","after":"4dd29b683334739168f60df520dcc9218b6fead7","ref":"refs/heads/master","pushedAt":"2024-05-16T02:02: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":"jit: Remove {llvm-config,clang}-N configure probes.\n\nPreviously we searched for llvm-config-N and clang-N as well as the\nunversioned names, and maintained a list of expected values of N. There\ndoesn't seem to be any reason to think that the default llvm-config and\nclang won't be good enough, and if they aren't, they can be overridden\nwith LLVM_CONFIG and CLANG, so let's stop maintaining that list.\n\nThe list had not been updated since LLVM 7 with no complaints, so commit\n820b5af73dc probably should have just removed it when dropping support\nfor 7, instead of trying to be helpful by bringing it up to date with\nrecent version numbers.\n\nThe Meson build system didn't have that, so no change there.\n\nSuggested-by: Peter Eisentraut \nDiscussion: https://postgr.es/m/CA%2BhUKG%2BSOP-aR%3DYF_n0dtXGWeCy6x%2BCn-RMWURU5ySQdmeKW1Q%40mail.gmail.com","shortMessageHtmlLink":"jit: Remove {llvm-config,clang}-N configure probes."}},{"before":"f01e3ba56fd125ccba65b23a1829fc25b6f3fc65","after":"0de37b51065bc5b5848d65a9bb6f932ef392374f","ref":"refs/heads/master","pushedAt":"2024-05-16T00:50:41.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 some inconsistencies in EXPLAIN output\n\n06286709e added a SERIALIZE option to EXPLAIN which included showing the\namount of kilobytes serialized. The calculation to convert bytes into\nkilobytes wasn't consistent with how that's done in the rest of EXPLAIN.\nTraditionally we round up to the nearest kB, but the new code rounded to\nthe nearest kB.\n\nTo fix this, invent a macro that does the conversion and use that macro\neverywhere that requires this conversion.\n\nAdditionally, 5de890e36 added EXPLAIN (MEMORY) but included the memory\nsizes in bytes. Convert these values to kilobytes to align with the\nother memory related outputs.\n\nIn passing, swap out a \"long\" type in show_hash_info() and use a uint64\ninstead. We do support platforms where sizeof(Size) == 8 and\nsizeof(long) == 4, so using a long there is questionable.\n\nReported-by: jian he\nReviewed-by: jian he\nDiscussion: https://www.postgresql.org/message-id/CACJufxE4Sp7xvgOwhqtFx5hS85AxMKobPWDo-xZHZVTpK3EBjA@mail.gmail.com","shortMessageHtmlLink":"Fix some inconsistencies in EXPLAIN output"}},{"before":"3c03ee1a39c0f808cb261a207b6d465c606598bf","after":"f01e3ba56fd125ccba65b23a1829fc25b6f3fc65","ref":"refs/heads/master","pushedAt":"2024-05-16T00:17: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":"doc: Mention more variant --name=value of -c name=value for postgres\n\npostgres --name=value and -c name=value are equivalents. This commit\nexpands the documentation of libpq's \"option\" connection parameter and\nthe server startup sequence for shell interactions to mention both\nrather than only -c.\n\nExtracted from a larger patch by the same authors.\n\nReported-by: Alexey Palazhchenko\nAuthor: David Johnston, Aleksander Alekseev\nReviewed-by: Nathan Bossart, Peter Eisentraut, Álvaro Herrera\nDiscussion: https://postgr.es/m/CAJ7c6TMkuLiLfrA+EFCPYfhXoMKRxxssB5c86+ibxfaz6+=Sdg@mail.gmail.com","shortMessageHtmlLink":"doc: Mention more variant --name=value of -c name=value for postgres"}},{"before":"a8f87d5d21c2f3ddd644c9cb313ecd43290a446e","after":"3c03ee1a39c0f808cb261a207b6d465c606598bf","ref":"refs/heads/master","pushedAt":"2024-05-15T23:02: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":"Doc: update src/tools/pgindent/README for current practice.\n\nThis README explains how to run pgindent, but it was written\nfor our former practice of running pgindent only infrequently.\nNowadays the plan is to keep the tree indent-clean all the time,\nso the typical thing is to do an incremental pgindent run with\neach commit. Revise to explain that as the normal case, and\nthe infrequent full-on process as a separate thing.\n\nFor now, pgperltidy is still a run-it-infrequently item.","shortMessageHtmlLink":"Doc: update src/tools/pgindent/README for current practice."}},{"before":"a826021e562450abb3b9682087111029f2319330","after":"e6fc3b70df906868df36517c2c7c5a38725e1451","ref":"refs/heads/REL_15_STABLE","pushedAt":"2024-05-15T20:54:43.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 query result leak during binary upgrade\n\n9a974cbcba00 moved the query in binary_upgrade_set_pg_class_oids to the\nouter level, but left the PQclear and query buffer destruction in the\nis_index conditional. 353708e1fb2d fixed the leak of the query buffer\nbut left the PGresult leak. This moves clearing the result to the outer\nlevel ensuring that it will be called.\n\nReviewed-by: Tom Lane \nDiscussion: https://postgr.es/m/374550C1-F4ED-4D9D-9498-0FD029CCF674@yesql.se\nBackpatch-through: v15","shortMessageHtmlLink":"Fix query result leak during binary upgrade"}},{"before":"315661ecafbcbb23116cceea2ea80657d7763af0","after":"0ae05c18e0bf740e6457e710f9323e75f6619c35","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-05-15T20:54:01.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 query result leak during binary upgrade\n\n9a974cbcba00 moved the query in binary_upgrade_set_pg_class_oids to the\nouter level, but left the PQclear and query buffer destruction in the\nis_index conditional. 353708e1fb2d fixed the leak of the query buffer\nbut left the PGresult leak. This moves clearing the result to the outer\nlevel ensuring that it will be called.\n\nReviewed-by: Tom Lane \nDiscussion: https://postgr.es/m/374550C1-F4ED-4D9D-9498-0FD029CCF674@yesql.se\nBackpatch-through: v15","shortMessageHtmlLink":"Fix query result leak during binary upgrade"}},{"before":"98b4f53d156efe09294d6e1d62a5b52f544eee29","after":"a8f87d5d21c2f3ddd644c9cb313ecd43290a446e","ref":"refs/heads/master","pushedAt":"2024-05-15T20:52:53.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 query result leak during binary upgrade\n\n9a974cbcba00 moved the query in binary_upgrade_set_pg_class_oids to the\nouter level, but left the PQclear and query buffer destruction in the\nis_index conditional. 353708e1fb2d fixed the leak of the query buffer\nbut left the PGresult leak. This moves clearing the result to the outer\nlevel ensuring that it will be called.\n\nReviewed-by: Tom Lane \nDiscussion: https://postgr.es/m/374550C1-F4ED-4D9D-9498-0FD029CCF674@yesql.se\nBackpatch-through: v15","shortMessageHtmlLink":"Fix query result leak during binary upgrade"}},{"before":"987ab19ec9260618b36c186e0777f0bd43b8ded1","after":"315661ecafbcbb23116cceea2ea80657d7763af0","ref":"refs/heads/REL_16_STABLE","pushedAt":"2024-05-15T11:57: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":"Re-forbid underscore in positional parameters\n\nUnderscores were added to numeric literals in faff8f8e47. This change\nalso affected the positional parameters (e.g., $1) rule, which uses\nthe same production for its digits. But this did not actually work,\nbecause the digits for parameters are processed using atol(), which\ndoes not handle underscores and ignores whatever it cannot parse.\n\nThe underscores notation is probably not useful for positional\nparameters, so for simplicity revert that rule to its old form that\nonly accepts digits 0-9.\n\nAuthor: Erik Wienhold \nReviewed-by: Michael Paquier \nDiscussion: https://www.postgresql.org/message-id/flat/5d216d1c-91f6-4cbe-95e2-b4cbd930520c%40ewie.name","shortMessageHtmlLink":"Re-forbid underscore in positional parameters"}},{"before":"96bc29edfde9b8ad0de573702a6b1c55f73ce912","after":"98b4f53d156efe09294d6e1d62a5b52f544eee29","ref":"refs/heads/master","pushedAt":"2024-05-15T11:57: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":"Re-forbid underscore in positional parameters\n\nUnderscores were added to numeric literals in faff8f8e47. This change\nalso affected the positional parameters (e.g., $1) rule, which uses\nthe same production for its digits. But this did not actually work,\nbecause the digits for parameters are processed using atol(), which\ndoes not handle underscores and ignores whatever it cannot parse.\n\nThe underscores notation is probably not useful for positional\nparameters, so for simplicity revert that rule to its old form that\nonly accepts digits 0-9.\n\nAuthor: Erik Wienhold \nReviewed-by: Michael Paquier \nDiscussion: https://www.postgresql.org/message-id/flat/5d216d1c-91f6-4cbe-95e2-b4cbd930520c%40ewie.name","shortMessageHtmlLink":"Re-forbid underscore in positional parameters"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAETRL-pgA","startCursor":null,"endCursor":null}},"title":"Activity · postgres/postgres"}