From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | 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:32:33 |
Message-ID: | 20220330003233.oqhww2oxu5pwobyf@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-03-29 19:51:26 -0400, Greg Stark 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?
In the commit message.
> > > + pgcform->relminmxid = GetOldestMultiXactId();
> >
> > Ugh. That's pretty expensive for something now done at a much higher rate than
> > before.
>
> This I'm really not sure about. I really don't know much about
> multixacts. I've been reading a bit but I'm not sure what to do yet.
> I'm wondering if there's something cheaper we can use. We don't need
> the oldest mxid that might be visible in a table somewhere, just the
> oldest that has a real live uncommitted transaction in it that could
> yet create new tuples in the truncated table.
> In the case of temporary tables I think we could just set it to the
> next mxid since there are no live transactions capable of inserting
> into the temporary table. But in the case of a table created in this
> transaction then that wouldn't be good enough. I think? I'm not clear
> whether existing mxids get reused for new updates if they happen to
> have the same set of locks in them as some existing mxid.
Yes, that can happen. But of course the current xid is always part of the
multixact, so it can't be a multixact from before the transaction started.
There's already a record of the oldest mxid a backend considers live, computed
on the first use of multixacts in a transaction. See
MultiXactIdSetOldestVisible(). Which I think might serve as a suitable
relminmxid of a temporary table in an already running transaction?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-03-30 00:48:25 | Re: pgsql: Add 'basebackup_to_shell' contrib module. |
Previous Message | David G. Johnston | 2022-03-30 00:30:21 | Re: Temporary tables versus wraparound... again |