aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Remove AtEOXact_CatCache().Tom Lane2017-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sole useful effect of this function, to check that no catcache entries have positive refcounts at transaction end, has really been obsolete since we introduced ResourceOwners in PG 8.1. We reduced the checks to assertions years ago, so that the function was a complete no-op in production builds. There have been previous discussions about removing it entirely, but consensus up to now was that it had some small value as a cross-check for bugs in the ResourceOwner logic. However, it now emerges that it's possible to trigger these assertions if you hit an assert-enabled backend with SIGTERM during a call to SearchCatCacheList, because that function temporarily increases the refcounts of entries it's intending to add to a catcache list construct. In a normal ERROR scenario, the extra refcounts are cleaned up by SearchCatCacheList's PG_CATCH block; but in a FATAL exit we do a transaction abort and exit without ever executing PG_CATCH handlers. There's a case to be made that this is a generic hazard and we should consider restructuring elog(FATAL) handling so that pending PG_CATCH handlers do get run. That's pretty scary though: it could easily create more problems than it solves. Preliminary stress testing by Andreas Seltenreich suggests that there are not many live problems of this ilk, so we rejected that idea. There are more-localized ways to fix the problem; the most principled one would be to use PG_ENSURE_ERROR_CLEANUP instead of plain PG_TRY. But adding cycles to SearchCatCacheList isn't very appealing. We could also weaken the assertions in AtEOXact_CatCache in some more or less ad-hoc way, but that just makes its raison d'etre even less compelling. In the end, the most reasonable solution seems to be to just remove AtEOXact_CatCache altogether, on the grounds that it's not worth trying to fix it. It hasn't found any bugs for us in many years. Per report from Jeevan Chalke. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAM2+6=VEE30YtRQCZX7_sCFsEpoUkFBV1gZazL70fqLn8rcvBA@mail.gmail.com
* Reword comment for clarityAlvaro Herrera2017-08-12
| | | | | Reported by Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoB+ycZ2z-4Ye=6MfQ_r0aV5r6cvVPw4kOyPdp6bHqQoBQ@mail.gmail.com
* Simplify fetch-slot-xmins logic in recovery TAP tests.Tom Lane2017-08-12
| | | | | | | | | | Merge wait_slot_xmins() into get_slot_xmins(). At this point the only place that wasn't doing a wait was the initial-state test, and a wait there seems pretty harmless. Michael Paquier Discussion: https://postgr.es/m/CAB7nPqSp_SLQb2uU7am+sn4V3g1UKv8j3yZU385oAG1cG_BN9Q@mail.gmail.com
* Be more thorough about cleaning out gcov litter.Tom Lane2017-08-11
| | | | | | At least on my machine, a run with code coverage enabled produces some ".gcov" files whose names begin with ".". "rm -f *.gcov" fails to match those, so they don't get cleaned up by "make clean". Fix it.
* Add regression tests exercising more code paths in nodeLimit.c.Tom Lane2017-08-11
| | | | | | | Perusal of the code coverage report shows that the existing regression test cases for LIMIT/OFFSET don't exercise the nodeLimit code paths involving backwards scan, empty results, or null values of LIMIT/OFFSET. Improve the coverage.
* Add regression tests exercising the non-hashed code paths in nodeSetop.c.Tom Lane2017-08-11
| | | | | | | Perusal of the code coverage report shows that the existing regression test cases for INTERSECT and EXCEPT seemingly all prefer the SETOP_HASHED implementation. Add some test cases in which we force use of the SETOP_SORTED mode.
* pg_upgrade: Clarify one messagePeter Eisentraut2017-08-11
| | | | Reported-by: Dennis Björklund <db@zigo.dhs.org>
* Remove pgbench's restriction on placement of -M switch.Tom Lane2017-08-11
| | | | | | | | | | | | | | | | | | | Previously the -M switch had to appear before any switch that directly or indirectly specified a benchmarking script. This was both confusing and inadequately documented, as per gripe from Tatsuo Ishii. We can remove the restriction at the cost of making an extra pass over the lists of SQL commands, which seems like a cheap price (the string scans themselves likely cost much more). The change is just to not extract parameters from the SQL commands until we have finished parsing the switches and know the final value of -M. Per discussion, we'll treat this as a low-grade bug fix and sneak it into v10, rather than holding it for v11. Tom Lane, reviewed by Tatsuo Ishii and Fabien Coelho Discussion: https://postgr.es/m/20170802.110328.1963639094551443169.t-ishii@sraoss.co.jp Discussion: https://postgr.es/m/10208.1502465077@sss.pgh.pa.us
* Remove uses of "slave" in replication contextsPeter Eisentraut2017-08-10
| | | | | This affects mostly code comments, some documentation, and tests. Official APIs already used "standby".
* Reject use of ucol_strcollUTF8() before ICU 53Peter Eisentraut2017-08-10
| | | | | | | | | | | | | | Various bugs can cause crashes, so don't use that function before ICU 53. It will fall back to the code path used for other encodings. Since we now tie the function availability to an ICU version, we don't need the configure test anymore. That also resolves the issue that the test result was previously hardcoded for Windows. researched by Daniel Verite <daniel@manitou-mail.org>, Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/f1438ec6-22aa-4029-9a3b-26f79d330e72%40manitou-mail.org
* Fix order of ICU_CFLAGSPeter Eisentraut2017-08-10
| | | | | It must be before CPPFLAGS so that an ICU installation in a nonstandard path can take precedence over one in the system path.
* Improve the error message when creating an empty range partition.Robert Haas2017-08-10
| | | | | | | | | | | The previous message didn't mention the name of the table or the bounds. Put the table name in the primary error message and the bounds in the detail message. Amit Langote, changed slightly by me. Suggestions on the exac phrasing from Tom Lane, David G. Johnston, and Dean Rasheed. Discussion: http://postgr.es/m/CA+Tgmoae6bpwVa-1BMaVcwvCCeOoJ5B9Q9-RHWo-1gJxfPBZ5Q@mail.gmail.com
* Fix typo in comment.Robert Haas2017-08-10
| | | | | | Etsuro Fujita Discussion: http://postgr.es/m/5f794b91-67df-1ac6-8a4f-069f8e8e169d@lab.ntt.co.jp
* Remove incorrect assertion in clog.cRobert Haas2017-08-10
| | | | | | | | | | | We must advance the oldest XID that can be safely looked up in clog *before* truncating CLOG, and the oldest XID that can't be reused *after* truncating CLOG. This assertion, and the accompanying comment, are confused; remove them. Reported by Neha Sharma. Discussion: http://postgr.es/m/CANiYTQumC3T=UMBMd1Hor=5XWZYuCEQBioL3ug0YtNQCMMT5wQ@mail.gmail.com
* Fix handling of container types in find_composite_type_dependencies.Tom Lane2017-08-09
| | | | | | | | | | | | | | | | | | | | | | find_composite_type_dependencies correctly found columns that are of the specified type, and columns that are of arrays of that type, but not columns that are domains or ranges over the given type, its array type, etc. The most general way to handle this seems to be to assume that any type that is directly dependent on the specified type can be treated as a container type, and processed recursively (allowing us to handle nested cases such as ranges over domains over arrays ...). Since a type's array type already has such a dependency, we can drop the existing special case for the array type. The very similar logic in get_rels_with_domain was likewise a few bricks shy of a load, as it supposed that a directly dependent type could *only* be a sub-domain. This is already wrong for ranges over domains, and it'll someday be wrong for arrays over domains. Add test cases illustrating the problems, and back-patch to all supported branches. Discussion: https://postgr.es/m/15268.1502309024@sss.pgh.pa.us
* Fix datumSerialize infrastructure to not crash on non-varlena data.Tom Lane2017-08-08
| | | | | | | | | | | | | | | | Commit 1efc7e538 did a poor job of emulating existing logic for touching Datums that might be expanded-object pointers. It didn't check for typlen being -1 first, which meant it could crash on fixed-length pass-by-ref values, and probably on cstring values as well. It also didn't use DatumGetPointer before VARATT_IS_EXTERNAL_EXPANDED, which while currently harmless is not according to documentation nor prevailing style. I also think the lack of any explanation as to why datumSerialize makes these particular nonobvious choices is pretty awful, so fix that. Per report from Jarred Ward. Back-patch to 9.6 where this code came in. Discussion: https://postgr.es/m/6F61E6D2-2F5E-4794-9479-A429BE1CEA4B@simple.com
* Reword some unclear commentsAlvaro Herrera2017-08-08
|
* Fix typo in commentAlvaro Herrera2017-08-08
|
* Fix yet another race condition in recovery/t/001_stream_rep.pl.Tom Lane2017-08-08
| | | | | | | | | | | | | | | | | | | | | | In commit 5c77690f6, we added polling in front of most of the get_slot_xmins calls in 001_stream_rep.pl, but today's results from buildfarm member nightjar show that at least one more poll loop is needed. Proactively add a poll loop before the next-to-last get_slot_xmins call as well. It may be that there is no race condition there because the standby_2 server is shut down at that point, but I'm quite tired of fighting with this test script. The empirical evidence that it's safe, from the buildfarm, is no stronger than the evidence for the other call that nightjar just proved unsafe. The only remaining get_slot_xmins calls without wait_slot_xmins protection are the first two, which should be OK since nothing has happened at that point. It's tempting to ignore that special case and merge get_slot_xmins and wait_slot_xmins into a single function. I didn't go that far though. Discussion: https://postgr.es/m/18436.1502228036@sss.pgh.pa.us
* Fix replication origin-related race conditionsAlvaro Herrera2017-08-08
| | | | | | | | | | | | | | | | | | | Similar to what was fixed in commit 9915de6c1cb2 for replication slots, but this time it's related to replication origins: DROP SUBSCRIPTION attempts to drop the replication origin, but that fails if the replication worker process hasn't yet marked it unused. This causes failures in the buildfarm: ERROR: could not drop replication origin with OID 1, in use by PID 34069 Like the aforementioned commit, fix by having the process running DROP SUBSCRIPTION sleep until the worker marks the the replication origin struct as free. This uses a condition variable on each replication origin shmem state struct, so that the session trying to drop can sleep and expect to be awakened by the process keeping the origin open. Also fix a SGML markup in the previous commit. Discussion: https://postgr.es/m/20170808001433.rozlseaf4m2wkw3n@alvherre.pgsql
* Fix inadequacies in recently added wait eventsAlvaro Herrera2017-08-08
| | | | | | | | | | | | | | | | | | | | | | | | In commit 9915de6c1cb2, we introduced a new wait point for replication slots and incorrectly labelled it as wait event PG_WAIT_LOCK. That's wrong, so invent an appropriate new wait event instead, and document it properly. While at it, fix numerous other problems in the vicinity: - two different walreceiver wait events were being mixed up in a single wait event (which wasn't documented either); split it out so that they can be distinguished, and document the new events properly. - ParallelBitmapPopulate was documented but didn't exist. - ParallelBitmapScan was not documented (I think this should be called "ParallelBitmapScanInit" instead.) - Logical replication wait events weren't documented - various symbols had been added in dartboard order in various places. Put them in alphabetical order instead, as was originally intended. Discussion: https://postgr.es/m/20170808181131.mu4fjepuh5m75cyq@alvherre.pgsql
* Stamp 10beta3.REL_10_BETA3Tom Lane2017-08-07
|
* Update SQL features listPeter Eisentraut2017-08-07
|
* Translation updatesPeter Eisentraut2017-08-07
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1a0b5e655d7871506c2b1c7ba562c2de6b6a55de
* Fix local/remote attribute mix-up in logical replicationPeter Eisentraut2017-08-07
| | | | | | | | | This would lead to failures if local and remote tables have a different column order. The tests previously didn't catch that because they only tested the initial data copy. So add another test that exercises the apply worker. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>
* Fix handling of dropped columns in logical replicationPeter Eisentraut2017-08-07
| | | | | | | | | The relation attribute map was not initialized for dropped columns, leading to errors later on. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Reported-by: Scott Milliken <scott@deltaex.com> Bug: #14769
* Require update permission for the large object written by lo_put().Tom Lane2017-08-07
| | | | | | | | | | lo_put() surely should require UPDATE permission, the same as lowrite(), but it failed to check for that, as reported by Chapman Flack. Oversight in commit c50b7c09d; backpatch to 9.4 where that was introduced. Tom Lane and Michael Paquier Security: CVE-2017-7548
* Again match pg_user_mappings to information_schema.user_mapping_options.Noah Misch2017-08-07
| | | | | | | | | | | | | | | Commit 3eefc51053f250837c3115c12f8119d16881a2d7 claimed to make pg_user_mappings enforce the qualifications user_mapping_options had been enforcing, but its removal of a longstanding restriction left them distinct when the current user is the subject of a mapping yet has no server privileges. user_mapping_options emits no rows for such a mapping, but pg_user_mappings includes full umoptions. Change pg_user_mappings to show null for umoptions. Back-patch to 9.2, like the above commit. Reviewed by Tom Lane. Reported by Jeff Janes. Security: CVE-2017-7547
* Don't allow logging in with empty password.Heikki Linnakangas2017-08-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some authentication methods allowed it, others did not. In the client-side, libpq does not even try to authenticate with an empty password, which makes using empty passwords hazardous: an administrator might think that an account with an empty password cannot be used to log in, because psql doesn't allow it, and not realize that a different client would in fact allow it. To clear that confusion and to be be consistent, disallow empty passwords in all authentication methods. All the authentication methods that used plaintext authentication over the wire, except for BSD authentication, already checked that the password received from the user was not empty. To avoid forgetting it in the future again, move the check to the recv_password_packet function. That only forbids using an empty password with plaintext authentication, however. MD5 and SCRAM need a different fix: * In stable branches, check that the MD5 hash stored for the user does not not correspond to an empty string. This adds some overhead to MD5 authentication, because the server needs to compute an extra MD5 hash, but it is not noticeable in practice. * In HEAD, modify CREATE and ALTER ROLE to clear the password if an empty string, or a password hash that corresponds to an empty string, is specified. The user-visible behavior is the same as in the stable branches, the user cannot log in, but it seems better to stop the empty password from entering the system in the first place. Secondly, it is fairly expensive to check that a SCRAM hash doesn't correspond to an empty string, because computing a SCRAM hash is much more expensive than an MD5 hash by design, so better avoid doing that on every authentication. We could clear the password on CREATE/ALTER ROLE also in stable branches, but we would still need to check at authentication time, because even if we prevent empty passwords from being stored in pg_authid, there might be existing ones there already. Reported by Jeroen van der Ham, Ben de Graaff and Jelte Fennema. Security: CVE-2017-7546
* Fix function name in code commentPeter Eisentraut2017-08-07
| | | | Reported-by: Peter Geoghegan <pg@bowt.ie>
* Improve wording of subscription refresh debug messagesPeter Eisentraut2017-08-07
| | | | Reported-by: Yugo Nagata <nagata@sraoss.co.jp>
* Downgrade subscription refresh messages to DEBUG1Peter Eisentraut2017-08-07
| | | | | | | | | The NOTICE messages about tables being added or removed during subscription refresh would be incorrect and possibly confusing if the transaction rolls back, so silence them but keep them available for debugging. Discussion: https://www.postgresql.org/message-id/CAD21AoAvaXizc2h7aiNyK_i0FQSa-tmhpdOGwbhh7Jy544Ad4Q%40mail.gmail.com
* Update RELEASE_CHANGES' example of branch name format.Tom Lane2017-08-06
| | | | | | | | | | | We're planning to put an underscore before the major version number in branch names for v10 and later. Make sure the recipe in RELEASE_CHANGES reflects that. In passing, add a reminder to consider doing pgindent right before the branch. Discussion: https://postgr.es/m/E1dAkjZ-0003MG-0U@gemulon.postgresql.org
* Fix thinko introduced in 2bef06d516460 et al.Andres Freund2017-08-06
| | | | | | | | | | | | | | The callers for GetOldestSafeDecodingTransactionId() all inverted the argument for the argument introduced in 2bef06d516460. Luckily this appears to be inconsequential for the moment, as we wait for concurrent in-progress transaction when assembling a snapshot. Additionally this could only make a difference when adding a second logical slot, because only a pre-existing slot could cause an issue by lowering the returned xid dangerously much. Reported-By: Antonin Houska Discussion: https://postgr.es/m/32704.1496993134@localhost Backport: 9.4-, where 2bef06d516460 was backpatched to.
* Suppress unused-variable warnings when building with ICU 4.2.Tom Lane2017-08-05
| | | | Tidy-up for commit eccead9ed.
* Make pg_stop_backup's wait_for_archive flag work on standbys.Robert Haas2017-08-05
| | | | | | | | | | | | Previously, it had no effect. Now, if archive_mode=always, it will work, and if not, you'll get a warning. Masahiko Sawada, Michael Paquier, and Robert Haas. The patch as submitted also changed the behavior so that we would write and remove history files on standbys, but that seems like material for a separate patch to me. Discussion: http://postgr.es/m/CAD21AoC2Xw6M=ZJyejq_9d_iDkReC_=rpvQRw5QsyzKQdfYpkw@mail.gmail.com
* Add support for ICU 4.2Peter Eisentraut2017-08-05
| | | | | | | | | | | | | Supporting ICU 4.2 seems useful because it ships with CentOS 6. Versions before ICU 4.6 don't support pkg-config, so document an installation method without using pkg-config. In ICU 4.2, ucol_getKeywordsForLocale() sometimes returns values that will not be accepted by uloc_toLanguageTag(). Skip loading keyword variants in that version. Reported-by: Victor Wagner <vitus@wagner.pp.ru>
* Fix bug in deciding whether to scan newly-attached partition.Robert Haas2017-08-04
| | | | | | | | | If the table being attached had different attribute numbers than the parent, the old code could incorrectly decide it needed to be scanned. Amit Langote, reviewed by Ashutosh Bapat Discussion: http://postgr.es/m/CA+TgmobexgbBr2+Utw-pOMw9uxaBRKRjMW_-mmzKKx9PejPLMg@mail.gmail.com
* Only kill sync workers at commit time in subscription DDLPeter Eisentraut2017-08-04
| | | | | | This allows a transaction abort to avoid killing those workers. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>
* hash: Immediately after a bucket split, try to clean the old bucket.Robert Haas2017-08-04
| | | | | | | | | | | | If it works, then we won't be storing two copies of all the tuples that were just moved. If not, VACUUM will still take care of it eventually. Per a report from AP and analysis from Amit Kapila, it seems that a bulk load can cause splits fast enough that VACUUM won't deal with the problem in time to prevent bloat. Amit Kapila; I rewrote the comment. Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au
* Message style improvementsPeter Eisentraut2017-08-04
|
* hash: Increase the number of possible overflow bitmaps by 8x.Robert Haas2017-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per a report from AP, it's not that hard to exhaust the supply of bitmap pages if you create a table with a hash index and then insert a few billion rows - and then you start getting errors when you try to insert additional rows. In the particular case reported by AP, there's another fix that we can make to improve recycling of overflow pages, which is another way to avoid the error, but there may be other cases where this problem happens and that fix won't help. So let's buy ourselves as much headroom as we can without rearchitecting anything. The comments claim that the old limit was 64GB, but it was really only 32GB, because we didn't use all the bits in the page for bitmap bits - only the largest power of 2 that could fit after deducting space for the page header and so forth. Thus, we have 4kB per page for bitmap bits, not 8kB. The new limit is thus actually 8 times the old *real* limit but only 4 times the old *purported* limit. Since this breaks on-disk compatibility, bump HASH_VERSION. We've already done this earlier in this release cycle, so this doesn't cause any incremental inconvenience for people using pg_upgrade from releases prior to v10. However, users who use pg_upgrade to reach 10beta3 or later from 10beta2 or earlier will need to REINDEX any hash indexes again. Amit Kapila and Robert Haas Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au
* Apply ALTER ... SET NOT NULL recursively in ALTER ... ADD PRIMARY KEY.Tom Lane2017-08-04
| | | | | | | | | | | | | | | | | | | | | If you do ALTER COLUMN SET NOT NULL against an inheritance parent table, it will recurse to mark all the child columns as NOT NULL as well. This is necessary for consistency: if the column is labeled NOT NULL then reading it should never produce nulls. However, that didn't happen in the case where ALTER ... ADD PRIMARY KEY marks a target column NOT NULL that wasn't before. That was questionable from the beginning, and now Tushar Ahuja points out that it can lead to dump/restore failures in some cases. So let's make that case recurse too. Although this is meant to fix a bug, it's enough of a behavioral change that I'm pretty hesitant to back-patch, especially in view of the lack of similar field complaints. It doesn't seem to be too late to put it into v10 though. Michael Paquier, editorialized on slightly by me Discussion: https://postgr.es/m/b8794d6a-38f0-9d7c-ad4b-e85adf860fc9@enterprisedb.com
* Disallow SSL session tickets.Tom Lane2017-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | We don't actually support session tickets, since we do not create an SSL session identifier. But it seems that OpenSSL will issue a session ticket on-demand anyway, which will then fail when used. This results in reconnection failures when using ticket-aware client-side SSL libraries (such as the Npgsql .NET driver), as reported by Shay Rojansky. To fix, just tell OpenSSL not to issue tickets. At some point in the far future, we might consider enabling tickets instead. But the security implications of that aren't entirely clear; and besides it would have little benefit except for very short-lived database connections, which is Something We're Bad At anyhow. It would take a lot of other work to get to a point where that would really be an exciting thing to do. While at it, also tell OpenSSL not to use a session cache. This doesn't really do anything, since a backend would never populate the cache anyway, but it might gain some micro-efficiencies and/or reduce security exposures. Patch by me, per discussion with Heikki Linnakangas and Shay Rojansky. Back-patch to all supported versions. Discussion: https://postgr.es/m/CADT4RqBU8N-csyZuzaook-c795dt22Zcwg1aHWB6tfVdAkodZA@mail.gmail.com
* Further unify ROLE and USER command grammar rulesPeter Eisentraut2017-08-03
| | | | | | | | ALTER USER ... SET did not support all the syntax variants of ALTER ROLE ... SET. Fix that, and to avoid further deviations of this kind, unify many the grammar rules for ROLE/USER/GROUP commands. Reported-by: Pavel Golub <pavel@microolap.com>
* Fix pg_dump/pg_restore to emit REFRESH MATERIALIZED VIEW commands last.Tom Lane2017-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because we push all ACL (i.e. GRANT/REVOKE) restore steps to the end, materialized view refreshes were occurring while the permissions on referenced objects were still at defaults. This led to failures if, say, an MV owned by user A reads from a table owned by user B, even if B had granted the necessary privileges to A. We've had multiple complaints about that type of restore failure, most recently from Jordan Gigov. The ideal fix for this would be to start treating ACLs as dependency- sortable objects, rather than hard-wiring anything about their dump order (the existing approach is a messy kluge dating to commit dc0e76ca3). But that's going to be a rather major change, and it certainly wouldn't lead to a back-patchable fix. As a short-term solution, convert the existing two-pass hack (ie, normal objects then ACLs) to a three-pass hack, ie, normal objects then ACLs then matview refreshes. Because this happens in RestoreArchive(), it will also fix the problem when restoring from an existing archive-format dump. (Note this means that if a matview refresh would have failed under the permissions prevailing at dump time, it'll fail during restore as well. We'll define that as user error rather than something we should try to work around.) To avoid performance loss in parallel restore, we need the matview refreshes to still be parallelizable. Hence, clean things up enough so that both ACLs and matviews are handled by the parallel restore infrastructure, instead of reverting back to serial restore for ACLs. There is still a final serial step, but it shouldn't normally have to do anything; it's only there to try to recover if we get stuck due to some problem like unresolved circular dependencies. Patch by me, but it owes something to an earlier attempt by Kevin Grittner. Back-patch to 9.3 where materialized views were introduced. Discussion: https://postgr.es/m/28572.1500912583@sss.pgh.pa.us
* Fix build on zlib-less environmentsAlvaro Herrera2017-08-03
| | | | | | | | | | | | | | | Commit 4d57e8381677 added support for getting I/O errors out of zlib, but it introduced a portability problem for systems without zlib. Repair by wrapping the zlib call inside #ifdef and restore the original code in the other branch. This serves to illustrate the inadequacy of the zlib abstraction in pg_backup_archiver: there is no way to call gzerror() in that abstraction. This means that the several places that call GZREAD and GZWRITE are currently doing error reporting wrongly, but ENOTIME to get it fixed before next week's release set. Backpatch to 9.4, like the commit that introduced the problem.
* Fix lock upgrade hazard in ATExecAttachPartition.Robert Haas2017-08-03
| | | | | | Amit Langote Discussion: http://postgr.es/m/CAFjFpReT_kq_uwU_B8aWDxR7jNGE=P0iELycdq5oupi=xSQTOw@mail.gmail.com
* Code beautification for ATExecAttachPartition.Robert Haas2017-08-03
| | | | | | Amit Langote Discussion: http://postgr.es/m/CAFjFpReT_kq_uwU_B8aWDxR7jNGE=P0iELycdq5oupi=xSQTOw@mail.gmail.com
* Allow a foreign table CHECK constraint to be initially NOT VALID.Robert Haas2017-08-03
| | | | | | | | | | | | For a table, the constraint can be considered validated immediately, because the table must be empty. But for a foreign table this is not necessarily the case. Fixes a bug in commit f27a6b15e6566fba7748d0d9a3fc5bcfd52c4a1b. Amit Langote, with some changes by me. Discussion: http://postgr.es/m/d2b7419f-4a71-cf86-cc99-bfd0f359a1ea@lab.ntt.co.jp
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-15 13:01:41 +0000