Fix example in comment.
Author: Adrien Nayrat
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/16954e22e2a881a4a5ead82f364635bfa63cc9df
Modified Files
--
src/backend/lib/integerset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process'
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process'
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process'
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process'
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process'
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process'
tableam: comment and formatting fixes.
Author: Heikki Linnakangas
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/6421011ea24db3a59dc7a0058a03e91981d53635
Modified Files
--
src/
doc: Fix whitespace
Author: Julien Rouhaud
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/122fa9f942478f8fdcfba961e01d172574369293
Modified Files
--
doc/src/sgml/client-auth.sgml | 6 +++---
doc/src/sgml/config.sgml| 2 +-
doc/src/sg
Fix improper interaction of FULL JOINs with lateral references.
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same const
Fix improper interaction of FULL JOINs with lateral references.
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same const
Fix improper interaction of FULL JOINs with lateral references.
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same const
Fix improper interaction of FULL JOINs with lateral references.
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same const
Fix improper interaction of FULL JOINs with lateral references.
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same const
Fix improper interaction of FULL JOINs with lateral references.
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same const
doc: Update serial explanation
The CREATE SEQUENCE command should include a data type specification,
since PostgreSQL 10.
Reported-by: [email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c66000385fe1dc94a6d5525dcd192f17b551fb9b
Modified Files
--
doc: Update serial explanation
The CREATE SEQUENCE command should include a data type specification,
since PostgreSQL 10.
Reported-by: [email protected]
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/dc92adc4bb8f3026a8eb70b297a8d6dd93e1166c
Modified Files
doc: Update serial explanation
The CREATE SEQUENCE command should include a data type specification,
since PostgreSQL 10.
Reported-by: [email protected]
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f604aa956d4f2540be4c3e7521045c98e6a70baa
Modified Files
Fix EvalPlanQualStart to handle partitioned result rels correctly.
The es_root_result_relations array needs to be shallow-copied in the
same way as the main es_result_relations array, else EPQ rechecks on
partitioned result relations fail, as seen in bug #15677 from
Norbert Benkocs.
Amit Langote,
Fix EvalPlanQualStart to handle partitioned result rels correctly.
The es_root_result_relations array needs to be shallow-copied in the
same way as the main es_result_relations array, else EPQ rechecks on
partitioned result relations fail, as seen in bug #15677 from
Norbert Benkocs.
Amit Langote,
Fix EvalPlanQualStart to handle partitioned result rels correctly.
The es_root_result_relations array needs to be shallow-copied in the
same way as the main es_result_relations array, else EPQ rechecks on
partitioned result relations fail, as seen in bug #15677 from
Norbert Benkocs.
Amit Langote,
doc: Add note about generated columns in foreign tables
Explain that it is not enforced that querying a generated column
returns data that is consistent with the data that was stored. This
is similar to the note about constraints nearby.
Reported-by: Amit Langote
Branch
--
master
Details
Add vacuum_truncate reloption.
vacuum_truncate controls whether vacuum tries to truncate off
any empty pages at the end of the table. Previously vacuum always
tried to do the truncation. However, the truncation could cause
some problems; for example, ACCESS EXCLUSIVE lock needs to
be taken on the
23 matches
Mail list logo
