== PostgreSQL Weekly News - August 19 2018 ==
| От | David Fetter |
|---|---|
| Тема | == PostgreSQL Weekly News - August 19 2018 == |
| Дата | |
| Msg-id | 20180819185625.GA24035@fetter.org обсуждение исходный текст |
| Список | pgsql-announce |
== PostgreSQL Weekly News - August 19 2018 == == PostgreSQL Product News == Ora2Pg 19.0, a tool for migrating Oracle databases to PostgreSQL, released. http://ora2pg.darold.net/ Ajqvue Version 2.0, a java-based UI which supports PostgreSQL, released. http://ajqvue.com pgbouncer 1.9.0, a connection pooler and more for PostgreSQL, released. https://pgbouncer.github.io/2018/08/pgbouncer-1-9-0 == PostgreSQL Jobs for August == http://archives.postgresql.org/pgsql-jobs/2018-08/ == PostgreSQL Local == PostgreOpen Silicon Valley 2018 will be held in San Francisco on September 5-7, 2018. https://2018.postgresopen.org/ The Portland PostgreSQL Users Group will be holding a PGDay on September 10, 2018 in Portland, OR. The CfP is open at https://goo.gl/forms/E0CiUQGSZGMYwh922 https://pdx.postgresql.us/pdxpgday2018 PostgresConf South Africa 2018 will take place in Johannesburg on October 9, 2018 https://postgresconf.org/conferences/SouthAfrica2018 PostgreSQL Conference Europe 2018 will be held on October 23-26, 2018 at the Lisbon Marriott Hotel in Lisbon, Portugal. https://2017.pgconf.eu/ 2Q PGConf will be on December 4-5, 2018 in Chicago, IL. The CfP is open through August 27, 2018 at midnight Pacific Time at http://www.2qpgconf.com/#cfp http://www.2qpgconf.com/ PGConf.ASIA 2018 will take place on December 10-12, 2018 in Akihabara, Tokyo, Japan. http://www.pgconf.asia/EN/2018/ == PostgreSQL in the News == Planet PostgreSQL: http://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to david@fetter.org. == Applied Patches == Tom Lane pushed: - Revert "Distinguish printf-like functions that support %m from those that don't.". This reverts commit 3a60c8ff892a8242b907f44702bfd9f1ff877d45. Buildfarm results show that that caused a whole bunch of new warnings on platforms where gcc believes the local printf to be non-POSIX-compliant. This problem outweighs the hypothetical-anyway possibility of getting warnings for misuse of %m. We could use gnu_printf archetype when we've substituted src/port/snprintf.c, but that brings us right back to the problem of not getting warnings for %m. A possible answer is to attack it in the other direction by insisting that %m support be included in printf's feature set, but that will take more investigation. In the meantime, revert the previous change, and update the comment for PGAC_C_PRINTF_ARCHETYPE to more fully explain what's going on. Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/46b5e7c4b5befbf6ac86d827a3a58f1f02c7338e - Fix bogus loop logic in 013_crash_restart test's pump_until subroutine. The pump_nb() step might've already received the desired data, so we must check for that at the top of the loop not the bottom. Otherwise, the call to pump() will sit with nothing to do until the timeout elapses. pump_until then falls out with apparent success ... but the timeout has been used up, causing the next call of pump_until to report a timeout failure. I believe this explains the intermittent timeout failures we've seen in the buildfarm ever since this test went in. I was able to reproduce the problem on gaur semi-repeatably, and this appears to fix it. In passing, remove a duplicate assignment, fix one stdin-assignment to look like the rest, and document the test's dependency on test_decoding. https://git.postgresql.org/pg/commitdiff/d11eae09e48694ad6b4139bbb7d7b112833301f5 - Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a attempted to turn the connect_timeout from an overall maximum time limit into a per-host limit, but it didn't do a great job of that. The timer would only get restarted if we actually detected timeout within connectDBComplete(), not if we changed our attention to a new host for some other reason. In that case the old timeout continued to run, possibly causing a premature timeout failure for the new host. Fix that, and also tweak the logic so that if we do get a timeout, we advance to the next available IP address, not to the next host name. There doesn't seem to be a good reason to assume that all the IP addresses supplied for a given host name will necessarily fail the same way as the current one. Moreover, this conforms better to the admittedly-vague documentation statement that the timeout is "per connection attempt". I changed that to "per host name or IP address" to be clearer. (Note that reconnections to the same server, such as for switching protocol version or SSL status, don't get their own separate timeout; that was true before and remains so.) Also clarify documentation about the interpretation of connect_timeout values less than 2. This seems like a bug, so back-patch to v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/1e6e98f7638904b2aa4df0bd87064239ce9d8fcf - Remove duplicate function declarations. Christoph Berg Discussion: https://postgr.es/m/20180814165536.GB21152@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/02dc7466baed074f7833bd6fd1067e23e1bfa1dd - Make snprintf.c follow the C99 standard for snprintf's result value. C99 says that the result should be the number of bytes that would have been emitted given a large enough buffer, not the number we actually were able to put in the buffer. It's time to make our substitute implementation comply with that. Not doing so results in inefficiency in buffer-enlargement cases, and also poses a portability hazard for third-party code that might expect C99-compliant snprintf behavior within Postgres. In passing, remove useless tests for str == NULL; neither C99 nor predecessor standards ever allowed that except when count == 0, so I see no reason to expend cycles on making that a non-crash case for this implementation. Also, don't waste a byte in pg_vfprintf's local I/O buffer; this might have performance benefits by allowing aligned writes during flushbuffer calls. Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/805889d7d23fbecf5925443deb334aaeb6beaeb0 - Clean up assorted misuses of snprintf()'s result value. Fix a small number of places that were testing the result of snprintf() but doing so incorrectly. The right test for buffer overrun, per C99, is "result >= bufsize" not "result > bufsize". Some places were also checking for failure with "result == -1", but the standard only says that a negative value is delivered on failure. (Note that this only makes these places correct if snprintf() delivers C99-compliant results. But at least now these places are consistent with all the other places where we assume that.) Also, make psql_start_test() and isolation_start_test() check for buffer overrun while constructing their shell commands. There seems like a higher risk of overrun, with more severe consequences, here than there is for the individual file paths that are made elsewhere in the same functions, so this seemed like a worthwhile change. Also fix guc.c's do_serialize() to initialize errno = 0 before calling vsnprintf. In principle, this should be unnecessary because vsnprintf should have set errno if it returns a failure indication ... but the other two places this coding pattern is cribbed from don't assume that, so let's be consistent. These errors are all very old, so back-patch as appropriate. I think that only the shell command overrun cases are even theoretically reachable in practice, but there's not much point in erroneous error checks. Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/cc4f6b77861803be99dfc17a38052035a0af5ae6 - Require a C99-compliant snprintf(), and remove related workarounds. Since our substitute snprintf now returns a C99-compliant result, there's no need anymore to have complicated code to cope with pre-C99 behavior. We can just make configure substitute snprintf.c if it finds that the system snprintf() is pre-C99. (Note: I do not believe that there are any platforms where this test will trigger that weren't already being rejected due to our other C99-ish feature requirements for snprintf. But let's add the check for paranoia's sake.) Then, simplify the call sites that had logic to cope with the pre-C99 definition. I also dropped some stuff that was being paranoid about the possibility of snprintf overrunning the given buffer. The only reports we've ever heard of that being a problem were for Solaris 7, which is long dead, and we've sure not heard any reports of these assertions triggering in a long time. So let's drop that complexity too. Likewise, drop some code that wasn't trusting snprintf to set errno when it returns -1. That would be not-per-spec, and again there's no real reason to believe it is a live issue, especially not for snprintfs that pass all of configure's feature checks. Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e1d19c902e59ad739cb4b6267ee2073a61e86cd3 - Fix configure's snprintf test so it exposes HP-UX bug. Since commit e1d19c902, buildfarm member gharial has been failing with symptoms indicating that snprintf sometimes returns -1 for buffer overrun, even though it passes the added configure check. Some google research suggests that this happens only in limited cases, such as when the overrun happens partway through a %d item. Adjust the configure check to exercise it that way. Since I'm now feeling more paranoid than I was before, also make the test explicitly verify that the buffer doesn't get physically overrun. https://git.postgresql.org/pg/commitdiff/9bed827b18cc4f27fb7cd7c02ad301519eca6d29 - Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands. Previously, this code blindly followed the common coding pattern of passing PQserverVersion(AH->connection) as the server-version parameter of fmtQualifiedId. That works as long as we have a connection; but in pg_restore with text output, we don't. Instead we got a zero from PQserverVersion, which fmtQualifiedId interpreted as "server is too old to have schemas", and so the name went unqualified. That still accidentally managed to work in many cases, which is probably why this ancient bug went undetected for so long. It only became obvious in the wake of the changes to force dump/restore to execute with restricted search_path. In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server- version behavioral dependency, and just making it schema-qualify all the time. We no longer support pg_dump from servers old enough to need the ability to omit schema name, let alone restoring to them. (Also, the few callers outside pg_dump already didn't work with pre-schema servers.) In older branches, that's not an acceptable solution, so instead just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify its output regardless of server version. Per bug #15338 from Oleg somebody. Back-patch to all supported branches. Discussion: https://postgr.es/m/153452458706.1316.5328079417086507743@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/6771c932cf5a8bbb8219461066987ad3b11688ff - Doc: remove obsolete advice about manually inserting snprintf into build. This para is obsolete, first because nobody is using Solaris 7 anymore, and second because if someone was, configure should catch the snprintf buffer overrun problem automatically (since commit 9bed827b1), and third because this is incorrect advice about how to manually force use of snprintf.c anyway, and has been so at least since commit 3bc6bdf32. The lack of complaints about it reinforces the conclusion that Solaris 7 no longer exists in the wild; so I don't feel a need to insert correct advice instead. https://git.postgresql.org/pg/commitdiff/47183265ed745d9ee7e0ac0798a5c88660436d4e Andrew Gierth pushed: - Avoid query-lifetime memory leaks in XMLTABLE (bug #15321). Multiple calls to XMLTABLE in a query (e.g. laterally applying it to a table with an xml column, an important use-case) were leaking large amounts of memory into the per-query context, blowing up memory usage. Repair by reorganizing memory context usage in nodeTableFuncscan; use the usual per-tuple context for row-by-row evaluations instead of perValueCxt, and use the explicitly created context -- renamed from perValueCxt to perTableCxt -- for arguments and state for each individual table-generation operation. Backpatch to PG10 where this code was introduced. Original report by IRC user begriffs; analysis and patch by me. Reviewed by Tom Lane and Pavel Stehule. Discussion: https://postgr.es/m/153394403528.10284.7530399040974170549@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/07172d5aff8f43cd6ce09f57a0b56a535d7eaf45 - Set scan direction appropriately for SubPlans (bug #15336). When executing a SubPlan in an expression, the EState's direction field was left alone, resulting in an attempt to execute the subplan backwards if it was encountered during a backwards scan of a cursor. Also, though much less likely, it was possible to reach the execution of an InitPlan while in backwards-scan state. Repair by saving/restoring estate->es_direction and forcing forward scan mode in the relevant places. Backpatch all the way, since this has been broken since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather than sharing the parent plan's, so there was no confusion over scan direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch by me, review by Tom Lane. Discussion: https://postgr.es/m/153449812167.1304.1741624125628126322@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/520acab171244b55d816c70b9a89280b09937925 Amit Kapila pushed: - Prohibit shutting down resources if there is a possibility of back up. Currently, we release the asynchronous resources as soon as it is evident that no more rows will be needed e.g. when a Limit is filled. This can be problematic especially for custom and foreign scans where we can scan backward. Fix that by disallowing the shutting down of resources in such cases. Reported-by: Robert Haas Analysed-by: Robert Haas and Amit Kapila Author: Amit Kapila Reviewed-by: Robert Haas Backpatch-through: 9.6 where this code was introduced Discussion: https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info https://git.postgresql.org/pg/commitdiff/2cd0acfdade82f3cab362fd9129d453f81cc2745 - Adjust comment atop ExecShutdownNode. After commits a315b967cc and b805b63ac2, part of the comment atop ExecShutdownNode is redundant. Adjust it. Author: Amit Kapila Backpatch-through: 10 where both the mentioned commits are present. Discussion: https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info https://git.postgresql.org/pg/commitdiff/4f9a97e417ca3c162c2c83918873e3ac2cf0ace4 Michaël Paquier pushed: - Make autovacuum more aggressive to remove orphaned temp tables. Commit dafa084, added in 10, made the removal of temporary orphaned tables more aggressive. This commit makes an extra step into the aggressiveness by adding a flag in each backend's MyProc which tracks down any temporary namespace currently in use. The flag is set when the namespace gets created and can be reset if the temporary namespace has been created in a transaction or sub-transaction which is aborted. The flag value assignment is assumed to be atomic, so this can be done in a lock-less fashion like other flags already present in PGPROC like databaseId or backendId, still the fact that the temporary namespace and table created are still locked until the transaction creating those commits acts as a barrier for other backends. This new flag gets used by autovacuum to discard more aggressively orphaned tables by additionally checking for the database a backend is connected to as well as its temporary namespace in-use, removing orphaned temporary relations even if a backend reuses the same slot as one which created temporary relations in a past session. The base idea of this patch comes from Robert Haas, has been written in its first version by Tsunakawa Takayuki, then heavily reviewed by me. Author: Tsunakawa Takayuki Reviewed-by: Michael Paquier, Kyotaro Horiguchi, Andres Freund Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8A4DC6@G01JPEXMBYT05 Backpatch: 11-, as PGPROC gains a new flag and we don't want silent ABI breakages on already released versions. https://git.postgresql.org/pg/commitdiff/246a6c8f7b237cc1943efbbb8a7417da9288f5c4 - Update comment in header of errcodes.txt. This file mentions all the files generated from it, but missed that errcodes-list.sgml is no more, while errcodes-table.sgml is. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/TU4PR8401MB0430855D6B971E49EB55F328EE3E0@TU4PR8401MB0430.NAMPRD84.PROD.OUTLOOK.COM https://git.postgresql.org/pg/commitdiff/3593579bcdc77a70e0f987dca6d47f0bf1337f76 - Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs. Author: Dian Fay Discussion: https://postgr.es/m/745abbd2-a1a0-ead8-2cb2-768c16747d97@gmail.com Backpatch-through: 9.3 https://git.postgresql.org/pg/commitdiff/ee80124811908ef1d4679296c46e36bd8a32b9de Peter Eisentraut pushed: - Remove obsolete comment. The sequence name is no longer stored in the sequence relation, since 1753b1b027035029c2a2a1649065762fafbf63f3. https://git.postgresql.org/pg/commitdiff/3ebdd21b794b49fde2010ff3d39071e02d27b404 - Remove obsolete linux dynloader code. This has been obsolete probably since the late 1990s. https://git.postgresql.org/pg/commitdiff/351855fc4ebc2b5e62565f63ddbedbcada80e532 - Remove obsolete openbsd dynloader code. dlopen() has been documented since OpenBSD 2.0 (1996). https://git.postgresql.org/pg/commitdiff/29351a06af5b14b8f5efca18f5ec58f56eb33f2b - Remove obsolete netbsd dynloader code. dlopen() has been documented since NetBSD 1.1 (1995). https://git.postgresql.org/pg/commitdiff/b68ff3ea672c066b7eee6ca777618025b40abfd4 - Remove obsolete darwin dynloader code. not needed since macOS 10.3 (2003) https://git.postgresql.org/pg/commitdiff/b5d29299ccad9b2385236f2b82a0c4e1365b9add - Remove obsolete freebsd dynloader code. dlopen() has been documented since FreeBSD 3.0 (1989). https://git.postgresql.org/pg/commitdiff/2db1905fdde019115e7c536dd98e1adeb8a0fa3a - doc: Update broken links. Discussion: https://www.postgresql.org/message-id/flat/153044458767.13254.16049977382403131287%40wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/6f1591955db0a30f701ab10ea40cefeca6ff9b3f - Remove unused configure test for ldopen(). unused since f2cc453dd7e87e800a62a173dea0353bf106668d https://git.postgresql.org/pg/commitdiff/9d0aa4f4d22a4feddbf7c05308fe32b32d14c13f - InsertPgAttributeTuple() to set attcacheoff. InsertPgAttributeTuple() is the interface between in-memory tuple descriptors and on-disk pg_attribute, so it makes sense to give it the job of resetting attcacheoff. This avoids having all the callers having to do so. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> https://git.postgresql.org/pg/commitdiff/e4597ee65d683e11a57a4b7f597807ebf44b6cf1 - Improve error messages for CREATE OR REPLACE PROCEDURE. Change the hint to recommend DROP PROCEDURE instead of FUNCTION. Also make the error message when changing the return type more specific to the case of procedures. Reported-by: Jeremy Evans <code@jeremyevans.net> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> https://git.postgresql.org/pg/commitdiff/d83423db869900ffa2470826de5f8255d45ff9c6 Bruce Momjian pushed: - pg_upgrade: fix shutdown check for standby servers. Commit 244142d32afd02e7408a2ef1f249b00393983822 only tested for the pg_controldata output for primary servers, but standby servers have different "Database cluster state" output, so check for that too. Diagnosed-by: Michael Paquier Discussion: https://postgr.es/m/20180810164240.GM13638@paquier.xyz Backpatch-through: 9.3 https://git.postgresql.org/pg/commitdiff/777e6ddf1723306bd2bf8fe6f804863f459b0323 - pg_upgrade: issue helpful error message for use on standbys. Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from a standby and allowed it to continue. This patch reports a helpful error message in these cases, suggesting to use rsync as documented. Diagnosed-by: Martín Marqués Discussion: https://postgr.es/m/CAPdiE1xYCow-reLjrhJ9DqrMu-ppNq0ChUUEvVdxhdjGRD5_eA@mail.gmail.com Backpatch-through: 9.3 https://git.postgresql.org/pg/commitdiff/b94f7b5350e97ef0587c0c64aed6eb940d964c06 Álvaro Herrera pushed: - Update FSM on WAL replay of page all-visible/frozen. We aren't very strict about keeping FSM up to date on WAL replay, because per-page freespace values aren't critical in replicas (can't write to heap in a replica; and if the replica is promoted, the values would be updated by VACUUM anyway). However, VACUUM since 9.6 can skip processing pages marked all-visible or all-frozen, and if such pages are recorded in FSM with wrong values, those values are blindly propagated to FSM's upper layers by VACUUM's FreeSpaceMapVacuum. (This rationale assumes that crashes are not very frequent, because those would cause outdated FSM to occur in the primary.) Even when the FSM is outdated in standby, things are not too bad normally, because, most per-page FSM values will be zero (other than those propagated with the base-backup that created the standby); only once the remaining free space is less than 0.2*BLCKSZ the per-page value is maintained by WAL replay of heap ins/upd/del. However, if wal_log_hints=on causes complete FSM pages to be propagated to a standby via full-page images, many too-optimistic per-page values can end up being registered in the standby. Incorrect per-page values aren't critical in most cases, since an inserter that is given a page that doesn't actually contain the claimed free space will update FSM with the correct value, and retry until it finds a usable page. However, if there are many such updates to do, an inserter can spend a long time doing them before a usable page is found; in a heavily trafficked insert-only table with many concurrent inserters this has been observed to cause several second stalls, causing visible application malfunction. To fix this problem, it seems sufficient to have heap_xlog_visible (replay of setting all-visible and all-frozen VM bits for a heap page) update the FSM value for the page being processed. This fixes the per-page counters together with making the page skippable to vacuum, so when vacuum does FreeSpaceMapVacuum, the values propagated to FSM upper layers are the correct ones, avoiding the problem. While at it, apply the same fix to heap_xlog_clean (replay of tuple removal by HOT pruning and vacuum). This makes any space freed by the cleaning available earlier than the next vacuum in the promoted replica. Backpatch to 9.6, where this problem was diagnosed on an insert-only table with all-frozen pages, which were introduced as a concept in that release. Theoretically it could apply with all-visible pages to older branches, but there's been no report of that and it doesn't backpatch cleanly anyway. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/20180802172857.5skoexsilnjvgruk@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/ab7dbd681c54d993fc8ebf8a413668fd75a4be0b - Fix executor prune failure when plan already pruned. In a multi-layer partitioning setup, if at plan time all the sub-partitions are pruned but the intermediate one remains, the executor later throws a spurious error that there's nothing to prune. That is correct, but there's no reason to throw an error. Therefore, don't. Reported-by: Andreas Seltenreich <seltenreich@gmx.de> Author: David Rowley <david.rowley@2ndquadrant.com> Discussion: https://postgr.es/m/87in4h98i0.fsf@ansel.ydns.eu https://git.postgresql.org/pg/commitdiff/1eb9221585c25cad1a563bc3414f697dae3fbc8b Thomas Munro pushed: - Improve comment in GetNewObjectId(). The previous comment gave the impression that skipping OIDs before FirstNormalObjectId was merely an optimization to avoid likely collisions. In fact other parts of the system have been relying on this threshold to detect system-created objects since commit 8e18d04d4da, so adjust the wording. Author: Thomas Munro Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAEepm%3D33JASACeOayr_W3%3DCSjy2jiPxM-k89axu0akFbHdjnjA%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/ca1e64febaf57eb5f3f24340c5bcce5430cad7a5 - Proof-reading for documentation. Somebody accidentally a word. Back-patch to 9.6. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20180816195431.GA23707%40telsasoft.com https://git.postgresql.org/pg/commitdiff/96e98fa2606b2b12805db99196f468152312af14 Andres Freund pushed: - Try to enable C99 in configure, but do not rely on it (yet). Based on recent discussion it seems possible that we might start to rely on more of C99. A prerequisite for that is enabling support for that on used compilers. Let's see on which buildfarm members autoconf's AC_PROG_CC_C99() is sufficient to do so. There's probably at least one member where the compiler is too old, but that'd probably be OK. If we go for this permanently we'd likely want to clean out / up a few other configure tests. Note this does not touch the msvc build infrastructure, which'd need separate treatment. Discussion: https://postgr.es/m/20180815222401.kxsupl5zie2jgi4x@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/86d78ef50e0195f8181f2b0bd9540f4ddfb73480 Tomáš Vondra pushed: - Close the file descriptor in ApplyLogicalMappingFile. The function was forgetting to close the file descriptor, resulting in failures like this: ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b" LOCATION: OpenTransientFile, fd.c:2161 Simply close the file at the end, and backpatch to 9.4 (where logical decoding was introduced). While at it, fix a nearby typo. Discussion: https://www.postgresql.org/message-id/flat/738a590a-2ce5-9394-2bef-7b1caad89b37%402ndquadrant.com https://git.postgresql.org/pg/commitdiff/fa73b377ee11ced0c051fb42c29a87b5c71b79e3 - Remove remaining GEODEBUG references from geo_ops.c. Commit a7dc63d904a6044d299aebdf59ad3199b6a9e99d removed most of the GEODEBUG occurrences, but there were a couple remaining. So remove them too, to get rid of the macro entirely. Author: Emre Hasegeli Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/a082aed0723c737ec65222730ccede5db5251b4d - Use the built-in float datatypes to implement geometric types. This patch makes the geometric operators and functions use the exported function of the float4/float8 datatypes. The main reason of doing so is to check for underflow and overflow, and to handle NaNs consciously. The float datatypes consider NaNs values to be equal and greater than all non-NaN values. This change considers NaNs equal only for equality operators. The placement operators, contains, overlaps, left/right of etc. continue to return false when NaNs are involved. We don't need to worry about them being considered greater than any-NaN because there aren't any basic comparison operators like less/greater than for the geometric datatypes. The changes may be summarised as: * Check for underflow, overflow and division by zero * Consider NaN values to be equal * Return NULL when the distance is NaN for all closest point operators * Favour not-NaN over NaN where it makes sense The patch also replaces all occurrences of "double" as "float8". They are the same, but were used inconsistently in the same file. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi, Tomas Vondra Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/c4c34008854654279ec30067d72fc5d174d2f42f Noah Misch pushed: - MSVC: Remove any tmp_check directory before running a TAP test suite. Back-patch to v11, where commit 90627cf98a8e7d0531789391fd798c9bfcc3bc1a made the GNU make build system do likewise. Without this, when a typical PostgresNode-using test failed, subsequent runs bailed out with a "File exists" error. https://git.postgresql.org/pg/commitdiff/a53f0edd64d0b11abc4a87681ba85669ae90ce1f - MSVC: Finish clean.bat tmp_check coverage. Use wildcards, so one can add a TAP test suite without updating this file. Back-patch to v11, which omitted multiple new suites. https://git.postgresql.org/pg/commitdiff/f3efef434fb107dfec8b7e225779479e39a5a360 == Pending Patches == Daniel Gustafsson sent in another revision of a patch to support an optional message in backend cancel/terminate. Alexander Korotkov sent in two approaches to fix a problem where LWLocks could prevent heavier-weight locks from ever being acquired. Michaël Paquier sent in two revisions of a patch to better document locking behavior around temp namespaces. Tom Lane sent in a patch to hold off looking up the next hostname in multi-host libpq connection info until needed. Etsuro Fujita sent in another revision of a patch to refuse partition-wise join when whole-row vars are involved. Andrew Gierth sent in two revisions of a patch to fix quadratic regex match/split performance. Michaël Paquier sent in a patch to improve VACUUM and ANALYZE by avoiding early lock queue. Masahiko Sawada sent in a patch to add a parallel option to lazy vacuum. Masahiko Sawada sent in another revision of a patch to implement a copy function for logical and physical replication slots. Peter Eisentraut sent in a patch to use a lower lock level for renaming indexes. Pavel Stěhule sent in a patch to implement schema private functions. Pavel Stěhule sent in another revision of a patch to implement schema variables. Fabien COELHO sent in two more revisions of a patch to pgbench to enable storing select results into variables. Tom Lane sent in another revision of a patch to change the current libpq behavior of "randomly overwrite previous errors" to "append to previous errors". Alexander Korotkov and Liudmila Mantrova traded patches to fix to_timestamp()'s format checking. Andrey V. Lepikhov sent in another revision of a patch to implement retail IndexTuple deletion. Amit Langote sent in a patch to eliminate execution-time locking of relations in PlannedStmt.rtable. Tomáš Vondra sent in another revision of a patch to fix a memory leak when serializing TRUNCATE in reorderbuffermemory leak when serializing TRUNCATE in reorderbuffer. Surafel Temesgen sent in a patch to implement a PERCENT option for FETCH FIRST clauses. Tsutomu Yamada sent in two revisions of a patch to fix the help options of contrib/oid2name and contrib/vacuumlo. Yugo Nagata sent in a patch to fix a situation where has_table_privilege returns an error when a table is specified by schema-qualified name and the user doesn't have privilege for its schema rather than simply returning false. Andrey V. Lepikhov sent in a patch to fix a problem where the XLogReadRecord() function forgets to bind the "record" pointer with the beginning of the readRecordBuf buffer in the case where a WAL record fits completely inside a page, and instead returns a pointer to an internal xlog page. Noriyoshi Shinoda sent in a patch to add a work_mem option to the postgres_fdw. Michaël Paquier sent in another revision of a patch to improve VACUUM and ANALYZE by avoiding early lock queue. Mathias Brossard sent in a patch to add a \dP[+] (partitions) command to psql. Paul Bonaud sent in two revisions of a patch to clarify a part of the pg_upgrade documentation with respect to when the latest checkpoint location could be wrong in a replication cluster. Fabien COELHO sent in a patch to make libpq's parsing of integers stricter. Amit Khandekar sent in a patch to slot-ify partition tuple conversion, avoiding a useless form/deform cycle. Tom Lane sent in a patch to speed up the snprintf implementation we ship. Emre Hasegeli sent in two more revisions of a patch to fix floating point handling of -0 for geometric types. Ashutosh Bapat and Andres Freund traded patches to implement a TupleTableSlot abstraction. Peter Eisentraut sent in a patch to update the documentation where it uses the word "procedure", now that there are actual PROCEDUREs to document. In passing, changed CREATE OPERATOR and CREATE TRIGGER to use FUNCTION rather than PROCEDURE, as they actually use functions. Peter Eisentraut sent in a patch to remove ATTRIBUTE_FIXED_PART_SIZE. Jonathan Katz sent in two revisions of a patch to fix the REFRESH MATERIALIZED VIEW ownership error messages. Noah Misch sent in two approaches to a fix for a problem on Win32 that manifested itself as "could not reattach to shared memory" on buildfarm member dory.
В списке pgsql-announce по дате отправления: