On 03.01.2018 23:49, legrand legrand wrote:
> Maybe that a simple check of the asof_timestamp value like:
>
> asof_timestamp >= now() - time_travel_period
> AND
> asof_timestamp >= latest_table_ddl
>
> would permit to raise a warning or an error message saying that query result
> can not be garanteed with this asof_timestamp value.
>
>
> latest_table_ddl being found with
>
> SELECT greatest( max(pg_xact_commit_timestamp( rel.xmin )),
> max(pg_xact_commit_timestamp( att.xmin ))) as latest_table_ddl
> FROM pg_catalog.pg_attribute att
> INNER JOIN pg_catalog.pg_class rel
> ON att.attrelid = rel.oid WHERE rel.relname = '<asof_tablename>' and
> rel.relowner= ...
>
> (tested with add/alter/drop column and drop/create/truncate table)
Well, it can be done.
But performing this query on each access to the table seems to be bad
idea: in case of nested loop join it can cause significant degrade of
performance.
The obvious solution is to calculate this latest_table_ddl timestamp
once and store it it somewhere (in ScanState?)
But I am not sure that this check is actually needed.
If table is changed in some incompatible way, then we will get error in
any case.
If table change is not critical for this query (for example some column
was added or removed which is not used in this query),
then should we really throw error in this case?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company