On 2016-12-05 20:51:02 +, Stephen Frost wrote:
> Add support for restrictive RLS policies
> Modified Files
> --
> src/backend/nodes/copyfuncs.c | 1 +
> src/backend/nodes/equalfuncs.c| 1 +
> src/backend/parser/gram.y | 43 +++--
> src/incl
Remove extraneous semicolon from uses of relptr_declare().
If we're going to write a semicolon after calls of relptr_declare(),
then we don't need one inside the macro, and removing it suppresses
"empty declaration" warnings from pickier compilers (eg pademelon).
While at it, we might as well use
Fix typo in new message in configure.
Remove spurious "of", and reformat to fit on a 80 chars wide line.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/44a977f55f33834a2fe0d1d9bd5eeb29ce67e914
Modified Files
--
configure| 4 ++--
configure.in | 4 ++-
Ensure gatherstate->nextreader is properly initialized.
The previously code worked OK as long as a Gather node was never
rescanned, or if it was rescanned, as long as it got at least as
many workers on rescan as it had originally. But if the number
of workers ever decreased on a rescan, then it c
Ensure gatherstate->nextreader is properly initialized.
The previously code worked OK as long as a Gather node was never
rescanned, or if it was rescanned, as long as it got at least as
many workers on rescan as it had originally. But if the number
of workers ever decreased on a rescan, then it c
Add support for restrictive RLS policies
We have had support for restrictive RLS policies since 9.5, but they
were only available through extensions which use the appropriate hooks.
This adds support into the grammer, catalog, psql and pg_dump for
restrictive RLS policies, thus reducing the cases
dsa: Cope with the possibility that SIZE_MAX is not defined.
Per buildfarm member gaur and Tom Lane.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/2bbdc6875d03bb826a4fd113eac45a72c68bc929
Modified Files
--
src/backend/utils/mmgr/dsa.c | 2 +-
1 file cha
libpq: Fix another bug in 721f7bd3cbccaf8c07cad2707826b83f84694832.
If we failed to connect to one or more hosts, and then afterwards we
find one that fails to be read-write, the latter error message was
clobbering any earlier ones. Repair.
Mithun Cy, slightly revised by me.
Branch
--
maste
Fix race introduced by 6d46f4783efe457f74816a75173eb23ed8930020.
It's possible for the metapage contents to change after we release
the lock, so we must read them before releasing the lock.
Amit Kapila. Submitted in response to a trouble report from
Andreas Seltenreich, though it is not certain
Assorted documentation improvements for max_parallel_workers.
Commit b460f5d6693103076dc554aa7cbb96e1e53074f9 overlooked a few bits
of documentation that seem like they should mention the new setting.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/0e50af245397c9bf3e
Reduce the default for max_worker_processes back to 8.
Commit b460f5d6693103076dc554aa7cbb96e1e53074f9 -- at my suggestion --
increased the default value of max_worker_processes from 8 to 16, on
the theory that this would be harmless and convenient for users.
Unfortunately, this caused some buildf
Fix more DSA problems uncovered by the buildfarm.
On 32-bit systems, don't try to use 64-bit DSA pointers, because the
computation of DSA_MAX_SEGMENT_SIZE overflows Size.
Cast 1 to Size before shifting it, so that the compiler doesn't
produce a result of the wrong width.
In passing, change one u
Try to fix some DSA-related compiler warnings.
Commit 13df76a537cca3b8884911d8fdf7c89a457a8dd3 was overconfident
about how portable %016lx is. Some compilers complain because they
need %016llx, while platforms where DSA pointers are only 32 bits
get unhappy about using a 64-bit format for a 32-bi
Fix creation of stand-alone INSTALL.html file.
I missed the notice at the top of the file, that plain xref must not be
used in installation.sgml.
Per buildfarm member guaibasaurus.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7dd8eb39bd2b9e06eeef038f80ae327efb4a7
Fix typo in docs.
Reported-by: Darko Prelec
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/daac8e30eb7874722f277ae3461abe46a39e56ed
Modified Files
--
doc/src/sgml/parallel.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-co
Fix typo in docs.
Reported-by: Darko Prelec
Branch
--
REL9_6_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/efeb3135061dd45d3882eadd878ac09943d0362a
Modified Files
--
doc/src/sgml/parallel.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via p
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers i
Fix incorrect output from gin_desc().
Previously gin_desc() displayed incorrect output "unknown action 0"
for XLOG_GIN_INSERT and XLOG_GIN_VACUUM_DATA_LEAF_PAGE records with
valid actions. The cause of this problem was that gin_desc() wrongly
used XLogRecGetData() to extract data from those record
Fix incorrect output from gin_desc().
Previously gin_desc() displayed incorrect output "unknown action 0"
for XLOG_GIN_INSERT and XLOG_GIN_VACUUM_DATA_LEAF_PAGE records with
valid actions. The cause of this problem was that gin_desc() wrongly
used XLogRecGetData() to extract data from those record
Fix incorrect output from gin_desc().
Previously gin_desc() displayed incorrect output "unknown action 0"
for XLOG_GIN_INSERT and XLOG_GIN_VACUUM_DATA_LEAF_PAGE records with
valid actions. The cause of this problem was that gin_desc() wrongly
used XLogRecGetData() to extract data from those record
20 matches
Mail list logo
