Nouvelles hebdomadaires de PostgreSQL - 22 janvier 2017
Offres d'emplois autour de PostgreSQL en janvier
- Internationales : http://archives.postgresql.org/pgsql-jobs/2017-01/
- Francophones : http://forums.postgresql.fr/viewforum.php?id=4
- [ndt: Meetup à Toulouse le 2 mars :https://www.meetup.com/fr-FR/PostgreSQL-User-Group-Toulouse/]
- La PGConf India 2017 aura lieu les 2 & 3 mars 2017 à Bengalore (État du Karnataka en Inde) : http://pgconf.in/
- PostgreSQL@SCaLE aura lieu les 2 & 3 mars 2017 au centre des conventions de Pasadena, comme partie du SCaLE 15X : http://www.socallinuxexpo.org/scale/15x/
- PgConf.Russia 2017 se déroulera du 15 au 17 mars 2017 à Moscou : https://pgconf.ru/en
- Le PGDay Asia 2017 est programmé les 17 et 18 mars à Singapour : http://tinyurl.com/pgDay-Asia-2017-Cfp
- Le PGDay nordique se tiendra à Stockholm (Suède) au Sheraton Hotel, le 21 mars 2017 : https://2017.nordicpgday.org/
- Le pgDay Paris 2017 aura lieu à Paris (France) le 23 mars 2017 : http://2017.pgday.paris/
- La PGConf US 2017 aura lieu à Jersey City (New Jersey, USA) du 28 au 31 mars : http://www.pgconf.us/2017/
- PGCon 2017 aura lieu à Ottawa du 23 au 26 mai. Les propositions seront attendues jusqu'au 19 janvier 2017 : http://www.pgcon.org/2017/papers.php
PostgreSQL dans les média
- Planet PostgreSQL : http://planet.postgresql.org/
- Planet PostgreSQLFr : http://planete.postgresql.fr/
PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA. La version originale se trouve à l'adresse suivante : http://www.postgresql.org/message-id/20170122232424.GA6120@fetter.org
Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.
Fujii Masao pushed:
- Fix typos in comments. Masahiko Sawada http://git.postgresql.org/pg/commitdiff/8fa6019b405f9d39539a77c6f5f11fe640ddf955
- Fix an assertion failure related to an exclusive backup. Previously multiple sessions could execute pg_start_backup() and pg_stop_backup() to start and stop an exclusive backup at the same time. This could trigger the assertion failure of "FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)". This happend because, even while pg_start_backup() was starting an exclusive backup, other session could run pg_stop_backup() concurrently and mark the backup as not-in-progress unconditionally. This patch introduces ExclusiveBackupState indicating the state of an exclusive backup. This state is used to ensure that there is only one session running pg_start_backup() or pg_stop_backup() at the same time, to avoid the assertion failure. Back-patch to all supported versions. Author: Michael Paquier Reviewed-By: Kyotaro Horiguchi and me Reported-By: Andreas Seltenreich Discussion: <firstname.lastname@example.org> http://git.postgresql.org/pg/commitdiff/974ece58bbb3c0ef185a9d44b1cedae51cd56b04
- Add description of temporary column into pg_replication_slots doc. Ayumi Ishii http://git.postgresql.org/pg/commitdiff/954737095061e5b5f1d87fb8cc43f7f8afff64c6
Magnus Hagander pushed:
- Make pg_basebackup use temporary replication slots. Temporary replication slots will be used by default when wal streaming is used and no slot name is specified with -S. If a slot name is specified, then a permanent slot with that name is used. If --no-slot is specified, then no permanent or temporary slot will be used. Temporary slots are only used on 10.0 and newer, of course. http://git.postgresql.org/pg/commitdiff/e7b020f786bf3b344f81d70aa423525fd4f44dfa
- Fix incorrect comparison due to bad merge. Noted by Fujii Masao http://git.postgresql.org/pg/commitdiff/fcf708623e860b7a1efef11a5d5661900307b6fc
- Add compression support to pg_receivexlog. Author: Michael Paquier, review and small changes by me http://git.postgresql.org/pg/commitdiff/cada1af31d769a6b607018d68894f2c879ff275f
- Implement array version of jsonb_delete and operator. This makes it possible to delete multiple keys from a jsonb value by passing in an array of text values, which makes the operaiton much faster than individually deleting the keys (which would require copying the jsonb structure over and over again. Reviewed by Dmitry Dolgov and Michael Paquier http://git.postgresql.org/pg/commitdiff/d00ca333c338b40911e89939c3cc771025978595
Tom Lane pushed:
- Fix NULL pointer dereference in tuplesort.c. Oversight in commit e94568ecc. This could cause a crash when an external datum tuplesort of a pass-by-value type required multiple passes. Per report from Mithun Cy. Peter Geoghegan Discussion: https://postgr.es/m/CAD__OujuhfWFULGFSt1fyHqUb8N-XafjJhudwt88V0Qs2o84qg@mail.gmail.com http://git.postgresql.org/pg/commitdiff/4e46c97fde42fa8ca57d29b9b47f2ebd11ab8105
- Fix check_srf_call_placement() to handle VALUES cases correctly. INSERT ... VALUES with a single VALUES row is implemented quite differently from the general VALUES case. A user-visible implication of that is that we accept SRFs in the single-row case, but not in the multi-row case. That's a historical artifact no doubt, but in view of the lack of field complaints, I'm not excited about fixing it right now. However, check_srf_call_placement() needs to know about this, first because it should throw an error in the unsupported case, and second because it should set p_hasTargetSRFs in the single-row case (because we treat that like a SELECT tlist). That's an oversight in commit a4c35ea1c. To fix, split EXPR_KIND_VALUES into two values. So far as I can see, this is the only place where we need to distinguish the two cases at present; but there might be more later. Patch by me, per report from Andres Freund. Discussion: https://email@example.com http://git.postgresql.org/pg/commitdiff/d43a619c60405ecda275ca9e3ac9ead242e20ecb
- Improve RLS planning by marking individual quals with security levels. In an RLS query, we must ensure that security filter quals are evaluated before ordinary query quals, in case the latter contain "leaky" functions that could expose the contents of sensitive rows. The original implementation of RLS planning ensured this by pushing the scan of a secured table into a sub-query that it marked as a security-barrier view. Unfortunately this results in very inefficient plans in many cases, because the sub-query cannot be flattened and gets planned independently of the rest of the query. To fix, drop the use of sub-queries to enforce RLS qual order, and instead mark each qual (RestrictInfo) with a security_level field establishing its priority for evaluation. Quals must be evaluated in security_level order, except that "leakproof" quals can be allowed to go ahead of quals of lower security_level, if it's helpful to do so. This has to be enforced within the ordering of any one list of quals to be evaluated at a table scan node, and we also have to ensure that quals are not chosen for early evaluation (i.e., use as an index qual or TID scan qual) if they're not allowed to go ahead of other quals at the scan node. This is sufficient to fix the problem for RLS quals, since we only support RLS policies on simple tables and thus RLS quals will always exist at the table scan level only. Eventually these qual ordering rules should be enforced for join quals as well, which would permit improving planning for explicit security-barrier views; but that's a task for another patch. Note that FDWs would need to be aware of these rules --- and not, for example, send an insecure qual for remote execution --- but since we do not yet allow RLS policies on foreign tables, the case doesn't arise. This will need to be addressed before we can allow such policies. Patch by me, reviewed by Stephen Frost and Dean Rasheed. Discussion: https://firstname.lastname@example.org http://git.postgresql.org/pg/commitdiff/215b43cdc8d6b4a1700886a39df1ee735cb0274d
- Avoid conflicts with collation aliases generated by stripping. This resulted in failures depending on the order of "locale -a" output. The original coding in initdb sorted the results, but that should be unnecessary as long as "locale -a" doesn't print duplicate names. The original entries will then all be non-dups, and while we might generate duplicate aliases by stripping, they should be for different encodings and thus not conflict. Even if the latter assumption fails somehow, it won't be fatal because we're using if_not_exists mode for the aliases. Discussion: https://postgr.es/m/26116.1484751196%40sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/0333a7340054c3356940759b1ab2391eed572171
- Disable transforms that replaced AT TIME ZONE with RelabelType. These resulted in wrong answers if the relabeled argument could be matched to an index column, as shown in bug #14504 from Evgeniy Kozlov. We might be able to resurrect these optimizations by adjusting the planner's treatment of RelabelType, or by adjusting btree's rules for selecting comparison functions, but either solution will take careful analysis and does not sound like a fit candidate for backpatching. I left the catalog infrastructure in place and just reduced the transform functions to always-return-NULL. This would be necessary anyway in the back branches, and it doesn't seem important to be more invasive in HEAD. Bug introduced by commit b8a18ad48. Back-patch to 9.5 where that came in. Report: https://email@example.com Discussion: https://firstname.lastname@example.org http://git.postgresql.org/pg/commitdiff/c22ecc6562aac895f0f0529707d7bdb460fd2a49
- Reset the proper GUC in create_index test. Thinko in commit a4523c5aa. It doesn't really affect anything at present, but it would be a problem if any tests added later in this file ought to get index-only-scan plans. Back-patch, like the previous commit, just to avoid surprises in case we add such a test and then back-patch it. Nikita Glukhov Discussion: https://email@example.com http://git.postgresql.org/pg/commitdiff/1586317c3f57e619e0cde674c6da406f9d73aaff
- Doc: improve documentation of new SRF-in-tlist behavior. Correct a misstatement about how things used to work: we did allow nested SRFs before, as long as no function had more than one set-returning input. Also, attempt to document the fact that the new implementation changes the behavior for SRFs within conditional constructs (eg CASE): the conditional construct no longer gates whether the SRF is run, and thus cannot affect the number of rows emitted. We might want to change this behavior, but first it behooves us to see if we can explain it. Minor other wordsmithing on what I wrote yesterday, too. Discussion: https://firstname.lastname@example.org http://git.postgresql.org/pg/commitdiff/f13a1277aa2df301583c6db9c2989d2e9d7f6483
- Fix Assert failure induced by commit 215b43cdc. I'd somehow talked myself into believing that set_append_rel_size doesn't need to worry about getting back an AND clause when it applies eval_const_expressions to the result of adjust_appendrel_attrs (that is, transposing the appendrel parent's restriction clauses for one child). But that is nonsense, and Andreas Seltenreich's fuzz tester soon turned up a counterexample. Put back the make_ands_implicit step that was there before, and add a regression test covering the case. Report: https://email@example.com http://git.postgresql.org/pg/commitdiff/d479e37e3d20efad8b178e0f1e468c086a7519a8
- Avoid core dump for empty prepared statement in an aborted transaction. Brown-paper-bag bug in commit ab1f0c822: the old code here coped with null CachedPlanSource.raw_parse_tree, the new code not so much. Per report from Dave Cramer. No regression test, because our core testing infrastructure doesn't provide any easy way to exercise this path. Fortunately, the JDBC crew test it regularly. Discussion: https://postgr.es/m/CADK3HH+Ug3xCysKqw_dZOnaNnytZ1Rh5yP05hjO-e4NoyRxVvA@mail.gmail.com http://git.postgresql.org/pg/commitdiff/ba61a04bc7fefeee03416d9911eb825c4897c223
- Allow backslash line continuations in pgbench's meta commands. A pgbench meta command can now be continued onto additional line(s) of a script file by writing backslash-return. The continuation marker is equivalent to white space in that it separates tokens. Eventually it'd be nice to have the same thing in psql, but that will be a much larger project. Fabien Coelho, reviewed by Rafia Sabih Discussion: https://postgr.es/m/alpine.DEB.2.20.1610031049310.19411@lancre http://git.postgresql.org/pg/commitdiff/cdc2a70470bdbe3663dc464deb753d6d931bba61
- Try to fix non-MSVC Windows builds in the wake of logical replication. pgoutput evidently needs to be built without -DBUILDING_DLL. (It seems like a pretty bad idea that these makefiles need to know exactly where all the shlibs are in the tree, or maybe what's bad is putting them under src/backend/. But right now is not the time to redesign that.) Also, remove "override CPPFLAGS" in pgoutput's Makefile. I don't think that that actually has any bad consequences, but it's certainly useless in a directory that has no .h files, and it might be contributing to the failure somehow. Per buildfarm. http://git.postgresql.org/pg/commitdiff/0502e854640bd024f349c0df46b7dd6812b8c05c
- Fix cross-shlib linking in temporary installs on HPUX 10. Turns out this has been broken for years and we'd not noticed. The one case that was getting exercised in the buildfarm, or probably anywhere else, was postgres_fdw.sl's reference to libpq.sl; and it turns out that that was always going to libpq.sl in the actual installation directory not the temporary install. We'd not noticed because the buildfarm script does "make install" before it tests contrib. However, the recent addition of a logical-replication test to the core regression scripts resulted in trying to use libpqwalreceiver.sl before "make install" happens, and that failed for lack of finding libpq.sl, as shown by failures on buildfarm members gaur and pademelon. There are two changes needed to fix it: the magic environment variable to specify shlib search path at runtime is SHLIB_PATH not LD_LIBRARY_PATH, and the shlib link command needs to specify the +s switch else the library will not honor SHLIB_PATH. I'm not quite sure why buildfarm members anole and gharial (HPUX 11) didn't show the same failure. Consulting man pages on the web says that HPUX 11 honors both LD_LIBRARY_PATH and SHLIB_PATH, which would explain half of it, and the rather confusing wording I've been able to find suggests that +s might effectively be the default in HPUX 11. But it seems at least as likely that there's just a libpq.so installed in /usr/lib on that machine; as long as it's not too ancient, that would satisfy the test. In any case I do not think this patch will break HPUX 11. At the moment I don't see a need to back-patch this, since it only matters for testing purposes, not to mention that HPUX 10 is probably dead in the real world anyway. http://git.postgresql.org/pg/commitdiff/d2ab1176160e30543da1e48f7e0d17564852b693
- Remove no-longer-needed loop in ExecGather(). Coverity complained quite properly that commit ea15e1867 had introduced unreachable code into ExecGather(); to wit, it was no longer possible to iterate the final for-loop more or less than once. So remove the for(). In passing, clean up a couple of comments, and make better use of a local variable. http://git.postgresql.org/pg/commitdiff/0a8b9d3b2c57028f7100078cd711370f396d5a81
- Relocate static function declarations to be after typedefs in jsonfuncs.c. Project style is to put things in this order, for the good and sufficient reason that you often need the typedefs in the function declarations. There already was one function declaration that needed a typedef, which was randomly placed away from all the other static function declarations in consequence. And the submitted patch for better json_populate_record functionality jumped through even more hoops in order to preserve this bad idea. This patch only moves lines from point A to point B, no other changes. http://git.postgresql.org/pg/commitdiff/90992e0e2f9fc4aa0f6402f0327604e5fef4630c
Peter Eisentraut pushed:
- doc: Update URL for Microsoft download site. http://git.postgresql.org/pg/commitdiff/6181c34da882544c4842e7442189a7ea1dd03032
- Rename C symbols for backend lo_ functions. Rename the C symbols for lo_* to be_lo_*, so they don't conflict with libpq prototypes. Reviewed-by: Pavel Stehule <firstname.lastname@example.org> http://git.postgresql.org/pg/commitdiff/6fc547960dbe0b8bd6cefae5ab7ec3605a5c46fc.
- Register missing money operators in system catalogs. The operators money*int8, int8*money, and money/int8 were implemented in code but not registered in pg_operator or pg_proc. Reviewed-by: Pavel Stehule <email@example.com> http://git.postgresql.org/pg/commitdiff/323b96aa34239b5a8fe773d614a6ee50d731a683.
- Remove unnecessary prototypes in loadable modules. Reviewed-by: Pavel Stehule <firstname.lastname@example.org> http://git.postgresql.org/pg/commitdiff/5d7c9c906a0b888dcfd3b0a2f2170e1f5ca366c4
- Add more tests for money type. Add tests for functions currently not covered at all. Reviewed-by: Pavel Stehule <email@example.com> http://git.postgresql.org/pg/commitdiff/09e35315ccafb83c52da2e0fd6a0a9be410ce6a4
- Remove unnecessary include. Between 6eeb95f0f56bb5e8a0a9328aeec04c9e6de87272 and 7b1c2a0f2066672b24f6257ec9b8d78a1754f494, builtins.h contained additional prototypes that have now been moved elsewhere, so we don't need to include nodes/parsenodes.h anymore. Fix some files that were relying on builtins.h implicitly pulling in some unrelated stuff they needed. Reviewed-by: Pavel Stehule <firstname.lastname@example.org> http://git.postgresql.org/pg/commitdiff/30b9a4495a8ec1f20ba518b34d679c700eadab16
- Correct include file path. Mistake in 352a24a1f9d6f7d4abb1175bfd22acc358f43140, not clear why it worked for some before. http://git.postgresql.org/pg/commitdiff/063ef8308b148e3581ddb626fdb397f7a5a48303
- Generate fmgr prototypes automatically. Gen_fmgrtab.pl creates a new file fmgrprotos.h, which contains prototypes for all functions registered in pg_proc.h. This avoids having to manually maintain these prototypes across a random variety of header files. It also automatically enforces a correct function signature, and since there are warnings about missing prototypes, it will detect functions that are defined but not registered in pg_proc.h (or otherwise used). Reviewed-by: Pavel Stehule <email@example.com> http://git.postgresql.org/pg/commitdiff/352a24a1f9d6f7d4abb1175bfd22acc358f43140
- initdb: Fix for mixed-case superuser names. The previous coding did not properly quote the user name before casting it to regrole. To avoid all that, just pass in BOOTSTRAP_SUPERUSERID numerically. Also fix one place where the BOOTSTRAP_SUPERUSERID was hardcoded as 10. http://git.postgresql.org/pg/commitdiff/8b0fec93ecc788c8d8b329d41ab795712d8dcc5a
- Add function to import operating system collations. Move this logic out of initdb into a user-callable function. This simplifies the code and makes it possible to update the standard collations later on if additional operating system collations appear. Reviewed-by: Andres Freund <firstname.lastname@example.org> Reviewed-by: Euler Taveira <email@example.com> http://git.postgresql.org/pg/commitdiff/aa17c06fb58533d09c79c68a4d34a6f56687ee38
- Bump catversion. http://git.postgresql.org/pg/commitdiff/e4c27f5befbfc80a1bf96fc93256dce08b148238
- Paper over pg_upgrade test failure. The publication test didn't drop all the publications it was creating when it was probably intending to do that. There is still a bug with dependency tracking in there, but this should at least quiet down the build farm. http://git.postgresql.org/pg/commitdiff/6c488ea13634897df5f9b5769eb26bbc3d926ce0
- Move some things from builtins.h to new header files. This avoids that builtins.h has to include additional header files. http://git.postgresql.org/pg/commitdiff/f21a563d25dbae153937aec062161184189478b8
- Logical replication. - Add PUBLICATION catalogs and DDL. - Add SUBSCRIPTION catalog and DDL. - Define logical replication protocol and output plugin. - Add logical replication workers. From: Petr Jelinek <firstname.lastname@example.org> Reviewed-by: Steve Singer <email@example.com> Reviewed-by: Andres Freund <firstname.lastname@example.org> Reviewed-by: Erik Rijkers <email@example.com> Reviewed-by: Peter Eisentraut <firstname.lastname@example.org> http://git.postgresql.org/pg/commitdiff/665d1fad99e7b11678b0d5fa24d2898424243cd6
- Add more includes so header files are self-contained. http://git.postgresql.org/pg/commitdiff/b48008676002895c284c9a7a3d4fc7210b58044d
- Add missing break. http://git.postgresql.org/pg/commitdiff/8f164e1eeaf31438f6706ed45efee607a2c7a21b
Álvaro Herrera pushed:
- Fix typo. http://git.postgresql.org/pg/commitdiff/dda7c34555ca3696fd2a8b93d9aabad333c6cb4e
- Fix typo. http://git.postgresql.org/pg/commitdiff/593c75d5c38a47096f11e318cdb3321a5780753f
- Remove dead code in bootstrap. The bootstrap scanner/parser contains code to parse floating point values, but this is not exercised anywhere, so remove it. Reviewed-by: Jim Nasby Discussion: https://email@example.com http://git.postgresql.org/pg/commitdiff/193a7d791ebe2adf32b36d5538e4602a90c3e0fb
- Make messages mentioning type names more uniform. This avoids additional translatable strings for each distinct type, as well as making our quoting style around type names more consistent (namely, that we don't quote type names). This continues what started as f402b9950120. Discussion: https://postgr.es/m/20160401170642.GA57509@alvherre.pgsql http://git.postgresql.org/pg/commitdiff/9a34123bc315e55b33038464422ef1cd2b67dab2
- Change some test macros to return true booleans. These macros work fine when they are used directly in an "if" test or similar, but as soon as the return values are assigned to boolean variables (or passed as boolean arguments to some function), they become bugs, hopefully caught by compiler warnings. To avoid future problems, fix the definitions so that they return actual booleans. To further minimize the risk that somebody uses them in back-patched fixes that only work correctly in branches starting from the current master and not in old ones, back-patch the change to supported branches as appropriate. See also commit af4472bcb88ab36b9abbe7fd5858e570a65a2d1a, and the long discussion (and larger patch) in the thread mentioned in its commit message. Discussion: https://firstname.lastname@example.org http://git.postgresql.org/pg/commitdiff/594e61a1de03ab93779e7e3d853edb7859d5c3cf
- Allow negative years in make_date to represent BC years. There doesn't seem to be any reason not to allow negative years to be interpreted as BC, so do that. The documentation is pretty vague on the details of this function, so nothing needs to change there. Reported-by: Andy Abelisto, in bug #14446 http://git.postgresql.org/pg/commitdiff/30bcebbdcf23eb8b78e553c4b3b5eb847410ef19
- Fix race condition in reading commit timestamps. If a user requests the commit timestamp for a transaction old enough that its data is concurrently being truncated away by vacuum at just the right time, they would receive an ugly internal file-not-found error message from slru.c rather than the expected NULL return value. In a primary server, the window for the race is very small: the lookup has to occur exactly between the two calls by vacuum, and there's not a lot that happens between them (mostly just a multixact truncate). In a standby server, however, the window is larger because the truncation is executed as soon as the WAL record for it is replayed, but the advance of the oldest-Xid is not executed until the next checkpoint record. To fix in the primary, simply reverse the order of operations in vac_truncate_clog. To fix in the standby, augment the WAL truncation record so that the standby is aware of the new oldest-XID value and can apply the update immediately. WAL version bumped because of this. No backpatch, because of the low importance of the bug and its rarity. Author: Craig Ringer Reviewed-By: Petr Jelínek, Peter Eisentraut Discussion: https://postgr.es/m/CAMsr+YFhVtRQT1VAwC+WGbbxZZRzNou=N9Ed-FrCqkwQ8H8oJQ@mail.gmail.com http://git.postgresql.org/pg/commitdiff/8eace46d34ab6ac0d887aa4d3504bc4222c2e448
- tests: Use the right Perl operator. We were using != to compare strings, for which "ne" is the right thing. It's not clear why it works everywhere except on Pavan's machine, but it's clearly bogus anyway. Author and reporter: Pavan Deolasee Discussion: https://postgr.es/m/CABOikdPhsHM+pX8skoEY1_T0OtKdO1udzUj4VCjU5VEt+bj4eA@mail.gmail.com http://git.postgresql.org/pg/commitdiff/a600ee9e3fcc43d4497d18d837f1e86148ca7580
- Record dependencies on owners for logical replication objects. This was forgotten in 665d1fad99e7b11678b0d5fa24d2898424243cd6 and caused the whole buildfarm to become red for a little while. Author: Petr Jelínek. Also fix a typo in a nearby error message. http://git.postgresql.org/pg/commitdiff/50cf1c80e6be80cc620749824fe9e3cd7f6c118e
Robert Haas pushed:
- Factor out logic for computing number of parallel workers. Forthcoming patches to allow other types of parallel scans will need this logic, or something like it. Dilip Kumar http://git.postgresql.org/pg/commitdiff/716c7d4b242f0a64ad8ac4dc48c6fed6557ba12c
- Update information_schema queries and system views for new relkind. The original table partitioning patch overlooked this. Discussion: http://postgr.es/m/CAG1_KcDJiZB=L6yOUO_bVufj2q2851_xdkfhw0JdcD_2VtKssw@mail.gmail.com Keith Fiske and Amit Langote, adjusted by me. http://git.postgresql.org/pg/commitdiff/262e821deced47337d6d807515997567bb45fd7d
- Add some more tests for tuple routing. Commit a25665088d812d08bb888e961f208eaebf522050 fixed some issues with how PartitionDispatch related code handled multi-level partitioned tables, but didn't add any tests. Discussion: http://postgr.es/m/CA%2BTgmoZ86v1G%2Bzx9etMiSQaBBvYMKfU-iitqZArSh5z0n8Q4cA%40mail.gmail.com Amit Langote, per a complaint from me. http://git.postgresql.org/pg/commitdiff/d26fa4fd47ae5f09c214e954ae9cf8a890bd3c35
- Avoid use of DROP TABLE .. CASCADE in partitioning tests. This isn't really guaranteed to always produce exactly the same output; the order can change from run to run. See related cleanup in 257d8157205a7be5f9799e8941b922521d678a25. http://git.postgresql.org/pg/commitdiff/e509e7f9e3c565043e1186f5a83122d71653d111
- Improve comment in hashsearch.c. Typo fix from Mithun Cy; other improvements by me. http://git.postgresql.org/pg/commitdiff/e37360d5df240443bb6e997d26d54f59146283fc
- Fix failure to enforce partitioning contraint for internal partitions. When a tuple is inherited into a partitioning root, no partition constraints need to be enforced; when it is inserted into a leaf, the parent's partitioning quals needed to be enforced. The previous coding got both of those cases right. When a tuple is inserted into an intermediate level of the partitioning hierarchy (i.e. a table which is both a partition itself and in turn partitioned), it must enforce the partitioning qual inherited from its parent. That case got overlooked; repair. Amit Langote http://git.postgresql.org/pg/commitdiff/39162b2030fb0a35a6bb28dc636b5a71b8df8d1c
- Fix RETURNING to work correctly with partition tuple routing. In ExecInsert(), do not switch back to the root partitioned table ResultRelInfo until after we finish ExecProcessReturning(), so that RETURNING projection is done using the partition's descriptor. For the projection to work correctly, we must initialize the same for each leaf partition during ModifyTableState initialization. Amit Langote http://git.postgresql.org/pg/commitdiff/05bd889904e03479a7169b1c36e0e1db13fff7cb
- Fix some problems in check_new_partition_bound(). Account for the fact that the highest bound less than or equal to the upper bound might be either the lower or the upper bound of the overlapping partition, depending on whether the proposed partition completely contains the existing partition or merely overlaps it. Also, we need not continue searching for even greater bound in partition_bound_bsearch() once we find the first bound that is *equal* to the probe, because we don't have duplicate datums. That spends cycles needlessly. Amit Langote, per a report from Amul Sul. Cosmetic changes by me. Discussion: http://postgr.es/m/CAAJ_b94XgbqVoXMyxxs63CaqWoMS1o2gpHiU0F7yGnJBnvDc_A%40mail.gmail.com http://git.postgresql.org/pg/commitdiff/8a8afe2f54c27dbb47df3853803158c5205d41ce
- Avoid some code duplication in map_partition_varattnos(). Code to map attribute numbers in map_partition_varattnos() duplicates what convert_tuples_by_name_map() does. Avoid that. Amit Langote, per a report from Álvaro Herrera. Discussion: http://postgr.es/m/9ce97382-54c8-deb3-9ee9-a2ec271d866b%40lab.ntt.co.jp http://git.postgresql.org/pg/commitdiff/cc144155f7cdd51e19984f82da6625dc75de9fda
- Teach partitioning tests not to use DROP TABLE ... CASCADE. This occasionally causes failures; the order in which the affected objects are listed is not 100% consistent. Amit Langote http://git.postgresql.org/pg/commitdiff/c3978149536a9c3fb837524407c58dec2b103c60
- Fix comparison logic in partition_bounds_equal for non-finite bounds. If either bound is infinite, then we shouldn't even try to perform a comparison of the values themselves. Rearrange the logic so that we don't. Per buildfarm member skink and Tom Lane. http://git.postgresql.org/pg/commitdiff/6546ffb35db78365d9f0011d75d16625e6040437
- Avoid useless respawining the autovacuum launcher at high speed. When (1) autovacuum = off and (2) there's at least one database with an XID age greater than autovacuum_freeze_max_age and (3) all tables in that database that need vacuuming are already being processed by a worker and (4) the autovacuum launcher is started, a kind of infinite loop occurs. The launcher starts a worker and immediately exits. The worker, finding no worker to do, immediately starts the launcher, supposedly so that the next database can be processed. But because datfrozenxid for that database hasn't been advanced yet, the new worker gets put right back into the same database as the old one, where it once again starts the launcher and exits. High-speed ping pong ensues. There are several possible ways to break the cycle; this seems like the safest one. Amit Khandekar (code) and Robert Haas (comments), reviewed by Álvaro Herrera. Discussion: http://postgr.es/m/CAJ3gD9eWejf72HKquKSzax0r+epS=nAbQKNnykkMA0E8c+rMDg@mail.gmail.com http://git.postgresql.org/pg/commitdiff/c6a389792e08980e395055ac219303cf4357ba33
Andres Freund pushed:
- Move targetlist SRF handling from expression evaluation to new executor node. Evaluation of set returning functions (SRFs_ in the targetlist (like SELECT generate_series(1,5)) so far was done in the expression evaluation (i.e. ExecEvalExpr()) and projection (i.e. ExecProject/ExecTargetList) code. This meant that most executor nodes performing projection, and most expression evaluation functions, had to deal with the possibility that an evaluated expression could return a set of return values. That's bad because it leads to repeated code in a lot of places. It also, and that's my (Andres's) motivation, made it a lot harder to implement a more efficient way of doing expression evaluation. To fix this, introduce a new executor node (ProjectSet) that can evaluate targetlists containing one or more SRFs. To avoid the complexity of the old way of handling nested expressions returning sets (e.g. having to pass up ExprDoneCond, and dealing with arguments to functions returning sets etc.), those SRFs can only be at the top level of the node's targetlist. The planner makes sure (via split_pathtarget_at_srfs()) that SRF evaluation is only necessary in ProjectSet nodes and that SRFs are only present at the top level of the node's targetlist. If there are nested SRFs the planner creates multiple stacked ProjectSet nodes. The ProjectSet nodes always get input from an underlying node. We also discussed and prototyped evaluating targetlist SRFs using ROWS FROM(), but that turned out to be more complicated than we'd hoped. While moving SRF evaluation to ProjectSet would allow to retain the old "least common multiple" behavior when multiple SRFs are present in one targetlist (i.e. continue returning rows until all SRFs are at the end of their input at the same time), we decided to instead only return rows till all SRFs are exhausted, returning NULL for already exhausted ones. We deemed the previous behavior to be too confusing, unexpected and actually not particularly useful. As a side effect, the previously prohibited case of multiple set returning arguments to a function, is now allowed. Not because it's particularly desirable, but because it ends up working and there seems to be no argument for adding code to prohibit it. Currently the behavior for COALESCE and CASE containing SRFs has changed, returning multiple rows from the expression, even when the SRF containing "arm" of the expression is not evaluated. That's because the SRFs are evaluated in a separate ProjectSet node. As that's quite confusing, we're likely to instead prohibit SRFs in those places. But that's still being discussed, and the code would reside in places not touched here, so that's a task for later. There's a lot of, now superfluous, code dealing with set return expressions around. But as the changes to get rid of those are verbose largely boring, it seems better for readability to keep the cleanup as a separate commit. Author: Tom Lane and Andres Freund Discussion: https://email@example.com http://git.postgresql.org/pg/commitdiff/69f4b9c85f168ae006929eec44fc44d569e846b9
- Adapt python regression tests to 69f4b9c85f16. Hopefully this'll unbreak the buildfarm. http://git.postgresql.org/pg/commitdiff/8b07aee8c5d803801c00103f0d61e32356aaf29c
- Remove obsoleted code relating to targetlist SRF evaluation. Since 69f4b9c plain expression evaluation (and thus normal projection) can't return sets of tuples anymore. Thus remove code dealing with that possibility. This will require adjustments in external code using ExecEvalExpr()/ExecProject() - that should neither be hard nor very common. Author: Andres Freund and Tom Lane Discussion: https://firstname.lastname@example.org http://git.postgresql.org/pg/commitdiff/ea15e18677fc2eff3135023e27f69ed8821554ed
- Fix platform dependant regression output triggered by 69f4b9c85f16. Due to the changed costing in that commit hash-aggregates started to be used, which results in big-endian vs. little-endian output differences. Disable hash-aggs for those tests. Author: Andres Freund, with input from Tom Lane Discussion: https://email@example.com http://git.postgresql.org/pg/commitdiff/182200531a92204b0547d337f50b665d222af168
Stephen Frost pushed:
- Dump sequence data based on the TableDataInfo flag. When considering a sequence's Data entry in dumpSequenceData, we were actually looking at the sequence definition's dump flag to decide if we should dump the data or not. That's generally fine, except for when the sequence data entry was created by processExtensionTables() because it's a config sequence. In that case, the sequence itself won't be marked as dumping data because it's part of an extension, leading to the need for processExtensionTables() to create the sequence data entry. This leads to extension config sequence data not being included in the dump when it should be. Fix this by looking at the sequence data's dump flag instead, just as dumpTableData() was doing for tables (which is why config tables were correctly being handled), and add a regression test to make sure we don't break it moving forward. All of this is a bit round-about since we can now represent which components of a given dump item should be dumped out through the dump flag. A future improvement might be to change checkExtensionMembership() to check for config sequences/tables and set the dump flag based on that directly, possibly removing the need for processExtensionTables(). Bug found by Daniele Varrazzo. Discussion: https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=UAG14dVqvftdmvw8OJ3gQ@mail.gmail.com Patch by Michael Paquier, with some tweaking of the regression tests by me. Back-patch to 9.6 where the bug was introduced. http://git.postgresql.org/pg/commitdiff/bec96c82f8ff4fcf7ef0f070f6f7447edf106de3
Correctifs en attente
Michaël Paquier and Karl O. Pinc traded patches to implement pg_current_logfile().
Michaël Paquier sent in another revision of a patch to rename pg_clog to pg_xact and pg_subtrans to pg_subxact.
Masahiko Sawada sent in two more revisions of a patch to support FDW transactions.
Amit Kapila sent in another revision of a patch to parallelize queries containing subplans.
Haribabu Kommi sent in four more revisions of a patch to implement a pg_hba_file_settings view.
Beena Emerson and Robert Haas traded patches to enable increasing WAL segment size.
Amit Kapila and Robert Haas traded patches to enable parallel index scans.
Michaël Paquier sent in a flock of back-patches for an issue in backups on standbys uncovered by sqlsmith.
Mithun Cy sent in another revision of a patch to cache hash index meta pages.
Nikita Glukhov sent in a patch to implement K-nearest-neighbor for B-Tree indexes.
Dilip Kumar sent in another revision of a patch to implement parallel bitmap heap scan.
Magnus Hagander and Michaël Paquier traded patches to implement a version of jsonb_delete which takes arrays as input.
Haribabu Kommi sent in another revision of a patch to implement a pg_stat_sql view.
Etsuro Fujita sent in another revision of a patch to fix a bug in foreign joins.
David Rowley sent in two more revisions of a patch to improve performance for outer joins where the outer side is unique.
Haribabu Kommi sent in another revision of a patch to implement a 64-bit macaddr type.
Ashutosh Sharma sent in another revision of a patch to add pgstathashindex to the pgstattuple extension.
Ashutosh Sharma and Jesper Pedersen traded patches to add hash index support to pageinspect.
Petr Jelínek sent in two more revisions of a patch to enable logical replication support for the initial data copy.
Petr Jelínek sent in another revision of a patch to add RENAME support for PUBLICATIONs and SUBSCRIPTIONs.
Petr Jelínek sent in a flock of patches to fix issues in logical replication.
Rafia Sabih sent in another revision of a patch to implement parallel index-only scans.
Pavan Deolasee sent in another revision of a patch to implement WARM.
Dmitry Fedin sent in a patch to change a misleading comment in pgtime.h.
Yugo Nagata sent in a patch to fix a comment in freelist.c.
Erik Rijkers sent in a patch to improve the logical replication documentation.
Jim Nasby sent in a patch to protect syscache from bloating with negative cache entries.
Petr Jelínek sent in a patch to fix AFTER trigger execution in logical replication.
Tom Lane sent in another revision of a patch to prevent the possibility of UNKNOWN output columns.