Fix transition tables for ON CONFLICT.
We now disallow having triggers with both transition tables and ON
INSERT OR UPDATE (which was a PG extension to the spec anyway),
because in this case it's not at all clear how the transition tables
should work for an INSERT ... ON CONFLICT query. Separate
Fix transition tables for wCTEs.
The original coding didn't handle this case properly; each separate
DML substatement needs its own set of transitions.
Patch by Thomas Munro
Discussion:
https://postgr.es/m/CAL9smLCDQ%3D2o024rBgtD4WihzX8B3C6u_oSQ2K3%2BR5grJrV0bg%40mail.gmail.com
Branch
--
m
Fix transition tables for partition/inheritance.
We disallow row-level triggers with transition tables on child tables.
Transition tables for triggers on the parent table contain only those
columns present in the parent. (We can't mix tuple formats in a
single transition table.)
Patch by Thomas
Fix COPY's handling of transition tables with indexes.
Commit c46c0e5202e8cfe750c6629db7852fdb15d528f3 failed to pass the
TransitionCaptureState object to ExecARInsertTriggers() in the case
where it's using heap_multi_insert and there are indexes. Repair.
Thomas Munro, from a report by David Fet
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
Avoid having vacuum set reltuples to 0 on non-empty relations in the
presence of page pins, which leads to serious estimation errors in the
planner. This particularly affects small heavily-accessed tables,
especially where locking (e.g. from FK constraints) forces frequent
vacuums for mxid cleanup
> "Tom" == Tom Lane writes:
Tom> Hm, buildfarm results suggest this test is not entirely stable:
I see it and will work on it.
Tom> I have not looked very closely, but I'm suspicious that the test
Tom> case depends on no autovacuum transactions running concurrently
Tom> with it. Disabl
>>>>> "Andrew" == Andrew Gierth writes:
Tom> I have not looked very closely, but I'm suspicious that the test
Tom> case depends on no autovacuum transactions running concurrently
Tom> with it. Disabling autovac on the table itself is not enough to
To
Repair test for vacuum reltuples fix.
Concurrent auto-analyze could be holding a snapshot, affecting the
removal of deleted row versions. Remove the deletion to avoid this
happening. Per buildfarm.
In passing, make the test independent of assumptions of physical row
order, just out of sheer par
Repair test for vacuum reltuples fix.
Concurrent auto-analyze could be holding a snapshot, affecting the
removal of deleted row versions. Remove the deletion to avoid this
happening. Per buildfarm.
In passing, make the test independent of assumptions of physical row
order, just out of sheer par
was not used (which affected a few regression tests). The
enable_hashagg option is respected.
Author: Andrew Gierth
Reviewers: Mark Dilger, Andres Freund
Discussion: https://postgr.es/m/87vatszyhj@news-spur.riddles.org.uk
Branch
--
master
Details
---
http://git.postgresql.org/pg
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> Support hashed aggregation with grouping sets.
Looks like some regression test plans aren't as stable as I hoped. On it.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-committers mailing list (pgsql-committer
Attempt to stabilize grouping sets regression test plans.
Per buildfarm members dromedary and arapaima.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/de4da168d57de812bb30d359394b7913635d21a9
Modified Files
--
src/test/regress/expected/groupingsets.out
> "Alvaro" == Alvaro Herrera writes:
Alvaro> Fix a couple of problems in pg_get_statisticsextdef
Alvaro> src/test/regress/expected/stats_ext.out | 7 +++
Missed an update to stats_ext_1.out ?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-committers mailing list (pgsql-committers@
Try and silence spurious Coverity warning.
gset_data (aka gd) in planner.c is always non-null if and only if
parse->groupingSets is non-null, but Coverity doesn't know that and
complains. Feed it an assertion to see if that keeps it happy.
Branch
--
master
Details
---
http://git.postgre
Repair crash with unsortable data in grouping sets.
Previously the code would generate incorrect results, assertion
failures, or crashes if given unsortable (but hashable) columns in
grouping sets. Handle by throwing an error instead.
Report and patch by Pavan Deolasee (though I changed the erro
20 matches
Mail list logo
