From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: More aggressive vacuuming of temporary tables |
Date: | 2020-08-29 16:17:54 |
Message-ID: | 3563973.1598717874@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> 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.
Hm. I suppose you'd need a PG_TRY block to ensure that the setting
got restored correctly after an error, so maintaining it that way
would be rather expensive. Also it just doesn't seem like
transaction-wide state, so having a static for it feels like the
wrong thing.
[thinks for awhile...] Would it make any sense to mark Portals as being
top-level or not, and then code that needs this info could look to
"ActivePortal->isTopLevel"? We are already paying the PG_TRY overhead
to maintain the ActivePortal variable safely. I'm not sure though
whether the Portal is granular enough. Do we set up a separate
Portal for subcommands?
In the big scheme of things, though, we don't need this info in so
many places that passing it down as a parameter is an undue burden.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-08-29 16:22:31 | Re: Ideas about a better API for postgres_fdw remote estimates |
Previous Message | Amit Kapila | 2020-08-29 11:47:46 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |