On Fri, Jul 29, 2016 at 11:58 AM, Tom Lane wrote:
> Maybe the real problem here is that the abstraction layer is so incomplete
> and apparently haphazard, so that it's not very obvious where you should
> use a pq_xxx name and where you should refer to socket_xxx. For some of
> the functions in pq
At Fri, 29 Jul 2016 11:58:04 -0400, Tom Lane wrote in
<14846.1469807...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > The many of the socket_* functions are required to be replaced
> > with mq_* functions for backgroud workers. So reverting the names
> > of socket_* functions should be accompan
At Fri, 29 Jul 2016 13:00:50 -0400, Tom Lane wrote in
<29430.1469811...@sss.pgh.pa.us>
> I wrote:
> > Kyotaro HORIGUCHI writes:
> >> Any work in this area is likely 10.0 material at this point.
>
> > I'm not really happy with that, since refactoring it again will create
> > back-patch hazards.
I wrote:
> Kyotaro HORIGUCHI writes:
>> Any work in this area is likely 10.0 material at this point.
> I'm not really happy with that, since refactoring it again will create
> back-patch hazards. But I see that a lot of the mess here was created
> in 9.5, which means we're probably stuck with ba
Kyotaro HORIGUCHI writes:
> At Fri, 29 Jul 2016 12:47:53 +0900, Michael Paquier
> wrote in
>
>>> At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane wrote in
>>> <4313.1469717...@sss.pgh.pa.us>
>>> I dunno, this seems like it's doubling down on some extremely poor
>>> decisions. Why is it that you
At Fri, 29 Jul 2016 12:47:53 +0900, Michael Paquier
wrote in
> On Fri, Jul 29, 2016 at 12:18 PM, Kyotaro HORIGUCHI
> wrote:
> > At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane wrote in
> > <4313.1469717...@sss.pgh.pa.us>
> >> Fujii Masao writes:
> >> > 3. Several source comments in pqcomm.c hav
On Fri, Jul 29, 2016 at 12:18 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane wrote in
> <4313.1469717...@sss.pgh.pa.us>
>> Fujii Masao writes:
>> > 3. Several source comments in pqcomm.c have not been updated.
>> > Some comments still use the old function name l
At Thu, 28 Jul 2016 10:46:00 -0400, Tom Lane wrote in
<4313.1469717...@sss.pgh.pa.us>
> Fujii Masao writes:
> > 3. Several source comments in pqcomm.c have not been updated.
> > Some comments still use the old function name like pq_putmessage().
>
> > Attached patch fixes the above issues.
Fujii Masao writes:
> 3. Several source comments in pqcomm.c have not been updated.
> Some comments still use the old function name like pq_putmessage().
> Attached patch fixes the above issues.
I dunno, this seems like it's doubling down on some extremely poor
decisions. Why is it that you
On Thu, Jul 28, 2016 at 9:08 PM, Fujii Masao wrote:
> On Thu, Jul 28, 2016 at 6:52 PM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> While testing replication for 9.5, we found that repl-master can
>> ignore wal_sender_timeout and seemingly waits for TCP
>> retransmission timeout for the case of sud
On Thu, Jul 28, 2016 at 6:52 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> While testing replication for 9.5, we found that repl-master can
> ignore wal_sender_timeout and seemingly waits for TCP
> retransmission timeout for the case of sudden power-off of a
> standby.
>
> My investigation told me tha
Hello,
While testing replication for 9.5, we found that repl-master can
ignore wal_sender_timeout and seemingly waits for TCP
retransmission timeout for the case of sudden power-off of a
standby.
My investigation told me that the immediate cause could be that
secure_write() is called with *blocki
12 matches
Mail list logo
