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
28 matches
Mail list logo
