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/>
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 |