On Thu, Nov 9, 2017 at 4:53 PM, Andres Freund wrote:
> Primarily because it's not an anti-corruption tool. I'd be surprised if
> there weren't ways to corrupt the page using these corruptions that
> aren't detected by it.
It's very hard to assess the risk of missing something that's actually
dete
On 2017-11-09 16:45:07 -0800, Peter Geoghegan wrote:
> On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote:
> >> Actually, on second thought, I take that back -- I don't think that
> >> REINDEXing will even finish once a HOT chain is broken by the bug.
> >> IndexBuildHeapScan() actually does quite
On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote:
>> Actually, on second thought, I take that back -- I don't think that
>> REINDEXing will even finish once a HOT chain is broken by the bug.
>> IndexBuildHeapScan() actually does quite a good job of making sure
>> that HOT chains are sane, which
On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote:
>> I don't follow you here. Why would REINDEXing make the rows that
>> should be dead disappear again, even for a short period of time?
>
> It's not the REINDEX that makes them reappear.
Of course. I was just trying to make sense of what you sa
On 2017-11-09 16:02:17 -0800, Peter Geoghegan wrote:
> > What I'm currently wondering about is how much we need to harden
> > postgres against such existing corruption. If e.g. the hot chains are
> > broken somebody might have reindexed thinking the problem is fixed - but
> > if they then later vac
On Thu, Nov 9, 2017 at 2:24 PM, Andres Freund wrote:
> Attached is a version of the already existing regression test that both
> reproduces the broken hot chain (and thus failing index lookups) and
> then also the tuple reviving. I don't see any need for letting this run
> with arbitrary permutat
Add hash partitioning.
Hash partitioning is useful when you want to partition a growing data
set evenly. This can be useful to keep table sizes reasonable, which
makes maintenance operations such as VACUUM faster, or to enable
partition-wise join.
At present, we still depend on constraint exclus
On 2017-11-04 06:15:00 -0700, Andres Freund wrote:
> The reason for that is that I hadn't yet quite figured out how the bug I
> described in the commit message (and the previously committed testcase)
> would cause that. I was planning to diagnose / experiment more with this
> and write an email if
Remove junk left from DSSSL to XSL conversion
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/4ea3c243b98da6d526960586e9acc6d22283ffa2
Modified Files
--
doc/src/sgml/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
Sent via
Remove junk left from DSSSL to XSL conversion
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/e7397f015c9589f95f5f5b48d7a274b2f1628971
Modified Files
--
doc/src/sgml/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
Sent via pgsql-c
Refactor permissions checks for large objects.
Up to now, ACL checks for large objects happened at the level of
the SQL-callable functions, which led to CVE-2017-7548 because of a
missing check. Push them down to be enforced in inv_api.c as much
as possible, in hopes of preventing future bugs. T
Restrict lo_import()/lo_export() via SQL permissions not hard-wired checks.
While it's generally unwise to give permissions on these functions to
anyone but a superuser, we've been moving away from hard-wired permission
checks inside functions in favor of using the SQL permission system to
control
Fix typo in ALTER SYSTEM output.
The header comment written into postgresql.auto.conf by ALTER SYSTEM
should match what initdb put there originally.
Feike Steenbergen
Discussion:
https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com
Branch
--
REL9_5_STABLE
Fix typo in ALTER SYSTEM output.
The header comment written into postgresql.auto.conf by ALTER SYSTEM
should match what initdb put there originally.
Feike Steenbergen
Discussion:
https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com
Branch
--
REL_10_STABLE
Fix typo in ALTER SYSTEM output.
The header comment written into postgresql.auto.conf by ALTER SYSTEM
should match what initdb put there originally.
Feike Steenbergen
Discussion:
https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com
Branch
--
master
Detail
Fix typo in ALTER SYSTEM output.
The header comment written into postgresql.auto.conf by ALTER SYSTEM
should match what initdb put there originally.
Feike Steenbergen
Discussion:
https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com
Branch
--
REL9_4_STABLE
Fix typo in ALTER SYSTEM output.
The header comment written into postgresql.auto.conf by ALTER SYSTEM
should match what initdb put there originally.
Feike Steenbergen
Discussion:
https://postgr.es/m/CAK_s-G0KcKdO=0hqzkwb3s+tqzuuhwwqmf5bdsmoo9ftx75...@mail.gmail.com
Branch
--
REL9_6_STABLE
Fix bogus logic for checking executables' versions within pg_upgrade.
Somebody messed up a refactoring here. As it stood, we'd check pg_ctl's
--version output twice for each cluster. Worse, the first check for the
new cluster's version happened before we'd done any validate_exec checks
there, br
Fix bogus logic for checking executables' versions within pg_upgrade.
Somebody messed up a refactoring here. As it stood, we'd check pg_ctl's
--version output twice for each cluster. Worse, the first check for the
new cluster's version happened before we'd done any validate_exec checks
there, br
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code,
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code,
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code,
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code,
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code,
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code,
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclo
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclo
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
REL9_2_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/203b965f275061894621a5a359213ac77558d33f
Modified Files
--
doc/src/sgml/release-9.2.sgml | 25
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/92d830f4bff643953a09563abaa106af42625207
Modified Files
--
doc/src/sgml/release-10.sgml | 108 ++
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclo
Always require SELECT permission for ON CONFLICT DO UPDATE.
The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT
permission on the columns of the arbiter index, but it failed to check
for that in the case of an arbiter specified by constraint name.
In addition, for a table with
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclo
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fb3930ab1fdb53ad842307a47ddaa1fed4e85d5c
Modified Files
--
doc/src/sgml/release-9.2.sgml | 25
Always require SELECT permission for ON CONFLICT DO UPDATE.
The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT
permission on the columns of the arbiter index, but it failed to check
for that in the case of an arbiter specified by constraint name.
In addition, for a table with
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/e7bae63e02dee20fdcbad2664d4722c80febf8a1
Modified Files
--
doc/src/sgml/release-9.2.sgml | 25
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7b4c179b70a59ad2dbd5c928ce8fc84629da0237
Modified Files
--
doc/src/sgml/release-9.2.sgml | 25
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/50abeafc74a812d2449ec49dc16e99baf8c5023a
Modified Files
--
doc/src/sgml/release-10.sgml | 108 +++
Add tests for json{b}_populate_recordset() crash case.
The problem reported as CVE-2017-15098 was already resolved in HEAD by
commit 37a795a60, but let's add the relevant test cases anyway.
Michael Paquier and Tom Lane, per a report from David Rowley.
Security: CVE-2017-15098
Branch
--
mast
Make json{b}_populate_recordset() use the right tuple descriptor.
json{b}_populate_recordset() used the tuple descriptor created from the
query-level AS clause without worrying about whether it matched the actual
input record type. If it didn't, that would usually result in a crash,
though disclo
Always require SELECT permission for ON CONFLICT DO UPDATE.
The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT
permission on the columns of the arbiter index, but it failed to check
for that in the case of an arbiter specified by constraint name.
In addition, for a table with
start-scripts: switch to $PGUSER before opening $PGLOG.
By default, $PGUSER has permission to unlink $PGLOG. If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages. Since these scripts open
$PGLOG as root, the attack works regard
Always require SELECT permission for ON CONFLICT DO UPDATE.
The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT
permission on the columns of the arbiter index, but it failed to check
for that in the case of an arbiter specified by constraint name.
In addition, for a table with
Last-minute updates for release notes.
Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d69c0710a68068c7a415aaefd2c7d51f3197fe38
Modified Files
--
doc/src/sgml/release-9.2.sgml | 25
49 matches
Mail list logo
