Movatterモバイル変換


[0]ホーム

URL:



Facebook
Postgres Pro
Facebook
Downloads
E.33. Release 9.6.24
Prev UpAppendix E. Release NotesHome Next

E.33. Release 9.6.24

Release date: 2021-11-11

This release contains a variety of fixes from 9.6.23. For information about new features in the 9.6 major release, seeSection E.57.

This is expected to be the lastPostgreSQL release in the 9.6.X series. Users are encouraged to update to a newer release branch soon.

E.33.1. Migration to Version 9.6.24

A dump/restore is not required for those running 9.6.X.

However, note that installations using physical replication should update standby servers before the primary server, as explained in the third changelog entry below.

Also, several bugs have been found that may have resulted in corrupted indexes, as explained in the next several changelog entries. If any of those cases apply to you, it's recommended to reindex possibly-affected indexes after updating.

Also, if you are upgrading from a version earlier than 9.6.21, seeSection E.36.

E.33.2. Changes

  • Make the server reject extraneous data after an SSL or GSS encryption handshake (Tom Lane)

    A man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could be abused to send faked SQL commands to the server, although that would only work if the server did not demand any authentication data. (However, a server relying on SSL certificate authentication might well not do so.)

    ThePostgreSQL Project thanks Jacob Champion for reporting this problem. (CVE-2021-23214)

  • Makelibpq reject extraneous data after an SSL or GSS encryption handshake (Tom Lane)

    A man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client's first few queries, although other details of libpq's behavior make that harder than it sounds. A different line of attack is to exfiltrate the client's password, or other sensitive data that might be sent early in the session. That has been shown to be possible with a server vulnerable to CVE-2021-23214.

    ThePostgreSQL Project thanks Jacob Champion for reporting this problem. (CVE-2021-23222)

  • Fix physical replication for cases where the primary crashes after shipping a WAL segment that ends with a partial WAL record (Álvaro Herrera)

    If the primary did not survive long enough to finish writing the rest of the incomplete WAL record, then the previous crash-recovery logic had it back up and overwrite WAL starting from the beginning of the incomplete WAL record. This is problematic since standby servers may already have copies of that WAL segment. They will then see an inconsistent next segment, and will not be able to recover without manual intervention. To fix, do not back up over a WAL segment boundary when restarting after a crash. Instead write a new type of WAL record at the start of the next WAL segment, informing readers that the incomplete WAL record will never be finished and must be disregarded.

    When applying this update, it's best to update standby servers before the primary, so that they will be ready to handle this new WAL record type if the primary happens to crash.

  • FixCREATE INDEX CONCURRENTLY to wait for the latest prepared transactions (Andrey Borodin)

    Rows inserted by just-prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. The previous fix for this type of problem failed to account forPREPARE TRANSACTION commands that were still in progress whenCREATE INDEX CONCURRENTLY checked for them. As before, in installations that have enabled prepared transactions (max_prepared_transactions > 0), it's recommended to reindex any concurrently-built indexes in case this problem occurred when they were built.

  • Avoid race condition that can cause backends to fail to add entries for new rows to an index being built concurrently (Noah Misch, Andrey Borodin)

    While it's apparently rare in the field, this case could potentially affect any index built or reindexed with theCONCURRENTLY option. It is recommended to reindex any such indexes to make sure they are correct.

  • Fixfloat4 andfloat8 hash functions to produce uniform results for NaNs (Tom Lane)

    SincePostgreSQL's floating-point types deem all NaNs to be equal, it's important for the hash functions to produce the same hash code for all bit-patterns that are NaNs according to the IEEE 754 standard. This failed to happen before, meaning that hash indexes and hash-based query plans might produce incorrect results for non-canonical NaN values. ('-NaN'::float8 is one way to produce such a value on most machines.) It is advisable to reindex hash indexes on floating-point columns, if there is any possibility that they might contain such values.

  • Prevent data loss during crash recovery ofCREATE TABLESPACE, whenwal_level =minimal (Noah Misch)

    If the server crashed betweenCREATE TABLESPACE and the next checkpoint, replay would fully remove the contents of the new tablespace's directory, relying on subsequent WAL replay to restore everything within that directory. This interacts badly with optimizations that skip writing WAL (one example isCOPY into a just-created table). Such optimizations are applied only whenwal_level isminimal, which is not the default in v10 and later.

  • Don't discard a cast to the same type with unspecified type modifier (Tom Lane)

    For example, if columnf1 is of typenumeric(18,3), the parser used to simply discard a cast likef1::numeric, on the grounds that it would have no run-time effect. That's true, but the exposed type of the expression should still be considered to be plainnumeric, notnumeric(18,3). This is important for correctly resolving the type of larger constructs, such as recursiveUNIONs.

  • Fix corner-case loss of precision in numericpower() (Dean Rasheed)

    The result could be inaccurate when the first argument is very close to 1.

  • Avoid regular expression errors with capturing parentheses inside{0} (Tom Lane)

    Regular expressions like(.){0}...\1 drewinvalid backreference number. Other regexp engines such as Perl don't complain, though, and for that matter ours doesn't either in some closely related cases. Worse, it could throw an assertion failure instead. Fix it so that no error is thrown and instead the back-reference is silently deemed to never match.

  • Prevent regular expression back-references from sometimes matching when they shouldn't (Tom Lane)

    The regexp engine was careless about clearing match data for capturing parentheses after rejecting a partial match. This could allow a later back-reference to match in places where it should fail for lack of a defined referent.

  • Fix regular expression performance bug with back-references inside iteration nodes (Tom Lane)

    Incorrect back-tracking logic could result in exponential time spent looking for a match. Fortunately the problem is masked in most cases by other optimizations.

  • Fix incorrect results fromAT TIME ZONE applied to atime with time zone value (Tom Lane)

    The results were incorrect if the target time zone was specified by a dynamic timezone abbreviation (that is, one that is defined as equivalent to a full time zone name, rather than a fixed UTC offset).

  • Clean up correctly if a transaction fails after exporting its snapshot (Dilip Kumar)

    This oversight would only cause a problem if the same session attempted to export a snapshot again. The most likely scenario for that is creation of a replication slot (followed by rollback) and then creation of another replication slot.

  • Prevent wraparound of overflowed-subtransaction tracking on standby servers (Kyotaro Horiguchi, Alexander Korotkov)

    This oversight could cause significant performance degradation (manifesting as excessive SubtransSLRU traffic) on standby servers.

  • Ensure that prepared transactions are properly accounted for during promotion of a standby server (Michael Paquier, Andres Freund)

    There was a narrow window where a prepared transaction could be omitted from a snapshot taken by a concurrently-running session. If that session then used the snapshot to perform data updates, erroneous results or data corruption could occur.

  • Fix detection of a relation that has grown to the maximum allowed length (Tom Lane)

    An attempt to extend a table or index past the limit of 2^32-1 blocks was rejected, but not soon enough to prevent inconsistent internal state from being created.

  • Correctly track the presence of data-modifying CTEs when expanding aDO INSTEAD rule (Greg Nancarrow, Tom Lane)

    The previous failure to do this could lead to problems such as unsafely choosing a parallel plan.

  • Ensure that walreceiver processes create all required archive notification files before exiting (Fujii Masao)

    If a walreceiver exited exactly at a WAL segment boundary, it failed to make a notification file for the last-received segment, thus delaying archiving of that segment on the standby.

  • Avoid trying to lock theOLD andNEW pseudo-relations in a rule that usesSELECT FOR UPDATE (Masahiko Sawada, Tom Lane)

  • Fix parser's processing of aggregateFILTER clauses (Tom Lane)

    If theFILTER expression is a plain boolean column, the semantic level of the aggregate could be mis-determined, leading to not-per-spec behavior. If theFILTER expression is itself a boolean-returning aggregate, an error should be thrown but was not, likely resulting in a crash at execution.

  • Avoid null-pointer-dereference crash when dropping a role that owns objects being dropped concurrently (Álvaro Herrera)

  • Preventsnapshot reference leak warning whenlo_export() or a related function fails (Heikki Linnakangas)

  • Ensure that scans of SP-GiST indexes are counted in the statistics views (Tom Lane)

    Incrementing the number-of-index-scans counter was overlooked in the SP-GiST code, although per-tuple counters were advanced correctly.

  • Recalculate relevant wait intervals ifrecovery_min_apply_delay is changed during recovery (Soumyadeep Chakraborty, Ashwin Agrawal)

  • Fixecpg to recover correctly aftermalloc() failure while establishing a connection (Michael Paquier)

  • AllowEXIT out of the outermost block in a PL/pgSQL routine (Tom Lane)

    If the routine does not require an explicitRETURN, this usage should be valid, but it was rejected.

  • Removepg_ctl's hard-coded limits on the total length of generated commands (Phil Krylov)

    For example, this removes a restriction on how many command-line options can be passed through to the postmaster. Individual path names thatpg_ctl deals with, such as the postmaster executable's name or the data directory name, are still limited toMAXPGPATH bytes in most cases.

  • Fixpg_dump to dump non-global default privileges correctly (Neil Chen, Masahiko Sawada)

    If a global (unrestricted)ALTER DEFAULT PRIVILEGES command revoked some present-by-default privilege, for exampleEXECUTE for functions, and then a restrictedALTER DEFAULT PRIVILEGES command granted that privilege again for a selected role or schema,pg_dump failed to dump the restricted privilege grant correctly.

  • Improvepg_dump's performance by avoiding making per-table queries for RLS policies, and by avoiding repetitive calls toformat_type() (Tom Lane)

    These changes provide only marginal improvement when dumping from a local server, but a dump from a remote server can benefit substantially due to fewer network round-trips.

  • Fix incorrect filename inpg_restore's error message about an invalid large object TOC file (Daniel Gustafsson)

  • Fix failure ofcontrib/btree_gin indexes on"char" (notchar(n)) columns, when an indexscan using the< or<= operator is performed (Tom Lane)

    Such an indexscan failed to return all the entries it should.

  • Changecontrib/pg_stat_statements to read itsquery texts file in units of at most 1GB (Tom Lane)

    Such large query text files are very unusual, but if they do occur, the previous coding would fail on Windows 64 (which rejects individual read requests of more than 2GB).

  • Fix null-pointer crash whencontrib/postgres_fdw tries to report a data conversion error (Tom Lane)

  • Add spinlock support for the RISC-V architecture (Marek Szuba)

    This is essential for reasonable performance on that platform.

  • Set correct type identifier on OpenSSL BIO (I/O abstraction) objects created byPostgreSQL (Itamar Gafni)

    This oversight probably only matters for code that is doing tasks like auditing the OpenSSL installation. But it's nominally a violation of the OpenSSL API, so fix it.

  • Makepg_regexec() robust against an out-of-rangesearch_start parameter (Tom Lane)

    ReturnREG_NOMATCH, instead of possibly crashing, whensearch_start is past the end of the string. This case is probably unreachable within corePostgreSQL, but extensions might be more careless about the parameter value.

  • Ensure thatGetSharedSecurityLabel() can be used in a newly-started session that has not yet built its critical relation cache entries (Jeff Davis)

  • Use the CLDR project's data to map Windows time zone names to IANA time zones (Tom Lane)

    When running on Windows,initdb attempts to set the new cluster'stimezone parameter to the IANA time zone matching the system's prevailing time zone. We were using a mapping table that we'd generated years ago and updated only fitfully; unsurprisingly, it contained a number of errors as well as omissions of recently-added zones. It turns out that CLDR has been tracking the most appropriate mappings, so start using their data. This change will not affect any existing installation, only newly-initialized clusters.

  • Update time zone data files totzdata release 2021e for DST law changes in Fiji, Jordan, Palestine, and Samoa, plus historical corrections for Barbados, Cook Islands, Guyana, Niue, Portugal, and Tonga.

    Also, the Pacific/Enderbury zone has been renamed to Pacific/Kanton. Also, the following zones have been merged into nearby, more-populous zones whose clocks have agreed with them since 1970: Africa/Accra, America/Atikokan, America/Blanc-Sablon, America/Creston, America/Curacao, America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville, and Antarctica/Syowa. In all these cases, the previous zone name remains as an alias.


Prev Home Next
E.32. Postgres Pro Standard 9.6.0.1 Up E.34. Release 9.6.23
pdfepub
Go to Postgres Pro Standard 9.6
By continuing to browse this website, you agree to the use of cookies. Go toPrivacy Policy.

[8]ページ先頭

©2009-2025 Movatter.jp