{"push_id":1766070236,"size":82,"distinct_size":82,"ref":"refs/heads/master","head":"ff077ec36c0f15e9b6ec918ca98d2df389806cc2","before":"0bed49f3392b66ba23ba02f1132625e3783bf628","commits":[{"sha":"f04c9a61468904b6815b2bc73a48878817766e0e","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Standardize terminology for pg_statistic_ext entries.\n\nConsistently refer to such an entry as a \"statistics object\", not just\n\"statistics\" or \"extended statistics\".  Previously we had a mismash of\nterms, accompanied by utter confusion as to whether the term was\nsingular or plural.  That's not only grating (at least to the ear of\na native English speaker) but could be outright misleading, eg in error\nmessages that seemed to be referring to multiple objects where only one\ncould be meant.\n\nThis commit fixes the code and a lot of comments (though I may have\nmissed a few).  I also renamed two new SQL functions,\npg_get_statisticsextdef -> pg_get_statisticsobjdef\npg_statistic_ext_is_visible -> pg_statistics_obj_is_visible\nto conform better with this terminology.\n\nI have not touched the SGML docs other than fixing those function\nnames; the docs certainly need work but it seems like a separable task.\n\nDiscussion: https://postgr.es/m/22676.1494557205@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/f04c9a61468904b6815b2bc73a48878817766e0e"},{"sha":"f6747434873693e001737ca06c30dcbcc2320b20","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Remove no-longer-needed fields of Hash plan nodes.\n\nskewColType/skewColTypmod are no longer used in the wake of commit\n9aab83fc5, and seem unlikely to be wanted in future, so let's drop 'em.\n\nDiscussion: https://postgr.es/m/16364.1494520862@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/f6747434873693e001737ca06c30dcbcc2320b20"},{"sha":"65b655b53ec1cb91fda0d34e5176f8cdcfcf2e3d","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Update config.guess and config.sub","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/65b655b53ec1cb91fda0d34e5176f8cdcfcf2e3d"},{"sha":"b5b0db19b895f033ada35bc7c337183be7356977","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix handling of extended statistics during ALTER COLUMN TYPE.\n\nALTER COLUMN TYPE on a column used by a statistics object fails since\ncommit 928c4de30, because the relevant switch in ATExecAlterColumnType\nis unprepared for columns to have dependencies from OCLASS_STATISTIC_EXT\nobjects.\n\nAlthough the existing types of extended statistics don't actually need us\nto do any work for a column type change, it seems completely indefensible\nthat that assumption is hidden behind the failure of an unrelated module\nto contain any code for the case.  Hence, create and call an API function\nin statscmds.c where the assumption can be explained, and where we could\nadd code to deal with the problem when it inevitably becomes real.\n\nAlso, the reason this wasn't handled before, neither for extended stats\nnor for the last half-dozen new OCLASS kinds :-(, is that the default:\nin that switch suppresses compiler warnings, allowing people to miss the\nneed to consider it when adding an OCLASS.  We don't really need a default\nbecause surely getObjectClass should only return valid values of the enum;\nso remove it, and add the missed OCLASS entries where they should be.\n\nDiscussion: https://postgr.es/m/20170512221010.nglatgt5azzdxjlj@alvherre.pgsql","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/b5b0db19b895f033ada35bc7c337183be7356977"},{"sha":"e84c0195980f24b1c7f857b88834c1dcaf20a102","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix maintenance hazards caused by ill-considered use of default: cases.\n\nRemove default cases from assorted switches over ObjectClass and some\nrelated enum types, so that we'll get compiler warnings when someone\nadds a new enum value without accounting for it in all these places.\n\nIn passing, re-order some switch cases as needed to match the declaration\nof enum ObjectClass.  OK, that's just neatnik-ism, but I dislike code\nthat looks like it was assembled with the help of a dartboard.\n\nDiscussion: https://postgr.es/m/20170512221010.nglatgt5azzdxjlj@alvherre.pgsql","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/e84c0195980f24b1c7f857b88834c1dcaf20a102"},{"sha":"93ece9cc887239deef6539d607063d98aa03aff3","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Edit SGML documentation related to extended statistics.\n\nUse the \"statistics object\" terminology uniformly here too.  Assorted\ncopy-editing.  Put new catalogs.sgml sections into alphabetical order.","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/93ece9cc887239deef6539d607063d98aa03aff3"},{"sha":"edbe2a29365e0358387db92db0ccd5260d2bc7b1","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Attempt to fix compiler warning.\n\nPer a report from Tom Lane, newer versions of gcc apparently think\nthat partexprs_item_saved can be used uninitialized.  Try to convince\nthem otherwise.","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/edbe2a29365e0358387db92db0ccd5260d2bc7b1"},{"sha":"7606bbb3de48b35f6fc0c918b39cd4be82de8848","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Make stats regression test more robust in the face of parallel query.\n\nCommit 60690a6fe attempted to fix the wait_for_stats() function in this\ntest so that it would wait properly if the tenk2 scans were done in\nparallel workers instead of the main session (typically as a consequence of\nforce_parallel_mode being turned on).  However, we made it test for whether\nthe main session's actions had been reported by looking for inserts on\n'trunc_stats_test'.  This is the Wrong Thing, because those aren't the last\nupdates we expect the main session to do.  As shown by recent failures on\nbuildfarm member frogmouth, it's entirely likely that the trunc_stats_test\nupdates will be reported in a separate message from later updates, which\nmeans there can be a window in which wait_for_stats() will exit but not all\nthe updates we are expecting to see will have arrived.  We should test for\nthe last updates we're expecting, namely those on 'trunc_stats_test4'.\n\nUnfortunately, I doubt that this explains frogmouth's failures, because\nthere's no reason to believe that it's running the tenk2 queries in\nparallel.  Still, the test is wrong on its own terms, so fix and back-patch\nto 9.6 where parallel query came in.","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/7606bbb3de48b35f6fc0c918b39cd4be82de8848"},{"sha":"b91e5b4684d840c903a78e86700b9d906033c2ad","author":{"name":"Bruce Momjian","email":"c14305a822a8e0093cd46d644546baf20ea0af1b@momjian.us"},"message":"doc:  update PG 10 release notes for recent changes","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/b91e5b4684d840c903a78e86700b9d906033c2ad"},{"sha":"5d00b764cd682f6071b35033f508a431d9d3f920","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Make pgstat tabstat lookup hash table less fragile.\n\nCode review for commit 090010f2e.\n\nFix cases where an elog(ERROR) partway through a function would leave the\npersistent data structures in a corrupt state.  pgstat_report_stat got this\nwrong by invalidating PgStat_TableEntry structs before removing hashtable\nentries pointing to them, and get_tabstat_entry got it wrong by ignoring\nthe possibility of palloc failure after it had already created a hashtable\nentry.\n\nAlso, avoid leaking a memory context per transaction, which the previous\ncode did through misunderstanding hash_create's API.  We do not need to\ncreate a context to hold the hash table; hash_create will do that.\n(The leak wasn't that large, amounting to only a memory context header\nper iteration, but it's still surprising that nobody noticed it yet.)","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/5d00b764cd682f6071b35033f508a431d9d3f920"},{"sha":"de7cca982ca253236051c2a7f6477bee5ce4b045","author":{"name":"Bruce Momjian","email":"c14305a822a8e0093cd46d644546baf20ea0af1b@momjian.us"},"message":"doc:  update the \"current as of\" date in the PG 10 release notes","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/de7cca982ca253236051c2a7f6477bee5ce4b045"},{"sha":"eda4ef81511ea62e49f5ea9edb8fbfdd529dd959","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"stats regression test's wait_for_stats() must check timestamp too.\n\npg_stat_get_snapshot_timestamp() returns the timestamp seen in the \"global\"\nstats file.  Because pgstat_write_statsfiles() writes per-DB stats files\nbefore the global file (or at least before renaming it into place), there\nis a window where the test backend can see all the stats updates that\nwait_for_stats() was checking for (all of which come from the per-DB file)\nbut also see the same global stats file it had seen at the start of the\ntest script.  This results in a failure in only the \"snapshot_newer\" query,\nas reported by a couple of buildfarm members recently.\n\nI suspect that this ought to be back-patched.  Commit 4e37b3e15 has\nevidently increased the probability of this window getting hit, but\nit's not apparent why it could not have been hit before.  I'll refrain\nfor the moment though.","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/eda4ef81511ea62e49f5ea9edb8fbfdd529dd959"},{"sha":"b1c45afb01248f5d6d6d2f0761a35843576f940f","author":{"name":"Magnus Hagander","email":"96ad6b06de7111eee5a9c968ba6978bf7a7a179d@hagander.net"},"message":"Fix typo in comment\n\nMichael Paquier","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/b1c45afb01248f5d6d6d2f0761a35843576f940f"},{"sha":"f8dc1985fd390774aab4ab0ba71036d6d5e631a9","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Fix ALTER SEQUENCE locking\n\nIn 1753b1b027035029c2a2a1649065762fafbf63f3, the pg_sequence system\ncatalog was introduced.  This made sequence metadata changes\ntransactional, while the actual sequence values are still behaving\nnontransactionally.  This requires some refinement in how ALTER\nSEQUENCE, which operates on both, locks the sequence and the catalog.\n\nThe main problems were:\n\n- Concurrent ALTER SEQUENCE causes \"tuple concurrently updated\" error,\n  caused by updates to pg_sequence catalog.\n\n- Sequence WAL writes and catalog updates are not protected by same\n  lock, which could lead to inconsistent recovery order.\n\n- nextval() disregarding uncommitted ALTER SEQUENCE changes.\n\nTo fix, nextval() and friends now lock the sequence using\nRowExclusiveLock instead of AccessShareLock.  ALTER SEQUENCE locks the\nsequence using ShareRowExclusiveLock.  This means that nextval() and\nALTER SEQUENCE block each other, and ALTER SEQUENCE on the same sequence\nblocks itself.  (This was already the case previously for the OWNER TO,\nRENAME, and SET SCHEMA variants.)  Also, rearrange some code so that the\nentire AlterSequence is protected by the lock on the sequence.\n\nAs an exception, use reduced locking for ALTER SEQUENCE ... RESTART.\nSince that is basically a setval(), it does not require the full locking\nof other ALTER SEQUENCE actions.  So check whether we are only running a\nRESTART and run with less locking if so.\n\nReviewed-by: Michael Paquier <michael.paquier@gmail.com>\nReported-by: Jason Petersen <jason@citusdata.com>\nReported-by: Andres Freund <andres@anarazel.de>","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/f8dc1985fd390774aab4ab0ba71036d6d5e631a9"},{"sha":"12590c5d33d013e55995c0c0ea6c70262a6d13b3","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix unsafe reference into relcache in constructed CommentStmt.\n\nThe CommentStmt made by RebuildConstraintComment() has to pstrdup the\nrelation name, else it will contain a dangling pointer after that\nrelcache entry is flushed.  (I'm less sure that pstrdup'ing conname\nis necessary, but let's be safe.)  Failure to do this leads to weird\nerrors or crashes, as reported by Marko Elezovic.\n\nBug introduced by commit e42375fc8, so back-patch to 9.5 as that was.\n\nFix by David Rowley, regression test by Michael Paquier\n\nDiscussion: https://postgr.es/m/DB6PR03MB30775D58E732D4EB0C13725B9AE00@DB6PR03MB3077.eurprd03.prod.outlook.com","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/12590c5d33d013e55995c0c0ea6c70262a6d13b3"},{"sha":"4041808b5b70433206b37e1305c807c325b06713","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix bogus syntax for CREATE PUBLICATION commands emitted by pg_dump.\n\nOriginal coding was careless about where to insert commas.\n\nMasahiko Sawada\n\nDiscussion: https://postgr.es/m/3427593a-61aa-b17e-64ef-383b7742d6d9@enterprisedb.com","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/4041808b5b70433206b37e1305c807c325b06713"},{"sha":"4b99d32b2b0de97063b85a0ea69d482d8a4bf075","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"doc: Remove unused file\n\nsql.sgml has not been part of the documentation since forever, so it's\npointless to keep it around.","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/4b99d32b2b0de97063b85a0ea69d482d8a4bf075"},{"sha":"82d24bab75d4f85ae7a6d89f149d29fbb2ccbc70","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Translation updates\n\nSource-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git\nSource-Git-Hash: 398beeef4921df0956f917becd7b5669d2a8a5c4","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/82d24bab75d4f85ae7a6d89f149d29fbb2ccbc70"},{"sha":"b1ff33fd9bb82937f4719f264972e6a3c83cdb89","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add assertion to quiet Coverity","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/b1ff33fd9bb82937f4719f264972e6a3c83cdb89"},{"sha":"e3f67a5a1732321dfa094e14c083dc482ad066b4","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Update oidjoins regression test for v10.","distinct":true,"url":"https://api.github.com/repos/wwjiang007/postgres/commits/e3f67a5a1732321dfa094e14c083dc482ad066b4"}]}
{"actor":{"display_login":"wwjiang007"}}