Re: Temporary tables versus wraparound... again

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Temporary tables versus wraparound... again
Date: 2022-03-30 00:30:21
Message-ID: CAKFQuwYyTE1U68EuZBoG+zRCrkcSx02zNfnq4KniJStVGHeHSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 29, 2022 at 4:52 PM Greg Stark <stark(at)mit(dot)edu> wrote:

> On Mon, 28 Mar 2022 at 16:30, Andres Freund <andres(at)anarazel(dot)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:

https://www.postgresql.org/docs/current/sql-createtable.html

"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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-30 00:32:33 Re: Temporary tables versus wraparound... again
Previous Message Andres Freund 2022-03-30 00:20:30 Re: Add parameter jit_warn_above_fraction