From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: More aggressive vacuuming of temporary tables |
Date: | 2020-08-29 01:43:18 |
Message-ID: | 20200829014318.GB1529@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 28, 2020 at 11:46:49AM -0400, Tom Lane wrote:
> Hence I propose 0001 attached. 80% of it is just API additions to allow
> passing down the isTopLevel flag so that we can do the right thing in
> the CLUSTER case; the important change is in vacuum_set_xid_limits.
> (For ease of review, I didn't reindent the existing code in
> vacuum_set_xid_limits, but that would be something to do before commit.)
I got to wonder lately if we should not have a static state like what
we do for MyXactFlags to track down if a utility query is a top-level
one or not as most of the time we just want to check the flag as
passed down by standard_ProcessUtility(). I have faced this problem
as well lately when pushing down a PreventInTransactionBlock() for
some stuff with REINDEX for example. Not sure how reliable this would
be though.. Passing isTopLevel down the road is a no-brainer, and
perhaps having a static value would create more problems than it
solves in practice.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Lepikhov | 2020-08-29 05:38:56 | Re: Ideas about a better API for postgres_fdw remote estimates |
Previous Message | Jeff Davis | 2020-08-29 01:32:38 | Re: Disk-based hash aggregate's cost model |