Improve wording in the planner doc
Change "In this case" to "In the example above" to clarify what it
actually refers to.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/77c616a79dc9e852fa66cc69e6b4997511cc4dfa
Modified Files
--
doc/src/sgml/plans
Improve wording in the planner doc
Change "In this case" to "In the example above" to clarify what it
actually refers to.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/5043e3afcc8701687bf3970bf56a648c8ea033d9
Modified Files
--
doc/src/sgml/plans
Improve wording in the planner doc
Change "In this case" to "In the example above" to clarify what it
actually refers to.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/bdc309c7dc849a7362a624846ebc9170a8c353f3
Modified Files
--
doc/src/sgml/planstats.sg
Improve wording in the planner doc
Change "In this case" to "In the example above" to clarify what it
actually refers to.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/779c46a39f04c7ea2f9aae3b92854b5a885fe07e
Modified Files
--
doc/src/sgml/plans
Improve wording in the planner doc
Change "In this case" to "In the example above" to clarify what it
actually refers to.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/ce18d6bd30de7150e5423f62d62c27b9431f2c05
Modified Files
--
doc/src/sgml/plans
Improve wording in the planner doc
Change "In this case" to "In the example above" to clarify what it
actually refers to.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/38e617df36958660eee37571e3cc1713e3a49a4f
Modified Files
--
doc/src/sgml/plans
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
In runtime.sgml, the old formulas for calculating the reasonable
values of SEMMNI and SEMMNS were incorrect. They have forgotten to
count the number of semaphores which both the checkpointer process
(introduced in 9.2) and
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
In runtime.sgml, the old formulas for calculating the reasonable
values of SEMMNI and SEMMNS were incorrect. They have forgotten to
count the number of semaphores which both the checkpointer process
(introduced in 9.2) and
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
In runtime.sgml, the old formulas for calculating the reasonable
values of SEMMNI and SEMMNS were incorrect. They have forgotten to
count the number of semaphores which both the checkpointer process
(introduced in 9.2) and
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
In runtime.sgml, the old formulas for calculating the reasonable
values of SEMMNI and SEMMNS were incorrect. They have forgotten to
count the number of semaphores which both the checkpointer process
(introduced in 9.2) and
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
In runtime.sgml, the old formulas for calculating the reasonable
values of SEMMNI and SEMMNS were incorrect. They have forgotten to
count the number of semaphores which both the checkpointer process
(introduced in 9.2) and
Move DATA entry to correct position
In commit 7b4bfc87 the DATA and DESCR entries for the new
row_security_active() function were inadvertantly put after
the PROVOLATILE defines, rather than before as they should
have been placed. Move them up where they belong.
Backpatch to 9.5 where the new ent
Move DATA entry to correct position
In commit 7b4bfc87 the DATA and DESCR entries for the new
row_security_active() function were inadvertantly put after
the PROVOLATILE defines, rather than before as they should
have been placed. Move them up where they belong.
Backpatch to 9.5 where the new ent
Allow the WAL writer to flush WAL at a reduced rate.
Commit 4de82f7d7 increased the WAL flush rate, mainly to increase the
likelihood that hint bits can be set quickly. More quickly set hint bits
can reduce contention around the clog et al. But unfortunately the
increased flush rate can have a si
pgbench: avoid FD_ISSET on an invalid file descriptor
The original code wasn't careful to test the file descriptor returned by
PQsocket() for an invalid socket. If an invalid socket did turn up,
that would amount to calling FD_ISSET with fd = -1, whereby undefined
behavior can be invoked.
To fix
pgbench: avoid FD_ISSET on an invalid file descriptor
The original code wasn't careful to test the file descriptor returned by
PQsocket() for an invalid socket. If an invalid socket did turn up,
that would amount to calling FD_ISSET with fd = -1, whereby undefined
behavior can be invoked.
To fix
pgbench: avoid FD_ISSET on an invalid file descriptor
The original code wasn't careful to test the file descriptor returned by
PQsocket() for an invalid socket. If an invalid socket did turn up,
that would amount to calling FD_ISSET with fd = -1, whereby undefined
behavior can be invoked.
To fix
pgbench: avoid FD_ISSET on an invalid file descriptor
The original code wasn't careful to test the file descriptor returned by
PQsocket() for an invalid socket. If an invalid socket did turn up,
that would amount to calling FD_ISSET with fd = -1, whereby undefined
behavior can be invoked.
To fix
pgbench: avoid FD_ISSET on an invalid file descriptor
The original code wasn't careful to test the file descriptor returned by
PQsocket() for an invalid socket. If an invalid socket did turn up,
that would amount to calling FD_ISSET with fd = -1, whereby undefined
behavior can be invoked.
To fix
pgbench: avoid FD_ISSET on an invalid file descriptor
The original code wasn't careful to test the file descriptor returned by
PQsocket() for an invalid socket. If an invalid socket did turn up,
that would amount to calling FD_ISSET with fd = -1, whereby undefined
behavior can be invoked.
To fix
On 2016-02-15 22:12:25 +, Tom Lane wrote:
> Suppress compiler warnings about useless comparison of unsigned to zero.
As Peter just noticed, I sent my email confirming that this fixes the
warning for my compiler, as a repl to the wrong commit message. One down
press too many... But even replyin
On Mon, Feb 15, 2016 at 2:17 PM, Andres Freund wrote:
> On 2016-02-15 22:01:12 +, Andres Freund wrote:
>> Allow SetHintBits() to succeed if the buffer's LSN is new enough.
>
> Thanks, that works with my brand of annoying compiler...
Wrong commit message. :-)
--
Peter Geoghegan
--
Sent v
On 2016-02-15 22:01:12 +, Andres Freund wrote:
> Allow SetHintBits() to succeed if the buffer's LSN is new enough.
Thanks, that works with my brand of annoying compiler...
Andres
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscriptio
Suppress compiler warnings about useless comparison of unsigned to zero.
Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,
and hence complain about the character range checks I added in commit
3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since
the reg
Suppress compiler warnings about useless comparison of unsigned to zero.
Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,
and hence complain about the character range checks I added in commit
3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since
the reg
Suppress compiler warnings about useless comparison of unsigned to zero.
Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,
and hence complain about the character range checks I added in commit
3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since
the reg
Suppress compiler warnings about useless comparison of unsigned to zero.
Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,
and hence complain about the character range checks I added in commit
3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since
the reg
Suppress compiler warnings about useless comparison of unsigned to zero.
Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,
and hence complain about the character range checks I added in commit
3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since
the reg
Suppress compiler warnings about useless comparison of unsigned to zero.
Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,
and hence complain about the character range checks I added in commit
3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since
the reg
Allow SetHintBits() to succeed if the buffer's LSN is new enough.
Previously we only allowed SetHintBits() to succeed if the commit LSN of
the last transaction touching the page has already been flushed to
disk. We can't generally change the LSN of the page, because we don't
necessarily have the r
Correct Copyright year from 2015 to 2016
Looks like this patch went in after Copyright messages
were updated for 2016 and it missed the boat. Fixed.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/cfafd8beadcd6f8c8a570ab2504a75c33c58e504
Modified Files
-
Make concurrent refresh check early that there is a unique index on matview.
In REFRESH MATERIALIZED VIEW command, CONCURRENTLY option is only
allowed if there is at least one unique index with no WHERE clause on
one or more columns of the matview. Previously, concurrent refresh
checked the existe
Fix typo
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/57c932475504d63d8f8a68fc6925d7decabc378a
Modified Files
--
doc/src/sgml/protocol.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-committers mailing list (pgsql-committ
On 2016-02-15 07:38:18 +, Noah Misch wrote:
> Replace broken link in comment.
>
> Modified Files
> --
> src/include/port/atomics/generic-xlc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks. It's pretty sad that IBM, HP, et al, can't keep their URLs
stable.
Andres
34 matches
Mail list logo
