{"push_id":1376144399,"size":22,"distinct_size":9,"ref":"refs/heads/decl-part-inh","head":"4159ec4922f71c3a5efd4b93d198c71ba64bce0b","before":"147fbc703bace50ec0e44f3f59f0775b32fc686f","commits":[{"sha":"f267c1c2447bb8da6e4a6b2fcbb612762c3579a8","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Fix possible pg_basebackup failure on standby with \"include WAL\".\n\nIf a restartpoint flushed no dirty buffers, it could fail to update\nthe minimum recovery point, leading to a minimum recovery point prior\nto the starting REDO location.  perform_base_backup() would interpret\nthat as meaning that no WAL files at all needed to be included in the\nbackup, failing an internal sanity check.  To fix, have restartpoints\nalways update the minimum recovery point to just after the checkpoint\nrecord itself, so that the file (or files) containing the checkpoint\nrecord will always be included in the backup.\n\nCode by Amit Kapila, per a design suggestion by me, with some\nadditional work on the code comment by me.  Test case by Michael\nPaquier.  Report by Kyotaro Horiguchi.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/f267c1c2447bb8da6e4a6b2fcbb612762c3579a8"},{"sha":"4f714b2fd2a580d909607de889ac822956eb8299","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"If the stats collector dies during Hot Standby, restart it.\n\nThis bug exists as far back as 9.0, when Hot Standby was introduced,\nso back-patch to all supported branches.\n\nReport and patch by Takayuki Tsunakawa, reviewed by Michael Paquier\nand Kuntal Ghosh.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/4f714b2fd2a580d909607de889ac822956eb8299"},{"sha":"84d457edaf4b3a1e10fd9e100e8ca18c042ad30c","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Format PL/Python module contents test vertically\n\nIt makes it readable again and makes merges more manageable.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/84d457edaf4b3a1e10fd9e100e8ca18c042ad30c"},{"sha":"eaed88ce120746b3004225252f52d8c79fea2f58","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add function name to PyArg_ParseTuple()\n\nThis causes the supplied function name to appear in any error message,\nmaking the error message friendlier and relieving us from having to\nprovide our own in some cases.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/eaed88ce120746b3004225252f52d8c79fea2f58"},{"sha":"ce4dc970560a25d4f7091a6e9ce8c6e1f25d55c9","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Remove invitation to report a bug about unknown encoding\n\nThe error message when we couldn't determine the encoding from a locale\nsaid to report a bug about that.  That might have been appropriate when\nthis code was first added, but by now this works pretty solidly and any\nencodings we don't recognize we probably just don't support.  We still\nprint the warning, but no longer invite the bug report.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/ce4dc970560a25d4f7091a6e9ce8c6e1f25d55c9"},{"sha":"a94b70356bcc3b2f5fc107d0ddfa936c32535a30","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"doc: Small style improvements","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/a94b70356bcc3b2f5fc107d0ddfa936c32535a30"},{"sha":"33839b5ffbd7be56681f31d107ec8238c4a0494a","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Fix leftover reference to background writer performing checkpoints.\n\nThis was changed in PostgreSQL 9.2, but somehow this comment never\ngot updated.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/33839b5ffbd7be56681f31d107ec8238c4a0494a"},{"sha":"d4b5d4caddb73f954d9ef86641201dc99677719d","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"pgstattuple: Don't take heavyweight locks when examining a hash index.\n\nIt's currently necessary to take a heavyweight lock when scanning a\nhash bucket, but pgstattuple only examines individual pages, so it\ndoesn't need to do this.  If, for some hypothetical reason, it did\nneed to do any heavyweight locking here, this logic would probably\nstill be incorrect, because most of the locks that it is taking are\nmeaningless.  Only a heavyweight lock on a primary bucket page has any\nmeaning, but this takes heavyweight locks on all pages regardless of\nfunction - and in particular overflow pages, where you might imagine\nthat we'd want to lock the primary bucket page if we needed to lock\nanything at all.\n\nThis is arguably a bug that has existed since this code was added in\ncommit dab42382f483c3070bdce14a4d93c5d0cf61e82b, but I'm not going to\nbother back-patching it because in most cases the only consequence is\nthat running pgstattuple() on a hash index is a little slower than it\notherwise might be, which is no big deal.\n\nExtracted from a vastly larger patch by Amit Kapila which heavyweight\nlocking for hash indexes entirely; analysis of why this can be done\nindependently of the rest by me.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/d4b5d4caddb73f954d9ef86641201dc99677719d"},{"sha":"a775406ec439bc585a17f8edffd47641390d6e5a","author":{"name":"Magnus Hagander","email":"96ad6b06de7111eee5a9c968ba6978bf7a7a179d@hagander.net"},"message":"Fix memory leak in tar file padding\n\nSpotted by Coverity, patch by Michael Paquier","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/a775406ec439bc585a17f8edffd47641390d6e5a"},{"sha":"9a00f03e479c2d4911eed5b4bd1994315d409938","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Improve speed of aggregates that use array_append as transition function.\n\nIn the previous coding, if an aggregate's transition function returned an\nexpanded array, nodeAgg.c and nodeWindowAgg.c would always copy it and thus\nforce it into the flat representation.  This led to ping-ponging between\nflat and expanded formats, which costs a lot.  For an aggregate using\narray_append as transition function, I measured about a 15X slowdown\ncompared to the pre-9.5 code, when working on simple int[] arrays.\nOf course, the old code was already O(N^2) in this usage due to copying\nflat arrays all the time, but it wasn't quite this inefficient.\n\nTo fix, teach nodeAgg.c and nodeWindowAgg.c to allow expanded transition\nvalues without copying, so long as the transition function takes care to\nreturn the transition value already properly parented under the aggcontext.\nThat puts a bit of extra responsibility on the transition function, but\ndoing it this way allows us to not need any extra logic in the fast path\nof advance_transition_function (ie, with a pass-by-value transition value,\nor with a modified-in-place pass-by-reference value).  We already know\nthat that's a hot spot so I'm loath to add any cycles at all there.  Also,\nwhile only array_append currently knows how to follow this convention,\nthis solution allows other transition functions to opt-in without needing\nto have a whitelist in the core aggregation code.\n\n(The reason we would need a whitelist is that currently, if you pass a\nR/W expanded-object pointer to an arbitrary function, it's allowed to do\nanything with it including deleting it; that breaks the core agg code's\nassumption that it should free discarded values.  Returning a value under\naggcontext is the transition function's signal that it knows it is an\naggregate transition function and will play nice.  Possibly the API rules\nfor expanded objects should be refined, but that would not be a\nback-patchable change.)\n\nWith this fix, an aggregate using array_append is no longer O(N^2), so it's\nmuch faster than pre-9.5 code rather than much slower.  It's still a bit\nslower than the bespoke infrastructure for array_agg, but the differential\nseems to be only about 10%-20% rather than orders of magnitude.\n\nDiscussion: <6315.1477677885@sss.pgh.pa.us>","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/9a00f03e479c2d4911eed5b4bd1994315d409938"},{"sha":"24ebc444c61306f50777f674544e8559e765ad81","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix bogus tree-flattening logic in QTNTernary().\n\nQTNTernary() contains logic to flatten, eg, '(a & b) & c' into 'a & b & c',\nwhich is all well and good, but it tries to do that to NOT nodes as well,\nso that '!!a' gets changed to '!a'.  Explicitly restrict the conversion to\nbe done only on AND and OR nodes, and add a test case illustrating the bug.\n\nIn passing, provide some comments for the sadly naked functions in\ntsquery_util.c, and simplify some baroque logic in QTNFree(), which\nI think may have been leaking some items it intended to free.\n\nNoted while investigating a complaint from Andreas Seltenreich.\nBack-patch to all supported versions.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/24ebc444c61306f50777f674544e8559e765ad81"},{"sha":"5ec81aceec8cc5a0edcc4609ee8edbc43a47e878","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix nasty performance problem in tsquery_rewrite().\n\ntsquery_rewrite() tries to find matches to subsets of AND/OR conditions;\nfor example, in the query 'a | b | c' the substitution subquery 'a | c'\nshould match and lead to replacement of the first and third items.\nThat's fine, but the matching algorithm apparently takes about O(2^N)\nfor an N-clause query (I say \"apparently\" because the code is also both\nunintelligible and uncommented).  We could probably do better than that\neven without any extra assumptions --- but actually, we know that the\nsubclauses are sorted, indeed are depending on that elsewhere in this very\nsame function.  So we can just scan the two lists a single time to detect\nmatches, as though we were doing a merge join.\n\nAlso do a re-flattening call (QTNTernary()) in tsquery_rewrite_query, just\nto make sure that the tree fits the expectations of the next search cycle.\nI didn't try to devise a test case for this, but I'm pretty sure that the\noversight could have led to failure to match in some cases where a match\nwould be expected.\n\nImprove comments, and also stick a CHECK_FOR_INTERRUPTS into\ndofindsubquery, just in case it's still too slow for somebody.\n\nPer report from Andreas Seltenreich.  Back-patch to all supported branches.\n\nDiscussion: <8760oasf2y.fsf@credativ.de>","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/5ec81aceec8cc5a0edcc4609ee8edbc43a47e878"},{"sha":"36d154ecb2286328c7c59b99d5abb71318e056eb","author":{"name":"Tatsuo Ishii","email":"e976844f84c6100bdd94f15ca8a88c4a94a262f0@postgresql.org"},"message":"Fix typo in sources.sgml.\n\nPer Shinichi Matsuda.","distinct":false,"url":"https://api.github.com/repos/amitlan/postgres/commits/36d154ecb2286328c7c59b99d5abb71318e056eb"},{"sha":"c62b9e98d4413aea5627d29e02c37f0e69ef2ea9","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"Catalog and DDL for partitioned tables.\n\nIn addition to a catalog for storing the partitioning information, this\ncommit also adds a new relkind to pg_class.h.\n\nPARTITION BY clause is added to CREATE TABLE. The tables so created are\nRELKIND_PARTITIONED_TABLE relations which are special in number of ways,\nespecially their interactions with table inheritance features.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/c62b9e98d4413aea5627d29e02c37f0e69ef2ea9"},{"sha":"369ec8927046a4a7a4ceb995291ab21dcfb0d8aa","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"psql and pg_dump support for partitioned tables.\n\nTakes care of both the partition key deparse stuff and the new relkind.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/369ec8927046a4a7a4ceb995291ab21dcfb0d8aa"},{"sha":"1e97b44f962dcd4d3431f2d94514865df09ac7e4","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"Catalog and DDL for partitions.\n\npg_class gets new fields: relispartition and relpartbound (a pg_node_tree).\n\nParent-child relationships of a partitioned table and its partitions are\nmanaged with inheritance, so not much here about that.\n\nDDL includes both a way to create new partition and \"attach\" an existing table\nas partition. An existing partition can be \"detached\" from a table, which\npreserves it as a regular (or partitioned) table.\n\nAdd a field to relcache for storing a \"partition descriptor\" of a partitioned\ntable which has hopefully all the information about a table's partitions that\nsomeone might want to do something with.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/1e97b44f962dcd4d3431f2d94514865df09ac7e4"},{"sha":"b038c0af6adfbb852cfe23138898f8a772c57f2f","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"psql and pg_dump support for partitions.\n\nTakes care of both the partition bound deparse stuff and handling\nparent-partition relationship (filtering pg_inherits entries pertaining\nto partitions and handling appropriately).","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/b038c0af6adfbb852cfe23138898f8a772c57f2f"},{"sha":"207f7f32e6b1bd70f25ffbcc15420f36297aeebd","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"Refactor optimizer's inheritance set expansion code.\n\nCurrently, a inheritance set is flattened upon expansion so that\nAppendRelInfos so formed do not preserve the immediate parent-child\nrelationship which could be useful information in certain optimization\nscenarios.  That is especially true for partitioned tables which are\nfashioned as inheritance hierarchies.\n\nBecause certain restrictions (such as multiple inheritance) that prevent\nregular inheritance expansion to be done recursively do not hold for\npartitioned table hierarchies, do the partitioned table inheritance set\nexpansion recursively.\n\nConsider this fact (non-flattened inheritance set) in places such as\ncreate_lateral_join_info() that traverse append_rel_list to propagate\ncertain query transformations from the parent to child tables.\n\nIf relation is the target table (UPDATE and DELETE), flattening is\ndone regardless (scared to modify inheritance_planner() yet).","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/207f7f32e6b1bd70f25ffbcc15420f36297aeebd"},{"sha":"bf9c3d9e2c8fd74c62f8246c59426ec83c5aa1e6","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"Teach a few places to use partition check quals.\n\nFor example, if a row is inserted directly into a partition we should make\nsure that it does not violate its bounds.  So teach copy.c and execMain.c\nto apply \"partition check constraint\".\n\nAlso, for constraint exclusion to work with partitioned tables, teach the\noptimizer to include check constraint expressions derived from partition bound\nbound info in the list of predicates it uses to perform the task.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/bf9c3d9e2c8fd74c62f8246c59426ec83c5aa1e6"},{"sha":"863dc4f848204ba32b52a71739ee4b4be44d7d34","author":{"name":"amit","email":"fc2791f35e0830a67c4ed7902719cfb31ef475bd@gmail.com"},"message":"Introduce a PartitionTreeNode data structure.\n\nIt encapsulates the tree structure of a partition hierarchy which can be\narbitrarily deeply nested.  Every node in the tree represents a partitioned\ntable.  The only currently envisioned application is for tuple-routing.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/863dc4f848204ba32b52a71739ee4b4be44d7d34"}]}
{"actor":{"display_login":"amitlan"}}