{"push_id":2695825339,"size":9,"distinct_size":1,"ref":"refs/heads/commitfest/18/1085","head":"0d4e35f77f32f073ad71107e2573ed2af2eb89c3","before":"c6e2d5e9bac74d623826b716ea1e069837836d65","commits":[{"sha":"683707868723d2a798ff8dcb0513d89735591b66","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Correct comment","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/683707868723d2a798ff8dcb0513d89735591b66"},{"sha":"2c059c86ba774930fa816278343ff30292db4e6c","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Add $Test::Builder::Level to pgbench test functions\n\nsame as c4309f4aeeae54e4c5281d68e29288af1d0d1ed2","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2c059c86ba774930fa816278343ff30292db4e6c"},{"sha":"fc057b2b8fc3c3556d9f8cc0195c622aaad92c9e","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Remove dead code for temporary relations in partition planning\n\nSince recent commit 1c7c317c, temporary relations cannot be mixed with\npermanent relations within the same partition tree, and the same counts\nfor temporary relations created by other sessions, which the planner\nsimply discarded.  Instead be paranoid and issue an error, as those\nshould be blocked at definition time, at least for now.\n\nAt the same time, a test case is added to stress what has been moved\nwhen expand_partitioned_rtentry gets called recursively but bumps on a\npartitioned relation with no partitions which should be handled the same\nway as the non-inheritance case.  This code may be reworked in a close\nfuture, and covering this code path will limit surprises.\n\nReported-by: David Rowley\nAuthor: David Rowley\nReviewed-by: Amit Langote, Robert Haas, Michael Paquier\nDiscussion: https://postgr.es/m/CAKJS1f_HyV1txn_4XSdH5EOhBMYaCwsXyAj6bHXk9gOu4JKsbw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/fc057b2b8fc3c3556d9f8cc0195c622aaad92c9e"},{"sha":"b46727e07a9f4b8e0c8de1f10bfd4986b02c154c","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"doc: Reorganize CREATE TABLE / LIKE option documentation\n\nThis section once started out small but has now grown quite a bit and\nneeds a bit of structure.\n\nRewrite as list, add documentation of EXCLUDING, and improve the\ndocumentation of INCLUDING ALL instead of just listing all the options\nagain.\n\nper report from Yugo Nagata that EXCLUDING was not documented, that part\nreviewed by Daniel Gustafsson, most of the rewrite was by me","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b46727e07a9f4b8e0c8de1f10bfd4986b02c154c"},{"sha":"b41669118c00e25376a6c9ac991e0d074990484a","author":{"name":"Fujii Masao","email":"1f6acd02e97f7332f0e624e7be5170a1e771cb87@postgresql.org"},"message":"Improve the performance of relation deletes during recovery.\n\nWhen multiple relations are deleted at the same transaction,\nthe files of those relations are deleted by one call to smgrdounlinkall(),\nwhich leads to scan whole shared_buffers only one time. OTOH,\npreviously, during recovery, smgrdounlink() (not smgrdounlinkall()) was\ncalled for each file to delete, which led to scan shared_buffers\nmultiple times. Obviously this could cause to increase the WAL replay\ntime very much especially when shared_buffers was huge.\n\nTo alleviate this situation, this commit changes the recovery so that\nit also calls smgrdounlinkall() only one time to delete multiple\nrelation files.\n\nThis is just fix for oversight of commit 279628a0a7, not new feature.\nSo, per discussion on pgsql-hackers, we concluded to backpatch this\nto all supported versions.\n\nAuthor: Fujii Masao\nReviewed-by: Michael Paquier, Andres Freund, Thomas Munro, Kyotaro Horiguchi, Takayuki Tsunakawa\nDiscussion: https://postgr.es/m/CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b41669118c00e25376a6c9ac991e0d074990484a"},{"sha":"3a01f68e35a3584431ac5381c6ed75b1b39aaf2a","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Check for interrupts inside the nbtree page deletion code.\n\nWhen deleting pages the nbtree code has to walk through siblings of a\ntree node. When those sibling links are corrupted that can lead to\nendless loops - which are currently not interruptible.  This is\nespecially problematic if autovacuum is repeatedly blocked on such\nindexes, as it can be hard to get out of that situation without\nresorting to single user mode.\n\nThus add interrupt checks to appropriate places in such\nloops. Unfortunately in one of the cases it's it's not easy to do so.\n\nBetween 9.3 and 9.4 the page deletion (and page split) code changed\nsignificantly. Before it was significantly less robust against\ninterruptions. Therefore don't backpatch to 9.3.\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/20180627191629.wkunw2qbibnvlz53@alap3.anarazel.de\nBackpatch: 9.4-","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3a01f68e35a3584431ac5381c6ed75b1b39aaf2a"},{"sha":"249126e761e13c4d8e7519569d483eaeca7dac25","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Use context with correct lifetime in hypothetical_dense_rank_final.\n\nThe query lifetime expression context created in\nhypothetical_dense_rank_final() was buggily allocated in the calling\nmemory context. I (Andres) broke that in bf6c614a2f2.\n\nReported-By: Rajkumar Raghuwanshi\nAuthor: Amit Langote\nDiscussion:  https://postgr.es/m/CAKcux6kmzWmur5HhA_aU6gYVFu0RLQdgJJ+aC9SLdcOvBSrpfA@mail.gmail.com\nBackpatch: 11-","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/249126e761e13c4d8e7519569d483eaeca7dac25"},{"sha":"3c64dcb1e35dccbfce531182fa9b9f48bec414ad","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Prevent references to invalid relation pages after fresh promotion\n\nIf a standby crashes after promotion before having completed its first\npost-recovery checkpoint, then the minimal recovery point which marks\nthe LSN position where the cluster is able to reach consistency may be\nset to a position older than the first end-of-recovery checkpoint while\nall the WAL available should be replayed.  This leads to the instance\nthinking that it contains inconsistent pages, causing a PANIC and a hard\ninstance crash even if all the WAL available has not been replayed for\ncertain sets of records replayed.  When in crash recovery,\nminRecoveryPoint is expected to always be set to InvalidXLogRecPtr,\nwhich forces the recovery to replay all the WAL available, so this\ncommit makes sure that the local copy of minRecoveryPoint from the\ncontrol file is initialized properly and stays as it is while crash\nrecovery is performed.  Once switching to archive recovery or if crash\nrecovery finishes, then the local copy minRecoveryPoint can be safely\nupdated.\n\nPavan Deolasee has reported and diagnosed the failure in the first\nplace, and the base fix idea to rely on the local copy of\nminRecoveryPoint comes from Kyotaro Horiguchi, which has been expanded\ninto a full-fledged patch by me.  The test included in this commit has\nbeen written by Álvaro Herrera and Pavan Deolasee, which I have modified\nto make it faster and more reliable with sleep phases.\n\nBackpatch down to all supported versions where the bug appears, aka 9.3\nwhich is where the end-of-recovery checkpoint is not run by the startup\nprocess anymore.  The test gets easily supported down to 10, still it\nhas been tested on all branches.\n\nReported-by: Pavan Deolasee\nDiagnosed-by: Pavan Deolasee\nReviewed-by: Pavan Deolasee, Kyotaro Horiguchi\nAuthor: Michael Paquier, Kyotaro Horiguchi, Pavan Deolasee, Álvaro\nHerrera\nDiscussion: https://postgr.es/m/CABOikdPOewjNL=05K5CbNMxnNtXnQjhTx2F--4p4ruorCjukbA@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3c64dcb1e35dccbfce531182fa9b9f48bec414ad"},{"sha":"0d4e35f77f32f073ad71107e2573ed2af2eb89c3","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 18/1085] XML XPath default namespace support\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread, and also periodically to check for bitrot caused by changes\non the master branch.\n\nCommitfest entry: https://commitfest.postgresql.org/18/1085\nPatch(es): https://www.postgresql.org/message-id/CAFj8pRBVUVvG1CXxgrs0UipTziUX6M788z-=L9gQvwAB4UGLeg@mail.gmail.com\nAuthor(s): Pavel Stehule","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/0d4e35f77f32f073ad71107e2573ed2af2eb89c3"}]}
{"actor":{"display_login":"postgresql-cfbot"}}