Fix bug in collecting total_latencies from all threads in pgbench.
This was broken in 1bc90f7a, which removed the thread-emulation. With modest
-j and -c settings the result were usually close enough that you wouldn't
notice it easily, but with a high enough thread count it would access
uninitiali
Improve logging of TAP tests.
Create a log file for each test run. Stdout and stderr of the test script,
as well as any subprocesses run as part of the test, are redirected to
the log file. This makes it a lot easier to debug test failures. Also print
the test output (ok 12 - ... messages) to the
Remove an unsafe Assert, and explain join_clause_is_movable_into() better.
join_clause_is_movable_into() is approximate, in the sense that it might
sometimes return "false" when actually it would be valid to push the given
join clause down to the specified level. This is okay ... but there was
an
Remove an unsafe Assert, and explain join_clause_is_movable_into() better.
join_clause_is_movable_into() is approximate, in the sense that it might
sometimes return "false" when actually it would be valid to push the given
join clause down to the specified level. This is okay ... but there was
an
Remove an unsafe Assert, and explain join_clause_is_movable_into() better.
join_clause_is_movable_into() is approximate, in the sense that it might
sometimes return "false" when actually it would be valid to push the given
join clause down to the specified level. This is okay ... but there was
an
Remove an unsafe Assert, and explain join_clause_is_movable_into() better.
join_clause_is_movable_into() is approximate, in the sense that it might
sometimes return "false" when actually it would be valid to push the given
join clause down to the specified level. This is okay ... but there was
an
Remove an unsafe Assert, and explain join_clause_is_movable_into() better.
join_clause_is_movable_into() is approximate, in the sense that it might
sometimes return "false" when actually it would be valid to push the given
join clause down to the specified level. This is okay ... but there was
an
Improve logging of TAP tests.
Create a log file for each test run. Stdout and stderr of the test script,
as well as any subprocesses run as part of the test, are redirected to
the log file. This makes it a lot easier to debug test failures. Also print
the test output (ok 12 - ... messages) to the
Centralize decision-making about where to get a backend's PGPROC.
This code was originally written as part of parallel query effort, but
it seems to have independent value, because if we make one decision
about where to get a PGPROC when we allocate and then put it back on a
different list at back
Make tap tests store postmaster logs and handle vpaths correctly
Given this it is possible that the buildfarm animals running these tests
will be able to capture adequate logging to allow diagnosis of failures.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/01f6bb4b
Make tap tests store postmaster logs and handle vpaths correctly
Given this it is possible that the buildfarm animals running these tests
will be able to capture adequate logging to allow diagnosis of failures.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/d
Make tap tests store postmaster logs and handle vpaths correctly
Given this it is possible that the buildfarm animals running these tests
will be able to capture adequate logging to allow diagnosis of failures.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/4
Disable ssl renegotiation by default.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Disable ssl renegotiation by default.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Disable ssl renegotiation by default.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Remove ssl renegotiation support.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Ad
Disable ssl renegotiation by default.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Remove ssl renegotiation support.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Ad
Disable ssl renegotiation by default.
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Plug RLS related information leak in pg_stats view.
The pg_stats view is supposed to be restricted to only show rows
about tables the user can read. However, it sometimes can leak
information which could not otherwise be seen when row level security
is enabled. Fix that by not showing pg_stats row
Plug RLS related information leak in pg_stats view.
The pg_stats view is supposed to be restricted to only show rows
about tables the user can read. However, it sometimes can leak
information which could not otherwise be seen when row level security
is enabled. Fix that by not showing pg_stats row
Joe Conway writes:
> Plug RLS related information leak in pg_stats view.
BTW, a note about this: I see you bumped catversion in both branches,
which is good, but you bumped it to the same thing, which I think is
bad. Two branches with different initial catalog contents should
not have identical
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/28/2015 01:56 PM, Tom Lane wrote:
> Joe Conway writes:
>> Plug RLS related information leak in pg_stats view.
>
> BTW, a note about this: I see you bumped catversion in both
> branches, which is good, but you bumped it to the same thing, which
Bump catversion so that HEAD is beyond 9.5
As pointed out by Tom, since HEAD has progressed beyond 9.5 in terms of
its catalog, we need to be sure catversion of HEAD is advanced beyond
that of 9.5. Corrects my mistake in the pg_stats view commit cfa928ff.
Branch
--
master
Details
---
htt
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Reduce chatter from signaling of autovacuum workers.
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case
Only adjust negative indexes in json_get up to the length of the path.
The previous code resulted in memory access beyond the path bounds. The
cure is to move it into a code branch that checks the value of lex_level
is within the correct bounds.
Bug reported and diagnosed by Piotr Stefaniak.
Bra
Only adjust negative indexes in json_get up to the length of the path.
The previous code resulted in memory access beyond the path bounds. The
cure is to move it into a code branch that checks the value of lex_level
is within the correct bounds.
Bug reported and diagnosed by Piotr Stefaniak.
Bra
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Update our documentation concerning where to create data directories.
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to
Create a pg_shdepend entry for each role in TO clause of policies.
CreatePolicy() and AlterPolicy() omit to create a pg_shdepend entry for
each role in the TO clause. Fix this by creating a new shared dependency
type called SHARED_DEPENDENCY_POLICY and assigning it to each role.
Reported by Noah
Create a pg_shdepend entry for each role in TO clause of policies.
CreatePolicy() and AlterPolicy() omit to create a pg_shdepend entry for
each role in the TO clause. Fix this by creating a new shared dependency
type called SHARED_DEPENDENCY_POLICY and assigning it to each role.
Reported by Noah
Disallow converting a table to a view if row security is present.
When DefineQueryRewrite() is about to convert a table to a view, it checks
the table for features unavailable to views. For example, it rejects tables
having triggers. It omits to reject tables having relrowsecurity or a
pg_policy
Disallow converting a table to a view if row security is present.
When DefineQueryRewrite() is about to convert a table to a view, it checks
the table for features unavailable to views. For example, it rejects tables
having triggers. It omits to reject tables having relrowsecurity or a
pg_policy
Suppress "variable may be used uninitialized" warning.
Also re-pgindent, just because I'm a neatnik.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/cab23771eb0250fe8e2ad179cf10ef965658f3e7
Modified Files
--
src/backend/commands/policy.c |8 ++
Suppress "variable may be used uninitialized" warning.
Also re-pgindent, just because I'm a neatnik.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/2c698f438acc0b4ebc73b27da734e488a5a967cc
Modified Files
--
src/backend/commands/policy.c |8
Prevent platform-dependent output row ordering in a new test query.
Buildfarm indicates this is necessary.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5d0e8bc9e036bffb88b7598aa4d46b7368a10f0c
Modified Files
--
src/test/regress/expected/rowsecurity.ou
Prevent platform-dependent output row ordering in a new test query.
Buildfarm indicates this is necessary.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/d7f0bb8cc7f4b43830499e89384befc3690b1560
Modified Files
--
src/test/regress/expected/rowsecu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/28/2015 04:56 PM, Tom Lane wrote:
> Suppress "variable may be used uninitialized" warning.
That's odd -- I compiled both with and without debug options looking
for warnings and saw none.
- --
Joe Conway
-BEGIN PGP SIGNATURE-
Version:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/28/2015 05:00 PM, Tom Lane wrote:
> Prevent platform-dependent output row ordering in a new test
> query.
>
> Buildfarm indicates this is necessary.
Yet another important safety tip -- thanks for fixing!
- --
Joe Conway
-BEGIN PGP SIGNATU
pg_basebackup: Add --slot option
This option specifies a replication slot for WAL streaming (-X stream),
so that there can be continuous replication slot use between WAL
streaming during the base backup and the start of regular streaming
replication.
Reviewed-by: Michael Paquier
Branch
--
m
pg_basebackup: Add tests for -X option
Reviewed-by: Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/90102bb538831fca734cc9fa1450b97c7d4e1190
Modified Files
--
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 13 -
src/test/per
pg_basebackup: Add tests for -R option
Reviewed-by: Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/36dc30aa7e0ab9628a5a975a921b8ff82e8f31bf
Modified Files
--
src/bin/pg_basebackup/t/010_pg_basebackup.pl |9 -
src/test/perl/Te
Joe Conway writes:
>> Suppress "variable may be used uninitialized" warning.
> That's odd -- I compiled both with and without debug options looking
> for warnings and saw none.
That warning is very compiler-dependent; smarter compilers can prove
that an uninitialized usage is unreachable while d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/28/2015 05:54 PM, Tom Lane wrote:
> Joe Conway writes:
>>> Suppress "variable may be used uninitialized" warning.
>
>> That's odd -- I compiled both with and without debug options
>> looking for warnings and saw none.
>
> That warning is very
On Wed, Jul 29, 2015 at 9:34 AM, Peter Eisentraut wrote:
> pg_basebackup: Add tests for -X option
One thing that I noticed after more tests is that actually the LSN
position restart_lsn is not necessarily 8-character long as this
tests, but it can be 7-character length as well:
like($lsn, qr!^0/[
56 matches
Mail list logo
