Re: Reaping Temp tables to avoid XID wraparound

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, James Sewell <james(dot)sewell(at)jirotech(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reaping Temp tables to avoid XID wraparound
Date: 2019-02-19 08:56:28
Message-ID: CABUevExUHxAULzq2G47nw8LMJeH2mnh=ApaVdo+32o4i5AOfPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 18, 2019 at 2:31 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Sun, Feb 17, 2019 at 05:47:09PM +0100, Magnus Hagander wrote:
> > We could I guess add a field specifically for temp_namespace_xid or such.
> > The question is if it's worth the overhead to do that.
>
> That would mean an extra 4 bytes in PGPROC, which is something we
> could live with, still the use-case looks rather narrow to me to
> justify that.
>

It does, tha'ts why I questioned if it's worth it. But, thinking some more
about it, some other options would be:

1. This is only set once per backend in normal operations, right? (Unless I
go drop the schema manually, but that's not exactly normal). So maybe we
could invent a pg stat message and send the information through the
collector? Since it doesn't have to be frequently updated, like your
typical backend_xmin.

2. Or probably even better, just put it in PgBackendStatus? Overhead here
is a lot cheaper than PGPROC.

ISTM 2 is probably the most reasonable option here?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2019-02-19 09:26:04 Re: Prepared transaction releasing locks before deregistering its GID
Previous Message Simon Riggs 2019-02-19 08:50:31 Re: Speed up transaction completion faster after many relations are accessed in a transaction