-
Latest Version
PostgreSQL 17.1 LATEST
-
Review by
-
Operating System
macOS 10.13 High Sierra or later
-
User Rating
Click to vote -
Author / Product
-
Filename
postgresql-17.1-1-osx.dmg
It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation (table sizes can go up to 32 TB).
Also Available: Download PostgreSQL for Windows
What's new in this version:
- Ensure cached plans are marked as dependent on the calling role when RLS applies to a non-top-level table reference
- If a CTE, subquery, sublink, security invoker view, or coercion projection in a query references a table with row-level security policies, we neglected to mark the resulting plan as potentially dependent on which role is executing it. This could lead to later query executions in the same session using the wrong plan, and then returning or hiding rows that should have been hidden or returned instead.
- The PostgreSQL Project thanks Wolfgang Walther for reporting this problem.
- Make libpq discard error messages received during SSL or GSS protocol negotiation
- An error message received before encryption negotiation is completed might have been injected by a man-in-the-middle, rather than being real server output. Reporting it opens the door to various security hazards; for example, the message might spoof a query result that a careless user could mistake for correct output. The best answer seems to be to discard such data and rely only on libpq's own report of the connection failure.
- The PostgreSQL Project thanks Jacob Champion for reporting this problem.
- Fix unintended interactions between SET SESSION AUTHORIZATION and SET ROLE
- The SQL standard mandates that SET SESSION AUTHORIZATION have a side-effect of doing SET ROLE NONE. Our implementation of that was flawed, creating more interaction between the two settings than intended. Notably, rolling back a transaction that had done SET SESSION AUTHORIZATION would revert ROLE to NONE even if that had not been the previous state, so that the effective user ID might now be different from what it had been before the transaction. Transiently setting session_authorization in a function SET clause had a similar effect. A related bug was that if a parallel worker inspected current_setting('role'), it saw none even when it should see something else.
- The PostgreSQL Project thanks Tom Lane for reporting this problem.
- Prevent trusted PL/Perl code from changing environment variables
- The ability to manipulate process environment variables such as PATH gives an attacker opportunities to execute arbitrary code. Therefore, “trusted” PLs must not offer the ability to do that. To fix plperl, replace %ENV with a tied hash that rejects any modification attempt with a warning. Untrusted plperlu retains the ability to change the environment.
- The PostgreSQL Project thanks Coby Abrams for reporting this problem.
- Fix updates of catalog state for foreign-key constraints when attaching or detaching table partitions
- If the referenced table is partitioned, then different catalog entries are needed for a referencing table that is stand-alone versus one that is a partition. ATTACH/DETACH PARTITION commands failed to perform this conversion correctly. In particular, after DETACH the now stand-alone table would be missing foreign-key enforcement triggers, which could result in the table later containing rows that fail the foreign-key constraint. A subsequent re-ATTACH could fail with surprising errors, too.
- The way to fix this is to do ALTER TABLE DROP CONSTRAINT on the now stand-alone table for each faulty constraint, and then re-add the constraint. If re-adding the constraint fails, then some erroneous data has crept in. You will need to manually re-establish consistency between the referencing and referenced tables, then re-add the constraint.
- This query can be used to identify broken constraints and construct the commands needed to recreate them
- Since it is possible that one or more of the ADD CONSTRAINT steps will fail, you should save the query's output in a file and then attempt to perform each step.
- Fix test for C locale when LC_COLLATE is different from LC_CTYPE
- When using libc as the default collation provider, the test to see if C locale is in use for collation accidentally checked LC_CTYPE not LC_COLLATE. This has no impact in the typical case where those settings are the same, nor if both are not C
- Don't use partitionwise joins or grouping if the query's collation for the key column doesn't match the partition key's collation
- Such plans could produce incorrect results.
- Avoid planner failure after converting an IS NULL test on a NOT NULL column to constant FALSE
- This bug typically led to errors such as “variable not found in subplan target lists”.
- Avoid possible planner crash while inlining a SQL function whose arguments contain certain array-related constructs
- Fix possible wrong answers or “wrong varnullingrels” planner errors for MERGE ... WHEN NOT MATCHED BY SOURCE actions
- Fix possible “could not find pathkey item to sort” error when the output of a UNION ALL member query needs to be sorted, and the sort column is an expression
- Fix edge case in B-tree ScalarArrayOp index scans
- When a scrollable cursor with a plan of this kind was backed up to its starting point and then run forward again, wrong answers were possible.
- Fix assertion failure or confusing error message for COPY
- Fix validation of COPY's FORCE_NOT_NULL and FORCE_NULL options
- Some incorrect usages are now rejected as they should be.
- Fix server crash when a json_objectagg() call contains a volatile function
- Fix detection of skewed data during parallel hash join
- After repartitioning the inner side of a hash join because one partition has accumulated too many tuples, we check to see if all the partition's tuples went into the same child partition, which suggests that they all have the same hash value and further repartitioning cannot improve matters. This check malfunctioned in some cases, allowing repeated futile repartitioning which would eventually end in a resource-exhaustion error.
- Avoid crash when ALTER DATABASE SET is used to set a server parameter that requires search-path-based lookup, such as default_text_search_config
- Avoid repeated lookups of opclasses and collations while creating a new index on a partitioned table
- This was problematic mainly because some of the lookups would be done with a restricted search_path, leading to unexpected failures if the CREATE INDEX command referenced objects outside pg_catalog.
- This fix also prevents comments on the parent partitioned index from being copied to child indexes.
- Add missing dependency from a partitioned table to a non-built-in access method specified in CREATE TABLE ... USING
- Dropping the access method should be blocked when a table exists that depends on it, but it was not, allowing subsequent odd behavior. Note that this fix only prevents problems for partitioned tables created after this update.
- Disallow locale names containing non-ASCII characters
- This is only an issue on Windows, as such locale names are not used elsewhere. They are problematic because it's quite unclear what encoding such names are represented in
- Anyone who encounters the new error message should either create a new duplicated locale with an ASCII-only name using Windows Locale Builder, or consider using BCP 47-compliant locale names like tr-TR.
- Fix race condition in committing a serializable transaction
- Mis-processing of a recently committed transaction could lead to an assertion failure or a “could not access status of transaction” error.
- Fix race condition in COMMIT PREPARED that resulted in orphaned 2PC files
- A concurrent PREPARE TRANSACTION could cause COMMIT PREPARED to not remove the on-disk two-phase state file for the completed transaction. There was no immediate ill effect, but a subsequent crash-and-recovery could fail with “could not access status of transaction”, requiring manual removal of the orphaned file to restore service.
- Avoid invalid memory accesses after skipping an invalid toast index during VACUUM FULL
- A list tracking yet-to-be-rebuilt indexes was not properly updated in this code path, risking assertion failures or crashes later on.
- Fix ways in which an “in place” catalog update could be lost
- Normal row updates write a new version of the row to preserve rollback-ability of the transaction. However, certain system catalog updates are intentionally non-transactional and are done with an in-place update of the row. These patches fix race conditions that could cause the effects of an in-place update to be lost. As an example, it was possible to forget having set pg_class.relhasindex to true, preventing updates of the new index and thus causing index corruption.
- Reset catalog caches at end of recovery
- This prevents scenarios wherein an in-place catalog update could be lost due to using stale data from a catalog cache.
- Avoid using parallel query while holding off interrupts
- This situation cannot arise normally, but it can be reached with test scenarios such as using a SQL-language function as B-tree support
- Ignore not-yet-defined Portals in the pg_cursors view
- It is possible for user-defined code that inspects this view to be called while a new cursor is being set up, and if that happens a null pointer dereference would ensue. Avoid the problem by defining the view to exclude incompletely-set-up cursors.
- Avoid “unexpected table_index_fetch_tuple call during logical decoding” error while decoding a transaction involving insertion of a column default value
- Reduce memory consumption of logical decoding
- Use a smaller default block size to store tuple data received during logical replication. This reduces memory wastage, which has been reported to be severe while processing long-running transactions, even leading to out-of-memory failures.
- Fix behavior of stable functions called from a CALL statement's argument list, when the CALL is within a PL/pgSQL EXCEPTION block
- As with a similar fix in our previous quarterly releases, this case allowed such functions to be passed the wrong snapshot, causing them to see stale values of rows modified since the start of the outer transaction.
- Parse libpq's keepalives connection option in the same way as other integer-valued options
- The coding used here rejected trailing whitespace in the option value, unlike other cases. This turns out to be problematic in ecpg's usage, for example.
- In ecpglib, fix out-of-bounds read when parsing incorrect datetime input
- It was possible to try to read the location just before the start of a constant array. Real-world consequences seem minimal, though.
- Fix psql's describe commands to again work with pre-9.4 servers
- Commands involving display of an ACL
- Avoid hanging if an interval less than 1ms is specified in psql's watch command
- Instead, treat this the same as an interval of zero
- Fix failure to find replication password in ~/.pgpass
- pg_basebackup and pg_receivewal failed to match an entry in ~/.pgpass that had replication in the database name field, if no -d or --dbname switch was supplied. This resulted in an unexpected prompt for password.
- In pg_combinebackup, throw an error if an incremental backup file is present in a directory that is supposed to contain a full backup
- In pg_combinebackup, don't construct filenames containing double slashes
- This caused no functional problems, but the duplicate slashes were visible in error messages, which could create confusion.
- Avoid trying to reindex temporary tables and indexes in vacuumdb and in parallel reindexdb
- Reindexing other sessions' temporary tables cannot work, but the check to skip them was missing in some code paths, leading to unwanted failures.
- Fix incorrect LLVM-generated code on ARM64 platforms
- When using JIT compilation on ARM platforms, the generated code could not support relocation distances exceeding 32 bits, allowing unlucky placement of generated code to cause server crashes on large-memory systems.
- Fix a few places that assumed that process start time
- On platforms where long is 32 bits
- Update time zone data files to tzdata release 2024b
- OperaOpera 114.0 Build 5282.185
- PhotoshopAdobe Photoshop CC 2024 25.12
- OKXOKX - Buy Bitcoin or Ethereum
- Hero WarsHero Wars - Online Action Game
- Adobe AcrobatAdobe Acrobat Pro 2024.002.20854
- TradingViewTradingView - Track All Markets
- ParallelsParallels Desktop 20.1.1
- 4K Video4K Video Downloader+ 1.10.0
- CleanMyMacCleanMyMac X 4.15.8
- 4DDiG4DDiG Mac Data Recovery 5.2.2
Comments and User Reviews