{"push_id":2427672573,"size":85,"distinct_size":85,"ref":"refs/heads/pqhost_fix","head":"000c74ff83bbc2486e49468bd2272710f3dfdab9","before":"4997fd576f3be7f7a696b9c551c593a02ed0a9b4","commits":[{"sha":"877cdf11eaa9cabcb9b1e3c1bef0760fe08efdc3","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Mop-up for letting VOID-returning SQL functions end with a SELECT.\n\nPart of the intent in commit fd1a421fe was to allow SQL functions that are\ndeclared to return VOID to contain anything, including an unrelated final\nSELECT, the same as SQL-language procedures can.  However, the planner's\ninlining logic didn't get that memo.  Fix it, and add some regression tests\ncovering this area, since evidently we had none.\n\nIn passing, clean up some typos in comments in create_function_3.sql,\nand get rid of its none-too-safe assumption that DROP CASCADE notice\noutput is immutably ordered.\n\nPer report from Prabhat Sahu.\n\nDiscussion: https://postgr.es/m/CANEvxPqxAj6nNHVcaXxpTeEFPmh24Whu+23emgjiuKrhJSct0A@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/877cdf11eaa9cabcb9b1e3c1bef0760fe08efdc3"},{"sha":"8d47a908626bf0800dc6a01f4ff2b2bc15cdaf86","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Update function comments\n\nAfter a6542a4b6870a019cd952d055d2e7af2da2fe102, some function comments\nwere misplaced.  Fix that.\n\nReviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/8d47a908626bf0800dc6a01f4ff2b2bc15cdaf86"},{"sha":"04700b685f31508036456bea4d92533e5ceee9d6","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Rename TransactionChain functions\n\nWe call this thing a \"transaction block\" everywhere except in a few\nfunctions, where it is mysteriously called a \"transaction chain\".  In\nthe SQL standard, a transaction chain is something different.  So rename\nthese functions to match the common terminology.\n\nReviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/04700b685f31508036456bea4d92533e5ceee9d6"},{"sha":"ec87efde8dbc670467468860c5d577dc805dae5e","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Simplify parse representation of savepoint commands\n\nInstead of embedding the savepoint name in a list and then requiring\ncomplex code to unpack it, just add another struct field to store it\ndirectly.\n\nReviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/ec87efde8dbc670467468860c5d577dc805dae5e"},{"sha":"81148856b0310e7b0e578508ace44c0aefcbee07","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Improve savepoint error messages\n\nInclude the savepoint name in the error message and rephrase it a bit to\nmatch common style.\n\nReviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/81148856b0310e7b0e578508ace44c0aefcbee07"},{"sha":"4120864b9e0a2a119786a1839d7c0988d0523ec0","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Change transaction state debug strings to match enum symbols\n\nIn some cases, these were different for no apparent reason, making\ndebugging unnecessarily mysterious.\n\nReviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/4120864b9e0a2a119786a1839d7c0988d0523ec0"},{"sha":"013c0baaddd9df7e1f940184a8ab8e478214b46c","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Doc: explicitly point out that enum values can't be dropped.\n\nThis was not stated in so many words anywhere.  Document it to make\nclear that it's a design limitation and not just an oversight or\ndocumentation omission.\n\nDiscussion: https://postgr.es/m/152089733343.1222.6927268289645380498@wrigleys.postgresql.org","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/013c0baaddd9df7e1f940184a8ab8e478214b46c"},{"sha":"9e17bdb8a525ff89c4535cd153dc0f2fa813ea59","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix query-lifespan memory leakage in repeatedly executed hash joins.\n\nExecHashTableCreate allocated some memory that wasn't freed by\nExecHashTableDestroy, specifically the per-hash-key function information.\nThat's not a huge amount of data, but if one runs a query that repeats\na hash join enough times, it builds up.  Fix by arranging for the data\nin question to be kept in the hashtable's hashCxt instead of leaving it\n\"loose\" in the query-lifespan executor context.  (This ensures that we'll\nalso clean up anything that the hash functions allocate in fn_mcxt.)\n\nPer report from Amit Khandekar.  It's been like this forever, so back-patch\nto all supported branches.\n\nDiscussion: https://postgr.es/m/CAJ3gD9cFofAWGvcxLOxDHC=B0hjtW8yGmUsF2hdGh97CM38=7g@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/9e17bdb8a525ff89c4535cd153dc0f2fa813ea59"},{"sha":"f3e4b95edb6cbf0cd41dc9ff0c884bfdc425e6fb","author":{"name":"Andres Freund","email":"c6cbfe878b4ee67646e7630734db67f536518d54@anarazel.de"},"message":"Make ExplainPropertyInteger accept 64bit input, remove *Long variant.\n\n'long' is not useful type across platforms, as it's 32bit on 32 bit\nplatforms, and even on some 64bit platforms (e.g. windows) it's still\nonly 32bits wide.\n\nAs ExplainPropertyInteger should never be performance critical, change\nit to accept a 64bit argument and remove ExplainPropertyLong.\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/20180314164832.n56wt7zcbpzi6zxe@alap3.anarazel.de","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/f3e4b95edb6cbf0cd41dc9ff0c884bfdc425e6fb"},{"sha":"7a50bb690b4837d29e715293c156cff2fc72885c","author":{"name":"Andres Freund","email":"c6cbfe878b4ee67646e7630734db67f536518d54@anarazel.de"},"message":"Add 'unit' parameter to ExplainProperty{Integer,Float}.\n\nThis allows to deduplicate some existing code, but mainly avoids some\nduplication in upcoming commits.\n\nIn passing, fix variable names indicating wrong unit (seconds instead\nof ms).\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/20180314002740.cah3mdsonz5mxney@alap3.anarazel.de","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/7a50bb690b4837d29e715293c156cff2fc72885c"},{"sha":"8a3d9425290ff5f6434990349886afae9e1c6008","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add ssl_passphrase_command setting\n\nThis allows specifying an external command for prompting for or\notherwise obtaining passphrases for SSL key files.  This is useful\nbecause in many cases there is no TTY easily available during service\nstartup.\n\nAlso add a setting ssl_passphrase_command_supports_reload, which allows\nsupporting SSL configuration reload even if SSL files need passphrases.\n\nReviewed-by: Daniel Gustafsson <daniel@yesql.se>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/8a3d9425290ff5f6434990349886afae9e1c6008"},{"sha":"e3bdb2d92600ed45bd46aaf48309a436a9628218","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Set libpq sslcompression to off by default\n\nSince SSL compression is no longer recommended, turn the default in\nlibpq from on to off.\n\nOpenSSL 1.1.0 and many distribution packages already turn compression\noff by default, so such a server won't accept compression anyway.  So\nthis will mainly affect users of older OpenSSL installations.\n\nAlso update the documentation to make clear that this setting is no\nlonger recommended.\n\nDiscussion: https://www.postgresql.org/message-id/flat/595cf3b1-4ffe-7f05-6f72-f72b7afa7993%402ndquadrant.com","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/e3bdb2d92600ed45bd46aaf48309a436a9628218"},{"sha":"e400840b1d92cb6a654c30a6aca68ba31eb8afbb","author":{"name":"Michael Meskes","email":"96a4f1ffa8d723ec3cfd43f587d79ea50a197a55@postgresql.org"},"message":"Fix closing of incorrectly named cursor.\n\nPatch by \"Shinoda, Noriyoshi\" <noriyoshi.shinoda@hpe.com>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/e400840b1d92cb6a654c30a6aca68ba31eb8afbb"},{"sha":"8f5ac440430ab1d4b0309a76df278caa87018beb","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix WHERE CURRENT OF when the referenced cursor uses an index-only scan.\n\n\"UPDATE/DELETE WHERE CURRENT OF cursor_name\" failed, with an error message\nlike \"cannot extract system attribute from virtual tuple\", if the cursor\nwas using a index-only scan for the target table.  Fix it by digging the\ncurrent TID out of the indexscan state.\n\nIt seems likely that the same failure could occur for CustomScan plans\nand perhaps some FDW plan types, so that leaving this to be treated as an\ninternal error with an obscure message isn't as good an idea as it first\nseemed.  Hence, add a bit of heaptuple.c infrastructure to let us deliver\na more on-topic message.  I chose to make the message match what you get\nfor the case where execCurrentOf can't identify the target scan node at\nall, \"cursor \"foo\" is not a simply updatable scan of table \"bar\"\".\nPerhaps it should be different, but we can always adjust that later.\n\nIn the future, it might be nice to provide hooks that would let custom\nscan providers and/or FDWs deal with this in other ways; but that's\nnot a suitable topic for a back-patchable bug fix.\n\nIt's been like this all along, so back-patch to all supported branches.\n\nYugo Nagata and Tom Lane\n\nDiscussion: https://postgr.es/m/20180201013349.937dfc5f.nagata@sraoss.co.jp","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/8f5ac440430ab1d4b0309a76df278caa87018beb"},{"sha":"2dbee9f19f6c6ac6c013f668611492486e623807","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix overflow handling in plpgsql's integer FOR loops.\n\nThe test to exit the loop if the integer control value would overflow\nan int32 turns out not to work on some ICC versions, as it's dependent\non the assumption that the compiler will execute the code as written\nrather than \"optimize\" it.  ICC lacks any equivalent of gcc's -fwrapv\nswitch, so it was optimizing on the assumption of no integer overflow,\nand that breaks this.  Rewrite into a form that in fact does not\ndo any overflowing computations.\n\nPer Tomas Vondra and buildfarm member fulmar.  It's been like this\nfor a long time, although it was not till we added a regression test\ncase covering the behavior (in commit dd2243f2a) that the problem\nbecame apparent.  Back-patch to all supported versions.\n\nDiscussion: https://postgr.es/m/50562fdc-0876-9843-c883-15b8566c7511@2ndquadrant.com","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/2dbee9f19f6c6ac6c013f668611492486e623807"},{"sha":"8d2814f274def85f39fbe997d454b01628cb5667","author":{"name":"Magnus Hagander","email":"96ad6b06de7111eee5a9c968ba6978bf7a7a179d@hagander.net"},"message":"Fix pg_recvlogical for pre-10 versions\n\nIn e170b8c8, protection against modified search_path was added. However,\nPostgreSQL versions prior to 10 does not accept SQL commands over a\nreplication connection, so the protection would generate a syntax error.\n\nSince we cannot run SQL commands on it, we are also not vulnerable to\nthe issue that e170b8c8 fixes, so we can just skip this command for\nolder versions.\n\nAuthor: Michael Paquier <michael@paquier.xyz>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/8d2814f274def85f39fbe997d454b01628cb5667"},{"sha":"a4678320471380e5159a8d6e89466d74d6ee1739","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Doc: note that statement-level view triggers require an INSTEAD OF trigger.\n\nIf a view lacks an INSTEAD OF trigger, DML on it can only work by rewriting\nthe command into a command on the underlying base table(s).  Then we will\nfire triggers attached to those table(s), not those for the view.  This\nseems appropriate from a consistency standpoint, but nowhere was the\nbehavior explicitly documented, so let's do that.\n\nThere was some discussion of throwing an error or warning if a statement\ntrigger is created on a view without creating a row INSTEAD OF trigger.\nBut a simple implementation of that would result in dump/restore ordering\nhazards.  Given that it's been like this all along, and we hadn't heard\na complaint till now, a documentation improvement seems sufficient.\n\nPer bug #15106 from Pu Qun.  Back-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/152083391168.1215.16892140713507052796@wrigleys.postgresql.org","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/a4678320471380e5159a8d6e89466d74d6ee1739"},{"sha":"71cce90ee99098f52e65278b96662e32ca005771","author":{"name":"Magnus Hagander","email":"96ad6b06de7111eee5a9c968ba6978bf7a7a179d@hagander.net"},"message":"Fix typo in comment\n\nAuthor: Daniel Gustafsson <daniel@yesql.se>","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/71cce90ee99098f52e65278b96662e32ca005771"},{"sha":"49525c46309828b3024fe8040fa99c7dcc83933d","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Rewrite recurse_union_children to iterate, rather than recurse.\n\nAlso, rename it to plan_union_chidren, so the old name wasn't\nvery descriptive.  This results in a small net reduction in code,\nseems at least to me to be easier to understand, and saves\nspace on the process stack.\n\nPatch by me, reviewed and tested by Ashutosh Bapat and Rajkumar\nRaghuwanshi.\n\nDiscussion: http://postgr.es/m/CA+TgmoaLRAOqHmMZx=ESM3VDEPceg+-XXZsRXQ8GtFJO_zbMSw@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/49525c46309828b3024fe8040fa99c7dcc83933d"},{"sha":"c596fadbfe20ff50a8e5f4bc4b4ff5b7c302ecc0","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Generate a separate upper relation for each stage of setop planning.\n\nCommit 3fc6e2d7f5b652b417fa6937c34de2438d60fa9f made setop planning\nstages return paths rather than plans, but all such paths were loosely\nassociated with a single RelOptInfo, and only the final path was added\nto the RelOptInfo.  Even at the time, it was foreseen that this should\nbe changed, because there is otherwise no good way for a single stage\nof setop planning to return multiple paths.  With this patch, each\nstage of set operation planning now creates a separate RelOptInfo;\nthese are distinguished by using appropriate relid sets.  Note that\nthis patch does nothing whatsoever about actually returning multiple\npaths for the same set operation; it just makes it possible for a\nfuture patch to do so.\n\nAlong the way, adjust things so that create_upper_paths_hook is called\nfor each of these new RelOptInfos rather than just once, since that\nmight be useful to extensions using that hook.  It might be a good\nto provide an FDW API here as well, but I didn't try to do that for\nnow.\n\nPatch by me, reviewed and tested by Ashutosh Bapat and Rajkumar\nRaghuwanshi.\n\nDiscussion: http://postgr.es/m/CA+TgmoaLRAOqHmMZx=ESM3VDEPceg+-XXZsRXQ8GtFJO_zbMSw@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/kommiharibabu/postgres/commits/c596fadbfe20ff50a8e5f4bc4b4ff5b7c302ecc0"}]}
{"actor":{"display_login":"kommiharibabu"}}