{"push_id":1478178989,"size":33,"distinct_size":33,"ref":"refs/heads/master","head":"80a7298b9eb7f108ef20be6ee00d9513a43c61a0","before":"4032ef18d06aa7a3db515926ddebe8af04e533fe","commits":[{"sha":"b86515da1a73d0a2e23aca728f18b5f9e809e89f","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Give a useful error message if uuid-ossp is built without preconfiguration.\n\nBefore commit b8cc8f947, it was possible to build contrib/uuid-ossp without\nhaving told configure you meant to; you could just cd into that directory\nand \"make\".  That no longer works because the code depends on configure to\nhave done header and library probes, but the ensuing error messages are\nnot so easy to interpret if you're not an old C hand.  We've gotten a\ncouple of complaints recently from people trying to do this the low-tech\nway, so add an explicit #error directing the user to use --with-uuid.\n\n(In principle we might want to do something similar in the other\noptionally-built contrib modules; but I don't think any of the others have\never worked without preconfiguration, so there are no bad habits to break\npeople of.)\n\nBack-patch to 9.4 where the previous commit came in.\n\nReport: https://postgr.es/m/CAHeEsBf42AWTnk=1qJvFv+mYgRFm07Knsfuc86Ono8nRjf3tvQ@mail.gmail.com\nReport: https://postgr.es/m/CAKYdkBrUaZX+F6KpmzoHqMtiUqCtAW_w6Dgvr6F0WTiopuGxow@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/b86515da1a73d0a2e23aca728f18b5f9e809e89f"},{"sha":"01ec25631fe0eae6af67c29c61a358dc6b92ed3c","author":{"name":"Heikki Linnakangas","email":"f503d7d54583b01050f859fedbc50f86f41cf34b@iki.fi"},"message":"Simplify tape block format.\n\nNo more indirect blocks. The blocks form a linked list instead.\n\nThis saves some memory, because we don't need to have a buffer in memory to\nhold the indirect block (or blocks). To reflect that, TAPE_BUFFER_OVERHEAD\nis reduced from 3 to 1 buffer, which allows using more memory for building\nthe initial runs.\n\nReviewed by Peter Geoghegan and Robert Haas.\n\nDiscussion: https://www.postgresql.org/message-id/34678beb-938e-646e-db9f-a7def5c44ada%40iki.fi","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/01ec25631fe0eae6af67c29c61a358dc6b92ed3c"},{"sha":"c4448683893bd37b59003603bc9075d362e81b5a","author":{"name":"Joe Conway","email":"3b8e10480754ba93523db5dc4626a5f001e54bb7@joeconway.com"},"message":"Protect dblink from invalid options when using postgres_fdw server\n\nWhen dblink uses a postgres_fdw server name for its connection, it\nis possible for the connection to have options that are invalid\nwith dblink (e.g. \"updatable\"). The recommended way to avoid this\nproblem is to use dblink_fdw servers instead. However there are use\ncases for using postgres_fdw, and possibly other FDWs, for dblink\nconnection options, therefore protect against trying to use any\noptions that do not apply by using is_valid_dblink_option() when\nbuilding the connection string from the options.\n\nBack-patch to 9.3. Although 9.2 supports FDWs for connection info,\nis_valid_dblink_option() did not yet exist, and neither did\npostgres_fdw, at least in the postgres source tree. Given the lack\nof previous complaints, fixing that seems too invasive/not worth it.\n\nAuthor: Corey Huinker\nReviewed-By: Joe Conway\nDiscussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/c4448683893bd37b59003603bc9075d362e81b5a"},{"sha":"3ee80672847c4100d5f9efdb9ea19cb96506d089","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Code review for ATExecAttachPartition.\n\nAmit Langote.  Most of this reported by Álvaro Herrera.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/3ee80672847c4100d5f9efdb9ea19cb96506d089"},{"sha":"2f802d95b4904dbed3dfdca1b3a607cd085d2e20","author":{"name":"Joe Conway","email":"3b8e10480754ba93523db5dc4626a5f001e54bb7@joeconway.com"},"message":"Make dblink try harder to form useful error messages\n\nWhen libpq encounters a connection-level error, e.g. runs out of memory\nwhile forming a result, there will be no error associated with PGresult,\nbut a message will be placed into PGconn's error buffer. postgres_fdw\ntakes care to use the PGconn error message when PGresult does not have\none, but dblink has been negligent in that regard. Modify dblink to mirror\nwhat postgres_fdw has been doing.\n\nBack-patch to all supported branches.\n\nAuthor: Joe Conway\nReviewed-By: Tom Lane\nDiscussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/2f802d95b4904dbed3dfdca1b3a607cd085d2e20"},{"sha":"097e41439d69e11fb870e009b1ac64dda4f01c3d","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Fix broken error check in _hash_doinsert.\n\nYou can't just cast a HashMetaPage to a Page, because the meta page\ndata is stored after the page header, not at offset 0.  Fortunately,\nthis didn't break anything because it happens to find hashm_bsize\nat the offset at which it expects to find pd_pagesize_version, and\nthe values are close enough to the same that this works out.\n\nStill, it's a bug, so back-patch to all supported versions.\n\nMithun Cy, revised a bit by me.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/097e41439d69e11fb870e009b1ac64dda4f01c3d"},{"sha":"6ef2eba3f57f17960b7cd4958e18aa79e357de2f","author":{"name":"Andres Freund","email":"c6cbfe878b4ee67646e7630734db67f536518d54@anarazel.de"},"message":"Skip checkpoints, archiving on idle systems.\n\nSome background activity (like checkpoints, archive timeout, standby\nsnapshots) is not supposed to happen on an idle system. Unfortunately\nso far it was not easy to determine when a system is idle, which\ndefeated some of the attempts to avoid redundant activity on an idle\nsystem.\n\nTo make that easier, allow to make individual WAL insertions as not\nbeing \"important\". By checking whether any important activity happened\nsince the last time an activity was performed, it now is easy to check\nwhether some action needs to be repeated.\n\nUse the new facility for checkpoints, archive timeout and standby\nsnapshots.\n\nThe lack of a facility causes some issues in older releases, but in my\nopinion the consequences (superflous checkpoints / archived segments)\naren't grave enough to warrant backpatching.\n\nAuthor: Michael Paquier, editorialized by Andres Freund\nReviewed-By: Andres Freund, David Steele, Amit Kapila, Kyotaro HORIGUCHI\nBug: #13685\nDiscussion:\n    https://www.postgresql.org/message-id/20151016203031.3019.72930@wrigleys.postgresql.org\n    https://www.postgresql.org/message-id/CAB7nPqQcPqxEM3S735Bd2RzApNqSNJVietAC=6kfkYv_45dKwA@mail.gmail.com\nBackpatch: -","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/6ef2eba3f57f17960b7cd4958e18aa79e357de2f"},{"sha":"cd1b215692d2cadf499936dba05f1f60bce59344","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix handling of expanded objects in CoerceToDomain and CASE execution.\n\nWhen the input value to a CoerceToDomain expression node is a read-write\nexpanded datum, we should pass a read-only pointer to any domain CHECK\nexpressions and then return the original read-write pointer as the\nexpression result.  Previously we were blindly passing the same pointer to\nall the consumers of the value, making it possible for a function in CHECK\nto modify or even delete the expanded value.  (Since a plpgsql function\nwill absorb a passed-in read-write expanded array as a local variable\nvalue, it will in fact delete the value on exit.)\n\nA similar hazard of passing the same read-write pointer to multiple\nconsumers exists in domain_check() and in ExecEvalCase, so fix those too.\n\nThe fix requires adding MakeExpandedObjectReadOnly calls at the appropriate\nplaces, which is simple enough except that we need to get the data type's\ntyplen from somewhere.  For the domain cases, solve this by redefining\nDomainConstraintRef.tcache as okay for callers to access; there wasn't any\nreason for the original convention against that, other than not wanting the\nAPI of typcache.c to be any wider than it had to be.  For CASE, there's\nno good solution except to add a syscache lookup during executor start.\n\nPer bug #14472 from Marcos Castedo.  Back-patch to 9.5 where expanded\nvalues were introduced.\n\nDiscussion: https://postgr.es/m/15225.1482431619@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/cd1b215692d2cadf499936dba05f1f60bce59344"},{"sha":"909cb78a8cce73c9678ddb3269b56e31b56e084b","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"doc: Further speed improvements for HTML XSLT build","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/909cb78a8cce73c9678ddb3269b56e31b56e084b"},{"sha":"22434dd06bbc5774c7bbffa5bf2bef3ead50c2f2","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Update sequence_1.out for recent changes","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/22434dd06bbc5774c7bbffa5bf2bef3ead50c2f2"},{"sha":"1ead0208b2178089b024caa2d1465a3f3056a45c","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix CREATE TABLE ... LIKE ... WITH OIDS.\n\nHaving a WITH OIDS specification should result in the creation of an OID\ncolumn, but commit b943f502b broke that in the case that there were LIKE\ntables without OIDS.  Commentary in that patch makes it look like this was\nintentional, but if so it was based on a faulty reading of what inheritance\ndoes: the parent tables can add an OID column, but they can't subtract one.\nAFAICS, the behavior ought to be that you get an OID column if any of the\ninherited tables, LIKE tables, or WITH clause ask for one.\n\nAlso, revert that patch's unnecessary split of transformCreateStmt's loop\nover the tableElts list into two passes.  That seems to have been based on\na misunderstanding as well: we already have two-pass processing here,\nwe don't need three passes.\n\nPer bug #14474 from Jeff Dafoe.  Back-patch to 9.6 where the misbehavior\nwas introduced.\n\nReport: https://postgr.es/m/20161222145304.25620.47445@wrigleys.postgresql.org","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/1ead0208b2178089b024caa2d1465a3f3056a45c"},{"sha":"12bd7dd317e8f4346fb3507578aca790ede6ebea","author":{"name":"Stephen Frost","email":"2063edcf0aa2fa8dfb7bba729d6cffa6fed14981@snowman.net"},"message":"Use TSConfigRelationId in AlterTSConfiguration()\n\nWhen we are altering a text search configuration, we are getting the\ntuple from pg_ts_config and using its OID, so use TSConfigRelationId\nwhen invoking any post-alter hooks and setting the object address.\n\nFurther, in the functions called from AlterTSConfiguration(), we're\nsaving information about the command via\nEventTriggerCollectAlterTSConfig(), so we should be setting\ncommandCollected to true.  Also add a regression test to\ntest_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.\n\nAuthor: Artur Zakirov, a few additional comments by me\nDiscussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru\n\nBack-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where\nit was introduced, and the fix for the ObjectAddressSet() call and\nsetting commandCollected to true to 9.5 where those changes to\nProcessUtilitySlow() were introduced.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/12bd7dd317e8f4346fb3507578aca790ede6ebea"},{"sha":"2ac3ef7a01df859c62d0a02333b646d65eaec5ff","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Fix tuple routing in cases where tuple descriptors don't match.\n\nThe previous coding failed to work correctly when we have a\nmulti-level partitioned hierarchy where tables at successive levels\nhave different attribute numbers for the partition key attributes.  To\nfix, have each PartitionDispatch object store a standalone\nTupleTableSlot initialized with the TupleDesc of the corresponding\npartitioned table, along with a TupleConversionMap to map tuples from\nthe its parent's rowtype to own rowtype.  After tuple routing chooses\na leaf partition, we must use the leaf partition's tuple descriptor,\nnot the root table's.  To that end, a dedicated TupleTableSlot for\ntuple routing is now allocated in EState.\n\nAmit Langote","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/2ac3ef7a01df859c62d0a02333b646d65eaec5ff"},{"sha":"0a85c102254b72ec7ce16bc504206a1a5c84bd76","author":{"name":"Joe Conway","email":"3b8e10480754ba93523db5dc4626a5f001e54bb7@joeconway.com"},"message":"Improve RLS documentation with respect to COPY\n\nDocumentation for pg_restore said COPY TO does not support row security\nwhen in fact it should say COPY FROM. Fix that.\n\nWhile at it, make it clear that \"COPY FROM\" does not allow RLS to be\nenabled and INSERT should be used instead. Also that SELECT policies\nwill apply to COPY TO statements.\n\nBack-patch to 9.5 where RLS first appeared.\n\nAuthor: Joe Conway\nReviewed-By: Dean Rasheed and Robert Haas\nDiscussion: https://postgr.es/m/5744FA24.3030008%40joeconway.com","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/0a85c102254b72ec7ce16bc504206a1a5c84bd76"},{"sha":"7819ba1ef6c5297b7e27878d2b3d30c5bcef8939","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Remove _hash_chgbufaccess().\n\nThis is basically for the same reasons I got rid of _hash_wrtbuf()\nin commit 25216c98938495fd741bf585dcbef45b3a9ffd40: it's not\nconvenient to have a function which encapsulates MarkBufferDirty(),\nespecially as we move towards having hash indexes be WAL-logged.\n\nPatch by me, reviewed (but not entirely endorsed) by Amit Kapila.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/7819ba1ef6c5297b7e27878d2b3d30c5bcef8939"},{"sha":"e13486eba05cc46951a34263d19b65d1eca0176b","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Remove sql_inheritance GUC.\n\nThis backward-compatibility GUC is long overdue for removal.\n\nDiscussion: http://postgr.es/m/CA+TgmoYe+EG7LdYX6pkcNxr4ygkP4+A=jm9o-CPXyOvRiCNwaQ@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/e13486eba05cc46951a34263d19b65d1eca0176b"},{"sha":"3e6639a465a5702d0aa98fc756b5ab8c7f97cde8","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"pg_dump: Remove obsolete handling of sequence names\n\nThere was code that attempted to check whether the sequence name stored\ninside the sequence was the same as the name in pg_class.  But that code\nwas already ifdef'ed out, and now that the sequence no longer stores its\nown name, it's altogether obsolete, so remove it.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/3e6639a465a5702d0aa98fc756b5ab8c7f97cde8"},{"sha":"ff33d1456ea098e160cbbc74b332656c06abc2ab","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Spellcheck: s/descendent/descendant/g\n\nI got a little annoyed by reading documentation paragraphs containing\nboth spellings within a few lines of each other.  My dictionary says\n\"descendant\" is the preferred spelling, and it's certainly the majority\nusage in our tree, so standardize on that.\n\nFor one usage in parallel.sgml, I thought it better to rewrite to avoid\nthe term altogether.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/ff33d1456ea098e160cbbc74b332656c06abc2ab"},{"sha":"3c9d398484fb6e188e665be8299d6e5e89924c94","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Doc: improve index entry for \"median\".\n\nWe had an index entry for \"median\" attached to the percentile_cont function\nentry, which was pretty useless because a person following the link would\nnever realize that that function was the one they were being hinted to use.\n\nInstead, make the index entry point at the example in syntax-aggregates,\nand add a <seealso> link to \"percentile\".\n\nAlso, since that example explicitly claims to be calculating the median,\nmake it use percentile_cont not percentile_disc.  This makes no difference\nin terms of the larger goals of that section, but so far as I can find,\nnearly everyone thinks that \"median\" means the continuous not discrete\ncalculation.\n\nPer gripe from Steven Winfield.  Back-patch to 9.4 where we introduced\npercentile_cont.\n\nDiscussion: https://postgr.es/m/20161223102056.25614.1166@wrigleys.postgresql.org","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/3c9d398484fb6e188e665be8299d6e5e89924c94"},{"sha":"158df30359025d74daee74a3b927fd07c3b1a413","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Remove unnecessary casts of makeNode() result\n\nmakeNode() is already a macro that has the right result pointer type, so\ncasting it again to the same type is unnecessary.","distinct":true,"url":"https://api.github.com/repos/dhyannataraj/postgres/commits/158df30359025d74daee74a3b927fd07c3b1a413"}]}
{"actor":{"display_login":"dhyannataraj"}}