Hi,
On Sun, Jan 11, 2009 at 7:29 PM, Fujii Masao wrote:
> Hi,
>
> On Thu, Jan 8, 2009 at 2:14 AM, Bruce Momjian wrote:
>> Greg Stark wrote:
>>>
>>> On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
>>>
>>> > Heikki Linnakangas wrote:
>>> >> It's required by the sync replication patch, but has no va
Hi,
On Thu, Jan 8, 2009 at 2:14 AM, Bruce Momjian wrote:
> Greg Stark wrote:
>>
>> On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
>>
>> > Heikki Linnakangas wrote:
>> >> It's required by the sync replication patch, but has no value
>> >> otherwise.
>> >
>> > Well, we have talked about allowing mo
Greg Stark wrote:
>
> On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
>
> > Heikki Linnakangas wrote:
> >> It's required by the sync replication patch, but has no value
> >> otherwise.
> >
> > Well, we have talked about allowing more signalling long-term, and
> > this
> > would accomplish that
On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
Heikki Linnakangas wrote:
It's required by the sync replication patch, but has no value
otherwise.
Well, we have talked about allowing more signalling long-term, and
this
would accomplish that independent of the sync replication, so we might
Heikki Linnakangas wrote:
> It's required by the sync replication patch, but has no value otherwise.
Well, we have talked about allowing more signalling long-term, and this
would accomplish that independent of the sync replication, so we might
want to revisit this someday if it isn't included in s
Hi,
On Wed, Jan 7, 2009 at 3:12 PM, Heikki Linnakangas
wrote:
> It's required by the sync replication patch, but has no value otherwise.
Yes. I'm reworking Synch Rep also including the patch.
BTW, attached is the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT O
It's required by the sync replication patch, but has no value otherwise.
Bruce Momjian wrote:
Is this for 8.4?
---
Heikki Linnakangas wrote:
I've been looking at the signal handling part of the synchronous
replication pat
Is this for 8.4?
---
Heikki Linnakangas wrote:
> I've been looking at the signal handling part of the synchronous
> replication patch. It looks OK, but one thing makes me worry.
>
> To set or clear the flag from PGPROC, to
Hi,
Sorry for this late reply.
On Thu, Dec 11, 2008 at 3:12 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Thu, Dec 11, 2008 at 10:55 AM, Fujii Masao
>> wrote:
>>>
>>> I will update the patch based on yours, and add the support for auxiliary
>>> processes into it.
>>
>> Or, should
Hi,
Alvaro Herrera wrote:
> No, the signalling needed here is far simpler than Markus' IMessage
> stuff.
Yup, see also Tom's comment [1].
For Postgres-R I'm currently multiplexing by embedding a message type in
the imessage data itself. So this part is certainly overlapping, yes.
Some of the me
Fujii Masao wrote:
On Thu, Dec 11, 2008 at 10:55 AM, Fujii Masao <[EMAIL PROTECTED]> wrote:
I will update the patch based on yours, and add the support for auxiliary
processes into it.
Or, should I leave renewal of the patch to you? Of course, if you don't have
time, I will do.
I can do it,
Hi,
On Thu, Dec 11, 2008 at 10:55 AM, Fujii Masao <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> My version doesn't have support for auxiliary processes. Does the
>> synchronous replication patch need that?
>
> Yes, the background writer also generates the WAL like a backend,
> so it has to be able to comm
Hi,
> My version doesn't have support for auxiliary processes. Does the
> synchronous replication patch need that?
Yes, the background writer also generates the WAL like a backend,
so it has to be able to communicate with walsender.
> On closer look, I don't see anything setting ProcSignalData.p
Fujii Masao wrote:
Hi,
On Wed, Dec 10, 2008 at 1:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm surprised you feel that way. You suggested earlier
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
that a solution that only works for pr
Fujii Masao wrote:
Hi,
On Wed, Dec 10, 2008 at 1:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm surprised you feel that way. You suggested earlier
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
that a solution that only works for pr
Hi,
On Wed, Dec 10, 2008 at 1:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I'm surprised you feel that way. You suggested earlier
>> (http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
>> that a solution that only works for processes atta
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm surprised you feel that way. You suggested earlier
> (http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
> that a solution that only works for processes attached to shared memory
> would probably suffice for now.
Well, I wasn't comp
Dimitri Fontaine escribió:
> Le mardi 09 décembre 2008, Tom Lane a écrit :
> > I think we need something closer to the postmaster signal multiplexing
> > mechanism, wherein there is a dedicated shared memory area of static
> > layout that holds the signaling flags. And it needs to be driven off
>
Hi,
I hope I'm not disturbing hackers at work by talking about completely
unrelated things but...
Le mardi 09 décembre 2008, Tom Lane a écrit :
> I think we need something closer to the postmaster signal multiplexing
> mechanism, wherein there is a dedicated shared memory area of static
> layout
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Thank you. Looks good to me, committed with minor changes.
I don't think this patch is anywhere near ready to apply.
Ok, I'll revert it if you feel that strongly.
In the first
place, touching the PGPROC like that without any l
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Thank you. Looks good to me, committed with minor changes.
I don't think this patch is anywhere near ready to apply. In the first
place, touching the PGPROC like that without any lock seems completely
unsafe --- among other things, you're relying o
Fujii Masao wrote:
Hi,
On Mon, Dec 8, 2008 at 11:39 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
To set or clear the flag from PGPROC, to send or handle a signal, we have
to acquire ProcArrayLock. Is that safe to do in a sign
Hi,
On Mon, Dec 8, 2008 at 11:39 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>>
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>>
>>> To set or clear the flag from PGPROC, to send or handle a signal, we have
>>> to acquire ProcArrayLock. Is that safe to do in a signal h
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If it's trying to do that then it's broken. In fact, if it's
trying to do much of an
On Mon, 2008-12-08 at 10:04 +0200, Heikki Linnakangas wrote:
> And is the performance impact of that acceptable?
No, but I think we already agreed to change that to a separate lwlock.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-h
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> To set or clear the flag from PGPROC, to send or handle a signal, we
> have to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If it's trying to do that then it's broken. In fact, if it's
trying to do much of anything beyond s
Greg Stark wrote:
Does this signal multiplexing solve the "out of signals" problem we have
generally?
It's a general solution, but it relies on flags in PGPROC, so it'll only
work for backends and auxiliary processes that have a PGPROC entry.
--
Heikki Linnakangas
EnterpriseDB http://w
Does this signal multiplexing solve the "out of signals" problem we
have generally? I need another signal for the progress indicator too.
Or is this only useful for other users which need the same locks or
other resources?
--
Greg
On 8 Dec 2008, at 08:04, Heikki Linnakangas <[EMAIL PROTEC
I've been looking at the signal handling part of the synchronous
replication patch. It looks OK, but one thing makes me worry.
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
And is the performance impa
29 matches
Mail list logo
