mirror of
https://github.com/postgres/postgres.git
synced 2026-03-13 22:28:01 -04:00
cfffa8a6b2
We implement ON COMMIT DELETE ROWS by truncating tables marked that way, which requires also truncating/rebuilding their indexes. But RelationTruncateIndexes asks the relcache for up-to-date copies of any index expressions, which may cause execution of eval_const_expressions on them, which can result in actual execution of subexpressions. This is a bad thing to have happening during ON COMMIT. Manuel Rigger reported that use of a SQL function resulted in crashes due to expectations that ActiveSnapshot would be set, which it isn't. The most obvious fix perhaps would be to push a snapshot during PreCommit_on_commit_actions, but I think that would just open the door to more problems: CommitTransaction explicitly expects that no user-defined code can be running at this point. Fortunately, since we know that no tuples exist to be indexed, there seems no need to use the real index expressions or predicates during RelationTruncateIndexes. We can set up dummy index expressions instead (we do need something that will expose the right data type, as there are places that build index tupdescs based on this), and just ignore predicates and exclusion constraints. In a green field it'd likely be better to reimplement ON COMMIT DELETE ROWS using the same "init fork" infrastructure used for unlogged relations. That seems impractical without catalog changes though, and even without that it'd be too big a change to back-patch. So for now do it like this. Per private report from Manuel Rigger. This has been broken forever, so back-patch to all supported branches. |
||
|---|---|---|
| .. | ||
| attoptcache.c | ||
| catcache.c | ||
| evtcache.c | ||
| inval.c | ||
| lsyscache.c | ||
| Makefile | ||
| plancache.c | ||
| relcache.c | ||
| relfilenodemap.c | ||
| relmapper.c | ||
| spccache.c | ||
| syscache.c | ||
| ts_cache.c | ||
| typcache.c | ||