On 05/03/2025 21:25, Andres Freund wrote:
On 2025-02-28 22:24:56 +0200, Heikki Linnakangas wrote:
The second patch makes it possible to use ModifyWaitEvent() to switch
between WL_POSTMASTER_DEATH and WL_EXIT_ON_PM_DEATH. WaitLatch() used to
modify WaitEventSet->exit_on_postmaster_death directly,
Hi,
On 2025-02-28 22:24:56 +0200, Heikki Linnakangas wrote:
> I noticed that the ShutdownLatchSupport() function is unused. The first
> patch removes it.
Looks like that's the case since
commit 80a8f95b3bca6a80672d1766c928cda34e979112
Author: Andres Freund
Date: 2021-08-13 05:49:26 -0700
On Wed, Jan 29, 2025 at 10:15 AM Andres Freund wrote:
> I was chatting with Heikki about this patch and he mentioned that he recalls a
> patch that did some work to unify the signal replacement, procsignal.h and
> CHECK_FOR_INTERRUPTS(). Thomas, that was probably from you? Do you have a
> pointer,
Hi,
I was chatting with Heikki about this patch and he mentioned that he recalls a
patch that did some work to unify the signal replacement, procsignal.h and
CHECK_FOR_INTERRUPTS(). Thomas, that was probably from you? Do you have a
pointer, if so?
It does seem like we're going to have to do some
Hi,
On 2024-12-02 16:39:28 +0200, Heikki Linnakangas wrote:
> From eff8de11fbfea4e2aadce9c1d71452b0f5a1b80b Mon Sep 17 00:00:00 2001
> From: Heikki Linnakangas
> Date: Mon, 2 Dec 2024 15:51:54 +0200
> Subject: [PATCH v5 1/4] Replace Latches with Interrupts
Your email has only three attachements
On 02/12/2024 09:32, Thomas Munro wrote:
On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas wrote:
Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
envisioned. Makes a lot of sense. If it's a single bit though, that
means that you'll still get woken up by interrupts that you'
On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas wrote:
> Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
> envisioned. Makes a lot of sense. If it's a single bit though, that
> means that you'll still get woken up by interrupts that you're not
> waiting for. Maybe that's fin
On 19/11/2024 23:02, Robert Haas wrote:
On Mon, Nov 18, 2024 at 11:09 PM Thomas Munro wrote:
Names don't match here. I prefer _CONTINUE. As for the general one,
I'm on the fence about INTERRUPT_GENERAL_WAKEUP, since wakeups aren't
necessarily involved, but I don't have a specific better idea
On 19/11/2024 06:09, Thomas Munro wrote:
It looks like maybeSleepingOnInterrupts replaces maybe_sleeping, and
SendInterrupt() would need to read it to suppress needless kill()
calls, but doesn't yet, or am I missing something?
Ah yes, you're right.
Hmm, I think there are two kinds of kill() s
On Mon, Nov 18, 2024 at 11:09 PM Thomas Munro wrote:
> Names don't match here. I prefer _CONTINUE. As for the general one,
> I'm on the fence about INTERRUPT_GENERAL_WAKEUP, since wakeups aren't
> necessarily involved, but I don't have a specific better idea so I'm
> not objecting... Perhaps it
Some feedback on v4-0001-Replace-Latches-with-Interrupts.patch:
+ latch.c -> waiteventset.c
+1
+ /*
+* INTERRUPT_RECOVERY_WAKEUP is used to wake up startup process, to tell
+* it that it should continue WAL replay. It's sent by WAL receiver when
+* more WAL arrives,
Here is also a version of Thomas's "Use Latch for bgworker state change
notification patch", rebased over the "Replace latches with Interrupts"
patch.
I used INTERRUPT_GENERAL_WAKEUP for the notification, as a
straightforward replacement of setting the latch, but I wonder if we
should have a
On Sun, 10 Nov 2024 at 22:30, Heikki Linnakangas wrote:
> I thought of the Wiki so that it could updated more casually by
> extension authors.
Makes sense, I agree it would be nice not to have to rely on
committers to merge these changes. Especially since many extension
authors are not committers
On 05/11/2024 22:21, Jelte Fennema-Nio wrote:
On Mon, 4 Nov 2024 at 20:42, Heikki Linnakangas wrote:
Having spent some time playing with this, I quite like option C: break
compatibility, but provide an out-of-tree header file with
*forward*-compatibility macros. That encourages extension author
On Mon, 4 Nov 2024 at 20:42, Heikki Linnakangas wrote:
> Having spent some time playing with this, I quite like option C: break
> compatibility, but provide an out-of-tree header file with
> *forward*-compatibility macros. That encourages extension authors to
> adapt to new idioms, but avoids havi
On Wed, Oct 30, 2024 at 01:23:54PM -0400, Robert Haas wrote:
> On Wed, Oct 30, 2024 at 12:03 PM Heikki Linnakangas wrote:
>> We can provide backwards compatibility macros and a new facility to
>> allocate custom interrupt bits. But how big of a problem is this anyway?
>> In an in-person chat last
On Wed, Oct 30, 2024 at 12:03 PM Heikki Linnakangas wrote:
> 1. Any extensions using WaitLatch, SetLatch, ResetLatch need to be
> changed to use WaitInterrupt, SetInterrupt/RaiseInterrupt,
> ResetInterrupt instead.
>
> 2. If an extension is defining its own Latch with InitLatch, rather than
> usin
One remaining issue with these patches is backwards-compatibility for
extensions:
1. Any extensions using WaitLatch, SetLatch, ResetLatch need to be
changed to use WaitInterrupt, SetInterrupt/RaiseInterrupt,
ResetInterrupt instead.
2. If an extension is defining its own Latch with InitLatch,
On Sat, Aug 31, 2024 at 10:17 AM Heikki Linnakangas wrote:
> > * This direction seems to fit quite nicely with future ideas about
> > asynchronous network I/O. That may sound unrelated, but imagine that
> > a future version of WaitEventSet is built on Linux io_uring (or
> > Windows iorings, or Wi
On Sun, Aug 25, 2024 at 5:17 AM Heikki Linnakangas wrote:
> On 07/08/2024 17:59, Heikki Linnakangas wrote:
> > I'm also wondering about the relationship between interrupts and
> > latches. Currently, SendInterrupt sets a latch to wake up the target
> > process. I wonder if it should be the other w
On 10/07/2024 09:48, Thomas Munro wrote:
The next problems to remove are, I think, the various SIGUSR2, SIGINT,
SIGTERM signals sent by the postmaster. These should clearly become
SendInterrupt() or ProcSetLatch(). The problem here is that the
postmaster doesn't have the proc numbers yet. One
On Mon, Jul 29, 2024 at 1:24 PM Tom Lane wrote:
> Robert Haas writes:
> > I wonder how this works right now. Is there something that limits the
> > number of authentication requests that can be in flight concurrently,
> > or is it completely uncapped (except by machine resources)?
>
> The former.
Robert Haas writes:
> I wonder how this works right now. Is there something that limits the
> number of authentication requests that can be in flight concurrently,
> or is it completely uncapped (except by machine resources)?
The former. IIRC, the postmaster won't spawn more than 2X max_connecti
On 29/07/2024 19:56, Robert Haas wrote:
On Wed, Jul 24, 2024 at 8:58 AM Heikki Linnakangas wrote:
a) assign every child process a PGPROC entry, and make postmaster
responsible for assigning them like you suggest. We'll need more PGPROC
entries, because currently a process doesn't reserve one un
On Wed, Jul 24, 2024 at 8:58 AM Heikki Linnakangas wrote:
> a) assign every child process a PGPROC entry, and make postmaster
> responsible for assigning them like you suggest. We'll need more PGPROC
> entries, because currently a process doesn't reserve one until
> authentication has happened. Or
On 10/07/2024 09:48, Thomas Munro wrote:
On Mon, Jul 8, 2024 at 9:38 PM Heikki Linnakangas wrote:
The patch actually does both: it still does kill(SIGUSR1) and also sets
the latch.
Yeah, I had some ideas about supporting old extension code that really
wanted a SIGUSR1, but on reflection, the
On Mon, Jul 8, 2024 at 5:38 AM Heikki Linnakangas wrote:
> Another approach would be to move the responsibility of background
> worker state notifications out of postmaster completely. When a new
> background worker is launched, the worker process itself could send the
> notification that it has s
On 08/07/2024 05:56, Thomas Munro wrote:
Here's an updated version of this patch.
The main idea is that SendProcSignal(pid, PROCSIGNAL_XXX, procno)
becomes SendInterrupt(INTERRUPT_XXX, procno), and all the pending
interrupt global variables and pss_procsignalFlags[] go away, along
with the SIGUS
On Fri, Nov 12, 2021 at 9:24 AM Robert Haas wrote:
> On Thu, Nov 11, 2021 at 2:50 PM Andres Freund wrote:
> > They can count, but only when used for network sockets or pipes ("slow
> > devices" or whatever the posix language is). Disk IO doesn't count as that.
> > So
> > I don't think it'd be a
On Thu, Nov 11, 2021 at 2:50 PM Andres Freund wrote:
> They can count, but only when used for network sockets or pipes ("slow
> devices" or whatever the posix language is). Disk IO doesn't count as that. So
> I don't think it'd be a huge issue.
Somehow the idea that the network is a slow device a
Hi,
On 2021-11-11 09:06:01 -0500, Robert Haas wrote:
> On Thu, Nov 11, 2021 at 12:27 AM Thomas Munro wrote:
> > > Depending on how you implement them, one difference could be whether /
> > > when
> > > "slow" system calls (recv, poll, etc) are interrupted.
> >
> > Hopefully by now all such waits
On Thu, Nov 11, 2021 at 12:27 AM Thomas Munro wrote:
> > Depending on how you implement them, one difference could be whether / when
> > "slow" system calls (recv, poll, etc) are interrupted.
>
> Hopefully by now all such waits are implemented with latch.c facilities?
Do read(), write(), etc. cou
On Thu, Oct 21, 2021 at 8:27 AM Andres Freund wrote:
> On 2021-10-21 07:55:54 +1300, Thomas Munro wrote:
> > I wonder if we really need signals to implement interrupts. Given
> > that they are non-preemptive/cooperative (work happens at the next
> > CFI()), why not just use shared memory flags an
Hi,
On 2021-10-21 07:55:54 +1300, Thomas Munro wrote:
> I wonder if we really need signals to implement interrupts. Given
> that they are non-preemptive/cooperative (work happens at the next
> CFI()), why not just use shared memory flags and latches? That skips
> a bunch of code, global variable
Hi,
I wonder if we really need signals to implement interrupts. Given
that they are non-preemptive/cooperative (work happens at the next
CFI()), why not just use shared memory flags and latches? That skips
a bunch of code, global variables and scary warnings about programming
in signal handlers.
35 matches
Mail list logo
