doc: Fix XSLT speedup with older upstream stylesheet versions
From: Alexander Law
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/0e4cc1fc51c77b3af22d8ff7163565c5ba96f310
Modified Files
--
doc/src/sgml/stylesheet-speedup-xhtml.xsl | 6 --
1 file chan
Remove unnecessary #include.
Accidentally added in 8b65cf4c5edabdcae45ceaef7b9ac236879aae50.
Pointed out by Álvaro Herrera
Branch
--
REL9_6_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/eaae83c123f5e8e103abbbe822fe73b791d9d5c9
Modified Files
--
src/include/stor
Remove unnecessary #include.
Accidentally added in 8b65cf4c5edabdcae45ceaef7b9ac236879aae50.
Pointed out by Álvaro Herrera
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5cd3864075622b203d530f1a710818777859304e
Modified Files
--
src/include/storage/buf
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
Fix improper repetition of previous results from a hashed aggregate.
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the
postgres_fdw: Cosmetic cleanup.
Etsuro Fujita
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/dcb7a54bd1cdbf5cca9549e8485cd34a28c7cf87
Modified Files
--
contrib/postgres_fdw/deparse.c | 4 ++--
contrib/postgres_fdw/postgres_fdw.c | 6 --
2 files c
On 2016-06-03 22:07:21 +, Tom Lane wrote:
> Also add a regression test case exercising the same scenario for
> FunctionScan. That's not broken right now, because the function's
> result will get shoved into a tuplestore between generation and use;
> but it could easily become broken whenever w
doc: more replacement of with something better
Reported-by: Alexander Law
Author: Alexander Law
Backpatch-through: 9.6
Branch
--
REL9_6_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/1414d490f7eee23bf3544953a47340e9b54fcf29
Modified Files
--
doc/src/sgml/conf
doc: more replacement of with something better
Reported-by: Alexander Law
Author: Alexander Law
Backpatch-through: 9.6
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/ca9cb940d23dc8869a635fa27a08e60837b17c07
Modified Files
--
doc/src/sgml/config.sgml
Fix small query-lifespan memory leak in bulk updates.
When there is an identifiable REPLICA IDENTITY index on the target table,
heap_update leaks the id_attrs bitmapset. That's not many bytes, but it
adds up over enough rows, since the code typically runs in a query-lifespan
context. Bug introdu
Fix small query-lifespan memory leak in bulk updates.
When there is an identifiable REPLICA IDENTITY index on the target table,
heap_update leaks the id_attrs bitmapset. That's not many bytes, but it
adds up over enough rows, since the code typically runs in a query-lifespan
context. Bug introdu
Fix small query-lifespan memory leak in bulk updates.
When there is an identifiable REPLICA IDENTITY index on the target table,
heap_update leaks the id_attrs bitmapset. That's not many bytes, but it
adds up over enough rows, since the code typically runs in a query-lifespan
context. Bug introdu
Fix small query-lifespan memory leak in bulk updates.
When there is an identifiable REPLICA IDENTITY index on the target table,
heap_update leaks the id_attrs bitmapset. That's not many bytes, but it
adds up over enough rows, since the code typically runs in a query-lifespan
context. Bug introdu
18 matches
Mail list logo
