Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/dacbdda1092e20507249bade076c859993f5e837
Modified Files
--
doc/src/sgml/func.sgml | 29 +
Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/1b5d34ca6244a9296215325a9f82fb805e739f9e
Modified Files
--
doc/src/sgml/func.sgml | 29
Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/f9ab07be9fbaa95735ae4c3a6592ad058e2c1819
Modified Files
--
doc/src/sgml/func.sgml | 29 +
Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/ea1703eb490b34ec689c7b1d32c06634871ada36
Modified Files
--
doc/src/sgml/func.sgml | 29 +
Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/4eb4e71119780a15168d03c933f41bc04b1ecd4e
Modified Files
--
doc/src/sgml/func.sgml | 29 +
Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/5c499d5cd2da2fd67f1b234a2994dd940f28fbc2
Modified Files
--
doc/src/sgml/func.sgml | 29 +
Docs: add an explicit example about controlling overall greediness of REs.
Per discussion of bug #13538.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/aa9f8cb131a91df16db69fd271f81e761db29625
Modified Files
--
doc/src/sgml/func.sgml | 29 +
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Tag refs/tags/REL9_5_ALPHA2 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Fix pg_dump to dump shell types.
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
Fix bogus "out of memory" reports in tuplestore.c.
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied t
On 08/03/2015 09:05 PM, Michael Paquier wrote:
On Mon, Aug 3, 2015 at 10:37 PM, Heikki Linnakangas wrote:
That's only on master, though. The TAP tests don't run on Windows in 9.5
anyway.
Oops, yes I got mistaken by the commit on 9.5.
I guess the pg_rewind tests used to work, but we didn't re
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Cap wal_buffers to avoid a server crash when it's set very large.
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just
Tab completion for CREATE SEQUENCE.
Vik Fearing, reviewed by Brendan Jurd, Michael Paquier, and myself
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/158e3bc8e2507244b0d1e87ee334f39b7400098a
Modified Files
--
src/bin/psql/tab-complete.c | 29 +
Update comment to match behavior of latest code.
Peter Geoghegan
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/a6a235782083a98588e41a1298c8fcd89cfaa6b3
Modified Files
--
src/backend/utils/sort/tuplesort.c |6 +++---
1 file changed, 3 insertions(+),
Update comment to match behavior of latest code.
Peter Geoghegan
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/9d7d0e640c21bfa36e1eeb7e7c9fcdbb2cfb9763
Modified Files
--
src/backend/utils/sort/tuplesort.c |6 +++---
1 file changed, 3 insertio
Share transition state between different aggregates when possible.
If there are two different aggregates in the query with same inputs, and
the aggregates have the same initial condition and transition function,
only calculate the state value once, and only call the final functions
separately. For
39 matches
Mail list logo
