Hi,
On Sun, Jan 11, 2009 at 7:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
On Thu, Jan 8, 2009 at 2:14 AM, Bruce Momjian br...@momjian.us wrote:
Greg Stark wrote:
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us wrote:
Heikki Linnakangas wrote:
It's required by the sync
Hi,
On Thu, Jan 8, 2009 at 2:14 AM, Bruce Momjian br...@momjian.us wrote:
Greg Stark wrote:
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us wrote:
Heikki Linnakangas wrote:
It's required by the sync replication patch, but has no value
otherwise.
Well, we have talked about
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
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us 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
Greg Stark wrote:
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us 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
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
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
Hi,
On Wed, Jan 7, 2009 at 3:12 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Hi,
Sorry for this late reply.
On Thu, Dec 11, 2008 at 3:12 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Thu, Dec 11, 2008 at 10:55 AM, Fujii Masao masao.fu...@gmail.com
wrote:
I will update the patch based on yours, and add the support for
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
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
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 attached to
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
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.pid
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 communicate
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,
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 signal
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 on
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
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
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
of
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
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
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
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
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
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
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
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 handler?
No. If
29 matches
Mail list logo
