INSERT ... ON CONFLICT statements record few metrics in the ModifyTable
node's instrument but they get overwritten by hypertable_modify_explain
causing wrong output in EXPLAIN ANALYZE statments. Fix it by saving the
metrics into HypertableModify node before replacing them.
Fixes#6014
To increase schema security we do not want to mix our own internal
objects with user objects. Since chunks are created in the
_timescaledb_internal schema our internal functions should live in
a different dedicated schema. This patch make the necessary
adjustments for the following functions:
- get_partition_for_key(val anyelement)
- get_partition_hash(val anyelement)
When doing upsert with prepared statement the code to restore
arbiter_indexes would not trigger when an error occurred on the
INSERT leading to a segfault on the next EXECUTE of the prepared
statement.
A prepared statement or function plan can be turned into a generic plan
after a couple executions. When this happens the last plan that run
through plan creation gets reused so we need to revert any modifications
we did to that plan so reusing it is safe.
Previously, hypertable insert tlists were only fixed
for the top-level plan. We also need to fix the tlist
for hypertable inserts that appear inside ctes
When doing an upsert, we expect to be able to translate a
hypertable index used as an arbiter to a chunk index. But,
it is possible that the corresponding chunk index has been dropped.
Previously this resulted in a postgres generated error like
"unexpected failure to find arbiter index". We now handle
this more gracefully.
Previously, the slots for upserts were only updated when
a ChunkInsertState was created, but not when it was found in the
ChunkDispatch cache. This was wrong -- we need to update the slots
every time we switch to the chunk.
Right now the switch function is called on every tuple. We will
optimize that later to only be called when the previous chunk was
different. But, that is not part of this bug-fix PR.
Previously we set the mt_existing and onConflictProjInfo slot
descriptors only when the current chunk had a tup_conv_map this
was based on a false assumption that these slot descriptors had the
hypertable's slot descriptor. In fact, since we are reusing these slots
across chunks, the slot descriptor will correspond to the previous
chunk's one. This led to an error if the previous chunk had a
tup_conv_map but the current one did not.
Most of the work done here was by @gayyappan with minor improvements by
@cevian. The latter is submitting because of a time-crunch having to do
with upcoming release.
Previously, there was a bug when chunks contained dropped columns
in the mapping of variable numbers. This PR fixes the bug and adds a
test for this case.
Previously, upserts (ON CONFLICT) clauses did not work well on tables
where the hypertable attribute numbers did not match chunk attribute
numbers. This is common if the hypertable has dropped columns or
there were other alter commands run on the hypertable before
chunks were created.
This PR fixes the projection of the returning clause as well
as the update clauses. It also fixes the where clause for ON CONFLICT
UPDATE. These fixes are mostly about mapping the attribute numbers
from the hypertable attnos->chunk attnos. Some slot tupleDesc also
needed to be changed to the tupleDesc of the chunk.
Note that because of the limitations in PG 9.6 we had to copy over
some expressions from the ModifyTable plan node inside the chunk
dispatch. These original expressions are irrecoverable from the
ModifyTableState node or the ProjectionInfo structs in 9.6.
Previously, the chunk dispatch node used arbiter index and other
information from the top-level Query node. This did not work with CTEs
(and probably subqueries) because the info for this insert was not at
the top-level. This commit changes the logic to use that same info from the
parent ModifyTable node (and ModifyTableState).
This commit also changes the logic to translate the arbiter indexes
from the hypertable index to the chunk index directly using our catalog
tables instead of re-inferring the index on the chunk.
This commit moves a lot of test setup logic to runner.sh. Also
passes the right commands to the regression infrastructure to create
appropriate users and run tests as a regular user.
Previously, when issued on hypertable, database maintenance
commands, like VACUUM and REINDEX, only affected the main
table and did not recurse to chunks.
This change fixes that issue, allowing database maintainers
to issue single commands on hypertables that affect all
the data stored in the hypertable.
These commands (VACUUM, REINDEX) only work at the table level
for hypertables. If issued at other levels, e.g., schema, or
database, the behavior is the same as in standard PostgreSQL
as all tables are covered by default.
REINDEX commands that specify a hypertable index do not
recurse as that requires mapping the hypertable
index to the corresponding index on the chunk. This might
be fixed in a future update.
Upserts are now supported as long as there is a unique index that
includes all hypertable dimensions. Upserts using ON CONFLICT ON
CONSTRAINT statements are currently unsupported, although this should
be possible in the future.
