From: | James Sewell <james(dot)sewell(at)jirotech(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reaping Temp tables to avoid XID wraparound |
Date: | 2019-02-18 00:19:01 |
Message-ID: | CAANVwEv7FXabuUnsd7Tmf7GGXVT+qKA=ZvdDvjx+vA6wM1_Bdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Yeah, possibly. I think that it could be tricky though to get that at
>> a global level in a cheap way. It makes also little sense to only
>> show the temp namespace OID if that information is not enough.
>>
>
> 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.
>
> Just having the namespace oid is at least enough to know that there is
> potentially something to go look at it. But it doesn't make for automated
> monitoring very well, at least not in systems that have a larger number of
> databases.
>
You can get the namespace oid today with a JOIN, the issue is that this
isn't enough information to go an look at - at the end of the day it's
useless unless you can remove the temp table or terminate the session which
owns it.
--
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have received this
communication in error, you may not copy or distribute any part of it or
otherwise disclose its contents to anyone. Please advise the sender of your
incorrect receipt of this correspondence.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-18 00:20:25 | Re: Optimze usage of immutable functions as relation |
Previous Message | Tom Lane | 2019-02-18 00:06:09 | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd) |