Re: Temporary tables versus wraparound... again

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Temporary tables versus wraparound... again
Дата
Msg-id 20220330003233.oqhww2oxu5pwobyf@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Temporary tables versus wraparound... again  (Greg Stark <stark@mit.edu>)
Ответы Re: Temporary tables versus wraparound... again  (Greg Stark <stark@mit.edu>)
Список 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@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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Temporary tables versus wraparound... again
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: pgsql: Add 'basebackup_to_shell' contrib module.