== PostgreSQL Weekly News - January 18 2015 == - Mailing list pgsql-announce
| From | David Fetter |
|---|---|
| Subject | == PostgreSQL Weekly News - January 18 2015 == |
| Date | |
| Msg-id | 20150119071548.GE12186@fetter.org Whole thread Raw |
| List | pgsql-announce |
== PostgreSQL Weekly News - January 18 2015 == Giulio Calacoci, the main developer of Barman, will host a the "Discover Barman 1.4.0" meetup in Prato, Italy next February 6th. Further information and registration: http://www.meetup.com/2ndQuadrant-Italia-PostgreSQL-Meetup/events/219801332/ The CfP for the second Swiss Postgres Conference, to be held June 25-26, 2015 at HSR Rapperswil, is open until April 1. http://www.postgres-conference.ch/cfp/ == PostgreSQL Product News == pgmp 1.0.2, a high-precision integer and rational arithmetic library exposing GMP, released. Details and download below: http://pgmp.projects.pgfoundry.org/ http://pgxn.org/dist/pgmp/ == PostgreSQL Jobs for January == http://archives.postgresql.org/pgsql-jobs/2015-01/threads.php == PostgreSQL Local == PGCon 2015 (June 16-20) call for papers is out. Talk submission ends January 19, 2014. Details at http://www.pgcon.org/2015/papers.php FOSDEM PGDay (January 30, 2015) and the FOSDEM PostgreSQL Dev Room (January 31-February 1, 2015) http://fosdem2015.pgconf.eu/ Prague PostgreSQL Developer Day (P2D2) 2015 will be in Prague, Czech Republic February 11-12, 2015. http://www.p2d2.cz/ The Melbourne PostgreSQL meetup on February 18, 2015 will be hosting Gabriele Bartolini on PostgreSQL 9.4 for devops. Details below, and R, SVP. http://www.meetup.com/melpug/events/219082475/ pgDaySF 2015 will be held March 10, 2015 in Burlingame, California. http://sfpostgres.org/pgday-sf-2015-call-for-speakers-and-sponsors/ The CfP is open for Nordic PostgreSQL Day 2015, which will be held March 11, 2015 in Copenhagen, Denmark. http://2015.nordicpgday.org/cfp/ The CfP for PGConf US 2015 is open through December 17th, 2014 Notifications will go out on January 10, 2014. The event takes place March 25-27, 2015 in NYC. http://nyc.pgconf.us/2015/ == 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 Pacific time. Please send English language ones to david@fetter.org, German language to pwn@pgug.de, Italian language to pwn@itpug.org. Spanish language to pwn@arpug.com.ar. == Applied Patches == Stephen Frost pushed: - Skip dead backends in MinimumActiveBackends. Back in ed0b409, PGPROC was split and moved to static variables in procarray.c, with procs in ProcArrayStruct replaced by an array of integers representing process numbers (pgprocnos), with -1 indicating a dead process which has yet to be removed. Access to procArray is generally done under ProcArrayLock and therefore most code does not have to concern itself with -1 entries. However, MinimumActiveBackends intentionally does not take ProcArrayLock, which means it has to be extra careful when accessing procArray. Prior to ed0b409, this was handled by checking for a NULL in the pointer array, but that check was no longer valid after the split. Coverity pointed out that the check could never happen and so it was removed in 5592eba. That didn't make anything worse, but it didn't fix the issue either. The correct fix is to check for pgprocno == -1 and skip over that entry if it is encountered. Back-patch to 9.2, since there can be attempts to access the arrays prior to their start otherwise. Note that the changes prior to 9.4 will look a bit different due to the change in 5592eba. Note that MinimumActiveBackends only returns a bool for heuristic purposes and any pre-array accesses are strictly read-only and so there is no security implication and the lack of fields complaints indicates it's very unlikely to run into issues due to this. Pointed out by Noah Misch. http://git.postgresql.org/pg/commitdiff/1bf4a84d0f9f7a442790d7948e96cd42eeb90a91 Tom Lane pushed: - Use correct text domain for errcontext() appearing within ereport(). The mechanism added in commit dbdf9679d7d61b03a3bf73af9b095831b7010eb5 for associating the correct translation domain with errcontext strings potentially fails in cases where errcontext() is used within an ereport() macro. Such usage was not originally envisioned for errcontext(), but we do have a few places that do it. In this situation, the intended comma expression becomes just a couple of arguments to errfinish(), which the compiler might choose to evaluate right-to-left. Fortunately, in such cases the textdomain for the errcontext string must be the same as for the surrounding ereport. So we can fix this by letting errstart initialize context_domain along with domain; then it will have the correct value no matter which order the calls occur in. (Note that error stack callback functions are not invoked until errfinish, so normal usage of errcontext won't affect what happens for errcontext calls within the ereport macro.) In passing, make sure that errcontext calls within the main backend set context_domain to something non-NULL. This isn't a live bug because NULL would select the current textdomain() setting which should be the right thing anyway --- but it seems better to handle this completely consistently with the regular domain field. Per report from Dmitry Voronin. Backpatch to 9.3; before that, there wasn't any attempt to ensure that errcontext strings were translated in an appropriate domain. http://git.postgresql.org/pg/commitdiff/1f9bf05e539646103c518bcbb49c04919b238f7a - Avoid unexpected slowdown in vacuum regression test. I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of an index using an extremely expensive index function. That function was evidently meant to be applied only twice ... but the test re-used an existing test table, which up till a couple lines before that had had over two thousand rows. Depending on timing of the concurrent regression tests, the intervening VACUUMs might have been unable to remove those recently-dead rows, and then the index build would need to create index entries for them too, leading to the wrap_do_analyze() function being executed 2000+ times not twice. Avoid this by using a different table that is guaranteed to have only the intended two rows in it. Back-patch to 9.0, like the commit that created the problem. http://git.postgresql.org/pg/commitdiff/5b3ce2c911a2ec9de13b0dea7e135ad945a14583 - Fix some functions that were declared static then defined not-static. Per testing with a compiler that whines about this. http://git.postgresql.org/pg/commitdiff/7391e2513f486a5df3eebf132c6dd6c16cf4e1f1 - Remove duplicate specification of -Ae for HP-UX C compiler. Autoconf has known about automatically selecting -Ae when needed for quite some time now, so remove the redundant addition in template/hpux. Noted while setting up buildfarm member pademelon. http://git.postgresql.org/pg/commitdiff/fd3d894e4ea0021efa2628e4dfc5fe0ed3071859 - Allow CFLAGS from configure's environment to override automatic CFLAGS. Previously, configure would add any switches that it chose of its own accord to the end of the user-specified CFLAGS string. Since most compilers process these left-to-right, this meant that configure's choices would override the user-specified flags in case of conflicts. We'd rather that worked the other way around, so adjust the logic to put the user's string at the end not the beginning. There does not seem to be a need for a similar behavior change for CPPFLAGS or LDFLAGS: in those, the earlier switches tend to win (think -I or -L behavior) so putting the user's string at the front is fine. Backpatch to 9.4 but not earlier. I'm not planning to run buildfarm member guar on older branches, and it seems a bit risky to change this behavior in long-stable branches. http://git.postgresql.org/pg/commitdiff/85a2a8903f7e9151793308d0638621003aded5ae - Improve performance of EXPLAIN with large range tables. As of 9.3, ruleutils.c goes to some lengths to ensure that table and column aliases used in its output are unique. Of course this takes more time than was required before, which in itself isn't fatal. However, EXPLAIN was set up so that recalculation of the unique aliases was repeated for each subexpression printed in a plan. That results in O(N^2) time and memory consumption for large plan trees, which did not happen in older branches. Fortunately, the expensive work is the same across a whole plan tree, so there is no need to repeat it; we can do most of the initialization just once per query and re-use it for each subexpression. This buys back most (not all) of the performance loss since 9.2. We need an extra ExplainState field to hold the precalculated deparse context. That's no problem in HEAD, but in the back branches, expanding sizeof(ExplainState) seems risky because third-party extensions might have local variables of that struct type. So, in 9.4 and 9.3, introduce an auxiliary struct to keep sizeof(ExplainState) the same. We should refactor the APIs to avoid such local variables in future, but that's material for a separate HEAD-only commit. Per gripe from Alexey Bashtanov. Back-patch to 9.3 where the issue was introduced. http://git.postgresql.org/pg/commitdiff/a5cd70dcbc268381e13cb0b2973b5732856d186f - Rearrange explain.c's API so callers need not embed sizeof(ExplainState). The folly of the previous arrangement was just demonstrated: there's no convenient way to add fields to ExplainState without breaking ABI, even if callers have no need to touch those fields. Since we might well need to do that again someday in back branches, let's change things so that only explain.c has to have sizeof(ExplainState) compiled into it. This costs one extra palloc() per EXPLAIN operation, which is surely pretty negligible. http://git.postgresql.org/pg/commitdiff/8e166e164c7c4531d7eb150d836aa2357989237a - Fix use-of-already-freed-memory problem in EvalPlanQual processing. Up to now, the "child" executor state trees generated for EvalPlanQual rechecks have simply shared the ResultRelInfo arrays used for the original execution tree. However, this leads to dangling-pointer problems, because ExecInitModifyTable() is all too willing to scribble on some fields of the ResultRelInfo(s) even when it's being run in one of those child trees. This trashes those fields from the perspective of the parent tree, because even if the generated subtree is logically identical to what was in use in the parent, it's in a memory context that will go away when we're done with the child state tree. We do however want to share information in the direction from the parent down to the children; in particular, fields such as es_instrument *must* be shared or we'll lose the stats arising from execution of the children. So the simplest fix is to make a copy of the parent's ResultRelInfo array, but not copy any fields back at end of child execution. Per report from Manuel Kniep. The added isolation test is based on his example. In an unpatched memory-clobber-enabled build it will reliably fail with "ctid is NULL" errors in all branches back to 9.1, as a consequence of junkfilter->jf_junkAttNo being overwritten with $7f7f. This test cannot be run as-is before that for lack of WITH syntax; but I have no doubt that some variant of this problem can arise in older branches, so apply the code change all the way back. http://git.postgresql.org/pg/commitdiff/c480cb9d246cec5e1dd7d72956e792df16e5445d - Improve new caching logic in tbm_add_tuples(). For no significant extra complexity, we can cache knowledge that the target page is lossy, and save a hash_search per iteration in that case as well. This probably makes little difference, since the extra rechecks that must occur when pages are lossy are way more expensive than anything we can save here ... but we might as well do it if we're going to cache anything. http://git.postgresql.org/pg/commitdiff/779fdcdeeeb9cdbfd271f8dc5bde76ed0c7b0813 - Show sort ordering options in EXPLAIN output. Up to now, EXPLAIN has contented itself with printing the sort expressions in a Sort or Merge Append plan node. This patch improves that by annotating the sort keys with COLLATE, DESC, USING, and/or NULLS FIRST/LAST whenever nondefault sort ordering options are used. The output is now a reasonably close approximation of an ORDER BY clause equivalent to the plan's ordering. Marius Timmer, Lukas Kreft, and Arne Scheffer; reviewed by Mike Blackwell. Some additional hacking by me. http://git.postgresql.org/pg/commitdiff/20af53d7191f84d0f5b86da4362e481b7e85d52a - Fix ancient thinko in default table rowcount estimation. The code used sizeof(ItemPointerData) where sizeof(ItemIdData) is correct, since we're trying to account for a tuple's line pointer. Spotted by Tomonari Katsumata (bug #12584). Although this mistake is of very long standing, no back-patch, since it's a relatively harmless error and changing it would risk changing default planner behavior in stable branches. (I don't see any change in regression test outputs here, but the buildfarm may think differently.) http://git.postgresql.org/pg/commitdiff/75df6dc083f7a989697b5002a421fb204f2eeddb Álvaro Herrera pushed: - Fix get_object_address argument type for extension statement. Commit 3f88672a4 neglected to update the AlterExtensionContentsStmt production in the grammar to use TypeName to represent types when passing objects to get_object_address. Reported as a pg_upgrade failure by Jeff Janes. http://git.postgresql.org/pg/commitdiff/5c5ffee80f3547625021c29f45b37321d8c710bf - Tweak heapam's rmgr desc output slightly. Some spaces were missing, and putting the affected tuple offset first in the lock cases instead of the locking data makes more sense. No backpatch since this is cosmetic and surrounding code has changed. http://git.postgresql.org/pg/commitdiff/d126e1e95fab44cc73002de3eaa08e2d88f11c50 Heikki Linnakangas pushed: - Fix typos in comment. Plus some tiny wordsmithing of not-quite-typos. http://git.postgresql.org/pg/commitdiff/3dfce37627b76e4da9e1d6090beedb608cefafcb - Silence Coverity warnings about unused return values from pushJsonbValue(). Similar warnings from backend were silenced earlier by commit c8315930, but there were a few more contrib/hstore. Michael Paquier http://git.postgresql.org/pg/commitdiff/e37d474f91c3a8a88be28a65389c948a55f18075 - Fix thinko in re-setting wal_log_hints flag from a parameter-change record. The flag is supposed to be copied from the record. Same issue with track_commit_timestamps, but that's master-only. Report and fix by Petr Jalinek. Backpatch to 9.4, where wal_log_hints was added. http://git.postgresql.org/pg/commitdiff/49b04188f83fb8cacf925978989bc20399e76786 - Another attempt at fixing Windows Norwegian locale. Previous fix mapped "Norwegian (Bokmål)" locale, which contains a non-ASCII character, to the pure ASCII alias "norwegian-bokmal". However, it turns out that more recent versions of the CRT library, in particular MSVCR110 (Visual Studio 2012), changed the behaviour of setlocale() so that if you pass "norwegian-bokmal" to setlocale, it returns "Norwegian_Norway". That meant trouble, when setlocale(..., NULL) first returned "Norwegian (Bokmål)_Norway", which we mapped to "norwegian-bokmal_Norway", but another call to setlocale(..., "norwegian-bokmal_Norway") returned "Norwegian_Norway". That caused PostgreSQL to think that they are different locales, and therefore not compatible. That caused initdb to fail at CREATE DATABASE. Older CRT versions seem to accept "Norwegian_Norway" too, so change the mapping to return "Norwegian_Norway" instead of "norwegian-bokmal". Backpatch to 9.2 like the previous attempt. We haven't made a release that includes the previous fix yet, so we don't need to worry about changing the locale of existing clusters from "norwegian-bokmal" to "Norwegian_Norway". (Doing any mapping like this at all requires changing the locale of existing databases; the release notes need to include instructions for that). http://git.postgresql.org/pg/commitdiff/aa1d2fc5e91e396bec5bf8a8d10b6cc4af0b0fff - Advance backend's advertised xmin more aggressively. Currently, a backend will reset it's PGXACT->xmin value when it doesn't have any registered snapshots left. That covered the common case that a transaction in read committed mode runs several queries, one after each other, as there would be no snapshots active between those queries. However, if you hold cursors across each of the query, we didn't get a chance to reset xmin. To make that better, keep all the registered snapshots in a pairing heap, ordered by xmin so that it's always quick to find the snapshot with the smallest xmin. That allows us to advance PGXACT->xmin whenever the oldest snapshot is deregistered, even if there are others still active. Per discussion originally started by Jeff Davis back in 2009 and more recently by Robert Haas. http://git.postgresql.org/pg/commitdiff/94028691609f8e148bd4ce72c46163f018832a5b Andres Freund pushed: - Allow latches to wait for socket writability without waiting for readability. So far WaitLatchOrSocket() required to pass in WL_SOCKET_READABLE as that solely was used to indicate error conditions, like EOF. Waiting for WL_SOCKET_WRITEABLE would have meant to busy wait upon socket errors. Adjust the API to signal errors by returning the socket as readable, writable or both, depending on WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE being specified. It would arguably be nicer to return WL_SOCKET_ERROR but that's not possible on platforms and would probably also result in more complex callsites. This previously had explicitly been forbidden in e42a21b9e6c9, as there was no strong use case at that point. We now are looking into making FE/BE communication use latches, so changing this makes sense. There also are some portability concerns because there cases of older platforms where select(2) is known to, in violation of POSIX, not return a socket as writable after the peer has closed it. So far the platforms where that's the case provide a working poll(2). If we find one where that's not the case, we'll need to add a workaround for that platform. Discussion: 20140927191243.GD5423@alap3.anarazel.de Reviewed-By: Heikki Linnakangas, Noah Misch http://git.postgresql.org/pg/commitdiff/4bad60e3fd9a5fc6070fd4d1bd820a280e174654 - Add barriers to the latch code. Since their introduction latches have required barriers in SetLatch and ResetLatch - but when they were introduced there wasn't any barrier abstraction. Instead latches were documented to rely on the callsites to provide barrier semantics. Now that the barrier support looks halfway complete, add the necessary barriers to both latch implementations. Also remove a now superflous lock acquisition from syncrep.c and a superflous (and insufficient) barrier from freelist.c. There might be other cases that can now be simplified, but those are the only ones I've seen on a quick scan. We might want to backpatch this at some later point, but right now the barrier infrastructure in the backbranches isn't totally on par with master. Discussion: 20150112154026.GB2092@awork2.anarazel.de http://git.postgresql.org/pg/commitdiff/14e8803f101a54d99600683543b0f893a2e3f529 - Remove some dead IsUnderPostmaster code from bootstrap.c. Since commit 626eb021988a2 has introduced the auxiliary process infrastructure, bootstrap_signals() was never used when forked from postmaster. Remove the IsUnderPostmaster specific code, and add a appropriate assertion. http://git.postgresql.org/pg/commitdiff/0139dea8f1cea49f13c22a3f645dbdd02b90d25c - Commonalize process startup code. Move common code, that was duplicated in every postmaster child/every standalone process, into two functions in miscinit.c. Not only does that already result in a fair amount of net code reduction but it also makes it much easier to remove more duplication in the future. The prime motivation wasn't code deduplication though, but easier addition of new common code. http://git.postgresql.org/pg/commitdiff/31c453165b5a656044ce1dbce89f5828c1c7e23c - Make logging_collector=on work with non-windows EXEC_BACKEND again. Commit b94ce6e80 reordered postmaster's startup sequence so that the tempfile directory is only cleaned up after all the necessary state for pg_ctl is collected. Unfortunately the chosen location is after the syslogger has been started; which normally is fine, except for !WIN32 EXEC_BACKEND builds, which pass information to children via files in the temp directory. Move the call to RemovePgTempFiles() to just before the syslogger has started. That's the first child we fork. Luckily EXEC_BACKEND is pretty much only used by endusers on windows, which has a separate method to pass information to children. That means the real world impact of this bug is very small. Discussion: 20150113182344.GF12272@alap3.anarazel.de Backpatch to 9.1, just as the previous commit was. http://git.postgresql.org/pg/commitdiff/2be82dcf17a18511df5153bcafe67a9c1387be1e - Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de http://git.postgresql.org/pg/commitdiff/59f71a0d0b56b2df48db4bf1738aece5551f7a47 - Blindly try to fix a warning in s_lock.h when compiling with gcc on HPPA. The possibly, depending on compiler settings, generated warning was "warning: `S_UNLOCK' redefined". The hppa spinlock implementation doesn't follow the rules of s_lock.h and provides a gcc specific implementation outside of the the part of the file that's supposed to do that. It does so to avoid duplication between the HP compiler and gcc. That unfortunately means that S_UNLOCK is already defined when the HPPA specific section is reached. Undefine the generic fallback S_UNLOCK definition inside the HPPA section. That's far from pretty, but has the big advantage of being simple. If somebody is interested to fix this in a prettier way... This presumably got broken in the course of 0709b7ee72. Discussion: 20150114225919.GY5245@awork2.anarazel.de Per complaint from Tom Lane. http://git.postgresql.org/pg/commitdiff/6cfd5086e140b365086d61f25c519d046dfcf7f0 - Make tbm_add_tuples more efficient by caching the last acccessed page. When adding a large number of tuples to a TID bitmap using tbm_add_tuples() sometimes a lot of time was spent looking up a page's entry in the bitmap's internal hashtable. Improve efficiency by caching the last accessed page, while iterating over the passed in tuples, hoping consecutive tuples will often be on the same page. In many cases that's a good bet, and in the rest the added overhead isn't big. Discussion: 54479A85.8060309@sigaev.ru Author: Teodor Sigaev Reviewed-By: David Rowley http://git.postgresql.org/pg/commitdiff/f5ae3ba4828ece02bae2d16b4cbce847fbcea850 - Replace walsender's latch with the general shared latch. Relying on the normal shared latch simplifies interrupt/signal handling because we can rely on all signal handlers setting the proc latch. That in turn allows us to avoid the use of ImmediateInterruptOK, which arguably isn't correct because WaitLatchOrSocket isn't declared to be immediately interruptible. Also change sections that wait on the walsender's latch to notice interrupts quicker/more reliably and make them more consistent with each other. This is part of a larger "get rid of ImmediateInterruptOK" series. Discussion: 20150115020335.GZ5245@awork2.anarazel.de http://git.postgresql.org/pg/commitdiff/ff44fba46c09c37dd9e60da1cb0b3a9339eb085f - Fix use of already freed memory when dumping a database's security label. pg_dump.c:dumDatabase() called ArchiveEntry() with the results of a a query that was PQclear()ed a couple lines earlier. Backpatch to 9.2 where security labels for shared objects where introduced. http://git.postgresql.org/pg/commitdiff/525b84c576e119de7f2b0d00e3a99d559771aa7b Robert Haas pushed: - vacuumlo: Avoid unlikely memory leak. Spotted by Coverity. This isn't likely to matter in practice, but there's no harm in fixing it. Michael Paquier http://git.postgresql.org/pg/commitdiff/4a0a5f21fa05070295557ad6ac9b9bbe247938ad - docs: Add missing <literal> markup. Michael Paquier http://git.postgresql.org/pg/commitdiff/73a8f5176ad980d1d2c265649757af3391079318 - pg_standby: Avoid writing one byte beyond the end of the buffer. Previously, read() might have returned a length equal to the buffer length, and then the subsequent store to buf[len] would write a zero-byte one byte past the end. This doesn't seem likely to be a security issue, but there's some chance it could result in pg_standby misbehaving. Spotted by Coverity; patch by Michael Paquier, reviewed by me. http://git.postgresql.org/pg/commitdiff/0b49642b99ca2818bb8bfcaddf522b2e36a5b350 Noah Misch pushed: - Update "pg_regress --no-locale" for Darwin and Windows. Commit 894459e59ffa5c7fee297b246c17e1f72564db1d revealed this option to be broken for NLS builds on Darwin, but "make -C contrib/unaccent check" and the buildfarm client rely on it. Fix that configuration by redefining the option to imply LANG=C on Darwin. In passing, use LANG=C instead of LANG=en on Windows; since only postmaster startup uses that value, testers are unlikely to notice the change. Back-patch to 9.0, like the predecessor commit. http://git.postgresql.org/pg/commitdiff/28df6a0df0a78360629163c3df5b073ea6deeca6 - Activate low-volume optional logging during regression test runs. Elaborated from an idea by Andres Freund. http://git.postgresql.org/pg/commitdiff/4c34dcf97f70fa5c3d5fbf70caff12032a27a7dd Peter Eisentraut pushed: - Install shared libraries also in bin on cygwin, mingw. This was previously only done for libpq, not it's done for all shared libraries. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> http://git.postgresql.org/pg/commitdiff/cb4a3b0410d3ba19e4524fceee99fb9b10a5e08a == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == Michael Paquier sent in three revisions of a patch to remove unused variables in hstore_to_jsonb. Petr (PJMODOS) Jelinek sent in another revision of a patch to implement a sequence access method. Dean Rasheed sent in three more revisions of a patch to fix some infelicities between INSERT...ON CONFLICT and RLS. Michael Paquier sent in two more revisions of a patch to implement table-level log_autovacuum_min_duration. Michael Paquier sent in two revisions of a patch to create non-erroring memory allocation functions. Michael Paquier sent in a patch to fix a memory leak in receivelog.c when receiving stream. Ali Akbar sent in a patch to clarify documentation that made generate_series(numeric, numeric) harder to implement. Oskari Saarenmaa sent in a patch to defines custom macros for each attribute and enables them individually for compilers that support them and never defines __attribute__. Andreas Karlsson and Michael Paquier traded patches to reduce the needed lock strength of triggers and foreign key DDL. Marco Nenciarini sent in two more revisions of a patch to implement incremental backup. Kyotaro HORIGUCHI sent in three more revisions of a patch to allow async execution of the PostgreSQL FDW. Tomas Vondra sent in another revision of a patch to reduce the amount of memory consumed by array_agg(). Michael Paquier sent in a patch to make mere absence of destination folders not be a failure mode. Etsuro Fujita sent in a patch to fix an issue where EvalPlanQual behaves oddly for FDW queries involving system columns. Heikki Linnakangas sent in two more revisions of a patch to add pg_rewind. Adam Brightwell sent in a patch to add some additional role attributes. Amit Langote sent in a patch to fix a typo in brin.c. Dilip Kumar sent in another revision of a patch to allow vacuumdb to work in parallel. Gilles Darold sent in a patch to fix an issue in pg_dump with unusally-named tables. Robert Haas sent in another revision of a patch to implement parallel mode and parallel contexts. Michael Paquier sent in two revisions of a patch to fix a situation where the error check always bypassed in tablefunc.c. Alexander Korotkov sent in two more revisions of a patch to implement fillfactor for GIN indexes. Andres Freund sent in a patch to fix various shortcomings of the new PrivateRefCount infrastructure. Pavel Stehule sent in a patch to add an array_position() function to PL/pgsql. Andres Freund and Michael Paquier traded patches to move binaries from contrib/ to bin/ Pavel Stehule sent in a patch to complete the deprecation of => for other than pair-like functionality. Tom Lane sent in a patch to deal with pg_stat wait timeout. Tom Lane sent in a patch to have the buildfarm clean up temporary installs when done. Michael Paquier sent in another revision of a patch to add recovery_timeout option to control timeout of restore_command nonzero status code.
pgsql-announce by date: