public inbox for [email protected]
help / color / mirror / Atom feedRE: Ability to reference other extensions by schema in extension scripts
3+ messages / 3 participants
[nested] [flat]
* RE: Ability to reference other extensions by schema in extension scripts
@ 2023-03-21 14:29 Regina Obe <[email protected]>
2023-03-21 14:52 ` Re: Ability to reference other extensions by schema in extension scripts Tom Lane <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Regina Obe @ 2023-03-21 14:29 UTC (permalink / raw)
To: 'Tom Lane' <[email protected]>; 'Sandro Santilli' <[email protected]>; +Cc: 'Gregory Stark (as CFM)' <[email protected]>; [email protected]; 'Regina Obe' <[email protected]>
> Pushed with some mostly-cosmetic adjustments (in particular I tried to
make
> the docs and tests neater).
>
> I did not commit the changes in get_available_versions_for_extension
> to add no_relocate as an output column. Those were dead code because you
> hadn't done anything to connect them up to an actual output parameter of
> pg_available_extension_versions(). While I'm not necessarily averse to
> making the no_relocate values visible somehow, I'm not convinced that
> pg_available_extension_versions should be the place to do it. ISTM what's
> relevant is the no_relocate values of *installed* extensions, not those of
> potentially-installable extensions. If we had a view over pg_extension
then
> that might be a place to add this, but we don't. On the whole it didn't
seem
> important enough to pursue, so I just left it out.
>
> regards, tom lane
Thanks. Agree with get_available_versions_for_extension, not necessary.
Thanks,
Regina
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Ability to reference other extensions by schema in extension scripts
2023-03-21 14:29 RE: Ability to reference other extensions by schema in extension scripts Regina Obe <[email protected]>
@ 2023-03-21 14:52 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2023-03-21 14:52 UTC (permalink / raw)
To: Regina Obe <[email protected]>; +Cc: 'Sandro Santilli' <[email protected]>; 'Gregory Stark (as CFM)' <[email protected]>; [email protected]
"Regina Obe" <[email protected]> writes:
>> making the no_relocate values visible somehow, I'm not convinced that
>> pg_available_extension_versions should be the place to do it. ISTM what's
>> relevant is the no_relocate values of *installed* extensions, not those of
>> potentially-installable extensions. If we had a view over pg_extension then
>> that might be a place to add this, but we don't. On the whole it didn't seem
>> important enough to pursue, so I just left it out.
> Thanks. Agree with get_available_versions_for_extension, not necessary.
If we did feel like doing something about this, on reflection I think
the thing to do would be to add no_relocate as an actual column in
pg_extension, probably of type "oid[]". Then we could modify the
SET SCHEMA code to check that instead of parsing the extension control
files. That'd be a little cleaner, but I can't say that I'm hugely
excited about it.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Introduce XID age based replication slot invalidation
@ 2026-07-09 21:52 Masahiko Sawada <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Masahiko Sawada @ 2026-07-09 21:52 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Srinath Reddy Sadipiralla <[email protected]>; SATYANARAYANA NARLAPURAM <[email protected]>; Hayato Kuroda (Fujitsu) <[email protected]>; John H <[email protected]>; pgsql-hackers
On Mon, Jul 6, 2026 at 11:34 PM Bharath Rupireddy
<[email protected]> wrote:
>
> Hi,
>
> On Thu, Jul 2, 2026 at 4:18 PM Masahiko Sawada <[email protected]> wrote:
> >
> > > Thank you Sawada-san. I've been thinking more about it and I agree we
> > > need to address this. While I still think the scenario is unlikely in
> > > practice (SIGTERM would have to take a long time, the slot's xmin
> > > would have to be very old while the walsender is still running, etc.),
> > > I think it's worth handling.
> > >
> > > I can think of a couple of approaches:
> > >
> > > 1. Use ConditionVariableTimedSleep instead of ConditionVariableSleep
> > > when called from an autovacuum worker. Workers don't block forever,
> > > but they still wait for the timeout duration, still send redundant
> > > SIGTERMs, and a correct timeout value needs to be chosen. When it
> > > expires, the worker either retries (still stuck) or gives up (same as
> > > approach 2).
> > >
> > > 2. Make the vacuum path non-blocking when another process is already
> > > invalidating the same slot. The first process to attempt invalidation
> > > proceeds normally: it sends SIGTERM and waits on
> > > ConditionVariableSleep for the process holding the slot to exit. But
> > > if a subsequent autovacuum worker finds that another process has
> > > already initiated invalidation of this slot, it skips the slot and
> > > proceeds with vacuum instead of waiting on the same
> > > ConditionVariableSleep.
> > >
> > > I think approach 2 is simple. If another process is already
> > > invalidating the slot, there's no reason for the autovacuum worker to
> > > also block. The tradeoff is that this vacuum cycle's OldestXmin won't
> > > move forward and it will need another cycle for this relation. But
> > > that's fine given that the scenario as explained above is unlikely to
> > > happen in practice.
> > >
> > > Please let me know if my thinking sounds reasonable. I'm open to other
> > > ideas too.
> >
> > The third idea I came up with is that (auto)vacuum behaves differently
> > in terms of XID-aged slot invalidation depending on the slot being
> > used or not; (auto)vacuum invalidate the XID-aged slot if no one is
> > holding the slot, and it just wakes up the checkpointer to invalidate
> > the slot if a process is still holding the slot. If the XID-aged slot
> > is not held by any process, (auto)vacuum simply invalidates the slot.
> > I believe that while the former case happens in most cases in
> > practice, delegating the checkpointer to invalidate XID-aged slots
> > might help avoid vacuum from being blocked.
> >
> > What do you think about the above idea?
>
> I see two cases here.
>
> 1/ No one is holding the slot. The connection is gone for whatever
> reason. Here vacuum just acquires and invalidates the slot right away,
> no signal, no waiting, and this already works.
>
> 2/ The slot is held but has aged out, due to a slow connection,
> replica lag, or slow decoding/apply. This is the case that involves
> terminating the holder and waiting, which is where blocking can
> happen.
>
> I partially agree with your suggestion for case 2. My preference is to
> not add any blockers for vacuum. It does opportunistic XID-age
> invalidation, invalidates the slots it can take without waiting, and
> leaves the held ones to the checkpointer, which is the guaranteed
> path. It is also easier to reason about and to explain to users.
>
> The tradeoff is that vacuum won't invalidate a held slot in the same
> pass, so the relation being vacuumed right then doesn't get the
> advanced horizon. Once the checkpointer has invalidated the slot,
> later relations pick it up, which may well be in the same vacuum cycle
> or next. I am fine with that.
>
> Given this, I do not think 0003 is needed anymore. Its whole purpose
> was to stop multiple vacuum processes piling onto the same slot's
> condition variable. If the vacuum never waits there, that contention
> cannot happen. There is only one checkpointer. The unheld case is
> already safe. The check runs under the slot's spinlock, so the first
> process marks the slot invalidated and any others see it is done and
> move on. No signal, no waiting. I will drop 0003.
Agree to drop 0003 patch.
> I would skip having the vacuum explicitly wake the checkpointer when
> it sees a held slot. Imagine one walsender holding the slot's xmin and
> 8 autovacuum workers running. Each worker hits that same held slot and
> would signal the checkpointer, so we would get a signal per worker for
> a single slot, repeated every cycle until the checkpointer acts. If
> the checkpointer is already running, another request gets queued, and
> this can happen repeatedly, creating a flood of checkpoint requests.
I agree that we should avoid requesting checkpoints just to invalidate
XID-aged slots.
> Since 0001 already invalidates aged slots during every checkpoint, the
> slot gets cleaned up on the checkpointer's regular pass anyway. I
> would rather rely on that than send extra signals to perform
> checkpoints.
If we rely on the checkpointer for held slot cases, XID-aged slots
held by someone could be left for up to one day, the maximum value of
checkpoint_timeout, in the worst case. I considered an alternative
idea: (auto)vacuum sets a flag on shmem for XID-based slot
invalidation and has the checkpointer perform the invalidation upon
request, without creating a checkpoint. But that seems beyond the
checkpointer's role. Given that it's not common for XID-aged slots to
be still held by someone, it would be okay to skip the held slots. The
same applies on replicas, where the restartpoint pass is the only
mechanism anway. So I agree to simply skip held slots.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-07-09 21:52 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-03-21 14:29 RE: Ability to reference other extensions by schema in extension scripts Regina Obe <[email protected]>
2023-03-21 14:52 ` Tom Lane <[email protected]>
2026-07-09 21:52 Re: Introduce XID age based replication slot invalidation Masahiko Sawada <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox