On Mon, 28 Mar 2022 at 16:30, Andres Freund <andres@anarazel.de> wrote:
>
> > Make ON COMMIT DELETE ROWS reset relfrozenxmin and other table stats
> > like normal truncate. Otherwise even typical short-lived transactions
> > using temporary tables can easily cause them to reach relfrozenxid.
>
> Might be worth mentioning that ON COMMIT DELETE is implemented as truncating
> tables. If we actually implemented it as deleting rows, it'd not at all be
> correct to reset relfrozenxmin.
In the commit message or are you saying this needs documentation or a comment?
Just flying by here but...
The user-facing documentation already covers this:
"All rows in the temporary table will be deleted at the end of each transaction block. Essentially, an automatic TRUNCATE is done at each commit. When used on a partitioned table, this is not cascaded to its partitions."
I'm not sure why we felt the need to add "essentially" here - but maybe it's because we didn't "reset relfronzedenxmin and other table stats like normal truncate."? Or maybe just natural word flow.
Either way, maybe word it like this to avoid the need for essentially altogether:
The temporary table will be automatically truncated at the end of each transaction block. However, unlike the TRUNCATE command, descendent tables will not be cascaded to. (I'm changing partitions to descendant tables to make a point here - the TRUNCATE command only references descendent tables, not mentioning partitioning by name at all. Is this desirable?)
I don't have any substantive insight into the commit message or code comments; but it doesn't seem immediately wrong to assume the reader understands that ON COMMIT DELETE ROWS uses something more akin to TRUNCATE rather than DELETE since that is what the feature is documented to do. The commit message in particular seems like it doesn't need to teach that point; but can do so if it makes understanding the changes easier.
David J.
