PostgreSQL 17.3 freeware
... Group, is a powerful, open-source relational database management system known for its robustness and flexibility. With support for advanced data types, complex queries, and extensive indexing options, it excels in handling large volumes of data while ensuring high performance and reliability. Its strong adherence to SQL standards, combined with a vibrant community and rich ecosystem of extensions, makes PostgreSQL an ideal choice for dev ... ...
Author | PostgreSQL Global Development |
Released | 2025-02-13 |
Filesize | 331.00 MB |
Downloads | 4638 |
OS | Windows 11, Windows Server 2019, Windows Server 2016, Windows 10 32/64 bit, Windows Server 2012 R2, Windows Server 2012, Windows 2008, Windows 8 32/64 bit, Windows 7 32/64 bit |
Installation | Instal And Uninstall |
Keywords | PostgreSQL, relational database manager, database management, query planner, SQL, query, table, management |
Users' rating (58 rating) |
PostgreSQL Free Download - we do not host any PostgreSQL torrent files or links of PostgreSQL on rapidshare.com, depositfiles.com, megaupload.com etc. All PostgreSQL download links are direct PostgreSQL download from publisher site or their selected mirrors.
17.3 | Feb 13, 2025 | New Release | Harden PQescapeString and allied functions against invalidly-encoded input strings (Andres Freund, Noah Misch) Data-quoting functions supplied by libpq now fully check the encoding validity of their input. If invalid characters are detected, they report an error if possible. For the ones that lack an error return convention, the output string is adjusted to ensure that the server will report invalid encoding and no intervening processing will be fooled by bytes that might happen to match single quote, backslash, etc. The purpose of this change is to guard against SQL-injection attacks that are possible if one of these functions is used to quote crafted input. There is no hazard when the resulting string is sent directly to a PostgreSQL server (which would check its encoding anyway), but there is a risk when it is passed through psql or other client-side code. Historically such code has not carefully vetted encoding, and in many cases it's not clear what it should do if it did detect such a problem. This fix is effective only if the data-quoting function, the server, and any intermediate processing agree on the character encoding that's being used. Applications that insert untrusted input into SQL commands should take special care to ensure that that's true. Applications and drivers that quote untrusted input without using these libpq functions may be at risk of similar problems. They should first confirm the data is valid in the encoding expected by the server. The PostgreSQL Project thanks Stephen Fewer for reporting this problem. (CVE-2025-1094) Restore auto-truncation of database and user names appearing in connection requests (Nathan Bossart) This reverts a v17 change that proved to cause trouble for some users. Over-length names should be truncated in an encoding-aware fashion, but for now just return to the former behavior of blind truncation at NAMEDATALEN-1 bytes. Exclude parallel workers from connection privilege checks and limits (Tom Lane) Do not check da |
17.2 | Nov 21, 2024 | New Release | The issues listed below affect PostgreSQL 17. Some of these issues may also affect other supported versions of PostgreSQL: Restore functionality of ALTER ROLE .. SET ROLE and ALTER DATABASE .. SET ROLE. The fix for CVE-2024-10978 accidentally caused settings for role to not be applied if they came from non-interactive sources, including previous ALTER {ROLE|DATABASE} commands and the PGOPTIONS environment variable. Restore compatibility for the timescaledb and other PostgreSQL extensions built using PostgreSQL prior to the 2024-11-14 release (17.0, 16.4, 15.8, 14.13, 13.16, 12.20, and earlier). This fix restores struct ResultRelInfo to its previous size, so that affected extensions don't need to be rebuilt. Fix cases where a logical replication slot's restart_lsn could go backwards. Avoid deleting still-needed WAL files during pg_rewind. Fix race conditions associated with dropping shared statistics entries, which could lead to loss of statistics data. Fix crash with ALTER TABLE when checking to see if an index's opclass options have changed if the table has an index with a non-default operator class. |
17.1 | Nov 14, 2024 | New Release | Ensure cached plans are marked as dependent on the calling role when RLS applies to a non-top-level table reference (Nathan Bossart) § 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. (CVE-2024-10976) Make libpq discard error messages received during SSL or GSS protocol negotiation (Jacob Champion) § 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. (CVE-2024-10977) Fix unintended interactions between SET SESSION AUTHORIZATION and SET ROLE (Tom Lane) § § 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 s |