8000 Commits · postgres/postgres · GitHub
[go: up one dir, main page]
Skip to content
{"payload":{"commitGroups":[{"title":"Jan 26, 2020","commits":[{"oid":"f37ff03478aefb5e01d748b85ad86e6213624992","url":"/postgres/postgres/commit/f37ff03478aefb5e01d748b85ad86e6213624992","authoredDate":"2020-01-27T09:05:27.000+13:00","committedDate":"2020-01-27T09:12:56.000+13:00","shortMessage":"Refactor confusing code in _mdfd_openseg().","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Refactor confusing code in _mdfd_openseg().\n\nAs reported independently by a couple of people, _mdfd_openseg() is coded in a\nway that seems to imply that the segments could be opened in an order that\nisn\u0026#39;t strictly sequential. Even if that were true, it\u0026#39;s also using the wrong\ncomparison. It\u0026#39;s not an active bug, since the condition is always true anyway,\nbut it\u0026#39;s confusing, so replace it with an assertion.\n\nAuthor: Thomas Munro\nReviewed-by: Andres Freund, Kyotaro Horiguchi, Noah Misch\nDiscussion: https://postgr.es/m/CA%2BhUKG%2BNBw%2BuSzxF1os-SO6gUuw%3DcqO5DAybk6KnHKzgGvxhxA%40mail.gmail.com\nDiscussion: https://postgr.es/m/20191222091930.GA1280238%40rfd.leadboat.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/f37ff03478aefb5e01d748b85ad86e6213624992\"\u003eRefactor confusing code in _mdfd_openseg().\u003c/a\u003e","bodyMessageHtml":"As reported independently by a couple of people, _mdfd_openseg() is coded in a\nway that seems to imply that the segments could be opened in an order that\nisn't strictly sequential. Even if that were true, it's also using the wrong\ncomparison. It's not an active bug, since the condition is always true anyway,\nbut it's confusing, so replace it with an assertion.\n\nAuthor: Thomas Munro\nReviewed-by: Andres Freund, Kyotaro Horiguchi, Noah Misch\nDiscussion: \u003ca href=\"https://postgr.es/m/CA%2BhUKG%2BNBw%2BuSzxF1os-SO6gUuw%3DcqO5DAybk6KnHKzgGvxhxA%40mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CA%2BhUKG%2BNBw%2BuSzxF1os-SO6gUuw%3DcqO5DAybk6KnHKzgGvxhxA%40mail.gmail.com\u003c/a\u003e\nDiscussion: \u003ca href=\"https://postgr.es/m/20191222091930.GA1280238%40rfd.leadboat.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20191222091930.GA1280238%40rfd.leadboat.com\u003c/a\u003e","authors":[{"login":"macdice","displayName":"Thomas Munro","avatarUrl":"https://avatars.githubusercontent.com/u/150350?v=4","path":"/macdice","isGitHub":false}],"committerAttribution":false,"committer":{"login":"macdice","displayName":"Thomas Munro","avatarUrl":"https://avatars.githubusercontent.com/u/150350?v=4","path":"/macdice","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"215824f9188a2b19f870e6a707c5a81e1ac3f1fc","url":"/postgres/postgres/commit/215824f9188a2b19f870e6a707c5a81e1ac3f1fc","authoredDate":"2020-01-26T14:31:08.000-05:00","committedDate":"2020-01-26T14:31:08.000-05:00","shortMessage":"In postgres_fdw, don't try to ship MULTIEXPR updates to remote server.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"In postgres_fdw, don\u0026#39;t try to ship MULTIEXPR updates to remote server.\n\nIn a statement like \u0026quot;UPDATE remote_tab SET (x,y) = (SELECT ...)\u0026quot;,\nwe\u0026#39;d conclude that the statement could be directly executed remotely,\nbecause the sub-SELECT is in a resjunk tlist item that\u0026#39;s not examined\nfor shippability. Currently that ends up crashing if the sub-SELECT\ncontains any remote Vars. Prevent the crash by deeming MULTIEXEC\nParams to be unshippable.\n\nThis is a bit of a brute-force solution, since if the sub-SELECT\n*doesn\u0026#39;t* contain any remote Vars, the current execution technology\nwould work; but that\u0026#39;s not a terribly common use-case for this syntax,\nI think. In any case, we generally don\u0026#39;t try to ship sub-SELECTs, so\nit won\u0026#39;t surprise anybody that this doesn\u0026#39;t end up as a remote direct\nupdate. I\u0026#39;d be inclined to see if that general limitation can be fixed\nbefore worrying about this case further.\n\nPer report from Lukáš Sobotka.\n\nBack-patch to 9.6. 9.5 had MULTIEXPR, but we didn\u0026#39;t try to perform\nremote direct updates then, so the case didn\u0026#39;t arise anyway.\n\nDiscussion: https://postgr.es/m/CAJif3k+iA_ekBB5Zw2hDBaE1wtiQa4LH4_JUXrrMGwTrH0J01Q@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/215824f9188a2b19f870e6a707c5a81e1ac3f1fc\"\u003eIn postgres_fdw, don't try to ship MULTIEXPR updates to remote server.\u003c/a\u003e","bodyMessageHtml":"In a statement like \"UPDATE remote_tab SET (x,y) = (SELECT ...)\",\nwe'd conclude that the statement could be directly executed remotely,\nbecause the sub-SELECT is in a resjunk tlist item that's not examined\nfor shippability. Currently that ends up crashing if the sub-SELECT\ncontains any remote Vars. Prevent the crash by deeming MULTIEXEC\nParams to be unshippable.\n\nThis is a bit of a brute-force solution, since if the sub-SELECT\n*doesn't* contain any remote Vars, the current execution technology\nwould work; but that's not a terribly common use-case for this syntax,\nI think. In any case, we generally don't try to ship sub-SELECTs, so\nit won't surprise anybody that this doesn't end up as a remote direct\nupdate. I'd be inclined to see if that general limitation can be fixed\nbefore worrying about this case further.\n\nPer report from Lukáš Sobotka.\n\nBack-patch to 9.6. 9.5 had MULTIEXPR, but we didn't try to perform\nremote direct updates then, so the case didn't arise anyway.\n\nDiscussion: \u003ca href=\"https://postgr.es/m/CAJif3k+iA_ekBB5Zw2hDBaE1wtiQa4LH4_JUXrrMGwTrH0J01Q@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CAJif3k+iA_ekBB5Zw2hDBaE1wtiQa4LH4_JUXrrMGwTrH0J01Q@mail.gmail.com\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"38a957316d7e46d4b00de40f43966984a463d80a","url":"/postgres/postgres/commit/38a957316d7e46d4b00de40f43966984a463d80a","authoredDate":"2020-01-26T11:39:00.000+02:00","committedDate":"2020-01-26T11:39:00.000+02:00","shortMessage":"Refactor XLogReadRecord(), adding XLogBeginRead() function.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Refactor XLogReadRecord(), adding XLogBeginRead() function.\n\nThe signature of XLogReadRecord() required the caller to pass the starting\nWAL position as argument, or InvalidXLogRecPtr to continue reading at the\nend of previous record. That\u0026#39;s slightly awkward to the callers, as most\nof them don\u0026#39;t want to randomly jump around in the WAL stream, but start\nreading at one position and then read everything from that point onwards.\nRemove the \u0026#39;RecPtr\u0026#39; argument and add a new function XLogBeginRead() to\nspecify the starting position instead. That\u0026#39;s more convenient for the\ncallers. Also, xlogreader holds state that is reset when you change the\nstarting position, so having a separate function for doing that feels like\na more natural fit.\n\nThis changes XLogFindNextRecord() function so that it doesn\u0026#39;t reset the\nxlogreader\u0026#39;s state to what it was before the call anymore. Instead, it\npositions the xlogreader to the found record, like XLogBeginRead().\n\nReviewed-by: Kyotaro Horiguchi, Alvaro Herrera\nDiscussion: https://www.postgresql.org/message-id/5382a7a3-debe-be31-c860-cb810c08f366%40iki.fi\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/38a957316d7e46d4b00de40f43966984a463d80a\"\u003eRefactor XLogReadRecord(), adding XLogBeginRead() function.\u003c/a\u003e","bodyMessageHtml":"The signature of XLogReadRecord() required the caller to pass the starting\nWAL position as argument, or InvalidXLogRecPtr to continue reading at the\nend of previous record. That's slightly awkward to the callers, as most\nof them don't want to randomly jump around in the WAL stream, but start\nreading at one position and then read everything from that point onwards.\nRemove the 'RecPtr' argument and add a new function XLogBeginRead() to\nspecify the starting position instead. That's more convenient for the\ncallers. Also, xlogreader holds state that is reset when you change the\nstarting position, so having a separate function for doing that feels like\na more natural fit.\n\nThis changes XLogFindNextRecord() function so that it doesn't reset the\nxlogreader's state to what it was before the call anymore. Instead, it\npositions the xlogreader to the found record, like XLogBeginRead().\n\nReviewed-by: Kyotaro Horiguchi, Alvaro Herrera\nDiscussion: \u003ca href=\"https://www.postgresql.org/message-id/5382a7a3-debe-be31-c860-cb810c08f366%40iki.fi\" rel=\"nofollow\"\u003ehttps://www.postgresql.org/message-id/5382a7a3-debe-be31-c860-cb810c08f366%40iki.fi\u003c/a\u003e","authors":[{"login":"hlinnaka","displayName":"Heikki Linnakangas","avatarUrl":"https://avatars.githubusercontent.com/u/191602?v=4","path":"/hlinnaka","isGitHub":false}],"committerAttribution":false,"committer":{"login":"hlinnaka","displayName":"Heikki Linnakangas","avatarUrl":"https://avatars.githubusercontent.com/u/191602?v=4","path":"/hlinnaka","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 25, 2020","commits":[{"oid":"10013684970453a0ddc86050bba813c611114321","url":"/postgres/postgres/commit/10013684970453a0ddc86050bba813c611114321","authoredDate":"2020-01-25T18:16:42.000-05:00","committedDate":"2020-01-25T18:16:42.000-05:00","shortMessage":"Clean up EXPLAIN's handling of per-worker details.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Clean up EXPLAIN\u0026#39;s handling of per-worker details.\n\nPreviously, it was possible for EXPLAIN ANALYZE of a parallel query\nto produce several different \u0026quot;Workers\u0026quot; fields for a single plan node,\nbecause different portions of explain.c independently generated\nper-worker data and wrapped that output in separate fields. This\nis pretty bogus, especially for the structured output formats: even\nif it\u0026#39;s not technically illegal, most programs would have a hard time\ndealing with such data.\n\nTo improve matters, add infrastructure that allows redirecting\nper-worker values into a side data structure, and then collect that\ndata into a single \u0026quot;Workers\u0026quot; field after we\u0026#39;ve finished running all\nthe relevant code for a given plan node.\n\nThere are a few visible side-effects:\n\n* In text format, instead of something like\n\n Sort Method: external merge Disk: 4920kB\n Worker 0: Sort Method: external merge Disk: 5880kB\n Worker 1: Sort Method: external merge Disk: 5920kB\n Buffers: shared hit=682 read=10188, temp read=1415 written=2101\n Worker 0: actual time=130.058..130.324 rows=1324 loops=1\n Buffers: shared hit=337 read=3489, temp read=505 written=739\n Worker 1: actual time=130.273..130.512 rows=1297 loops=1\n Buffers: shared hit=345 read=3507, temp read=505 written=744\n\nyou get\n\n Sort Method: external merge Disk: 4920kB\n Buffers: shared hit=682 read=10188, temp read=1415 written=2101\n Worker 0: actual time=130.058..130.324 rows=1324 loops=1\n Sort Method: external merge Disk: 5880kB\n Buffers: shared hit=337 read=3489, temp read=505 written=739\n Worker 1: actual time=130.273..130.512 rows=1297 loops=1\n Sort Method: external merge Disk: 5920kB\n Buffers: shared hit=345 read=3507, temp read=505 written=744\n\n* When JIT is enabled, any relevant per-worker JIT stats are attached\nto the child node of the Gather or Gather Merge node, which is where\nthe other per-worker output has always been. Previously, that info\nwas attached directly to a Gather node, or missed entirely for Gather\nMerge.\n\n* A query\u0026#39;s summary JIT data no longer includes a bogus\n\u0026quot;Worker Number: -1\u0026quot; field.\n\nA notable code-level change is that indenting for lines of text-format\noutput should now be handled by calling \u0026quot;ExplainIndentText(es)\u0026quot;,\ninstead of hard-wiring how much space to emit. This seems a good deal\ncleaner anyway.\n\nThis patch also adds a new \u0026quot;explain.sql\u0026quot; regression test script that\u0026#39;s\ndedicated to testing EXPLAIN. There is more that can be done in that\nline, certainly, but for now it just adds some coverage of the XML and\nYAML output formats, which had been completely untested.\n\nAlthough this is surely a bug fix, it\u0026#39;s not clear that people would\nbe happy with rearranging EXPLAIN output in a minor release, so apply\nto HEAD only.\n\nMaciek Sakrejda and Tom Lane, based on an idea of Andres Freund\u0026#39;s;\nreviewed by Georgios Kokolatos\n\nDiscussion: https://postgr.es/m/CAOtHd0AvAA8CLB9Xz0wnxu1U=zJCKrr1r4QwwXi_kcQsHDVU=Q@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/10013684970453a0ddc86050bba813c611114321\"\u003eClean up EXPLAIN's handling of per-worker details.\u003c/a\u003e","bodyMessageHtml":"Previously, it was possible for EXPLAIN ANALYZE of a parallel query\nto produce several different \"Workers\" fields for a single plan node,\nbecause different portions of explain.c independently generated\nper-worker data and wrapped that output in separate fields. This\nis pretty bogus, especially for the structured output formats: even\nif it's not technically illegal, most programs would have a hard time\ndealing with such data.\n\nTo improve matters, add infrastructure that allows redirecting\nper-worker values into a side data structure, and then collect that\ndata into a single \"Workers\" field after we've finished running all\nthe relevant code for a given plan node.\n\nThere are a few visible side-effects:\n\n* In text format, instead of something like\n\n Sort Method: external merge Disk: 4920kB\n Worker 0: Sort Method: external merge Disk: 5880kB\n Worker 1: Sort Method: external merge Disk: 5920kB\n Buffers: shared hit=682 read=10188, temp read=1415 written=2101\n Worker 0: actual time=130.058..130.324 rows=1324 loops=1\n Buffers: shared hit=337 read=3489, temp read=505 written=739\n Worker 1: actual time=130.273..130.512 rows=1297 loops=1\n Buffers: shared hit=345 read=3507, temp read=505 written=744\n\nyou get\n\n Sort Method: external merge Disk: 4920kB\n Buffers: shared hit=682 read=10188, temp read=1415 written=2101\n Worker 0: actual time=130.058..130.324 rows=1324 loops=1\n Sort Method: external merge Disk: 5880kB\n Buffers: shared hit=337 read=3489, temp read=505 written=739\n Worker 1: actual time=130.273..130.512 rows=1297 loops=1\n Sort Method: external merge Disk: 5920kB\n Buffers: shared hit=345 read=3507, temp read=505 written=744\n\n* When JIT is enabled, any relevant per-worker JIT stats are attached\nto the child node of the Gather or Gather Merge node, which is where\nthe other per-worker output has always been. Previously, that info\nwas attached directly to a Gather node, or missed entirely for Gather\nMerge.\n\n* A query's summary JIT data no longer includes a bogus\n\"Worker Number: -1\" field.\n\nA notable code-level change is that indenting for lines of text-format\noutput should now be handled by calling \"ExplainIndentText(es)\",\ninstead of hard-wiring how much space to emit. This seems a good deal\ncleaner anyway.\n\nThis patch also adds a new \"explain.sql\" regression test script that's\ndedicated to testing EXPLAIN. There is more that can be done in that\nline, certainly, but for now it just adds some coverage of the XML and\nYAML output formats, which had been completely untested.\n\nAlthough this is surely a bug fix, it's not clear that people would\nbe happy with rearranging EXPLAIN output in a minor release, so apply\nto HEAD only.\n\nMaciek Sakrejda and Tom Lane, based on an idea of Andres Freund's;\nreviewed by Georgios Kokolatos\n\nDiscussion: \u003ca href=\"https://postgr.es/m/CAOtHd0AvAA8CLB9Xz0wnxu1U=zJCKrr1r4QwwXi_kcQsHDVU=Q@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CAOtHd0AvAA8CLB9Xz0wnxu1U=zJCKrr1r4QwwXi_kcQsHDVU=Q@mail.gmail.com\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"13661ddd7eaec7e2809ff5c29fc14653b6161036","url":"/postgres/postgres/commit/13661ddd7eaec7e2809ff5c29fc14653b6161036","authoredDate":"2020-01-25T14:00:59.000Z","committedDate":"2020-01-25T14:00:59.000Z","shortMessage":"Add functions gcd() and lcm() for integer and numeric types.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add functions gcd() and lcm() for integer and numeric types.\n\nThese compute the greatest common divisor and least common multiple of\na pair of numbers using the Euclidean algorithm.\n\nVik Fearing, reviewed by Fabien Coelho.\n\nDiscussion: https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/13661ddd7eaec7e2809ff5c29fc14653b6161036\"\u003eAdd functions gcd() and lcm() for integer and numeric types.\u003c/a\u003e","bodyMessageHtml":"These compute the greatest common divisor and least common multiple of\na pair of numbers using the Euclidean algorithm.\n\nVik Fearing, reviewed by Fabien Coelho.\n\nDiscussion: \u003ca href=\"https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com\u003c/a\u003e","authors":[{"login":"deanrasheed","displayName":"Dean Rasheed","avatarUrl":"https://avatars.githubusercontent.com/u/43264115?v=4","path":"/deanrasheed","isGitHub":false}],"committerAttribution":false,"committer":{"login":"deanrasheed","displayName":"Dean Rasheed","avatarUrl":"https://avatars.githubusercontent.com/u/43264115?v=4","path":"/deanrasheed","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 24, 2020","commits":[{"oid":"530609aa4263bee5b5ca205d83f0dbad098d0465","url":"/postgres/postgres/commit/530609aa4263bee5b5ca205d83f0dbad098d0465","authoredDate":"2020-01-17T14:06:41.000-05:00","committedDate":"2020-01-24T10:29:52.000-08:00","shortMessage":"Remove jsonapi.c's lex_accept().","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Remove jsonapi.c\u0026#39;s lex_accept().\n\nAt first glance, this function seems useful, but it actually increases\nthe amount of code required rather than decreasing it. Inline the\nlogic into the callers instead; most callers don\u0026#39;t use the \u0026#39;lexeme\u0026#39;\nargument for anything and as a result considerable simplification is\npossible.\n\nAlong the way, fix the header comment for the nearby function\nlex_expect(), which mislabeled it as lex_accept().\n\nPatch by me, reviewed by David Steele, Mark Dilger, and Andrew\nDunstan.\n\nDiscussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/530609aa4263bee5b5ca205d83f0dbad098d0465\"\u003eRemove jsonapi.c's lex_accept().\u003c/a\u003e","bodyMessageHtml":"At first glance, this function seems useful, but it actually increases\nthe amount of code required rather than decreasing it. Inline the\nlogic into the callers instead; most callers don't use the 'lexeme'\nargument for anything and as a result considerable simplification is\npossible.\n\nAlong the way, fix the header comment for the nearby function\nlex_expect(), which mislabeled it as lex_accept().\n\nPatch by me, reviewed by David Steele, Mark Dilger, and Andrew\nDunstan.\n\nDiscussion: \u003ca href=\"http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com\" rel=\"nofollow\"\u003ehttp://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com\u003c/a\u003e","authors":[{"login":"robertmhaas","displayName":"Robert Haas","avatarUrl":"https://avatars.githubusercontent.com/u/886678?v=4","path":"/robertmhaas","isGitHub":false}],"committerAttribution":false,"committer":{"login":"robertmhaas","displayName":"Robert Haas","avatarUrl":"https://avatars.githubusercontent.com/u/886678?v=4","path":"/robertmhaas","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"11b5e3e35d3900164cb36754ee4e4dcab0bd02f0","url":"/postgres/postgres/commit/11b5e3e35d3900164cb36754ee4e4dcab0bd02f0","authoredDate":"2020-01-24T10:17:43.000-08:00","committedDate":"2020-01-24T10:17:43.000-08:00","shortMessage":"Split JSON lexer/parser from 'json' data type support.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Split JSON lexer/parser from \u0026#39;json\u0026#39; data type support.\n\nKeep the code that pertains to the \u0026#39;json\u0026#39; data type in json.c, but\nmove the lexing and parsing code to a new file jsonapi.c, a name\nI chose because the corresponding prototypes are in jsonapi.h.\n\nThis seems like a logical division, because the JSON lexer and parser\nare also used by the \u0026#39;jsonb\u0026#39; data type, but the SQL-callable functions\nin json.c are a separate thing. Also, the new jsonapi.c file needs to\ninclude far fewer header files than json.c, which seems like a good\nsign that this is an appropriate place to insert an abstraction\nboundary. I took the opportunity to remove a few apparently-unneeded\nincludes from json.c at the same time.\n\nPatch by me, reviewed by David Steele, Mark Dilger, and Andrew\nDunstan. The previous commit was, too, but I forgot to note it\nin the commit message.\n\nDiscussion: http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/11b5e3e35d3900164cb36754ee4e4dcab0bd02f0\"\u003eSplit JSON lexer/parser from 'json' data type support.\u003c/a\u003e","bodyMessageHtml":"Keep the code that pertains to the 'json' data type in json.c, but\nmove the lexing and parsing code to a new file jsonapi.c, a name\nI chose because the corresponding prototypes are in jsonapi.h.\n\nThis seems like a logical division, because the JSON lexer and parser\nare also used by the 'jsonb' data type, but the SQL-callable functions\nin json.c are a separate thing. Also, the new jsonapi.c file needs to\ninclude far fewer header files than json.c, which seems like a good\nsign that this is an appropriate place to insert an abstraction\nboundary. I took the opportunity to remove a few apparently-unneeded\nincludes from json.c at the same time.\n\nPatch by me, reviewed by David Steele, Mark Dilger, and Andrew\nDunstan. The previous commit was, too, but I forgot to note it\nin the commit message.\n\nDiscussion: \u003ca href=\"http://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com\" rel=\"nofollow\"\u003ehttp://postgr.es/m/CA+TgmoYfOXhd27MUDGioVh6QtpD0C1K-f6ObSA10AWiHBAL5bA@mail.gmail.com\u003c/a\u003e","authors":[{"login":"robertmhaas","displayName":"Robert Haas","avatarUrl":"https://avatars.githubusercontent.com/u/886678?v=4","path":"/robertmhaas","isGitHub":false}],"committerAttribution":false,"committer":{"login":"robertmhaas","displayName":"Robert Haas","avatarUrl":"https://avatars.githubusercontent.com/u/886678?v=4","path":"/robertmhaas","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"ce0425b162d0a8c168e1fbab5324fb1cbca4b6b7","url":"/postgres/postgres/commit/ce0425b162d0a8c168e1fbab5324fb1cbca4b6b7","authoredDate":"2020-01-24T09:58:37.000-08:00","committedDate":"2020-01-24T09:58:37.000-08:00","shortMessage":"Adjust src/include/utils/jsonapi.h so it's not backend-only.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Adjust src/include/utils/jsonapi.h so it\u0026#39;s not backend-only.\n\nThe major change here is that we no longer include jsonb.h into\njsonapi.h. The reason that was necessary is that jsonapi.h included\nseveral prototypes functions in jsonfuncs.c that depend on the Jsonb\ntype. Move those prototypes to a new header, jsonfuncs.h, and include\nit where needed.\n\nThe other change is that JsonEncodeDateTime is now declared in\njson.h rather than jsonapi.h.\n\nTaken together, these steps eliminate all dependencies of jsonapi.h\non backend-only data types and header files, so that it can\npotentially be included in frontend code.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/ce0425b162d0a8c168e1fbab5324fb1cbca4b6b7\"\u003eAdjust src/include/utils/jsonapi.h so it's not backend-only.\u003c/a\u003e","bodyMessageHtml":"The major change here is that we no longer include jsonb.h into\njsonapi.h. The reason that was necessary is that jsonapi.h included\nseveral prototypes functions in jsonfuncs.c that depend on the Jsonb\ntype. Move those prototypes to a new header, jsonfuncs.h, and include\nit where needed.\n\nThe other change is that JsonEncodeDateTime is now declared in\njson.h rather than jsonapi.h.\n\nTaken together, these steps eliminate all dependencies of jsonapi.h\non backend-only data types and header files, so that it can\npotentially be included in frontend code.","authors":[{"login":"robertmhaas","displayName":"Robert Haas","avatarUrl":"https://avatars.githubusercontent.com/u/886678?v=4","path":"/robertmhaas","isGitHub":false}],"committerAttribution":false,"committer":{"login":"robertmhaas","displayName":"Robert Haas","avatarUrl":"https://avatars.githubusercontent.com/u/886678?v=4","path":"/robertmhaas","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"d694e0bb793ebd6b392e6ef6a3b0a59ae66cbc95","url":"/postgres/postgres/commit/d694e0bb793ebd6b392e6ef6a3b0a59ae66cbc95","authoredDate":"2020-01-24T20:42:52.000+09:00","committedDate":"2020-01-24T20:42:52.000+09:00","shortMessage":"Add pg_file_sync() to adminpack extension.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add pg_file_sync() to adminpack extension.\n\nThis function allows us to fsync the specified file or directory.\nIt\u0026#39;s useful, for example, when we want to sync the file that\npg_file_write() writes out or that COPY TO exports the data into,\nfor durability.\n\nAuthor: Fujii Masao\nReviewed-By: Julien Rouhaud, Arthur Zakirov, Michael Paquier, Atsushi Torikoshi\nDiscussion: https://www.postgresql.org/message-id/CAHGQGwGY8uzZ_k8dHRoW1zDcy1Z7=5GQ+So4ZkVy2u=nLsk=hA@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/d694e0bb793ebd6b392e6ef6a3b0a59ae66cbc95\"\u003eAdd pg_file_sync() to adminpack extension.\u003c/a\u003e","bodyMessageHtml":"This function allows us to fsync the specified file or directory.\nIt's useful, for example, when we want to sync the file that\npg_file_write() writes out or that COPY TO exports the data into,\nfor durability.\n\nAuthor: Fujii Masao\nReviewed-By: Julien Rouhaud, Arthur Zakirov, Michael Paquier, Atsushi Torikoshi\nDiscussion: \u003ca href=\"https://www.postgresql.org/message-id/CAHGQGwGY8uzZ_k8dHRoW1zDcy1Z7=5GQ+So4ZkVy2u=nLsk=hA@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://www.postgresql.org/message-id/CAHGQGwGY8uzZ_k8dHRoW1zDcy1Z7=5GQ+So4ZkVy2u=nLsk=hA@mail.gmail.com\u003c/a\u003e","authors":[{"login":"MasaoFujii","displayName":"Fujii Masao","avatarUrl":"https://avatars.githubusercontent.com/u/157553?v=4","path":"/MasaoFujii","isGitHub":false}],"committerAttribution":false,"committer":{"login":"MasaoFujii","displayName":"Fujii Masao","avatarUrl":"https://avatars.githubusercontent.com/u/157553?v=4","path":"/MasaoFujii","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"cc25464763f0211e59a209eb50a7b7a79449051f","url":"/postgres/postgres/commit/cc25464763f0211e59a209eb50a7b7a79449051f","authoredDate":"2020-01-24T12:23:06.000+01:00","committedDate":"2020-01-24T12:23:06.000+01:00","shortMessage":"Add exclusion to headercheck","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add exclusion to headercheck\n\nsrc/include/common/unicode_combining_table.h is currently not meant to\nbe included standalone. Things could be refactored to allow it, but\nthat would be beyond the present purpose. So adding an exclusion here\nseems best.\n\nDiscussion: https://www.postgresql.org/message-id/10754.1579535012@sss.pgh.pa.us\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/cc25464763f0211e59a209eb50a7b7a79449051f\"\u003eAdd exclusion to headercheck\u003c/a\u003e","bodyMessageHtml":"src/include/common/unicode_combining_table.h is currently not meant to\nbe included standalone. Things could be refactored to allow it, but\nthat would be beyond the present purpose. So adding an exclusion here\nseems best.\n\nDiscussion: \u003ca href=\"https://www.postgresql.org/message-id/10754.1579535012@sss.pgh.pa.us\" rel=\"nofollow\"\u003ehttps://www.postgresql.org/message-id/10754.1579535012@sss.pgh.pa.us\u003c/a\u003e","authors":[{"login":"petere","displayName":"Peter Eisentraut","avatarUrl":"https://avatars.githubusercontent.com/u/105543?v=4","path":"/petere","isGitHub":false}],"committerAttribution":false,"committer":{"login":"petere","displayName":"Peter Eisentraut","avatarUrl":"https://avatars.githubusercontent.com/u/105543?v=4","path":"/petere","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"a7a848844d74e63ee102717972de3e60b5f4549a","url":"/postgres/postgres/commit/a7a848844d74e63ee102717972de3e60b5f4549a","authoredDate":"2020-01-23T10:27:49.000+01:00","committedDate":"2020-01-24T12:18:07.000+01:00","shortMessage":"Fix typo","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix typo\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/a7a848844d74e63ee102717972de3e60b5f4549a\"\u003eFix typo\u003c/a\u003e","bodyMessageHtml":"","authors":[{"login":"petere","displayName":"Peter Eisentraut","avatarUrl":"https://avatars.githubusercontent.com/u/105543?v=4","path":"/petere","isGitHub":false}],"committerAttribution":false,"committer":{"login":"petere","displayName":"Peter Eisentraut","avatarUrl":"https://avatars.githubusercontent.com/u/105543?v=4","path":"/petere","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"6de7bcb76f6593dcd107a6bfed645f2142bf3225","url":"/postgres/postgres/commit/6de7bcb76f6593dcd107a6bfed645f2142bf3225","authoredDate":"2020-01-24T09:55:21.000+09:00","committedDate":"2020-01-24T09:55:21.000+09:00","shortMessage":"Doc: Fix list of storage parameters available for ALTER TABLE","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Doc: Fix list of storage parameters available for ALTER TABLE\n\nOnly the parameter parallel_workers can be used directly with ALTER\nTABLE.\n\nIssue introduced in 6f3a13f, so backpatch down to 10.\n\nAuthor: Justin Pryzby\nDiscussion: https://postgr.es/m/20200106025623.GA12066@telsasoft.com\nBackpatch-through: 10\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/6de7bcb76f6593dcd107a6bfed645f2142bf3225\"\u003eDoc: Fix list of storage parameters available for ALTER TABLE\u003c/a\u003e","bodyMessageHtml":"Only the parameter parallel_workers can be used directly with ALTER\nTABLE.\n\nIssue introduced in \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/6f3a13ff058f15d565a30c16c0c2cb14cc994e42/hovercard\" href=\"https://github.com/postgres/postgres/commit/6f3a13ff058f15d565a30c16c0c2cb14cc994e42\"\u003e\u003ctt\u003e6f3a13f\u003c/tt\u003e\u003c/a\u003e, so backpatch down to 10.\n\nAuthor: Justin Pryzby\nDiscussion: \u003ca href=\"https://postgr.es/m/20200106025623.GA12066@telsasoft.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20200106025623.GA12066@telsasoft.com\u003c/a\u003e\nBackpatch-through: 10","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate 8000 ":null}]},{"title":"Jan 23, 2020","commits":[{"oid":"c32704441d47cc1cbb36367a429814511edb6ffd","url":"/postgres/postgres/commit/c32704441d47cc1cbb36367a429814511edb6ffd","authoredDate":"2020-01-23T18:20:57.000-05:00","committedDate":"2020-01-23T18:20:57.000-05:00","shortMessage":"Add configure probe for rl_completion_suppress_quote.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add configure probe for rl_completion_suppress_quote.\n\nI had supposed that all versions of Readline that have filename\nquoting hooks also have the rl_completion_suppress_quote variable.\nBut it seems OpenBSD managed to find a version someplace that does\nnot, so we\u0026#39;ll have to expend a separate configure probe for that.\n\n(Light testing suggests that this version also lacks the bugs that\nmake it necessary to frob that variable. Hooray!)\n\nPer buildfarm.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/c32704441d47cc1cbb36367a429814511edb6ffd\"\u003eAdd configure probe for rl_completion_suppress_quote.\u003c/a\u003e","bodyMessageHtml":"I had supposed that all versions of Readline that have filename\nquoting hooks also have the rl_completion_suppress_quote variable.\nBut it seems OpenBSD managed to find a version someplace that does\nnot, so we'll have to expend a separate configure probe for that.\n\n(Light testing suggests that this version also lacks the bugs that\nmake it necessary to frob that variable. Hooray!)\n\nPer buildfarm.","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"9a3a75cb81d3b060b8e76001d04c78ab4ce0dcef","url":"/postgres/postgres/commit/9a3a75cb81d3b060b8e76001d04c78ab4ce0dcef","authoredDate":"2020-01-23T16:15:32.000-05:00","committedDate":"2020-01-23T16:15:32.000-05:00","shortMessage":"Fix an oversight in commit 4c70098ff.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix an oversight in commit 4c70098ff.\n\nI had supposed that the from_char_seq_search() call sites were\nall passing the constant arrays you'd expect them to pass ...\nbut on looking closer, the one for DY format was passing the\ndays[] array not days_short[]. This accidentally worked because\nthe day abbreviations in English are all the same as the first\nthree letters of the full day names. However, once we took out\nthe \u0026quot;maximum comparison length\u0026quot; logic, it stopped working.\n\nAs penance for that oversight, add regression test cases covering\nthis, as well as every other switch case in DCH_from_char() that\nwas not reached according to the code coverage report.\n\nAlso, fold the DCH_RM and DCH_rm cases into one --- now that\nseq_search is case independent, there's no need to pass different\ncomparison arrays for those cases.\n\nBack-patch, as the previous commit was.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/9a3a75cb81d3b060b8e76001d04c78ab4ce0dcef\"\u003eFix an oversight in commit\u003c/a\u003e \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/4c70098ffa8cf19e79e7b124ccac05dd338c937b/hovercard\" href=\"https://github.com/postgres/postgres/commit/4c70098ffa8cf19e79e7b124ccac05dd338c937b\"\u003e\u003ctt\u003e4c70098\u003c/tt\u003e\u003c/a\u003e\u003ca data-pjax=\"true\" title=\"Fix an oversight in commit 4c70098ff.\n\nI had supposed that the from_char_seq_search() call sites were\nall passing the constant arrays you'd expect them to pass ...\nbut on looking closer, the one for DY format was passing the\ndays[] array not days_short[]. This accidentally worked because\nthe day abbreviations in English are all the same as the first\nthree letters of the full day names. However, once we took out\nthe \u0026quot;maximum comparison length\u0026quot; logic, it stopped working.\n\nAs penance for that oversight, add regression test cases covering\nthis, as well as every other switch case in DCH_from_char() that\nwas not reached according to the code coverage report.\n\nAlso, fold the DCH_RM and DCH_rm cases into one --- now that\nseq_search is case independent, there's no need to pass different\ncomparison arrays for those cases.\n\nBack-patch, as the previous commit was.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/9a3a75cb81d3b060b8e76001d04c78ab4ce0dcef\"\u003e.\u003c/a\u003e","bodyMessageHtml":"I had supposed that the from_char_seq_search() call sites were\nall passing the constant arrays you'd expect them to pass ...\nbut on looking closer, the one for DY format was passing the\ndays[] array not days_short[]. This accidentally worked because\nthe day abbreviations in English are all the same as the first\nthree letters of the full day names. However, once we took out\nthe \"maximum comparison length\" logic, it stopped working.\n\nAs penance for that oversight, add regression test cases covering\nthis, as well as every other switch case in DCH_from_char() that\nwas not reached according to the code coverage report.\n\nAlso, fold the DCH_RM and DCH_rm cases into one --- now that\nseq_search is case independent, there's no need to pass different\ncomparison arrays for those cases.\n\nBack-patch, as the previous commit was.","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"4c70098ffa8cf19e79e7b124ccac05dd338c937b","url":"/postgres/postgres/commit/4c70098ffa8cf19e79e7b124ccac05dd338c937b","authoredDate":"2020-01-23T13:42:09.000-05:00","committedDate":"2020-01-23T13:42:09.000-05:00","shortMessage":"Clean up formatting.c's logic for matching constant strings.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Clean up formatting.c\u0026#39;s logic for matching constant strings.\n\nseq_search(), which is used to match input substrings to constants\nsuch as month and day names, had a lot of bizarre and unnecessary\nbehaviors. It was mostly possible to avert our eyes from that before,\nbut we don\u0026#39;t want to duplicate those behaviors in the upcoming patch\nto allow recognition of non-English month and day names. So it\u0026#39;s time\nto clean this up. In particular:\n\n* seq_search scribbled on the input string, which is a pretty dangerous\nthing to do, especially in the badly underdocumented way it was done here.\nFortunately the input string is a temporary copy, but that was being made\nthree subroutine levels away, making it something easy to break\naccidentally. The behavior is externally visible nonetheless, in the form\nof odd case-folding in error reports about unrecognized month/day names.\nThe scribbling is evidently being done to save a few calls to pg_tolower,\nbut that\u0026#39;s such a cheap function (at least for ASCII data) that it\u0026#39;s\npretty pointless to worry about. In HEAD I switched it to be\npg_ascii_tolower to ensure it is cheap in all cases; but there are corner\ncases in Turkish where this\u0026#39;d change behavior, so leave it as pg_tolower\nin the back branches.\n\n* seq_search insisted on knowing the case form (all-upper, all-lower,\nor initcap) of the constant strings, so that it didn\u0026#39;t have to case-fold\nthem to perform case-insensitive comparisons. This likewise seems like\nexcessive micro-optimization, given that pg_tolower is certainly very\ncheap for ASCII data. It seems unsafe to assume that we know the case\nform that will come out of pg_locale.c for localized month/day names, so\nit\u0026#39;s better just to define the comparison rule as \u0026quot;downcase all strings\nbefore comparing\u0026quot;. (The choice between downcasing and upcasing is\narbitrary so far as English is concerned, but it might not be in other\nlocales, so follow citext\u0026#39;s lead here.)\n\n* seq_search also had a parameter that\u0026#39;d cause it to report a match\nafter a maximum number of characters, even if the constant string were\nlonger than that. This was not actually used because no caller passed\na value small enough to cut off a comparison. Replicating that behavior\nfor localized month/day names seems expensive as well as useless, so\nlet\u0026#39;s get rid of that too.\n\n* from_char_seq_search used the maximum-length parameter to truncate\nthe input string in error reports about not finding a matching name.\nThis leads to rather confusing reports in many cases. Worse, it is\noutright dangerous if the input string isn\u0026#39;t all-ASCII, because we\nrisk truncating the string in the middle of a multibyte character.\nThat\u0026#39;d lead either to delivering an illegible error message to the\nclient, or to encoding-conversion failures that obscure the actual\ndata problem. Get rid of that in favor of truncating at whitespace\nif any (a suggestion due to Alvaro Herrera).\n\nIn addition to fixing these things, I const-ified the input string\npointers of DCH_from_char and its subroutines, to make sure there\naren\u0026#39;t any other scribbling-on-input problems.\n\nThe risk of generating a badly-encoded error message seems like\nenough of a bug to justify back-patching, so patch all supported\nbranches.\n\nDiscussion: https://postgr.es/m/29432.1579731087@sss.pgh.pa.us\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/4c70098ffa8cf19e79e7b124ccac05dd338c937b\"\u003eClean up formatting.c's logic for matching constant strings.\u003c/a\u003e","bodyMessageHtml":"seq_search(), which is used to match input substrings to constants\nsuch as month and day names, had a lot of bizarre and unnecessary\nbehaviors. It was mostly possible to avert our eyes from that before,\nbut we don't want to duplicate those behaviors in the upcoming patch\nto allow recognition of non-English month and day names. So it's time\nto clean this up. In particular:\n\n* seq_search scribbled on the input string, which is a pretty dangerous\nthing to do, especially in the badly underdocumented way it was done here.\nFortunately the input string is a temporary copy, but that was being made\nthree subroutine levels away, making it something easy to break\naccidentally. The behavior is externally visible nonetheless, in the form\nof odd case-folding in error reports about unrecognized month/day names.\nThe scribbling is evidently being done to save a few calls to pg_tolower,\nbut that's such a cheap function (at least for ASCII data) that it's\npretty pointless to worry about. In HEAD I switched it to be\npg_ascii_tolower to ensure it is cheap in all cases; but there are corner\ncases in Turkish where this'd change behavior, so leave it as pg_tolower\nin the back branches.\n\n* seq_search insisted on knowing the case form (all-upper, all-lower,\nor initcap) of the constant strings, so that it didn't have to case-fold\nthem to perform case-insensitive comparisons. This likewise seems like\nexcessive micro-optimization, given that pg_tolower is certainly very\ncheap for ASCII data. It seems unsafe to assume that we know the case\nform that will come out of pg_locale.c for localized month/day names, so\nit's better just to define the comparison rule as \"downcase all strings\nbefore comparing\". (The choice between downcasing and upcasing is\narbitrary so far as English is concerned, but it might not be in other\nlocales, so follow citext's lead here.)\n\n* seq_search also had a parameter that'd cause it to report a match\nafter a maximum number of characters, even if the constant string were\nlonger than that. This was not actually used because no caller passed\na value small enough to cut off a comparison. Replicating that behavior\nfor localized month/day names seems expensive as well as useless, so\nlet's get rid of that too.\n\n* from_char_seq_search used the maximum-length parameter to truncate\nthe input string in error reports about not finding a matching name.\nThis leads to rather confusing reports in many cases. Worse, it is\noutright dangerous if the input string isn't all-ASCII, because we\nrisk truncating the string in the middle of a multibyte character.\nThat'd lead either to delivering an illegible error message to the\nclient, or to encoding-conversion failures that obscure the actual\ndata problem. Get rid of that in favor of truncating at whitespace\nif any (a suggestion due to Alvaro Herrera).\n\nIn addition to fixing these things, I const-ified the input string\npointers of DCH_from_char and its subroutines, to make sure there\naren't any other scribbling-on-input problems.\n\nThe risk of generating a badly-encoded error message seems like\nenough of a bug to justify back-patching, so patch all supported\nbranches.\n\nDiscussion: \u003ca href=\"https://postgr.es/m/29432.1579731087@sss.pgh.pa.us\" rel=\"nofollow\"\u003ehttps://postgr.es/m/29432.1579731087@sss.pgh.pa.us\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"cd69ec66c88633c09bc9a984a7f0930e09c7c96e","url":"/postgres/postgres/commit/cd69ec66c88633c09bc9a984a7f0930e09c7c96e","authoredDate":"2020-01-23T11:07:12.000-05:00","committedDate":"2020-01-23T11:07:12.000-05:00","shortMessage":"Improve psql's tab completion for filenames.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Improve psql\u0026#39;s tab completion for filenames.\n\nThe Readline library contains a fair amount of knowledge about how to\ntab-complete filenames, but it turns out that that doesn\u0026#39;t work too well\nunless we follow its expectation that we use its filename quoting hooks\nto quote and de-quote filenames. We were trying to do such quote handling\nwithin complete_from_files(), and that\u0026#39;s still what we have to do if we\u0026#39;re\nusing libedit, which lacks those hooks. But for Readline, it works a lot\nbetter if we tell Readline that single-quote is a quoting character and\nthen provide hooks that know the details of the quoting rules for SQL\nand psql meta-commands.\n\nHence, resurrect the quoting hook functions that existed in the original\nversion of tab-complete.c (and were disabled by commit f6689a328 because\nthey \u0026quot;didn\u0026#39;t work so well yet\u0026quot;), and whack on them until they do seem to\nwork well.\n\nNotably, this fixes bug #16059 from Steven Winfield, who pointed out\nthat the previous coding would strip quote marks from filenames in SQL\nCOPY commands, even though they\u0026#39;re syntactically necessary there.\nNow, we not only don\u0026#39;t do that, but we\u0026#39;ll add a quote mark when you\ntab-complete, even if you didn\u0026#39;t type one.\n\nGetting this to work across a range of libedit versions (and, to a\nlesser extent, libreadline versions) was depressingly difficult.\nIt will be interesting to see whether the new regression test cases\npass everywhere in the buildfarm.\n\nSome future patch might try to handle quoted SQL identifiers with\nsimilar explicit quoting/dequoting logic, but that\u0026#39;s for another day.\n\nPatch by me, reviewed by Peter Eisentraut.\n\nDiscussion: https://postgr.es/m/16059-8836946734c02b84@postgresql.org\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/cd69ec66c88633c09bc9a984a7f0930e09c7c96e\"\u003eImprove psql's tab completion for filenames.\u003c/a\u003e","bodyMessageHtml":"The Readline library contains a fair amount of knowledge about how to\ntab-complete filenames, but it turns out that that doesn't work too well\nunless we follow its expectation that we use its filename quoting hooks\nto quote and de-quote filenames. We were trying to do such quote handling\nwithin complete_from_files(), and that's still what we have to do if we're\nusing libedit, which lacks those hooks. But for Readline, it works a lot\nbetter if we tell Readline that single-quote is a quoting character and\nthen provide hooks that know the details of the quoting rules for SQL\nand psql meta-commands.\n\nHence, resurrect the quoting hook functions that existed in the original\nversion of tab-complete.c (and were disabled by commit \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/f6689a328f07fe579d57c1a419fd8b53db7499c7/hovercard\" href=\"https://github.com/postgres/postgres/commit/f6689a328f07fe579d57c1a419fd8b53db7499c7\"\u003e\u003ctt\u003ef6689a3\u003c/tt\u003e\u003c/a\u003e because\nthey \"didn't work so well yet\"), and whack on them until they do seem to\nwork well.\n\nNotably, this fixes bug #16059 from Steven Winfield, who pointed out\nthat the previous coding would strip quote marks from filenames in SQL\nCOPY commands, even though they're syntactically necessary there.\nNow, we not only don't do that, but we'll add a quote mark when you\ntab-complete, even if you didn't type one.\n\nGetting this to work across a range of libedit versions (and, to a\nlesser extent, libreadline versions) was depressingly difficult.\nIt will be interesting to see whether the new regression test cases\npass everywhere in the buildfarm.\n\nSome future patch might try to handle quoted SQL identifiers with\nsimilar explicit quoting/dequoting logic, but that's for another day.\n\nPatch by me, reviewed by Peter Eisentraut.\n\nDiscussion: \u003ca href=\"https://postgr.es/m/16059-8836946734c02b84@postgresql.org\" rel=\"nofollow\"\u003ehttps://postgr.es/m/16059-8836946734c02b84@postgresql.org\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"5ba40b62318e4d941497333b72d589420a48d82f","url":"/postgres/postgres/commit/5ba40b62318e4d941497333b72d589420a48d82f","authoredDate":"2020-01-23T17:01:46.000+09:00","committedDate":"2020-01-23T17:01:46.000+09:00","shortMessage":"Doc: Fix and tweak documentation for ANALYZE reporting","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Doc: Fix and tweak documentation for ANALYZE reporting\n\nThe docs had some typos and grammar mistakes, and its indentation was\ninconsistent.\n\nAuthor: Amit Langote, Justin Pryzby\nDiscussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/5ba40b62318e4d941497333b72d589420a48d82f\"\u003eDoc: Fix and tweak documentation for ANALYZE reporting\u003c/a\u003e","bodyMessageHtml":"The docs had some typos and grammar mistakes, and its indentation was\ninconsistent.\n\nAuthor: Amit Langote, Justin Pryzby\nDiscussion: \u003ca href=\"https://postgr.es/m/20200116151930.GM26045@telsasoft.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20200116151930.GM26045@telsasoft.com\u003c/a\u003e","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"f942dfb952aaccb0163564c86c0b7654b8512807","url":"/postgres/postgres/commit/f942dfb952aaccb0163564c86c0b7654b8512807","authoredDate":"2020-01-23T15:56:56.000+09:00","committedDate":"2020-01-23T15:56:56.000+09:00","shortMessage":"Clarify some comments in vacuumlazy.c","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Clarify some comments in vacuumlazy.c\n\nAuthor: Justin Pryzby\nDiscussion: https://postgr.es/m/20200113004542.GA26045@telsasoft.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/f942dfb952aaccb0163564c86c0b7654b8512807\"\u003eClarify some comments in vacuumlazy.c\u003c/a\u003e","bodyMessageHtml":"Author: Justin Pryzby\nDiscussion: \u003ca href=\"https://postgr.es/m/20200113004542.GA26045@telsasoft.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20200113004542.GA26045@telsasoft.com\u003c/a\u003e","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 22, 2020","commits":[{"oid":"611ce856f5a862a291a05d148828208e1f4ed46b","url":"/postgres/postgres/commit/611ce856f5a862a291a05d148828208e1f4ed46b","authoredDate":"2020-01-22T18:35:05.000-03:00","committedDate":"2020-01-22T18:37:39.000-03:00","shortMessage":"Add BRIN test case","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add BRIN test case\n\nThis test case was sketched in commit message 4c87010981f3 to explain an\nancient bug; it translates to a coverage increase, so add it to the BRIN\nregression tests.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/611ce856f5a862a291a05d148828208e1f4ed46b\"\u003eAdd BRIN test case\u003c/a\u003e","bodyMessageHtml":"This test case was sketched in commit message \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/4c87010981f3a9a41751e5550f6eb889ab5667e8/hovercard\" href=\"https://github.com/postgres/postgres/commit/4c87010981f3a9a41751e5550f6eb889ab5667e8\"\u003e\u003ctt\u003e4c87010\u003c/tt\u003e\u003c/a\u003e to explain an\nancient bug; it translates to a coverage increase, so add it to the BRIN\nregression tests.","authors":[{"login":"alvherre","displayName":"Alvaro Herrera","avatarUrl":"https://avatars.githubusercontent.com/u/340005?v=4","path":"/alvherre","isGitHub":false}],"committerAttribution":false,"committer":{"login":"alvherre","displayName":"Alvaro Herrera","avatarUrl":"https://avatars.githubusercontent.com/u/340005?v=4","path":"/alvherre","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"41c184bc642b25f67fb1d8ee290f28805fa5a0b4","url":"/postgres/postgres/commit/41c184bc642b25f67fb1d8ee290f28805fa5a0b4","authoredDate":"2020-01-22T11:56:34.000+09:00","committedDate":"2020-01-22T11:56:34.000+09:00","shortMessage":"Add GUC ignore_invalid_pages.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add GUC ignore_invalid_pages.\n\nDetection of WAL records having references to invalid pages\nduring recovery causes PostgreSQL to raise a PANIC-level error,\naborting the recovery. Setting ignore_invalid_pages to on causes\nthe system to ignore those WAL records (but still report a warning),\nand continue recovery. This behavior may cause crashes, data loss,\npropagate or hide corruption, or other serious problems.\nHowever, it may allow you to get past the PANIC-level error,\nto finish the recovery, and to cause the server to start up.\n\nAuthor: Fujii Masao\nReviewed-by: Michael Paquier\nDiscussion: https://www.postgresql.org/message-id/CAHGQGwHCK6f77yeZD4MHOnN+PaTf6XiJfEB+Ce7SksSHjeAWtg@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/41c184bc642b25f67fb1d8ee290f28805fa5a0b4\"\u003eAdd GUC ignore_invalid_pages.\u003c/a\u003e","bodyMessageHtml":"Detection of WAL records having references to invalid pages\nduring recovery causes PostgreSQL to raise a PANIC-level error,\naborting the recovery. Setting ignore_invalid_pages to on causes\nthe system to ignore those WAL records (but still report a warning),\nand continue recovery. This behavior may cause crashes, data loss,\npropagate or hide corruption, or other serious problems.\nHowever, it may allow you to get past the PANIC-level error,\nto finish the recovery, and to cause the server to start up.\n\nAuthor: Fujii Masao\nReviewed-by: Michael Paquier\nDiscussion: \u003ca href=\"https://www.postgresql.org/message-id/CAHGQGwHCK6f77yeZD4MHOnN+PaTf6XiJfEB+Ce7SksSHjeAWtg@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://www.postgresql.org/message-id/CAHGQGwHCK6f77yeZD4MHOnN+PaTf6XiJfEB+Ce7SksSHjeAWtg@mail.gmail.com\u003c/a\u003e","authors":[{"login":"MasaoFujii","displayName":"Fujii Masao","avatarUrl":"https://avatars.githubusercontent.com/u/157553?v=4","path":"/MasaoFujii","isGitHub":false}],"committerAttribution":false,"committer":{"login":"MasaoFujii","displayName":"Fujii Masao","avatarUrl":"https://avatars.githubusercontent.com/u/157553?v=4","path":"/MasaoFujii","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"79a3efb84d09b1e98ad7bb2756fa570efb578d1d","url":"/postgres/postgres/commit/79a3efb84d09b1e98ad7bb2756fa570efb578d1d","authoredDate":"2020-01-22T07:43:51.000+05:30","committedDate":"2020-01-22T07:43:51.000+05:30","shortMessage":"Fix the computation of max dead tuples during the vacuum.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix the computation of max dead tuples during the vacuum.\n\nIn commit 40d964ec99, we changed the way memory is allocated for dead\ntuples but forgot to update the place where we compute the maximum\nnumber of dead tuples. This could lead to invalid memory requests.\n\nReported-by: Andres Freund\nDiagnosed-by: Andres Freund\nAuthor: Masahiko Sawada\nReviewed-by: Amit Kapila and Dilip Kumar\nDiscussion: https://postgr.es/m/20200121060020.e3cr7s7fj5rw4lok@alap3.anarazel.de\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/79a3efb84d09b1e98ad7bb2756fa570efb578d1d\"\u003eFix the computation of max dead tuples during the vacuum.\u003c/a\u003e","bodyMessageHtml":"In commit \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/40d964ec997f64227bc0ff5e058dc4a5770a70a9/hovercard\" href=\"https://github.com/postgres/postgres/commit/40d964ec997f64227bc0ff5e058dc4a5770a70a9\"\u003e\u003ctt\u003e40d964e\u003c/tt\u003e\u003c/a\u003e, we changed the way memory is allocated for dead\ntuples but forgot to update the place where we compute the maximum\nnumber of dead tuples. This could lead to invalid memory requests.\n\nReported-by: Andres Freund\nDiagnosed-by: Andres Freund\nAuthor: Masahiko Sawada\nReviewed-by: Amit Kapila and Dilip Kumar\nDiscussion: \u003ca href=\"https://postgr.es/m/20200121060020.e3cr7s7fj5rw4lok@alap3.anarazel.de\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20200121060020.e3cr7s7fj5rw4lok@alap3.anarazel.de\u003c/a\u003e","authors":[{"login":null,"displayName":"Amit Kapila","avatarUrl":"https://github.githubassets.com/images/gravatars/gravatar-user-420.png","isGitHub":false}],"committerAttribution":false,"committer":{"login":null,"displayName":"Amit Kapila","avatarUrl":"https://github.githubassets.com/images/gravatars/gravatar-user-420.png","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"a904abe2e284f570168839e52e18ef0b7f26179d","url":"/postgres/postgres/commit/a904abe2e284f570168839e52e18ef0b7f26179d","authoredDate":"2020-01-22T09:49:18.000+09:00","committedDate":"2020-01-22T09:49:18.000+09:00","shortMessage":"Fix concurrent indexing operations with temporary tables","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix concurrent indexing operations with temporary tables\n\nAttempting to use CREATE INDEX, DROP INDEX or REINDEX with CONCURRENTLY\non a temporary relation with ON COMMIT actions triggered unexpected\nerrors because those operations use multiple transactions internally to\ncomplete their work. Here is for example one confusing error when using\nON COMMIT DELETE ROWS:\nERROR: index \u0026quot;foo\u0026quot; already contains data\n\nIssues related to temporary relations and concurrent indexing are fixed\nin this commit by enforcing the non-concurrent path to be taken for\ntemporary relations even if using CONCURRENTLY, transparently to the\nuser. Using a non-concurrent path does not matter in practice as locks\ncannot be taken on a temporary relation by a session different than the\none owning the relation, and the non-concurrent operation is more\neffective.\n\nThe problem exists with REINDEX since v12 with the introduction of\nCONCURRENTLY, and with CREATE/DROP INDEX since CONCURRENTLY exists for\nthose commands. In all supported versions, this caused only confusing\nerror messages to be generated. Note that with REINDEX, it was also\npossible to issue a REINDEX CONCURRENTLY for a temporary relation owned\nby a different session, leading to a server crash.\n\nThe idea to enforce transparently the non-concurrent code path for\ntemporary relations comes originally from Andres Freund.\n\nReported-by: Manuel Rigger\nAuthor: Michael Paquier, Heikki Linnakangas\nReviewed-by: Andres Freund, Álvaro Herrera, Heikki Linnakangas\nDiscussion: https://postgr.es/m/CA+u7OA6gP7YAeCguyseusYcc=uR8+ypjCcgDDCTzjQ+k6S9ksQ@mail.gmail.com\nBackpatch-through: 9.4\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/a904abe2e284f570168839e52e18ef0b7f26179d\"\u003eFix concurrent indexing operations with temporary tables\u003c/a\u003e","bodyMessageHtml":"Attempting to use CREATE INDEX, DROP INDEX or REINDEX with CONCURRENTLY\non a temporary relation with ON COMMIT actions triggered unexpected\nerrors because those operations use multiple transactions internally to\ncomplete their work. Here is for example one confusing error when using\nON COMMIT DELETE ROWS:\nERROR: index \"foo\" already contains data\n\nIssues related to temporary relations and concurrent indexing are fixed\nin this commit by enforcing the non-concurrent path to be taken for\ntemporary relations even if using CONCURRENTLY, transparently to the\nuser. Using a non-concurrent path does not matter in practice as locks\ncannot be taken on a temporary relation by a session different than the\none owning the relation, and the non-concurrent operation is more\neffective.\n\nThe problem exists with REINDEX since v12 with the introduction of\nCONCURRENTLY, and with CREATE/DROP INDEX since CONCURRENTLY exists for\nthose commands. In all supported versions, this caused only confusing\nerror messages to be generated. Note that with REINDEX, it was also\npossible to issue a REINDEX CONCURRENTLY for a temporary relation owned\nby a different session, leading to a server crash.\n\nThe idea to enforce transparently the non-concurrent code path for\ntemporary relations comes originally from Andres Freund.\n\nReported-by: Manuel Rigger\nAuthor: Michael Paquier, Heikki Linnakangas\nReviewed-by: Andres Freund, Álvaro Herrera, Heikki Linnakangas\nDiscussion: \u003ca href=\"https://postgr.es/m/CA+u7OA6gP7YAeCguyseusYcc=uR8+ypjCcgDDCTzjQ+k6S9ksQ@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CA+u7OA6gP7YAeCguyseusYcc=uR8+ypjCcgDDCTzjQ+k6S9ksQ@mail.gmail.com\u003c/a\u003e\nBackpatch-through: 9.4","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 21, 2020","commits":[{"oid":"9b9c5f279e8261ab90dc64559911d2578288b7e9","url":"/postgres/postgres/commit/9b9c5f279e8261ab90dc64559911d2578288b7e9","authoredDate":"2020-01-21T16:17:21.000-05:00","committedDate":"2020-01-21T16:17:21.000-05:00","shortMessage":"Clarify behavior of adding and altering a column in same ALTER command.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Clarify behavior of adding and altering a column in same ALTER co 10000 mmand.\n\nThe behavior of something like\n\nALTER TABLE transactions\n ADD COLUMN status varchar(30) DEFAULT \u0026#39;old\u0026#39;,\n ALTER COLUMN status SET default \u0026#39;current\u0026#39;;\n\nis to fill existing table rows with \u0026#39;old\u0026#39;, not \u0026#39;current\u0026#39;. That\u0026#39;s\nintentional and desirable for a couple of reasons:\n\n* It makes the behavior the same whether you merge the sub-commands\ninto one ALTER command or give them separately;\n\n* If we applied the new default while filling the table, there would\nbe no way to get the existing behavior in one SQL command.\n\nThe same reasoning applies in cases that add a column and then\nmanipulate its GENERATED/IDENTITY status in a second sub-command,\nsince the generation expression is really just a kind of default.\nHowever, that wasn\u0026#39;t very obvious (at least not to me; earlier in\nthe referenced discussion thread I\u0026#39;d thought it was a bug to be\nfixed). And it certainly wasn\u0026#39;t documented.\n\nHence, add documentation, code comments, and a test case to clarify\nthat this behavior is all intentional.\n\nIn passing, adjust ATExecAddColumn\u0026#39;s defaults-related relkind check\nso that it matches up exactly with ATRewriteTables, instead of being\neffectively (though not literally) the negated inverse condition.\nThe reasoning can be explained a lot more concisely that way, too\n(not to mention that the comment now matches the code, which it\ndid not before).\n\nDiscussion: https://postgr.es/m/10365.1558909428@sss.pgh.pa.us\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/9b9c5f279e8261ab90dc64559911d2578288b7e9\"\u003eClarify behavior of adding and altering a column in same ALTER command.\u003c/a\u003e","bodyMessageHtml":"The behavior of something like\n\nALTER TABLE transactions\n ADD COLUMN status varchar(30) DEFAULT 'old',\n ALTER COLUMN status SET default 'current';\n\nis to fill existing table rows with 'old', not 'current'. That's\nintentional and desirable for a couple of reasons:\n\n* It makes the behavior the same whether you merge the sub-commands\ninto one ALTER command or give them separately;\n\n* If we applied the new default while filling the table, there would\nbe no way to get the existing behavior in one SQL command.\n\nThe same reasoning applies in cases that add a column and then\nmanipulate its GENERATED/IDENTITY status in a second sub-command,\nsince the generation expression is really just a kind of default.\nHowever, that wasn't very obvious (at least not to me; earlier in\nthe referenced discussion thread I'd thought it was a bug to be\nfixed). And it certainly wasn't documented.\n\nHence, add documentation, code comments, and a test case to clarify\nthat this behavior is all intentional.\n\nIn passing, adjust ATExecAddColumn's defaults-related relkind check\nso that it matches up exactly with ATRewriteTables, instead of being\neffectively (though not literally) the negated inverse condition.\nThe reasoning can be explained a lot more concisely that way, too\n(not to mention that the comment now matches the code, which it\ndid not before).\n\nDiscussion: \u003ca href=\"https://postgr.es/m/10365.1558909428@sss.pgh.pa.us\" rel=\"nofollow\"\u003ehttps://postgr.es/m/10365.1558909428@sss.pgh.pa.us\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"affdde2e15d9df6e9736bbb7e7cd9d56049d2f5a","url":"/postgres/postgres/commit/affdde2e15d9df6e9736bbb7e7cd9d56049d2f5a","authoredDate":"2020-01-20T23:26:51.000-08:00","committedDate":"2020-01-20T23:26:51.000-08:00","shortMessage":"Fix edge case leading to agg transitions skipping ExecAggTransReparent() calls.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix edge case leading to agg transitions skipping ExecAggTransReparent() calls.\n\nThe code checking whether an aggregate transition value needs to be\nreparented into the current context has always only compared the\ntransition return value with the previous transition value by datum,\ni.e. without regard for NULLness. This normally works, because when\nthe transition function returns NULL (via fcinfo-\u0026gt;isnull), it\u0026#39;ll\nreturn a value that won\u0026#39;t be the same as its input value.\n\nBut there\u0026#39;s no hard requirement that that\u0026#39;s the case. And it turns\nout, it\u0026#39;s possible to hit this case (see discussion or reproducers),\nleading to a non-null transition value not being reparented, followed\nby a crash caused by that.\n\nInstead of adding another comparison of NULLness, instead have\nExecAggTransReparent() ensure that pergroup-\u0026gt;transValue ends up as 0\nwhen the new transition value is NULL. That avoids having to add an\nadditional branch to the much more common cases of the transition\nfunction returning the old transition value (which is a pointer in\nthis case), and when the new value is different, but not NULL.\n\nIn branches since 69c3936a149, also deduplicate the reparenting code\nbetween the expression evaluation based transitions, and the path for\nordered aggregates.\n\nReported-By: Teodor Sigaev, Nikita Glukhov\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/bd34e930-cfec-ea9b-3827-a8bc50891393@sigaev.ru\nBackpatch: 9.4-, this issue has existed since at least 7.4\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/affdde2e15d9df6e9736bbb7e7cd9d56049d2f5a\"\u003eFix edge case leading to agg transitions skipping ExecAggTransReparent() calls.\u003c/a\u003e","bodyMessageHtml":"The code checking whether an aggregate transition value needs to be\nreparented into the current context has always only compared the\ntransition return value with the previous transition value by datum,\ni.e. without regard for NULLness. This normally works, because when\nthe transition function returns NULL (via fcinfo-\u0026gt;isnull), it'll\nreturn a value that won't be the same as its input value.\n\nBut there's no hard requirement that that's the case. And it turns\nout, it's possible to hit this case (see discussion or reproducers),\nleading to a non-null transition value not being reparented, followed\nby a crash caused by that.\n\nInstead of adding another comparison of NULLness, instead have\nExecAggTransReparent() ensure that pergroup-\u0026gt;transValue ends up as 0\nwhen the new transition value is NULL. That avoids having to add an\nadditional branch to the much more common cases of the transition\nfunction returning the old transition value (which is a pointer in\nthis case), and when the new value is different, but not NULL.\n\nIn branches since \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/69c3936a1499b772a749ae629fc59b2d72722332/hovercard\" href=\"https://github.com/postgres/postgres/commit/69c3936a1499b772a749ae629fc59b2d72722332\"\u003e\u003ctt\u003e69c3936\u003c/tt\u003e\u003c/a\u003e, also deduplicate the reparenting code\nbetween the expression evaluation based transitions, and the path for\nordered aggregates.\n\nReported-By: Teodor Sigaev, Nikita Glukhov\nAuthor: Andres Freund\nDiscussion: \u003ca href=\"https://postgr.es/m/bd34e930-cfec-ea9b-3827-a8bc50891393@sigaev.ru\" rel=\"nofollow\"\u003ehttps://postgr.es/m/bd34e930-cfec-ea9b-3827-a8bc50891393@sigaev.ru\u003c/a\u003e\nBackpatch: 9.4-, this issue has existed since at least 7.4","authors":[{"login":"anarazel","displayName":"Andres Freund","avatarUrl":"https://avatars.githubusercontent.com/u/1598211?v=4","path":"/anarazel","isGitHub":false}],"committerAttribution":false,"committer":{"login":"anarazel","displayName":"Andres Freund","avatarUrl":"https://avatars.githubusercontent.com/u/1598211?v=4","path":"/anarazel","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"62c9b522311afd791fd92fe46a294f7e21f10540","url":"/postgres/postgres/commit/62c9b522311afd791fd92fe46a294f7e21f10540","authoredDate":"2020-01-21T13:46:39.000+09:00","committedDate":"2020-01-21T13:46:39.000+09:00","shortMessage":"Add GUC variables for stat tracking and timeout as PGDLLIMPORT","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add GUC variables for stat tracking and timeout as PGDLLIMPORT\n\nThis helps integration of extensions with Windows. The following\nparameters are changed:\n- idle_in_transaction_session_timeout (9.6 and newer versions)\n- lock_timeout\n- statement_timeout\n- track_activities\n- track_counts\n- track_functions\n\nAuthor: Pascal Legrand\nReviewed-by: Amit Kamila, Julien Rouhaud, Michael Paquier\nDiscussion: https://postgr.es/m/1579298868581-0.post@n3.nabble.com\nBackpatch-through: 9.4\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/62c9b522311afd791fd92fe46a294f7e21f10540\"\u003eAdd GUC variables for stat tracking and timeout as PGDLLIMPORT\u003c/a\u003e","bodyMessageHtml":"This helps integration of extensions with Windows. The following\nparameters are changed:\n- idle_in_transaction_session_timeout (9.6 and newer versions)\n- lock_timeout\n- statement_timeout\n- track_activities\n- track_counts\n- track_functions\n\nAuthor: Pascal Legrand\nReviewed-by: Amit Kamila, Julien Rouhaud, Michael Paquier\nDiscussion: \u003ca href=\"https://postgr.es/m/1579298868581-0.post@n3.nabble.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/1579298868581-0.post@n3.nabble.com\u003c/a\u003e\nBackpatch-through: 9.4","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 20, 2020","commits":[{"oid":"31f403e95fdf88338d3fc9c6af80fcf6d8241044","url":"/postgres/postgres/commit/31f403e95fdf88338d3fc9c6af80fcf6d8241044","authoredDate":"2020-01-20T14:26:56.000-05:00","committedDate":"2020-01-20T14:26:56.000-05:00","shortMessage":"Further tweaking of jsonb_set_lax().","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Further tweaking of jsonb_set_lax().\n\nSome buildfarm members were still warning about this, because in\n9c679a08f I\u0026#39;d missed decorating one of the ereport() code paths\nwith a dummy return.\n\nAlso, adjust the error messages to be more in line with project\nstyle guide.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/31f403e95fdf88338d3fc9c6af80fcf6d8241044\"\u003eFurther tweaking of jsonb_set_lax().\u003c/a\u003e","bodyMessageHtml":"Some buildfarm members were still warning about this, because in\n\u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/9c679a08f0cdedcf7f084daea3cba6ae9c3cbced/hovercard\" href=\"https://github.com/postgres/postgres/commit/9c679a08f0cdedcf7f084daea3cba6ae9c3cbced\"\u003e\u003ctt\u003e9c679a0\u003c/tt\u003e\u003c/a\u003e I'd missed decorating one of the ereport() code paths\nwith a dummy return.\n\nAlso, adjust the error messages to be more in line with project\nstyle guide.","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"cd23a2019c4b8da47905e91c8a841cadac978a32","url":"/postgres/postgres/commit/cd23a2019c4b8da47905e91c8a841cadac978a32","authoredDate":"2020-01-20T12:57:17.000-05:00","committedDate":"2020-01-20T12:57:17.000-05:00","shortMessage":"Fix pg_dump's sigTermHandler() to use _exit() not exit().","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix pg_dump\u0026#39;s sigTermHandler() to use _exit() not exit().\n\nsigTermHandler() tried to be careful to invoke only operations that\nare safe to do in a signal handler. But for some reason we forgot\nthat exit(3) is not among those, because it calls atexit handlers\nthat might do various random things. (pg_dump itself installs no\natexit handlers, but e.g. OpenSSL does.) That led to crashes or\nlockups when attempting to terminate a parallel dump or restore\nvia a signal.\n\nFix by calling _exit() instead.\n\nPer bug #16199 from Raúl Marín. Back-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/16199-cb2f121146a96f9b@postgresql.org\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/cd23a2019c4b8da47905e91c8a841cadac978a32\"\u003eFix pg_dump's sigTermHandler() to use _exit() not exit().\u003c/a\u003e","bodyMessageHtml":"sigTermHandler() tried to be careful to invoke only operations that\nare safe to do in a signal handler. But for some reason we forgot\nthat exit(3) is not among those, because it calls atexit handlers\nthat might do various random things. (pg_dump itself installs no\natexit handlers, but e.g. OpenSSL does.) That led to crashes or\nlockups when attempting to terminate a parallel dump or restore\nvia a signal.\n\nFix by calling _exit() instead.\n\nPer bug #16199 from Raúl Marín. Back-patch to all supported branches.\n\nDiscussion: \u003ca href=\"https://postgr.es/m/16199-cb2f121146a96f9b@postgresql.org\" rel=\"nofollow\"\u003ehttps://postgr.es/m/16199-cb2f121146a96f9b@postgresql.org\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"4c87010981f3a9a41751e5550f6eb889ab5667e8","url":"/postgres/postgres/commit/4c87010981f3a9a41751e5550f6eb889ab5667e8","authoredDate":"2020-01-20T10:36:35.000+02:00","committedDate":"2020-01-20T10:36:35.000+02:00","shortMessage":"Fix crash in BRIN inclusion op functions, due to missing datum copy.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix crash in BRIN inclusion op functions, due to missing datum copy.\n\nThe BRIN add_value() and union() functions need to make a longer-lived\ncopy of the argument, if they want to store it in the BrinValues struct\nalso passed as argument. The functions for the \u0026quot;inclusion operator\nclasses\u0026quot; used with box, range and inet types didn\u0026#39;t take into account\nthat the union helper function might return its argument as is, without\nmaking a copy. Check for that case, and make a copy if necessary. That\ncase arises at least with the range_union() function, when one of the\narguments is an \u0026#39;empty\u0026#39; range:\n\nCREATE TABLE brintest (n numrange);\nCREATE INDEX brinidx ON brintest USING brin (n);\nINSERT INTO brintest VALUES (\u0026#39;empty\u0026#39;);\nINSERT INTO brintest VALUES (numrange(0, 2^1000::numeric));\nINSERT INTO brintest VALUES (\u0026#39;(-1, 0)\u0026#39;);\n\nSELECT brin_desummarize_range(\u0026#39;brinidx\u0026#39;, 0);\nSELECT brin_summarize_range(\u0026#39;brinidx\u0026#39;, 0);\n\nBackpatch down to 9.5, where BRIN was introduced.\n\nDiscussion: https://www.postgresql.org/message-id/e6e1d6eb-0a67-36aa-e779-bcca59167c14%40iki.fi\nReviewed-by: Emre Hasegeli, Tom Lane, Alvaro Herrera\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/4c87010981f3a9a41751e5550f6eb889ab5667e8\"\u003eFix crash in BRIN inclusion op functions, due to missing datum copy.\u003c/a\u003e","bodyMessageHtml":"The BRIN add_value() and union() functions need to make a longer-lived\ncopy of the argument, if they want to store it in the BrinValues struct\nalso passed as argument. The functions for the \"inclusion operator\nclasses\" used with box, range and inet types didn't take into account\nthat the union helper function might return its argument as is, without\nmaking a copy. Check for that case, and make a copy if necessary. That\ncase arises at least with the range_union() function, when one of the\narguments is an 'empty' range:\n\nCREATE TABLE brintest (n numrange);\nCREATE INDEX brinidx ON brintest USING brin (n);\nINSERT INTO brintest VALUES ('empty');\nINSERT INTO brintest VALUES (numrange(0, 2^1000::numeric));\nINSERT INTO brintest VALUES ('(-1, 0)');\n\nSELECT brin_desummarize_range('brinidx', 0);\nSELECT brin_summarize_range('brinidx', 0);\n\nBackpatch down to 9.5, where BRIN was introduced.\n\nDiscussion: \u003ca href=\"https://www.postgresql.org/message-id/e6e1d6eb-0a67-36aa-e779-bcca59167c14%40iki.fi\" rel=\"nofollow\"\u003ehttps://www.postgresql.org/message-id/e6e1d6eb-0a67-36aa-e779-bcca59167c14%40iki.fi\u003c/a\u003e\nReviewed-by: Emre Hasegeli, Tom Lane, Alvaro Herrera","authors":[{"login":"hlinnaka","displayName":"Heikki Linnakangas","avatarUrl":"https://avatars.githubusercontent.com/u/191602?v=4","path":"/hlinnaka","isGitHub":false}],"committerAttribution":false,"committer":{"login":"hlinnaka","displayName":"Heikki Linnakangas","avatarUrl":"https://avatars.githubusercontent.com/u/191602?v=4","path":"/hlinnaka","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"40d964ec997f64227bc0ff5e058dc4a5770a70a9","url":"/postgres/postgres/commit/40d964ec997f64227bc0ff5e058dc4a5770a70a9","authoredDate":"2020-01-20T07:57:49.000+05:30","committedDate":"2020-01-20T07:57:49.000+05:30","shortMessage":"Allow vacuum command to process indexes in parallel.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Allow vacuum command to process indexes in parallel.\n\nThis feature allows the vacuum to leverage multiple CPUs in order to\nprocess indexes. This enables us to perform index vacuuming and index\ncleanup with background workers. This adds a PARALLEL option to VACUUM\ncommand where the user can specify the number of workers that can be used\nto perform the command which is limited by the number of indexes on a\ntable. Specifying zero as a number of workers will disable parallelism.\nThis option can\u0026#39;t be used with the FULL option.\n\nEach index is processed by at most one vacuum process. Therefore parallel\nvacuum can be used when the table has at least two indexes.\n\nThe parallel degree is either specified by the user or determined based on\nthe number of indexes that the table has, and further limited by\nmax_parallel_maintenance_workers. The index can participate in parallel\nvacuum iff it\u0026#39;s size is greater than min_parallel_index_scan_size.\n\nAuthor: Masahiko Sawada and Amit Kapila\nReviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra,\nMahendra Singh and Sergei Kornilov\nTested-by: Mahendra Singh and Prabhat Sahu\nDiscussion:\nhttps://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com\nhttps://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/40d964ec997f64227bc0ff5e058dc4a5770a70a9\"\u003eAllow vacuum command to process indexes in parallel.\u003c/a\u003e","bodyMessageHtml":"This feature allows the vacuum to leverage multiple CPUs in order to\nprocess indexes. This enables us to perform index vacuuming and index\ncleanup with background workers. This adds a PARALLEL option to VACUUM\ncommand where the user can specify the number of workers that can be used\nto perform the command which is limited by the number of indexes on a\ntable. Specifying zero as a number of workers will disable parallelism.\nThis option can't be used with the FULL option.\n\nEach index is processed by at most one vacuum process. Therefore parallel\nvacuum can be used when the table has at least two indexes.\n\nThe parallel degree is either specified by the user or determined based on\nthe number of indexes that the table has, and further limited by\nmax_parallel_maintenance_workers. The index can participate in parallel\nvacuum iff it's size is greater than min_parallel_index_scan_size.\n\nAuthor: Masahiko Sawada and Amit Kapila\nReviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra,\nMahendra Singh and Sergei Kornilov\nTested-by: Mahendra Singh and Prabhat Sahu\nDiscussion:\n\u003ca href=\"https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com\u003c/a\u003e\n\u003ca href=\"https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com\u003c/a\u003e","authors":[{"login":null,"displayName":"Amit Kapila","avatarUrl":"https://github.githubassets.com/images/gravatars/gravatar-user-420.png","isGitHub":false}],"committerAttribution":false,"committer":{"login":null,"displayName":"Amit Kapila","avatarUrl":"https://github.githubassets.com/images/gravatars/gravatar-user-420.png","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"44f1fc8df5dadbc5e80661660903aab4076d868f","url":"/postgres/postgres/commit/44f1fc8df5dadbc5e80661660903aab4076d868f","authoredDate":"2020-01-19T19:15:15.000-05:00","committedDate":"2020-01-19T19:15:15.000-05:00","shortMessage":"Fix out-of-memory handling in ecpglib.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Fix out-of-memory handling in ecpglib.\n\necpg_build_params() would crash on a null pointer dereference if\nrealloc() failed, due to updating the persistent \u0026quot;stmt\u0026quot; struct\ntoo aggressively. (Even without the crash, this would\u0026#39;ve leaked\nthe old storage that we were trying to realloc.)\n\nPer Coverity. This seems to have been broken in commit 0cc050794,\nso back-patch into v12.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/44f1fc8df5dadbc5e80661660903aab4076d868f\"\u003eFix out-of-memory handling in ecpglib.\u003c/a\u003e","bodyMessageHtml":"ecpg_build_params() would crash on a null pointer dereference if\nrealloc() failed, due to updating the persistent \"stmt\" struct\ntoo aggressively. (Even without the crash, this would've leaked\nthe old storage that we were trying to realloc.)\n\nPer Coverity. This seems to have been broken in commit \u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/0cc0507940c1cf4153fc25c8f6f4f75adada86d0/hovercard\" href=\"https://github.com/postgres/postgres/commit/0cc0507940c1cf4153fc25c8f6f4f75adada86d0\"\u003e\u003ctt\u003e0cc0507\u003c/tt\u003e\u003c/a\u003e,\nso back-patch into v12.","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 19, 2020","commits":[{"oid":"9c679a08f0cdedcf7f084daea3cba6ae9c3cbced","url":"/postgres/postgres/commit/9c679a08f0cdedcf7f084daea3cba6ae9c3cbced","authoredDate":"2020-01-19T16:04:36.000-05:00","committedDate":"2020-01-19T16:04:36.000-05:00","shortMessage":"Silence minor compiler warnings.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Silence minor compiler warnings.\n\nEnsure that ClassifyUtilityCommandAsReadOnly() has defined behavior\neven if TransactionStmt.kind has a value that\u0026#39;s not one of the\ndeclared values for its enum.\n\nSuppress warnings from compilers that don\u0026#39;t know that elog(ERROR)\ndoesn\u0026#39;t return, in ClassifyUtilityCommandAsReadOnly() and\njsonb_set_lax().\n\nPer Coverity and buildfarm.\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/9c679a08f0cdedcf7f084daea3cba6ae9c3cbced\"\u003eSilence minor compiler warnings.\u003c/a\u003e","bodyMessageHtml":"Ensure that ClassifyUtilityCommandAsReadOnly() has defined behavior\neven if TransactionStmt.kind has a value that's not one of the\ndeclared values for its enum.\n\nSuppress warnings from compilers that don't know that elog(ERROR)\ndoesn't return, in ClassifyUtilityCommandAsReadOnly() and\njsonb_set_lax().\n\nPer Coverity and buildfarm.","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"7aaefadaac6452b2e813fae4ea531cb12d022531","url":"/postgres/postgres/commit/7aaefadaac6452b2e813fae4ea531cb12d022531","authoredDate":"2020-01-19T13:54:58.000+02:00","committedDate":"2020-01-19T13:54:58.000+02:00","shortMessage":"Remove separate files for the initial contents of pg_(sh)description","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Remove separate files for the initial contents of pg_(sh)description\n\nThis data was only in separate files because it was the most convenient\nway to handle it with a shell script. Now that we use a general-purpose\nprogramming language, it\u0026#39;s easy to assemble the data into the same format\nas the rest of the catalogs and output it into postgres.bki. This allows\nremoval of some special-purpose code from initdb.c.\n\nDiscussion: https://www.postgresql.org/message-id/CACPNZCtVFtjHre6hg9dput0qRPp39pzuyA2A6BT8wdgrRy%2BQdA%40mail.gmail.com\nAuthor: John Naylor\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/7aaefadaac6452b2e813fae4ea531cb12d022531\"\u003eRemove separate files for the initial contents of pg_(sh)description\u003c/a\u003e","bodyMessageHtml":"This data was only in separate files because it was the most convenient\nway to handle it with a shell script. Now that we use a general-purpose\nprogramming language, it's easy to assemble the data into the same format\nas the rest of the catalogs and output it into postgres.bki. This allows\nremoval of some special-purpose code from initdb.c.\n\nDiscussion: \u003ca href=\"https://www.postgresql.org/message-id/CACPNZCtVFtjHre6hg9dput0qRPp39pzuyA2A6BT8wdgrRy%2BQdA%40mail.gmail.com\" rel=\"nofollow\"\u003ehttps://www.postgresql.org/message-id/CACPNZCtVFtjHre6hg9dput0qRPp39pzuyA2A6BT8wdgrRy%2BQdA%40mail.gmail.com\u003c/a\u003e\nAuthor: John Naylor","authors":[{"login":"hlinnaka","displayName":"Heikki Linnakangas","avatarUrl":"https://avatars.githubusercontent.com/u/191602?v=4","path":"/hlinnaka","isGitHub":false}],"committerAttribution":false,"committer":{"login":"hlinnaka","displayName":"Heikki Linnakangas","avatarUrl":"https://avatars.githubusercontent.com/u/191602?v=4","path":"/hlinnaka","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"e0ed6817c0ee218a3681920807404603e042ff04","url":"/postgres/postgres/commit/e0ed6817c0ee218a3681920807404603e042ff04","authoredDate":"2020-01-19T18:55:51.000+09:00","committedDate":"2020-01-19T18:55:51.000+09:00","shortMessage":"Doc: Improve description of connection strings with Percent-encoding","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Doc: Improve description of connection strings with Percent-encoding\n\nClarify the description related to the use of characters which can be\nencoded, and add an example.\n\nAuthor: Jobin Augustine\nReviewed-by: Peter Eisentraut, Alvaro Herrera, Heikki Linnakangas,\nMichael Paquier, Alex Shulgin\nDiscussion: https://postgr.es/m/CANaTPsrYgSgE2fuj3=4x=Jmx1c+NgkEDzftNknZbrMuqL+aBhQ@mail.gmail.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/e0ed6817c0ee218a3681920807404603e042ff04\"\u003eDoc: Improve description of connection strings with Percent-encoding\u003c/a\u003e","bodyMessageHtml":"Clarify the description related to the use of characters which can be\nencoded, and add an example.\n\nAuthor: Jobin Augustine\nReviewed-by: Peter Eisentraut, Alvaro Herrera, Heikki Linnakangas,\nMichael Paquier, Alex Shulgin\nDiscussion: \u003ca href=\"https://postgr.es/m/CANaTPsrYgSgE2fuj3=4x=Jmx1c+NgkEDzftNknZbrMuqL+aBhQ@mail.gmail.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/CANaTPsrYgSgE2fuj3=4x=Jmx1c+NgkEDzftNknZbrMuqL+aBhQ@mail.gmail.com\u003c/a\u003e","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate":null}]},{"title":"Jan 18, 2020","commits":[{"oid":"34a0a81bfb388504deaa51b16a8bb531b827e519","url":"/postgres/postgres/commit/34a0a81bfb388504deaa51b16a8bb531b827e519","authoredDate":"2020-01-18T17:51:03.000-05:00","committedDate":"2020-01-18T17:51:17.000-05:00","shortMessage":"Doc: rearrange the documentation of binary-string functions.","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Doc: rearrange the documentation of binary-string functions.\n\nRather than intermixing the discussion of text-string and binary-string\nfunctions, make a clean break, moving all discussion of binary-string\noperations into section 9.5. This involves some duplication of\nfunction descriptions between 9.4 and 9.5, but it seems cleaner on the\nwhole since the individual descriptions are clearer (and on the other\nside of the coin, it gets rid of some duplicated descriptions, too).\n\nMove the convert*/encode/decode functions to a separate table, because\nthey don\u0026#39;t quite seem to fit under the heading of \u0026quot;binary string\nfunctions\u0026quot;.\n\nAlso provide full documentation of the textual formats supported by\nencode() and decode() (which was the original goal of this patch\nseries, many moons ago).\n\nAlso move the table of built-in encoding conversions out of section 9.4,\nwhere it no longer had any relevance whatsoever, and put it into section\n23.3 about character sets. I chose to put both that and table 23.2\n(multibyte-translation-table) into a new \u0026lt;sect2\u0026gt; so as not to break up\nthe flow of discussion in 23.3.3.\n\nAlso do a bunch of minor copy-editing on the function descriptions\nin 9.4 and 9.5.\n\nKarl Pinc, reviewed by Fabien Coelho, further hacking by me\n\nDiscussion: https://postgr.es/m/20190304163347.7bca4897@slate.meme.com\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/34a0a81bfb388504deaa51b16a8bb531b827e519\"\u003eDoc: rearrange the documentation of binary-string functions.\u003c/a\u003e","bodyMessageHtml":"Rather than intermixing the discussion of text-string and binary-string\nfunctions, make a clean break, moving all discussion of binary-string\noperations into section 9.5. This involves some duplication of\nfunction descriptions between 9.4 and 9.5, but it seems cleaner on the\nwhole since the individual descriptions are clearer (and on the other\nside of the coin, it gets rid of some duplicated descriptions, too).\n\nMove the convert*/encode/decode functions to a separate table, because\nthey don't quite seem to fit under the heading of \"binary string\nfunctions\".\n\nAlso provide full documentation of the textual formats supported by\nencode() and decode() (which was the original goal of this patch\nseries, many moons ago).\n\nAlso move the table of built-in encoding conversions out of section 9.4,\nwhere it no longer had any relevance whatsoever, and put it into section\n23.3 about character sets. I chose to put both that and table 23.2\n(multibyte-translation-table) into a new \u0026lt;sect2\u0026gt; so as not to break up\nthe flow of discussion in 23.3.3.\n\nAlso do a bunch of minor copy-editing on the function descriptions\nin 9.4 and 9.5.\n\nKarl Pinc, reviewed by Fabien Coelho, further hacking by me\n\nDiscussion: \u003ca href=\"https://postgr.es/m/20190304163347.7bca4897@slate.meme.com\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20190304163347.7bca4897@slate.meme.com\u003c/a\u003e","authors":[{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false}],"committerAttribution":false,"committer":{"login":"tglsfdc","displayName":"Tom Lane","avatarUrl":"https://avatars.githubusercontent.com/u/8755309?v=4","path":"/tglsfdc","isGitHub":false},"pusher":null,"pushedDate":null},{"oid":"41aadeeb124ee5f8e7d154a16a74d53286882b74","url":"/postgres/postgres/commit/41aadeeb124ee5f8e7d154a16a74d53286882b74","authoredDate":"2020-01-18T12:32:43.000+09:00","committedDate":"2020-01-18T12:32:43.000+09:00","shortMessage":"Add GUC checks for ssl_min_protocol_version and ssl_max_protocol_version","shortMessageMarkdown":null,"shortMessageMarkdownLink":"\u003ca data-pjax=\"true\" title=\"Add GUC checks for ssl_min_protocol_version and ssl_max_protocol_version\n\nMixing incorrect bounds set in the SSL context leads to confusing error\nmessages generated by OpenSSL which are hard to act on. New checks are\nadded within the GUC machinery to improve the user experience as they\napply to any SSL implementation, not only OpenSSL, and doing the checks\nbeforehand avoids the creation of a SSL during a reload (or startup)\nwhich we know will never be used anyway.\n\nBackpatch down to 12, as those parameters have been introduced by\ne73e67c.\n\nAuthor: Michael Paquier\nReviewed-by: Daniel Gustafsson\nDiscussion: https://postgr.es/m/20200114035420.GE1515@paquier.xyz\nBackpatch-through: 12\" class=\"color-fg-default\" href=\"/postgres/postgres/commit/41aadeeb124ee5f8e7d154a16a74d53286882b74\"\u003eAdd GUC checks for ssl_min_protocol_version and ssl_max_protocol_version\u003c/a\u003e","bodyMessageHtml":"Mixing incorrect bounds set in the SSL context leads to confusing error\nmessages generated by OpenSSL which are hard to act on. New checks are\nadded within the GUC machinery to improve the user experience as they\napply to any SSL implementation, not only OpenSSL, and doing the checks\nbeforehand avoids the creation of a SSL during a reload (or startup)\nwhich we know will never be used anyway.\n\nBackpatch down to 12, as those parameters have been introduced by\n\u003ca class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/postgres/postgres/commit/e73e67c719593c1c16139cc6c516d8379f22f182/hovercard\" href=\"https://github.com/postgres/postgres/commit/e73e67c719593c1c16139cc6c516d8379f22f182\"\u003e\u003ctt\u003ee73e67c\u003c/tt\u003e\u003c/a\u003e.\n\nAuthor: Michael Paquier\nReviewed-by: Daniel Gustafsson\nDiscussion: \u003ca href=\"https://postgr.es/m/20200114035420.GE1515@paquier.xyz\" rel=\"nofollow\"\u003ehttps://postgr.es/m/20200114035420.GE1515@paquier.xyz\u003c/a\u003e\nBackpatch-through: 12","authors":[{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false}],"committerAttribution":false,"committer":{"login":"michaelpq","displayName":"Michael Paquier","avatarUrl":"https://avatars.githubusercontent.com/u/985332?v=4","path":"/michaelpq","isGitHub":false},"pusher":null,"pushedDate":null}]}],"currentCommit":{"oid":"f37ff03478aefb5e01d748b85ad86e6213624992"},"filters":{"since":null,"until":null,"author":null,"newPath":null,"originalBranch":null,"currentBlobPath":null,"pagination":{"startCursor":"f37ff03478aefb5e01d748b85ad86e6213624992 0","endCursor":"f37ff03478aefb5e01d748b85ad86e6213624992 34","hasNextPage":true,"hasPreviousPage":false}},"metadata":{"browsingRenameHistory":null,"showProfileHelp":false,"deferredDataUrl":"/postgres/postgres/commits/deferred_commit_data/f37ff03478aefb5e01d748b85ad86e6213624992?original_branch=f37ff03478aefb5e01d748b85ad86e6213624992","deferredContributorUrl":"/postgres/postgres/commits/deferred_commit_contributors","softNavToCommit":true},"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":"f37ff03478aefb5e01d748b85ad86e6213624992","listCacheKey":"v0:1752611535.0","refType":"tree","currentOid":"f37ff03478aefb5e01d748b85ad86e6213624992"},"timedOutMessage":""},"title":"Commits · postgres/postgres","appPayload":{"helpUrl":"https://docs.github.com"}}

Commits

Branch selector

User selector

Datepicker

Commit History

Commits on Jan 26, 2020

Commits on Jan 25, 2020

Commits on Jan 24, 2020

Commits on Jan 23, 2020

Commits on Jan 22, 2020

Commits on Jan 21, 2020

Commits on Jan 20, 2020

Commits on Jan 19, 2020

Commits on Jan 18, 2020

Pagination
0