Hi,
On Tue, Jul 28, 2009 at 12:09 AM, Tom Lane wrote:
> I think you're making things more complicated when they should be
> getting simpler.
>
> It strikes me that the current API of "pass the BackendId if known or
> InvalidBackendId if not" still works for processes without a BackendId,
> as long
Fujii Masao writes:
> On Mon, Jul 27, 2009 at 2:43 AM, Tom Lane wrote:
>> If we want to be able to signal processes that don't have a ProcState
>> entry, it would be better to assign an independent index instead of
>> overloading BackendId like this.
> OK, I'll change the mechanism to assign a Pr
Hi,
Thanks for reviewing the patch!
On Mon, Jul 27, 2009 at 2:43 AM, Tom Lane wrote:
> Neither of these changes seem like a good idea to me. The use of a
> spinlock renders the mechanism unsafe for use from the postmaster ---
> we do not wish the postmaster to risk getting stuck if the contents
Fujii Masao writes:
> I updated the patch to solve two problems which you pointed.
> Here is the changes:
> * Prevented the obsolete flag to being set to a new process, by using
>newly-introduced spinlock.
> * Used the index of AuxiliaryProcs instead of auxType, to assign
>backend ID to
On Fri, Jul 17, 2009 at 3:30 PM, Jaime
Casanova wrote:
>>
>> i wasn't able to repeat this on a new instalation and of
>> course i can't swear this is your patch fault...
>>
> this is not your patch fault but an existing bug, i repeat that
> behaviour in an unpatched source tree...
>
ok, i reproduc
On Fri, Jul 17, 2009 at 1:44 PM, Jaime
Casanova wrote:
>
> i wasn't able to repeat this on a new instalation and of
> course i can't swear this is your patch fault...
>
this is not your patch fault but an existing bug, i repeat that
behaviour in an unpatched source tree...
with the steps in the p
On Fri, Jul 17, 2009 at 8:58 AM, Fujii Masao wrote:
> Hi,
>
> On Fri, Jul 17, 2009 at 5:41 PM, Fujii Masao wrote:
>>> I'm reviewing this patch:
>>> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
>
> I updated the patch to solve two problems whi
Hi,
On Fri, Jul 17, 2009 at 5:41 PM, Fujii Masao wrote:
>> I'm reviewing this patch:
>> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
I updated the patch to solve two problems which you pointed.
Here is the changes:
* Prevented the obsolet
Hi Jaime,
On Fri, Jul 17, 2009 at 6:31 AM, Jaime
Casanova wrote:
> I'm reviewing this patch:
> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
Thanks for reviewing the patch!
> something that make me nervous is this:
>/*
> * N
On Thu, Jul 16, 2009 at 2:57 AM, Jaime
Casanova wrote:
> Hi,
>
> I'm reviewing this patch:
> http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
Another thing that took my attention, i don't think this is safe (it
assumes only one auxiliary process
Hi,
I'm reviewing this patch:
http://archives.postgresql.org/message-id/3f0b79eb0907022341m1d36a841x19c3e2a5a6906...@mail.gmail.com
This one applies almost cleanly, except for a minor hunk in elog.c and
postinit.c
Compiles and pass regression tests (i tried both steps in a debian
lenny amd turion
11 matches
Mail list logo
