Fix incorrect use of term HEAD for Git
HEAD as used here was CVS terminology. Now we mean master.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/cc4ec2d29ac4f3b8335d1851627a9735b81beb50
Modified Files
--
src/tools/RELEASE_CHANGES | 6 +++---
src/tools/
Hack pg_ctl to report postmaster's exit status.
Temporarily change pg_ctl so that the postmaster's exit status will
be printed (to the postmaster's stdout). This is to help identify
the cause of intermittent "postmaster exited during a parallel
transaction" failures seen on a couple of buildfarm
Remove use of deprecated Autoconf define
Change from HAVE_TM_ZONE to HAVE_STRUCT_TM_TM_ZONE.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4d7e5a5db01edaff749555220aa41eb35be06799
Modified Files
--
src/interfaces/ecpg/pgtypeslib/dt_common.c | 4 ++--
s
Simplify PGAC_STRUCT_TIMEZONE Autoconf macro
Since 63bd0db12199c5df043e1dea0f2b574f622b3a4c we don't use tzname
anymore, so we don't need to check for it. Instead, just keep the
part of PGAC_STRUCT_TIMEZONE that we need, which is the check for
struct tm.tm_zone.
Discussion:
https://www.postgres
Check for too many postmaster children before spawning a bgworker.
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, Ass
Check for too many postmaster children before spawning a bgworker.
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, Ass
Check for too many postmaster children before spawning a bgworker.
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, Ass
Check for too many postmaster children before spawning a bgworker.
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, Ass
Check for too many postmaster children before spawning a bgworker.
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, Ass
Check for too many postmaster children before spawning a bgworker.
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, Ass
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
doc: move mention of log_min_error_statement in a better spot
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through:
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
REL9_4
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
REL_12
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
REL9_6
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
REL_10
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
master
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
REL9_5
docs: clarify that today/tomorrow/yesterday is at 00:00
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion:
https://postgr.es/m/[email protected]
Backpatch-through: 9.4
Branch
--
REL_11
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
docs: Improve A?synchronous Multimaster Replication descr.
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion:
https://postgr.es/m/156856543824.1274
Improve test coverage of pg_rewind
This includes new TAP tests for a couple of areas not covered yet and
some improvements:
- More coverage for --no-ensure-shutdown, the enforced recovery step and
--dry-run.
- Failures with option combinations and basic option checks.
- Removal of a duplicated com
Clarify some comments about ntstatus.h in win32_port.h
Some comments in this file referred to outdated links. This simplifies
the outdated comment blocks and refreshes the links.
Reported-by: Vignesh C
Author: Juan José SantamarÃa Flecha
Discussion: https://postgr.es/m/46c03e17-16f7-4c38-b148-02
Update some outdated links about XLC and UNIX specification
Author: Vignesh C
Discussion:
https://postgr.es/m/CALDaNm3Dy=dTdx8UCVw=DWbzLzmRUC1dkq45=heozdug3u_...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a7471bd85c05f849e88d6cfe9da3c795008e8f2e
34 matches
Mail list logo
