""Magnus Hagander"" <[EMAIL PROTECTED]>
> > Why not just use the pid in teh name, and have one segment
> > per backend?
> >
> > Being used only for signals you mean? That might work.
>
> That was my idea. We'll end up using three global namespace objects
> (mutex+event+shared memory) instead of
> > Why not just use the pid in teh name, and have one segment
> per backend?
>
> Being used only for signals you mean? That might work.
That was my idea. We'll end up using three global namespace objects
(mutex+event+shared memory) instead of one (named pipe), but as we're
not talking thousand
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Why not just use the pid in teh name, and have one segment per backend?
Being used only for signals you mean? That might work.
I dislike fooling around with the contents of postmaster.pid, as that
will inject platform-specific code into places wher
> I have simplified the code according to the discussion. Now
> there is no pipe or signaling threads, process access shared
> memory directly to pass signals.
> Seems everything works fine except pg_ctl. I now have two
> choices to fix it:
>
> (1) Record Shared memory name (it is already there
I have simplified the code according to the discussion. Now there is no pipe
or signaling threads, process access shared memory directly to pass signals.
Seems everything works fine except pg_ctl. I now have two choices to fix it:
(1) Record Shared memory name (it is already there) and the offset
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
>
> It may not be necessary at all. But what I meant is I don't know what
> the default permissinos ar eon a shared mem/event object in the global
> namespace. On the naemd pipe it's "creator/owner full" (so the postgres
> account itself can issue ki
> > > I assume that this will not break the use of pg_ctl to deliver
> > > pseudo-signals. That would be a show-stopper.
> >
> > It shouldn't, but there is one concern: it has to be created in the
> > global namespace. On older windows there is no different, but on
> > modern windows with termin
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
> > I assume that this will not break the use of pg_ctl to
> > deliver pseudo-signals. That would be a show-stopper.
>
> It shouldn't, but there is one concern: it has to be created in the
> global namespace. On older windows there is no different, bu
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
>
> Yeah, that should work. With one shared memory segment and one event for
> each process, of course. The event can be the same one as is used now,
> only it has to be named so it can be accessed externally.
>
Yes, the shared memory segment size co
> >>(*) the process who kill the signal:
> >> - put the signal in a *shared memory variable
> >>pg_signal_queue* and
> >>SetEvent(*shared_memory_event_variable*), then it is done;
> >>
> >>(*) the process who should receive the signal:
> >> - the main thread of this process could be awakened by the
Magnus Hagander wrote:
(*) the process who kill the signal:
- put the signal in a *shared memory variable
pg_signal_queue* and
SetEvent(*shared_memory_event_variable*), then it is done;
(*) the process who should receive the signal:
- the main thread of this process could be awakened by th
> Currently PG win32 port mainly does the following to simulate signals:
>
> (*) the process who kill the signal:
> - put the signal in a named pipe, then it is done;
>
> (*) the process who should receive the signal:
> - a non-stop thread "pg_signal_thread" will read the signal
> from the pip
Currently PG win32 port mainly does the following to simulate signals:
(*) the process who kill the signal:
- put the signal in a named pipe, then it is done;
(*) the process who should receive the signal:
- a non-stop thread "pg_signal_thread" will read the signal from the pipe,
and start anot
13 matches
Mail list logo
