Nouvelles hebdomadaires de PostgreSQL - 10 décembre 2017
L'appel à conférenciers pour la PGCon 2018 à Ottawa court jusqu'au 19 janvier 2018 : https://www.pgcon.org/2018/papers.php
[ndt: MeetUp à Paris le 18 janvier : https://www.meetup.com/fr-FR/PostgreSQL-User-Group-Paris/]
Les nouveautés des produits dérivés
- OmniDB 2.4, un outil de gestion de BDD via navigateur web : https://www.2ndquadrant.com/en/resources/omnidb/
- check_pgactivity 2.3, un agent distant de Nagios pour surveiller PostgreSQL : https://github.com/OPMDG/check_pgactivity/releases
- PostgreSQL PHP Generator Lite : http://www.sqlmaestro.com/products/postgresql/phpgenerator/
- pitrery 2.0, un ensemble de scripts Bash permettant de gérer les sauvegardes PITR de PostgreSQL : https://github.com/dalibo/pitrery
Offres d'emplois autour de PostgreSQL en décembre
- Internationales : http://archives.postgresql.org/pgsql-jobs/2017-12/
- Francophones : http://forums.postgresql.fr/viewforum.php?id=4
PostgreSQL Local
- [ndt: MeetUp à Toulouse le 13 décembre : https://www.meetup.com/PostgreSQL-User-Group-Toulouse/]
- [ndt: MeetUp à Lyon le 13 décembre : https://www.meetup.com/PostgreSQL-Lyon-User-Group/]
- FOSDEM PGDay 2018, une conférence d'une journée tenue avant l'événement principal, sera tenue à Bruxelles (Belgique) le 2 février 2018 : https://2018.fosdempgday.org/
- Prague PostgreSQL Developer Day 2018 (P2D2 2018) est une série de conférences sur deux jours qui aura lieu les 14 & 15 février 2018 à Prague (République Tchèque). L'appel à conférenciers est lancé jusqu'au 5 janvier 2018 à l'adresse https://p2d2.cz/callforpapers : http://www.p2d2.cz/
- La PGConf India 2018 aura lieu les 22 & 23 février 2018 à Bengalore (État du Karnataka en Inde) : http://pgconf.in/
- PostgreSQL@SCaLE est un événement de 2 jours à double programmes qui aura lieu les 8 & 9 mars 2018 au centre de convention de Pasadena, intégré au SCaLE 16X : http://www.socallinuxexpo.org/scale/16x/cfp
- Le PGDay nordique 2018 se tiendra à Oslo (Norvège) à l'hôtel Radisson Blu le 13 mars 2018. L'appel à conférenciers s'éteint le 31 décembre 2017 : https://2018.nordicpgday.org/cfp/
- Le pgDay Paris 2018 aura lieu à l'espace Saint Martin (Paris, France) le 15 mars 2018. L'appel à conférenciers court jusqu'au 31 décembre 2017 : http://2018.pgday.paris/callforpapers/
- PGConf APAC 2018 se tiendra à Singapour du 22 au 24 mars 2018 : http://2018.pgconfapac.org/
- La conférence germanophone PostgreSQL Conference 2018 aura lieu le 13 avril 2018 à Berlin. L'appel à conférenciers est ouvert à l'adresse http://2018.pgconf.de/de/callforpapers.html jusqu'au 9 janvier 2018, et le site de la conférence est disponible ici : http://2018.pgconf.de/
- La PGCon 2018 se tiendra à Ottawa du 29 mai au 1er juin 2018. L'appel à conférenciers court jusqu'au 19 janvier 2018 à l'adresse https://www.pgcon.org/2018/papers.php : https://www.pgcon.org/2018/
- La PGConf.Brazil 2018 aura lieu à São Paulo (Brésil) les 3 & 4 août 2018. L'appel à conférenciers sera lancé prochainement : http://pgconf.com.br
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/20171210191901.GA9755@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.
Correctifs appliqués
Robert Haas pushed:
- Remove memory leak protection from Gather and Gather Merge nodes. Before commit 6b65a7fe62e129d5c2b85cd74d6a91d8f7564608, tqueue.c could perform tuple remapping and thus leak memory, which is why commit af33039317ddc4a0e38a02e2255c2bf453115fd2 made TupleQueueReaderNext run in a short-lived context. Now, however, tqueue.c has been reduced to a shadow of its former self, and there shouldn't be any chance of leaks any more. Accordingly, remove some tuple copying and memory context manipulation to speed up processing. Patch by me, reviewed by Amit Kapila. Some testing by Rafia Sabih. Discussion: http://postgr.es/m/CAA4eK1LSDydwrNjmYSNkfJ3ZivGSWH9SVswh6QpNzsMdj_oOQA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9f4992e2a9939a4c3d560c2ac58067861ee0029a
- Mark assorted variables PGDLLIMPORT. This makes life easier for extension authors who wish to support Windows. Brian Cloutier, slightly amended by me. Discussion: http://postgr.es/m/CAJCy68fscdNhmzFPS4kyO00CADkvXvEa-28H-OtENk-pa2OTWw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c572599c65bfe0387563233faabecd2845073538
- postgres_fdw: Fix failing regression test. Commit ab3f008a2dc364cf7fb75de0a691fb0c61586c8e broke this. Report by Stephen Frost. Discussion: http://postgr.es/m/20171205180342.GO4628@tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/82c5c533d1f55dfbf3eacc61aff64fedc8915d78
- postgres_fdw: Judge password use by run-as user, not session user. This is a backward incompatibility which should be noted in the release notes for PostgreSQL 11. For security reasons, we require that a postgres_fdw foreign table use password authentication when accessing a remote server, so that an unprivileged user cannot usurp the server's credentials. Superusers are exempt from this requirement, because we assume they are entitled to usurp the server's credentials or, at least, can find some other way to do it. But what should happen when the foreign table is accessed by a view owned by a user different from the session user? Is it the view owner that must be a superuser in order to avoid the requirement of using a password, or the session user? Historically it was the latter, but this requirement makes it the former instead. This allows superusers to delegate to other users the right to select from a foreign table that doesn't use password authentication by creating a view over the foreign table and handing out rights to the view. It is also more consistent with the idea that access to a view should use the view owner's privileges rather than the session user's privileges. The upshot of this change is that a superuser selecting from a view created by a non-superuser may now get an error complaining that no password was used, while a non-superuser selecting from a view created by a superuser will no longer receive such an error. No documentation changes are present in this patch because the wording of the documentation already suggests that it works this way. We should perhaps adjust the documentation in the back-branches, but that's a task for another patch. Originally proposed by Jeff Janes, but with different semantics; adjusted to work like this by me per discussion. Discussion: http://postgr.es/m/CA+TgmoaY4HsVZJv5SqEjCKLDwtCTSwXzKpRftgj50wmMMBwciA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ab3f008a2dc364cf7fb75de0a691fb0c61586c8e
- Fix accumulation of parallel worker instrumentation. When a Gather or Gather Merge node is started and stopped multiple times, the old code wouldn't reset the shared state between executions, potentially resulting in dramatically inflated instrumentation data for nodes beneath it. (The per-worker instrumentation ended up OK, I think, but the overall totals were inflated.) Report by hubert depesz lubaczewski. Analysis and fix by Amit Kapila, reviewed and tweaked a bit by me. Discussion: http://postgr.es/m/20171127175631.GA405@depesz.com https://git.postgresql.org/pg/commitdiff/2c09a5c12a66087218c7f8cba269cd3de51b9b82
- Fix Parallel Append crash. Reported by Tom Lane and the buildfarm. Amul Sul and Amit Khandekar Discussion: http://postgr.es/m/17868.1512519318@sss.pgh.pa.us Discussion: http://postgr.es/m/CAJ3gD9cJQ4d-XhmZ6BqM9rMM2KDBfpkdgOAb4+psz56uBuMQ_A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9c64ddd414855fb10e0355e887745270a4464c50
- Report failure to start a background worker. When a worker is flagged as BGW_NEVER_RESTART and we fail to start it, or if it is not marked BGW_NEVER_RESTART but is terminated before startup succeeds, what BgwHandleStatus should be reported? The previous code really hadn't considered this possibility (as indicated by the comments which ignore it completely) and would typically return BGWH_NOT_YET_STARTED, but that's not a good answer, because then there's no way for code using GetBackgroundWorkerPid() to tell the difference between a worker that has not started but will start later and a worker that has not started and will never be started. So, when this case happens, return BGWH_STOPPED instead. Update the comments to reflect this. The preceding fix by itself is insufficient to fix the problem, because the old code also didn't send a notification to the process identified in bgw_notify_pid when startup failed. That might've been technically correct under the theory that the status of the worker was BGWH_NOT_YET_STARTED, because the status would indeed not change when the worker failed to start, but now that we're more usefully reporting BGWH_STOPPED, a notification is needed. Without these fixes, code which starts background workers and then uses the recommended APIs to wait for those background workers to start would hang indefinitely if the postmaster failed to fork a worker. Amit Kapila and Robert Haas Discussion: http://postgr.es/m/CAA4eK1KDfKkvrjxsKJi3WPyceVi3dH1VCkbTJji2fuwKuB=3uw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/28724fd90d2f85a0573a8107b48abad062a86d83
- When VACUUM or ANALYZE skips a concurrently dropped table, log it. Hopefully, the additional logging will help avoid confusion that could otherwise result. Nathan Bossart, reviewed by Michael Paquier, Fabrízio Mello, and me https://git.postgresql.org/pg/commitdiff/ab6eaee88420db58a948849d5a735997728d73a9
- Support Parallel Append plan nodes. When we create an Append node, we can spread out the workers over the subplans instead of piling on to each subplan one at a time, which should typically be a bit more efficient, both because the startup cost of any plan executed entirely by one worker is paid only once and also because of reduced contention. We can also construct Append plans using a mix of partial and non-partial subplans, which may allow for parallelism in places that otherwise couldn't support it. Unfortunately, this patch doesn't handle the important case of parallelizing UNION ALL by running each branch in a separate worker; the executor infrastructure is added here, but more planner work is needed. Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and Rajkumar Raghuwanshi. Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ab72716778128fb63d54ac256adf7fe6820a1185
- Speed up isolation test for concurrent VACUUM/ANALYZE behavior. Per Tom Lane, the old test sometimes times out with CLOBBER_CACHE_ALWAYS. Nathan Bossart Discussion: http://postgr.es/m/28614.1512583046@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0a3edbb3302173f8ac465570b6273392aa6e20b1
Tom Lane pushed:
- Support boolean columns in functional-dependency statistics. There's no good reason that the multicolumn stats stuff shouldn't work on booleans. But it looked only for "Var = pseudoconstant" clauses, and it will seldom find those for boolean Vars, since earlier phases of planning will fold "boolvar = true" or "boolvar = false" to just "boolvar" or "NOT boolvar" respectively. Improve dependencies_clauselist_selectivity() to recognize such clauses as equivalent to equality restrictions. This fixes a failure of the extended stats mechanism to apply in a case reported by Vitaliy Garnashevich. It's not a complete solution to his problem because the bitmap-scan costing code isn't consulting extended stats where it should, but that's surely an independent issue. In passing, improve some comments, get rid of a NumRelids() test that's redundant with the preceding bms_membership() test, and fix dependencies_clauselist_selectivity() so that estimatedclauses actually is a pure output argument as stated by its API contract. Back-patch to v10 where this code was introduced. Discussion: https://postgr.es/m/73a4936d-2814-dc08-ed0c-978f76f435b0@gmail.com https://git.postgresql.org/pg/commitdiff/ecc27d55f4c37a8485a7d0e1dae0eb5ef2bc886e
- Clean up assorted messiness around AllocateDir() usage. This patch fixes a couple of low-probability bugs that could lead to reporting an irrelevant errno value (and hence possibly a wrong SQLSTATE) concerning directory-open or file-open failures. It also fixes places where we took shortcuts in reporting such errors, either by using elog instead of ereport or by using ereport but forgetting to specify an errcode. And it eliminates a lot of just plain redundant error-handling code. In service of all this, export fd.c's formerly-static function ReadDirExtended, so that external callers can make use of the coding pattern dir = AllocateDir(path); while ((de = ReadDirExtended(dir, path, LOG)) != NULL) if they'd like to treat directory-open failures as mere LOG conditions rather than errors. Also fix FreeDir to be a no-op if we reach it with dir == NULL, as such a coding pattern would cause. Then, remove code at many call sites that was throwing an error or log message for AllocateDir failure, as ReadDir or ReadDirExtended can handle that job just fine. Aside from being a net code savings, this gets rid of a lot of not-quite-up-to-snuff reports, as mentioned above. (In some places these changes result in replacing a custom error message such as "could not open tablespace directory" with more generic wording "could not open directory", but it was agreed that the custom wording buys little as long as we report the directory name.) In some other call sites where we can't just remove code, change the error reports to be fully project-style-compliant. Also reorder code in restoreTwoPhaseData that was acquiring a lock between AllocateDir and ReadDir; in the unlikely but surely not impossible case that LWLockAcquire changes errno, AllocateDir failures would be misreported. There is no great value in opening the directory before acquiring TwoPhaseStateLock, so just do it in the other order. Also fix CheckXLogRemoved to guarantee that it preserves errno, as quite a number of call sites are implicitly assuming. (Again, it's unlikely but I think not impossible that errno could change during a SpinLockAcquire. If so, this function was broken for its own purposes as well as breaking callers.) And change a few places that were using not-per-project-style messages, such as "could not read directory" when "could not open directory" is more correct. Back-patch the exporting of ReadDirExtended, in case we have occasion to back-patch some fix that makes use of it; it's not needed right now but surely making it global is pretty harmless. Also back-patch the restoreTwoPhaseData and CheckXLogRemoved fixes. The rest of this is essentially cosmetic and need not get back-patched. Michael Paquier, with a bit of additional work by me Discussion: https://postgr.es/m/CAB7nPqRpOCxjiirHmebEFhXVTK7V5Jvw4bz82p7Oimtsm3TyZA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2069e6faa0f72eba968714b2260cd65436d0ef3a
- Improve error handling in RemovePgTempFiles(). Modify this function and its subsidiaries so that syscall failures are reported via ereport(LOG), rather than silently ignored as before. We don't want to throw a hard ERROR, as that would prevent database startup, and getting rid of leftover temporary files is not important enough for that. On the other hand, not reporting trouble at all seems like an odd choice not in line with current project norms, especially since any failure here is quite unexpected. On the same reasoning, adjust these functions' AllocateDir/ReadDir calls so that failure to scan a directory results in LOG not ERROR. I also removed the previous practice of silently ignoring ENOENT failures during directory opens --- there are some corner cases where that could happen given a previous database crash, but that seems like a bad excuse for ignoring a condition that isn't expected in most cases. A LOG message during postmaster start seems OK in such situations, and better than no output at all. In passing, make RemovePgTempRelationFiles' test for "is the file name all digits" look more like the way it's done elsewhere. Discussion: https://postgr.es/m/19907.1512402254@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/561885db05d3296082ce8750805b8ec322cf9aa1
- Simplify do_pg_start_backup's API by opening pg_tblspc internally. do_pg_start_backup() expects its callers to pass in an open DIR pointer for the pg_tblspc directory, but there's no apparent advantage in that. It complicates the callers without adding any flexibility, and there's no robustness advantage, since we surely have to be prepared for errors during the scan of pg_tblspc anyway. In fact, by holding an extra kernel resource during operations like the preliminary checkpoint, we might be making things a fraction more failure-prone not less. Hence, remove that argument and open the directory just for the duration of the actual scan. Discussion: https://postgr.es/m/28752.1512413887@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/066bc21c0e085e2642ff25cc665c4efad3669d6f
- Treat directory open failures as hard errors in ResetUnloggedRelations(). Previously, this code just reported such problems at LOG level and kept going. The problem with this approach is that transient failures (e.g., ENFILE) could prevent us from resetting unlogged relations to empty, yet allow recovery to appear to complete successfully. That seems like a data corruption hazard large enough to treat such problems as reasons to fail startup. For the same reason, treat unlink failures for unlogged files as hard errors not just LOG messages. It's a little odd that we did it like that when file-level errors in other steps (copy_file, fsync_fname) are ERRORs. The sole case that I left alone is that ENOENT failure on a tablespace (not database) directory is not an error, though it will now be logged rather than just silently ignored. This is to cover the scenario where a previous DROP TABLESPACE removed the tablespace directory but failed before removing the pg_tblspc symlink. I'm not sure that that's very likely in practice, but that seems like the only real excuse for the old behavior here, so let's allow for it. (As coded, this will also allow ENOENT on $PGDATA/base/. But since we'll fail soon enough if that's gone, I don't think we need to complicate this code by distinguishing that from a true tablespace case.) Discussion: https://postgr.es/m/21040.1512418508@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8dc3c971a9d6db5ddc9f0a3c11a70308412d66c3
- Fix broken markup. https://git.postgresql.org/pg/commitdiff/7404704a0c5abf0510a9cd889bd867ce46bdfc4c
- Adjust regression test cases added by commit ab7271677. I suppose it is a copy-and-paste error that this test doesn't actually test the "Parallel Append with both partial and non-partial subplans" case (EXPLAIN alone surely doesn't qualify as a test of executor behavior). Fix that. Also, add cosmetic aliases to make it possible to tell apart these otherwise-identical test cases in log_statement output. https://git.postgresql.org/pg/commitdiff/979a36c3894db0a4b0d6b4b20fc861a0bbe3271c
- In plpgsql, unify duplicate variables for record and row cases. plpgsql's function exec_move_row() handles assignment of a composite source value to either a PLpgSQL_rec or PLpgSQL_row target variable. Oddly, rather than taking a single target argument which it could do run-time type detection on, it was coded to take two separate arguments (only one of which is allowed to be non-NULL). This choice had then back-propagated into storing two separate target variables in various plpgsql statement nodes, with lots of duplicative coding and awkward interface logic to support that. Simplify matters by folding those pairs down to single variables, distinguishing the two cases only where we must ... which turns out to be only in exec_move_row itself. This is purely refactoring and should not change any behavior. In passing, remove unused field PLpgSQL_stmt_open.returntype. Discussion: https://postgr.es/m/11787.1512713374@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/dd759b96ea8fa41b48541dd321c07d9a947f8de9
- Fix plpgsql to reinitialize record variables at block re-entry. If one exits and re-enters a DECLARE ... BEGIN ... END block within a single execution of a plpgsql function, perhaps due to a surrounding loop, the declared variables are supposed to get re-initialized to null (or whatever their initializer is). But this failed to happen for variables of type "record", because while exec_stmt_block() expected such variables to be included in the block's initvarnos list, plpgsql_add_initdatums() only adds DTYPE_VAR variables to that list. This bug appears to have been there since the aboriginal addition of plpgsql to our tree. Fix by teaching plpgsql_add_initdatums() to include DTYPE_REC variables as well. (We don't need to consider other DTYPEs because they don't represent separately-stored values.) I failed to resist the temptation to make some nearby cosmetic adjustments, too. No back-patch, because there have not been field complaints, and it seems possible that somewhere out there someone has code depending on the incorrect behavior. In any case this change would have no impact on correctly-written code. Discussion: https://postgr.es/m/22994.1512800671@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/390d58135b22bc25229b524a60f69682182201d8
Peter Eisentraut pushed:
- Fix warnings from cpluspluscheck. Fix warnings about "comparison between signed and unsigned integer expressions" in inline functions in header files by adding some casts. https://git.postgresql.org/pg/commitdiff/e7cfb26fbc11ea94e93e443e2260e106b6daabdd
- doc: Turn on generate.consistent.ids parameter. This ensures that automatically generated HTML anchors don't change in every build. https://git.postgresql.org/pg/commitdiff/28f8896af0765a05447f605c55fa9f1ab3b41150
- doc: Update memory requirements for FOP. Reported-by: Dave Page <dpage@pgadmin.org> https://git.postgresql.org/pg/commitdiff/8097d189ccc2cd55a8bf189bd21cb196e3cfc385
- doc: Flex is not a GNU package. Remove the designation that Flex is a GNU package. Even though Bison is a GNU package, leave out the designation to not make the sentence unnecessarily complicated. Author: Pavan Maddamsetti <pavan.maddamsetti@gmail.com> https://git.postgresql.org/pg/commitdiff/51cff91c905e3b32c1f9b56d82d5c802b257b157
- Apply identity sequence values on COPY. A COPY into a table should apply identity sequence values just like it does for ordinary defaults. This was previously forgotten, leading to null values being inserted, which in turn would fail because identity columns have not-null constraints. Author: Michael Paquier <michael.paquier@gmail.com> Reported-by: Steven Winfield <steven.winfield@cantabcapital.com> Bug: #14952 https://git.postgresql.org/pg/commitdiff/2d2d06b7e27e3177d5bef0061801c75946871db3
- Fix mistake in comment. Reported-by: Masahiko Sawada <sawada.mshk@gmail.com> https://git.postgresql.org/pg/commitdiff/af9f8b7ca343eefa33b693d7919d8f945aeee3e7
- Prohibit identity columns on typed tables and partitions. Those cases currently crash and supporting them is more work then originally thought, so we'll just prohibit these scenarios for now. Author: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> Reported-by: Мансур Галиев <gomer94@yandex.ru> Bug: #14866 https://git.postgresql.org/pg/commitdiff/005ac298b1bdc3e9bd19e5ee2bcf7e320ebe4130
Andres Freund pushed:
- Fix EXPLAIN ANALYZE of hash join when the leader doesn't participate. If a hash join appears in a parallel query, there may be no hash table available for explain.c to inspect even though a hash table may have been built in other processes. This could happen either because parallel_leader_participation was set to off or because the leader happened to hit the end of the outer relation immediately (even though the complete relation is not empty) and decided not to build the hash table. Commit bf11e7ee introduced a way for workers to exchange instrumentation via the DSM segment for Sort nodes even though they are not parallel-aware. This commit does the same for Hash nodes, so that explain.c has a way to find instrumentation data from an arbitrary participant that actually built the hash table. Author: Thomas Munro Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm%3D3DUQC2-z252N55eOcZBer6DPdM%3DFzrxH9dZc5vYLsjaA%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/5bcf389ecfd40daf92238e1abbff4fc4d3f18b33
Noah Misch pushed:
- MSVC: Test whether 32-bit Perl needs -D_USE_32BIT_TIME_T. Commits 5a5c2feca3fd858e70ea348822595547e6fa6c15 and b5178c5d08ca59e30f9d9428fa6fdb2741794e65 introduced support for modern MSVC-built, 32-bit Perl, but they broke use of MinGW-built, 32-bit Perl distributions like Strawberry Perl and modern ActivePerl. Perl has no robust means to report whether it expects a -D_USE_32BIT_TIME_T ABI, so test this. Back-patch to 9.3 (all supported versions). The chief alternative was a heuristic of adding -D_USE_32BIT_TIME_T when $Config{gccversion} is nonempty. That banks on every gcc-built Perl using the same ABI. gcc could change its default ABI the way MSVC once did, and one could build Perl with gcc and the non-default ABI. The GNU make build system could benefit from a similar test, without which it does not support MSVC-built Perl. For now, just add a comment. Most users taking the special step of building Perl with MSVC probably build PostgreSQL with MSVC. Discussion: https://postgr.es/m/20171130041441.GA3161526@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/65a00f30352a3c0ab5615fac008735b103cfa5bb
- MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries. Notably, this permits linking to the 32-bit Perl binaries advertised on perl.org, namely Strawberry Perl and ActivePerl. This has a side effect of permitting linking to binaries built with obsolete MSVC versions. By default, MSVC 2012 and later require a "safe exception handler table" in each binary. MinGW-built, 32-bit DLLs lack the relevant exception handler metadata, so linking to them failed with error LNK2026. Restore the semantics of MSVC 2010, which omits the table from a given binary if some linker input lacks metadata. This has no effect on 64-bit builds or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754ab8f@wagner.wagner.home https://git.postgresql.org/pg/commitdiff/7e0c574ee26ce0308b76166312788e909b555c23
Magnus Hagander pushed:
- Fix typo. Reported by Robins Tharakan https://git.postgresql.org/pg/commitdiff/d8f632caec3fcc5eece9d53d7510322f11489fe4
- Fix regression test output. Missed this in the last commit. https://git.postgresql.org/pg/commitdiff/ce1468d02bdbbe3aa710463fa9faaf8cf865ad72
Correctifs en attente
Yura Sokolov sent in another revision of a patch to improve compactify_tuples.
Dmitry Dolgov sent in another revision of a patch to implement generic type subscripting.
Jing Wang sent in another revision of a patch to implement COMMENT ON DATABASE CURRENT_DATABASE.
John Naylor sent in a patch to make bootstrap data simpler and faster.
Sergei Kornilov sent in another revision of a patch to implement ALTER TABLE ... SET ... NOT NULL by constraints only.
Oliver Ford sent in a patch to add the GROUPS option to window functions.
Fabien COELHO sent in another revision of a patch to add more functions and operators to pgbench.
Konstantin Knizhnik sent in another revision of a patch to add a projection function to CREATE INDEX.
Konstantin Knizhnik sent in another revision of a patch to implement auto-prepare.
Alexander Kuzmenkov sent in another revision of a patch to implement full merge join on comparison clauses.
Konstantin Knizhnik sent in two more revisions of a patch to optimize secondary indexes.
Robert Haas sent in another revision of a patch to improve processing at GATHER nodes.
Raúl Marín Rodríguez sent in another revision of a patch to add pow() support for pgbench.
Nikhil Sontakke and Peter Eisentraut traded patches to implement logical decoding of two-phase transactions.
Alexander Kuzmenkov sent in another revision of a patch to implement CSN-based snapshots.
Dang Minh Huong and Masahiko Sawada traded patches to fix an issue with user-defined types in logical replication.
Craig Ringer sent in a patch to fix an issue where standby disconnect could corrupt serialized reorder buffers.
Rajkumar Raghuwanshi sent in two revisions of a patch to implement partition-wise join with default partitions.
Thomas Munro sent in another revision of a patch to support kqueue.
Nathan Bossart sent in a patch to fix some crash bugs in VACUUM.
Thomas Munro sent in another revision of a patch to fix es_query_dsa.
Nikita Glukhov and Alexander Korotkov traded patches to add compress methods for SP-GiST.
Ashutosh Bapat sent in two revisions of a patch to mention ordered datums in PartitionBoundInfoData comment.
Amit Kapila and Thomas Munro traded patches to fix the EXPLAIN ANALYZE output for the parallel worker case.
Andres Freund sent in a patch to allow tupleslots to have a fixed tupledesc and use same in executor nodes.
Andrew Dunstan sent in another revision of a patch to make ALTER TABLE ADD COLUMN fast with DEFAULT.
Petr Jelínek sent in another revision of a patch to fix walsender timeouts when decoding a large transaction.
Nikita Glukhov sent in two more revisions of a patch to implement compress method for SP-GiST.
Álvaro Herrera sent in two more revisions of a patch to fix freezing of a dead HOT-updated tuple.
Peter Eisentraut sent in another revision of a patch to implement transaction control for procedures in the built-in PLs.
Anthony Bykov sent in another revision of a patch to implement a JSONB transform for PL/PythonU.
David Rowley sent in another revision of a patch to remove Merge]Append nodes which contain a single subpath.
Anthony Bykov sent in another revision of a patch to implement a JSONB transform for PL/Perl.
Peter Geoghegan sent in another revision of a patch to add a Bloom filter data structure implementation and use same to add amcheck verification of indexes against heap.
Peter Eisentraut sent in a patch to start a separate test suite for PL/pgsql.
Alexander Korotkov sent in a patch to fix some pg_trgm word_similarity inconsistencies.
Beena Emerson sent in another revision of a patch to implement runtime partition pruning.
David Rowley sent in a patch to fix an out of date comment in cached_plan_cost.
Ian Barwick sent in a patch to add %r as part of the psql prompt format to show recovery status.
Alexander Korotkov sent in another revision of a patch to fix contrib/cube's KNN.
Rushabh Lathia sent in two more revisions of a patch to implement parallel tuplesort for parallel B-tree index creation.
Thomas Munro sent in a patch to add defenses against pre-crash files to BufFileOpenShared().
Thomas Munro sent in another revision of a patch to make SERIALIZABLE isolation work with parallel query.
Etsuro Fujita sent in a patch to fix incorrect debug info printed in generate_partition_wise_join_paths.
Alexander Korotkov sent in another revision of a patch to implement incremental sort.
Masahiko Sawada sent in another revision of a patch to move relation extension locks out of the heavyweight lock manager.
Masahiko Sawada sent in another revision of a patch to fix an assertion failure when the non-exclusive pg_stop_backup aborted.
Amit Langote sent in a patch to teach operator_predicate_proof() to strip RelabelType.
Andres Freund sent in a patch to provide overflow safe integer math inline functions and hand code string to int32 conversion for performance.
Thomas Munro sent in a patch to add an extra barrier function to enable changing the party size of a static barrier.
Peter Geoghegan sent in a patch to remove a leftover reference to replacement selection 1 run case.
Tom Lane sent in a patch to refactor memory context creation.
Emre Hasegeli sent in a patch to fix a potential endless loop in polygon @> polygon.