[pgpool-hackers: 419] Fwd: Issue: about redundancy of pgpool-II, Ticket# 15058-20802, Customer: SIOS Engineers, Account: SIOS Technology, Inc.

Ahsan Hadi ahsan.hadi at enterprisedb.com
Wed Nov 20 21:50:21 JST 2013


Hi Tatsuo,

I am following up on a customer enquiry in pgpool failover mechanism. If
you are running a pgpool master/slave environment and the clients are
connected to the master node, the slave goes down due to any odd reason,
the failover process is initiated and the client are not able to execute
queries on master until the failover is completed.

I understand that this is done by design. Do you know the reasoning behind
this behaviour?

-- Ahsan

---------- Forwarded message ----------
From: Ahsan Hadi <ahsan.hadi at enterprisedb.com>
Date: Mon, Nov 11, 2013 at 7:06 PM
Subject: Re: Issue: about redundancy of pgpool-II, Ticket# 15058-20802,
Customer: SIOS Engineers, Account: SIOS Technology,Inc.
To: Sivananda Reddy <sivananda.reddy at enterprisedb.com>
Cc: Arshu Arora <arshu.arora at enterprisedb.com>, Yuji Fujita <
yuji.fujita at enterprisedb.com>, Tom Kincaid <tom.kincaid at enterprisedb.com>,
Deepanshu Sharma <deepanshu.sharma at enterprisedb.com>, Katsuji Takatsuru <
katsuji.takatsuru at enterprisedb.com>, Naveed Shaikh <
naveed.shaikh at enterprisedb.com>, Baji Shaik <baji.shaik at enterprisedb.com>,
Asif Naeem <asif.naeem at enterprisedb.com>, pgpool-escalations <
pgpool-escalations at enterprisedb.com>, Muhammad Usama <
muhammad.usama at enterprisedb.com>, Team Support <teamsupport at enterprisedb.com>,
Ibrar Ahmed <ibrar.ahmed at enterprisedb.com>





On Mon, Nov 11, 2013 at 10:19 AM, Sivananda Reddy <
sivananda.reddy at enterprisedb.com> wrote:

> Hi All,
>
> We have received below update from the customer. Kindly advise on this.
>
> *Customer's e-mail:*
> *================*
>
> *-Quote-*
>
> Hi,
>
> Thanks for the comments.
>
>  Okay, let's make it clarify what are the customer's requests.
>
> We have already talked a lot about two scenarios of master/slave pgpool-II
> actually, those tickets were mentioned below. Then you can see its detailed
> information.
>
> 1. #15058-20802 - pgpool-II active/standby with streaming
> replication(asynchronous)
>
> 2. #15058-34335 - FB id #23381, pgpool-II active/standby with
> slony-I(asynchronous)
>
> But we think we could consider that a point of these stories has something
> in common.
>
> Which should be that the client always should be able to access and use
> its master db even when its slave has an error or down status. So we could
> also say that the client should not be affected by slave db error.
>
> Here is the customer's requirements and their opinions.
>
> They have a master/slave pgpool-II setup, and the clients are connected to
> the master (primary) instance. Then when the slave (secondary) instance
> goes down due to an error, it triggers a failover(failover handler) and all
> the clients have to wait until the failover handler is done. It looked like
> current pgpool-II specification for now. However according to the
> customer's opinion, all the clients should be able to maintain existing
> connections to the master (primary) instance and also execute sql queries
> for the master even during the failover handler working. Because this is an
> asynchronous replication and as the master instance have no problem at that
> time actually, so the client should be able to use the master database
> normally at least. This is what the customer is expecting to achieve.
>

Thanks for the explanation. We are now able to reproduce the behaviour. The
clients have to wait until the failover process is completed before they
can run any more queries against the master node.

You are right, this is pgpool's documented behaviour. This needs a detailed
study before we can say whether it is possible to change this behaviour and
if it will require any architectural changes to provide this functionality.

I will also discuss this on pgpool hackers.


>  (pgpool-II config file)
>
> * Please have a attached file.
>
>  - The file name corresponds its issue number.
>
> Regards,
>
> *Un-Quote-*
>
>
> On Thu, Nov 7, 2013 at 2:16 PM, Ahsan Hadi <ahsan.hadi at enterprisedb.com>wrote:
>
>>
>>
>>
>> On Thu, Nov 7, 2013 at 1:26 PM, Arshu Arora <arshu.arora at enterprisedb.com
>> > wrote:
>>
>>> Hi Yuji,
>>>
>>> Yes, the meeting was requested by Ahsan on 21st Oct to understand the
>>> request.
>>>
>>> Hi Ahsan,
>>>
>>> We have also received a call from SIOS and they also wanted to continue
>>> over the email. Could you please guide us how to proceed further on this.
>>>
>>
>> I am happy to continue discussing this over emails. From our perspective
>> we want some clarity on the enhancement request. Please have the customer
>> describe the current behaviour that they are seeing with fail-over and the
>> proposed behaviour that they want., Please ask them to share their pgpool
>> configuration file.
>>
>>
>>>
>>> Regards,
>>> Arshu
>>>
>>>
>>> On Wed, Nov 6, 2013 at 8:06 PM, Yuji Fujita <
>>> yuji.fujita at enterprisedb.com> wrote:
>>>
>>>>  Hi Arshu,
>>>>
>>>> Is this for between Ahsan and Watanabe-san of SIOS in Japan?
>>>>
>>>> My understanding is just to confirm the requirement from customer
>>>> Watanabe-san could do it in writing.
>>>>
>>>> Why we have to do by Webex.
>>>> And even so, should we do in groups?
>>>>
>>>> I do not not see the reason why this should be organizaed in this big
>>>> meeting set up?
>>>> Correct me if I am wrong.
>>>>
>>>> Thanks
>>>> Yuji
>>>>
>>>> (2013/11/06 18:04), Arshu Arora wrote:
>>>>
>>>>  Hi Ahsan,
>>>>
>>>>  User has confirmed their availability for webex in the below
>>>> timeslots. Kindly confirm your availability.
>>>>
>>>>  *Quote:*
>>>>
>>>> Apologies for getting back to you late on this.
>>>>
>>>> Please take one hour from these candidate time slots, though it seemed
>>>>
>>>> to be difficult for people in U.S..
>>>>
>>>> Then kindly tell us what is needed to attend the webex.
>>>>
>>>> Day 1.
>>>>
>>>> ---
>>>>
>>>> 23:00 - 01:30 EST 6th Nov.(Wed) ~ 7th Nov.(Thu) - New York  (UTC -5)
>>>>
>>>> 09:30 - 12:00 IST 7th Nov.(Thu)                 - New Delhi (UTC +5.5)
>>>>
>>>> 13:00 - 15:30 JST 7th Nov.(Thu)                 - Tokyo     (UTC +9)
>>>>
>>>> ---
>>>>
>>>> Day 2.
>>>>
>>>> ---
>>>>
>>>> 20:00 - 03:00 EST 7th Nov.(Thu) ~ 8th Nov.(Fri) - New York  (UTC -5)
>>>>
>>>> 06:30 - 13:30 IST 8th Nov.(Fri)                 - New Delhi (UTC +5.5)
>>>>
>>>> 10:00 - 17:00 JST 8th Nov.(Fri)                 - Tokyo     (UTC +9)
>>>>
>>>> *Unquote:*
>>>>
>>>> Regards,
>>>>
>>>> Arshu
>>>>
>>>>
>>>>
>>>> On Mon, Oct 21, 2013 at 2:58 PM, Yuji Fujita <
>>>> yuji.fujita at enterprisedb.com> wrote:
>>>>
>>>>>  Ahsan,
>>>>>
>>>>> Thank you very much.
>>>>>
>>>>> Deepush,
>>>>> Will you send that questions to Watanabe-san of SIOS through support
>>>>> channel?
>>>>> He knew the detail of the requirements and he is right person to
>>>>> answer thsi question.
>>>>>
>>>>> I also inform this to Watanabe-san of SIOS and Takatsuru-san our SE to
>>>>> look into this
>>>>> before support team reach him
>>>>>
>>>>> Thanks
>>>>> Yuji
>>>>>
>>>>> (2013/10/21 18:13), Ahsan Hadi wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 21, 2013 at 3:14 AM, Tom Kincaid <
>>>>> tom.kincaid at enterprisedb.com> wrote:
>>>>>
>>>>>>
>>>>>>  Thanks for the clarification Yuji. Ahsan can Usama take care of
>>>>>> this?
>>>>>>
>>>>>
>>>>>  Sure we can take care of this but we need to understand the
>>>>> enhancement request or bug first. Here is a quote from the end-user...
>>>>>
>>>>>  "
>>>>> So taken together, what the customer/end user asked us is to change
>>>>> pgpool-II behaviour when it's during a failover so that all client
>>>>> connections are able to connect pgpool-II(master db), and also execute any
>>>>> SQLs for the master db even when it's during a failover triggered by
>>>>> backend(a slave db) error.
>>>>>  "
>>>>> So we have a master/slave pgpool setup and the clients are connected
>>>>> to the master (primary) instance, the slave (secondary) instance goes down
>>>>> due to an error. This triggers a fail-over and when this happen all the
>>>>> clients should be able to connect to the master (primary) instance and
>>>>> execute sql queries when the fail-over is happening.
>>>>>
>>>>>  Is that what the customer is expecting to achieve? We did some
>>>>> pgpool fail-over testing and found the fail-over to be working correctly
>>>>> for the above scenario. The client is not able to connect to pgpool for a
>>>>> few seconds when the fail-over is happening but it is able to successfully
>>>>> connect shortly after. Is the customer concerned about the few seconds
>>>>> where the client is not able to connect to pgpool?
>>>>>
>>>>>  Is it possible the customer can show us the behaviour on webex
>>>>> sometime so we can completely understand the request.
>>>>>
>>>>>
>>>>>>
>>>>>> On Sun, Oct 20, 2013 at 5:55 PM, Yuji Fujita <
>>>>>> yuji.fujita at enterprisedb.com> wrote:
>>>>>>
>>>>>>>  Hi Deepunshu,
>>>>>>>
>>>>>>> He is not requesting us to develop a custom code of pgpool for the
>>>>>>> client.
>>>>>>> This is pgpool community issue and should be handled by communty
>>>>>>> core to take care.
>>>>>>> And this requires the chages of the specification of pgpool II.
>>>>>>>
>>>>>>> He is suggesting and requesting to post the requirements from
>>>>>>> customer to the pgpool
>>>>>>> community on the wab and let pgpool II development core members to
>>>>>>> consider the specification changes.
>>>>>>>
>>>>>>> In short, he is requesting to pass this enhancement request to
>>>>>>> pgpool community core.
>>>>>>> Not holding us that requirements within.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yuji
>>>>>>>
>>>>>>> (2013/10/20 19:29), Deepanshu Sharma wrote:
>>>>>>>
>>>>>>> Hi Katsuji,
>>>>>>>
>>>>>>>  Apologies but there is some confusion on our side on what needs to
>>>>>>> be done next.
>>>>>>> Are you suggesting that EnterpriseDB develops a custom code of
>>>>>>> pgpool for the client?
>>>>>>>
>>>>>>>  Regards,
>>>>>>> Deepanshu
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 9, 2013 at 2:12 PM, Arshu Arora <
>>>>>>> arshu.arora at enterprisedb.com> wrote:
>>>>>>>
>>>>>>>> Adding Katsuji Takatsuru
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Oct 9, 2013 at 2:06 PM, Arshu Arora <
>>>>>>>> arshu.arora at enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>>    Hi all,
>>>>>>>>>
>>>>>>>>>  We have received a below response from sales engineer in Japan:
>>>>>>>>>
>>>>>>>>>  *Quote:*
>>>>>>>>>
>>>>>>>>> This is Katsuji Takatsuru who am working as a sales engineer in
>>>>>>>>> Japan,
>>>>>>>>>  and I have been supported  SIOS corporation too.
>>>>>>>>>   Let me consult you about ticket#15058-39039.
>>>>>>>>>
>>>>>>>>>   They understand the specification of pgpool-II well and they
>>>>>>>>> have been
>>>>>>>>> tried to persuadetheir customer that this behavior is besed on the
>>>>>>>>> specification
>>>>>>>>> of pgpool-II.
>>>>>>>>>   However their customer have not  accepted  it so far.
>>>>>>>>>   They are familiar with Oracle RAC,  and they seem to pursue high
>>>>>>>>> availability
>>>>>>>>> near it.
>>>>>>>>>
>>>>>>>>>   "Even when the slave database goes down, pgpool-II restart its
>>>>>>>>> child processes."
>>>>>>>>>    As far as my opinion, I feel that the specification  is
>>>>>>>>> somewhat strange.
>>>>>>>>>    I think fail-over process is unnecessary in case of  slave
>>>>>>>>> database down.
>>>>>>>>>
>>>>>>>>>    Could you please contibute this issue to the community?
>>>>>>>>>    Then,  Japan team , including me , is willing to follow this
>>>>>>>>> issue.
>>>>>>>>>    Thank you in advance.
>>>>>>>>>
>>>>>>>>>  *Unquote:*
>>>>>>>>>
>>>>>>>>>  Regards,
>>>>>>>>>  Arshu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Oct 1, 2013 at 4:54 PM, Naveed Shaikh <
>>>>>>>>> naveed.shaikh at enterprisedb.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>>  We have received following feedback from the customer. Kindly
>>>>>>>>>> advice.
>>>>>>>>>>
>>>>>>>>>>  *Customer email:-*
>>>>>>>>>>
>>>>>>>>>>  Hi team,
>>>>>>>>>>
>>>>>>>>>> Thank you for considering about this issue.
>>>>>>>>>> We are of course okay to have a web-ex meeting.
>>>>>>>>>> However what we can tell you so far is just the customer's
>>>>>>>>>> request like mentioned below.
>>>>>>>>>>
>>>>>>>>>> --- quote ---
>>>>>>>>>> So taken together, what the customer/end user asked us is to
>>>>>>>>>> change pgpool-II behavior when it's during a failover so that all client
>>>>>>>>>> connections are able to connect pgpool-II(master db), and also execute any
>>>>>>>>>> SQLs for the master db even when it's during a failover triggered by
>>>>>>>>>> backend(a slave db) error.
>>>>>>>>>> --- unquote ---
>>>>>>>>>>
>>>>>>>>>> We think that current pgpool-II architecture or other HA cluster
>>>>>>>>>> software can not realize such behavior.
>>>>>>>>>> To execute failover safely in pgpool-II, we need to restart all
>>>>>>>>>> the child processes, and this makes disabling new client connection
>>>>>>>>>> temporarily.
>>>>>>>>>> In contrast, the customer's request is to be able to connect to
>>>>>>>>>> master db even when it's during a failover.
>>>>>>>>>>
>>>>>>>>>> We appreciate your offer to have a web-ex session with your
>>>>>>>>>> development team, but before that,
>>>>>>>>>> we think we are going to talk with Mr. Fujita about this on
>>>>>>>>>> tomorrow.
>>>>>>>>>>
>>>>>>>>>> Kindly give us for some time to give you an update.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   --
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>  EnterpriseDB Corporation
>>>>>>>>>>  The Enterprise PostgreSQL Company
>>>>>>>>>>
>>>>>>>>>>  To reach Support Call:
>>>>>>>>>> US: +1-732-331-1320 - UK: +44 - 2033719820
>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>
>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>
>>>>>>>>>>  This e-mail message (and any attachment) is intended for the
>>>>>>>>>> use of the individual or entity to whom it is addressed. This message
>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>> and delete this message.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 27, 2013 at 5:41 PM, Naveed Shaikh <
>>>>>>>>>> naveed.shaikh at enterprisedb.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Ahsan,
>>>>>>>>>>>
>>>>>>>>>>>  Thanks for the update. We will ask the customer for the web-ex
>>>>>>>>>>> and will update you soon as per their feedback on this.
>>>>>>>>>>>
>>>>>>>>>>>   --
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>  The Enterprise PostgreSQL Company
>>>>>>>>>>>
>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>  US: +1-732-331-1320 - UK: +44 - 2033719820
>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>
>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>  EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>>
>>>>>>>>>>>  This e-mail message (and any attachment) is intended for the
>>>>>>>>>>> use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>> and delete this message.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Sep 27, 2013 at 5:39 PM, Ahsan Hadi <
>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Naveed,
>>>>>>>>>>>>
>>>>>>>>>>>>  Since we aren't able to reproduce the issue, do you think it
>>>>>>>>>>>> makes sense if the customer shows us the issue over a webex session
>>>>>>>>>>>> sometime next week?
>>>>>>>>>>>>
>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 27, 2013 at 5:04 PM, Naveed Shaikh <
>>>>>>>>>>>> naveed.shaikh at enterprisedb.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Ahsan,
>>>>>>>>>>>>>
>>>>>>>>>>>>>  We have received following update from the customer. Kindly
>>>>>>>>>>>>> advice.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  *Customer email:-*
>>>>>>>>>>>>> *===================*
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for your notification.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We think that current point that we are discussing is
>>>>>>>>>>>>> mentioned below.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --- quote ---
>>>>>>>>>>>>> So taken together, what the customer/end user asked us is to
>>>>>>>>>>>>> change pgpool-II behavior when it's during a failover so that all client
>>>>>>>>>>>>> connections are able to connect pgpool-II(master db), and also execute any
>>>>>>>>>>>>> SQLs for the master db even when it's during a failover triggered by
>>>>>>>>>>>>> backend(a slave db) error.
>>>>>>>>>>>>> --- unquote ---
>>>>>>>>>>>>>
>>>>>>>>>>>>> However we also know that current pgpool-II implementation can
>>>>>>>>>>>>> not realize the customer's system requirements mentioned above, and then we
>>>>>>>>>>>>> have already told them that it needs very long time to meet their
>>>>>>>>>>>>> requirement and it also not sure that pgpool-II can be like so or not.
>>>>>>>>>>>>> So what we expect you is talking with the pgpool-II community
>>>>>>>>>>>>> and raising the customer's request to them, though we also think that it's
>>>>>>>>>>>>> very difficult to implement it because it needs change of software design.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>   --
>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>  The Enterprise PostgreSQL Company
>>>>>>>>>>>>>
>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>> US: +1-732-331-1320 - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>
>>>>>>>>>>>>>  This e-mail message (and any attachment) is intended for the
>>>>>>>>>>>>> use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Sep 11, 2013 at 12:25 PM, Ahsan Hadi <
>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Sep 11, 2013 at 11:46 AM, Arshu Arora <
>>>>>>>>>>>>>> arshu.arora at enterprisedb.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  We have received following feedback from the user. Kindly
>>>>>>>>>>>>>>> advice how to proceed further on this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  *Quote:*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Let us clarify about the customer/end user's current
>>>>>>>>>>>>>>> argument on this issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * end user means " Softbank mobile" actually.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First, we understood that "fail_over_on_backend_error = on"
>>>>>>>>>>>>>>> gives us a failover when the pgpool detects slave database failure, and
>>>>>>>>>>>>>>> which also gives us pgpool child process restart to refresh any tcp
>>>>>>>>>>>>>>> connections between the clients and the pgpool-II node. So,
>>>>>>>>>>>>>>> this pgpool-II mechanism should work properly to receive new
>>>>>>>>>>>>>>> client connections after finishing the failover because all connection
>>>>>>>>>>>>>>> should be refreshed by it, and this is also what you pointed out which
>>>>>>>>>>>>>>> should solve the customer's problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, especially the end user insists that pgpool-II(and
>>>>>>>>>>>>>>> its master db) should do accept new client connections even when it's
>>>>>>>>>>>>>>> during a failover. One of their reason and their idea based on the 2nd fact
>>>>>>>>>>>>>>> mentioned below, we think.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [facts confirmed by the customer]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What they saw was 2 fact mentioned below.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. A client new connection was not accepted pgpool=II
>>>>>>>>>>>>>>> whatever "fail_over_on_backend_error" is on or off. This was confirmed by
>>>>>>>>>>>>>>> you, the customer and SIOS.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * SIOS think that this is very common behavior because it's
>>>>>>>>>>>>>>> pgpoll-II specification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. The user confirm that established connection(already
>>>>>>>>>>>>>>> connected to a master db through pgpool-II) between a client anda
>>>>>>>>>>>>>>> pgpool-II(Master db) is not affected by a failover triggered by backend(a
>>>>>>>>>>>>>>> slave db) error, which means that they can execute any SQL for
>>>>>>>>>>>>>>> the master db even when it's during the failover. We talked
>>>>>>>>>>>>>>> about this with you on the "Ticket #: 15058-29968" actually.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * As far as we SIOS confirm the phenomenon, we couldn't
>>>>>>>>>>>>>>> execute SQLs for master db through pgpool-II when it's during a failover .
>>>>>>>>>>>>>>> So this is a difference between the customer ans us(SIOS).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  That's the part we are not able to reproduce locally, I was
>>>>>>>>>>>>>> able to execute sql statement on the master db through pgpool when slave db
>>>>>>>>>>>>>> was stopped. It falls over to master db when slave goes down and falls over
>>>>>>>>>>>>>> to slave db when master goes down.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  We are currently doing some failover and watchdog testing
>>>>>>>>>>>>>> of pgpool so we will test this scenario again with multiple physical
>>>>>>>>>>>>>> machine's and see if we are able to reproduce the issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Is the customer not able to connect to the master db for a
>>>>>>>>>>>>>> few seconds when slave goes down and is able to connect again after a
>>>>>>>>>>>>>> little while?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So taken together, what the customer/end user asked us is to
>>>>>>>>>>>>>>> change pgpool-II behavior when it's during a failover so that all client
>>>>>>>>>>>>>>> connections are able to connect pgpool-II(master db), and also execute any
>>>>>>>>>>>>>>> SQLs for the master db even when it's during a failover
>>>>>>>>>>>>>>> triggered by backend(a slave db) error.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (back ground of their opinion)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They got service outage on their commercial system actually,
>>>>>>>>>>>>>>> because of this pgpool-II mechanism.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It'll helpful if you could give us your opinion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  *Unquote:*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>  Arshu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 7:39 PM, Naveed Shaikh <
>>>>>>>>>>>>>>> naveed.shaikh at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Ahsan,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  Thanks for following up this. We are still waiting a
>>>>>>>>>>>>>>>> response from customer. We will update you soon as per we get an update
>>>>>>>>>>>>>>>> from a customer.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   --
>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>  The Enterprise PostgreSQL Company
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>>>>> US: +1-732-331-1320 - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  This e-mail message (and any attachment) is intended for
>>>>>>>>>>>>>>>> the use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 7:31 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Baji,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  I tried reproducing this again today. I am able to
>>>>>>>>>>>>>>>>> connect to the master even when i stop the slave running in another session.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  Did you get any more updates on this from the customer?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Aug 29, 2013 at 2:53 PM, Baji Shaik <
>>>>>>>>>>>>>>>>> baji.shaik at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Ahsan,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  Yes, we were able to reproduce this issue once(for 1 or
>>>>>>>>>>>>>>>>>> 2 sec), however not after that. Their pgpool configuration file shows "ssl
>>>>>>>>>>>>>>>>>> = off". they say, even they set to
>>>>>>>>>>>>>>>>>> "fail_over_on_backend_error = on", the pgpool-II behavior was not improved
>>>>>>>>>>>>>>>>>> on their environment.  We will get a confirmation from
>>>>>>>>>>>>>>>>>> customer on this and we will update you.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Aug 28, 2013 at 9:14 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Support,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  We are trying to reproduce the issue locally but no
>>>>>>>>>>>>>>>>>>> success so far. Did you say that you were able to reproduce the issue
>>>>>>>>>>>>>>>>>>> successfully one but not after that? Is the customer consistently not able
>>>>>>>>>>>>>>>>>>> to connect to the master when one of the slave is down? Is the customer
>>>>>>>>>>>>>>>>>>> running with SSL enabled?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Aug 27, 2013 at 3:24 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Aug 27, 2013 at 3:14 PM, Naveed Shaikh <
>>>>>>>>>>>>>>>>>>>> naveed.shaikh at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  Do we have any update on this issue.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  Not yet...We have multiple PGPOOL issues that we are
>>>>>>>>>>>>>>>>>>>> dealing with right now. Will have update on it later this week, I am going
>>>>>>>>>>>>>>>>>>>> to try and reproduce the customer behaviour to start with.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   --
>>>>>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>  The Enterprise PostgreSQL Company
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>>>>>>>>>> US: +1-732-331-1320 - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  This e-mail message (and any attachment) is intended
>>>>>>>>>>>>>>>>>>>>> for the use of the individual or entity to whom it is addressed. This
>>>>>>>>>>>>>>>>>>>>> message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 6:40 PM, Baji Shaik <
>>>>>>>>>>>>>>>>>>>>> baji.shaik at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Hi All,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Customer has came back on this issue. They
>>>>>>>>>>>>>>>>>>>>>> complaint that even they have enabled the "fail_over_on_backend_error = on"
>>>>>>>>>>>>>>>>>>>>>> parameter, they are not able to connect to Master for sometime when Slave
>>>>>>>>>>>>>>>>>>>>>> is down from OS command prompt using psql, it is not reproducible through
>>>>>>>>>>>>>>>>>>>>>> psql prompt(find the detailed attachments). We have tried to reproduce the
>>>>>>>>>>>>>>>>>>>>>> issue, however it was reproduced once, and we are not sure why it was not
>>>>>>>>>>>>>>>>>>>>>> able to connect for a second. And We have tested with creating a script
>>>>>>>>>>>>>>>>>>>>>> which  runs psql command multiple times and shutdown the Slave on other
>>>>>>>>>>>>>>>>>>>>>> session. However we cant see that error again.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ cat pgpool.conf|grep -i
>>>>>>>>>>>>>>>>>>>>>> 'fail_over_on_backend_error'
>>>>>>>>>>>>>>>>>>>>>> *fail_over_on_backend_error = on*
>>>>>>>>>>>>>>>>>>>>>> -bash-4.1$
>>>>>>>>>>>>>>>>>>>>>> -bash-4.1$
>>>>>>>>>>>>>>>>>>>>>> -bash-4.1$ *date; ./psql -p 9999 -h localhost -U
>>>>>>>>>>>>>>>>>>>>>> enterprisedb -c "select current_timestamp;" *edb2013-08-26
>>>>>>>>>>>>>>>>>>>>>> 12:29:52 GMT LOG:  received fast shutdown request
>>>>>>>>>>>>>>>>>>>>>> 2013-08-26 12:29:52 GMT LOG:  aborting any active
>>>>>>>>>>>>>>>>>>>>>> transactions
>>>>>>>>>>>>>>>>>>>>>> 2013-08-26 12:29:52 GMT FATAL:  terminating
>>>>>>>>>>>>>>>>>>>>>> walreceiver process due to administrator command
>>>>>>>>>>>>>>>>>>>>>> 2013-08-26 12:29:52 GMT FATAL:  terminating
>>>>>>>>>>>>>>>>>>>>>> connection due to administrator command
>>>>>>>>>>>>>>>>>>>>>> 2013-08-26 12:29:52 GMT LOG:  shutting down
>>>>>>>>>>>>>>>>>>>>>> 2013-08-26 12:29:52 GMT LOG:  database system is shut
>>>>>>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  *Mon Aug 26 12:29:53 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>> *psql: -bash-4.1$ 2013-08-26 12:29:53 GMT LOG:
>>>>>>>>>>>>>>>>>>>>>>  incomplete startup packet*
>>>>>>>>>>>>>>>>>>>>>> *2013-08-26 12:29:53 GMT LOG:  connection failed
>>>>>>>>>>>>>>>>>>>>>> during start up processing: user= database=*
>>>>>>>>>>>>>>>>>>>>>> date; ./psql -p 9999 -h localhost -U enterprisedb -c
>>>>>>>>>>>>>>>>>>>>>> "select current_timestamp;" edb
>>>>>>>>>>>>>>>>>>>>>> Mon Aug 26 12:29:55 GMT 2013
>>>>>>>>>>>>>>>>>>>>>>         current_timestamp
>>>>>>>>>>>>>>>>>>>>>> ----------------------------------
>>>>>>>>>>>>>>>>>>>>>>  26-AUG-13 12:29:55.063265 +00:00
>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Other sesion I ran:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$date; *./pg_ctl -D rep/slave/ stop -mf*
>>>>>>>>>>>>>>>>>>>>>> Mon Aug 26 12:29:52 GMT 2013
>>>>>>>>>>>>>>>>>>>>>> waiting for server to shut down.... done
>>>>>>>>>>>>>>>>>>>>>> server stopped
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  *Below is the response from the Customer:*
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  *Quote:*
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Kindly let us ask you about "Ticket #: 15058-21131".
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Though we understood what you told us before that
>>>>>>>>>>>>>>>>>>>>>> psql connection is not accepted by pgpool-II because of new_connection() of
>>>>>>>>>>>>>>>>>>>>>> pgpool3.2.1/pool_connection_pool.c source code logic, however even the
>>>>>>>>>>>>>>>>>>>>>> customer set to "fail_over_on_backend_error = on", the pgpool-II behavior
>>>>>>>>>>>>>>>>>>>>>> was not improved on their environment like your test case. Could you have a
>>>>>>>>>>>>>>>>>>>>>> look at attached log file and its pgpool configuration file?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  As far as we had looked at the
>>>>>>>>>>>>>>>>>>>>>> pgpool3.2.1/pool_connection_pool.c source, it seemed that psql connection
>>>>>>>>>>>>>>>>>>>>>> was not accepted even they set "fail_over_on_backend_error = on". According
>>>>>>>>>>>>>>>>>>>>>> to our tracing source codes, customer system looked like and should have
>>>>>>>>>>>>>>>>>>>>>> been going to notice_backend_error() -> degenerate_backend_set() ->
>>>>>>>>>>>>>>>>>>>>>> parallel mode = off(from customer's pgpool.conf) -> use_watchdog = off
>>>>>>>>>>>>>>>>>>>>>> (from customer's pgpool.conf) -> *new_connection() returns NULL?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  So we'd like to know your opinions about the
>>>>>>>>>>>>>>>>>>>>>> customer case.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  Your test case (With fail_over_on_backend_error =
>>>>>>>>>>>>>>>>>>>>>> on:)
>>>>>>>>>>>>>>>>>>>>>> * You gave us this on 5/17/2013 12:52 AM EDT of
>>>>>>>>>>>>>>>>>>>>>> "Ticket #: 15058-2113"
>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>> With fail_over_on_backend_error = on:
>>>>>>>>>>>>>>>>>>>>>> -------------------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ more pgpool.conf|grep
>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error
>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error = on
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./pg_ctl -D rep/slave stop -mf
>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:31:20 GMT 2013
>>>>>>>>>>>>>>>>>>>>>> waiting for server to shut down...2013-05-10 00:31:20
>>>>>>>>>>>>>>>>>>>>>> GMT LOG: received fast shutdown request
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;" edb
>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:31:21 GMT 2013
>>>>>>>>>>>>>>>>>>>>>> ?column?
>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;" edb
>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:31:22 GMT 2013
>>>>>>>>>>>>>>>>>>>>>> ?column?
>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;" edb
>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:31:23 GMT 2013
>>>>>>>>>>>>>>>>>>>>>> ?column?
>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  *Unquote:*
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue, Jul 2, 2013 at 8:45 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Naveed,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  Did we communicate the findings and suggestions to
>>>>>>>>>>>>>>>>>>>>>>> the customer that Asif shared on this email chain on May 9th?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  As i recall we concluded that with "fail_over_on_backend_error"
>>>>>>>>>>>>>>>>>>>>>>> enabled, the customer issues is solved, did the customer try that? This was
>>>>>>>>>>>>>>>>>>>>>>> something that support (baji) also tested and verified.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  The last email on this thread is from May 10th. So
>>>>>>>>>>>>>>>>>>>>>>> i am not sure what type of progress you were expecting to make on this
>>>>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Tue, Jul 2, 2013 at 8:01 PM, Naveed Shaikh <
>>>>>>>>>>>>>>>>>>>>>>> naveed.shaikh at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  HI All,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  We have received following email from the
>>>>>>>>>>>>>>>>>>>>>>>> customer regarding the progress of the *Fogbug
>>>>>>>>>>>>>>>>>>>>>>>> #23381. *We have checked the FB#23381 and we
>>>>>>>>>>>>>>>>>>>>>>>> didn't see any progress which we can share with the customer. Kindly
>>>>>>>>>>>>>>>>>>>>>>>> advice.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  *Customer email:-*
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> As we have got an extra inquiry regarding
>>>>>>>>>>>>>>>>>>>>>>>> #15058-21131(Fogbug #23381) and #15058-21088 from the customer.
>>>>>>>>>>>>>>>>>>>>>>>> Kindly let us ask you about it again.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> According to the customer saying, the point of what
>>>>>>>>>>>>>>>>>>>>>>>> they want to insist is differences between a new connection which is not
>>>>>>>>>>>>>>>>>>>>>>>> connected yet and a connection which is already connected.
>>>>>>>>>>>>>>>>>>>>>>>> In short, they pointed out that 2nd connected case
>>>>>>>>>>>>>>>>>>>>>>>> should have been incorrect or the 1st new connection case should have been
>>>>>>>>>>>>>>>>>>>>>>>> able to accept queries like the 2nd case.
>>>>>>>>>>>>>>>>>>>>>>>> Specifically, please have a look at the attached
>>>>>>>>>>>>>>>>>>>>>>>> excel file as we translated diagram of the system and the phenomenon.
>>>>>>>>>>>>>>>>>>>>>>>> Hopefully you'll see it, and could give us your
>>>>>>>>>>>>>>>>>>>>>>>> opinion about it.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> (Conditions)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - PPAS 9.2.1.3
>>>>>>>>>>>>>>>>>>>>>>>> - RHEL5.4(x86_64)
>>>>>>>>>>>>>>>>>>>>>>>> - Attachment: pgpool_info.zip
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>>>>>>   Thanks & Regards,
>>>>>>>>>>>>>>>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>>>> The Postgres Database Company
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>>>>>>>>>>>>> US: +1-732-331-1320 - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>  This e-mail message (and any attachment) is
>>>>>>>>>>>>>>>>>>>>>>>> intended for the use of the individual or entity to whom it is addressed.
>>>>>>>>>>>>>>>>>>>>>>>> This message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 10, 2013 at 11:58 AM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yes I don't see why we shouldn't.
>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> *From: * Venkatesulu J <
>>>>>>>>>>>>>>>>>>>>>>>>> venkatesulu.j at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>> *Date: *Fri, 10 May 2013 11:42:11 +0530
>>>>>>>>>>>>>>>>>>>>>>>>> *To: *<ahsan.hadi at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>> *Cc: *Team Support<teamsupport at enterprisedb.com>;
>>>>>>>>>>>>>>>>>>>>>>>>> support-escalations<
>>>>>>>>>>>>>>>>>>>>>>>>> support-escalations at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>> *Subject: *Re: Issue: about redundancy of
>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-II, Ticket# 15058-20802, Customer: SIOS Engineers, Account: SIOS
>>>>>>>>>>>>>>>>>>>>>>>>> Technology,Inc.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Ahsan,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  Please confirm, can we share this information to
>>>>>>>>>>>>>>>>>>>>>>>>> the customer?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>>>>>>>>>>> Venkat.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 10, 2013 at 9:51 AM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Great.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Are you going to communicate this configuration
>>>>>>>>>>>>>>>>>>>>>>>>>> setting change to the customer?
>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>  *From: * Baji Shaik <baji.shaik at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> *Date: *Fri, 10 May 2013 06:20:23 +0530
>>>>>>>>>>>>>>>>>>>>>>>>>> *To: *Asif Naeem<asif.naeem at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> *Cc: *Venkatesulu J<
>>>>>>>>>>>>>>>>>>>>>>>>>> venkatesulu.j at enterprisedb.com>; Ahsan Hadi<
>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com>; Team Support<
>>>>>>>>>>>>>>>>>>>>>>>>>> teamsupport at enterprisedb.com>;
>>>>>>>>>>>>>>>>>>>>>>>>>> support-escalations<
>>>>>>>>>>>>>>>>>>>>>>>>>> support-escalations at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> *Subject: *Re: Issue: about redundancy of
>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-II, Ticket# 15058-20802, Customer: SIOS Engineers, Account: SIOS
>>>>>>>>>>>>>>>>>>>>>>>>>> Technology,Inc.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Asif,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  Thank you very much for your efforts on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  I have tested this with enabling and disabling
>>>>>>>>>>>>>>>>>>>>>>>>>> the "fail_over_on_backend_error" parameter.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  When "fail_over_on_backend_error" parameter is
>>>>>>>>>>>>>>>>>>>>>>>>>> disabled, as you said, we cannot connect to master during health check. And
>>>>>>>>>>>>>>>>>>>>>>>>>> if this parameter is enabled, they we have not face this issue.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  *With fail_over_on_backend_error = off:*
>>>>>>>>>>>>>>>>>>>>>>>>>> *-------------------------------*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ more pgpool.conf|grep
>>>>>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error
>>>>>>>>>>>>>>>>>>>>>>>>>> *fail_over_on_backend_error = off*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./pg_ctl -D rep/slave stop -mf
>>>>>>>>>>>>>>>>>>>>>>>>>> *Fri May 10 00:25:56 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>>>>>> waiting for server to shut down....2013-05-10
>>>>>>>>>>>>>>>>>>>>>>>>>> 00:25:56 GMT LOG:  received fast shutdown request
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> *Fri May 10 00:25:57 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>>>>>> psql: -bash-4.1$ 2013-05-10 00:25:57 GMT LOG:
>>>>>>>>>>>>>>>>>>>>>>>>>>  incomplete startup packet
>>>>>>>>>>>>>>>>>>>>>>>>>>  2013-05-10 00:25:57 GMT LOG:  connection failed
>>>>>>>>>>>>>>>>>>>>>>>>>> during start up processing: user= database=
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:26:01 GMT 2013
>>>>>>>>>>>>>>>>>>>>>>>>>> psql: 2013-05-10 00:26:01 GMT LOG:  incomplete
>>>>>>>>>>>>>>>>>>>>>>>>>> startup packet
>>>>>>>>>>>>>>>>>>>>>>>>>> 2013-05-10 00:26:01 GMT LOG:  connection failed
>>>>>>>>>>>>>>>>>>>>>>>>>> during start up processing: user= database=
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> *Fri May 10 00:26:06 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>>>>>> psql: -bash-4.1$ 2013-05-10 00:26:06 GMT LOG:
>>>>>>>>>>>>>>>>>>>>>>>>>>  incomplete startup packet
>>>>>>>>>>>>>>>>>>>>>>>>>> 2013-05-10 00:26:06 GMT LOG:  connection failed
>>>>>>>>>>>>>>>>>>>>>>>>>> during start up processing: user= database=
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> *Fri May 10 00:26:08 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>>>>>>  ?column?
>>>>>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>>>>>>         1
>>>>>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ==================================================================
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  *With fail_over_on_backend_error = on:*
>>>>>>>>>>>>>>>>>>>>>>>>>> *-------------------------------*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ more pgpool.conf|grep
>>>>>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error
>>>>>>>>>>>>>>>>>>>>>>>>>> *fail_over_on_backend_error = on*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./pg_ctl -D rep/slave stop -mf
>>>>>>>>>>>>>>>>>>>>>>>>>> *Fri May 10 00:31:20 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>>>>>> waiting for server to shut down...2013-05-10
>>>>>>>>>>>>>>>>>>>>>>>>>> 00:31:20 GMT LOG:  received fast shutdown request
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> *Fri May 10 00:31:21 GMT 2013*
>>>>>>>>>>>>>>>>>>>>>>>>>>   ?column?
>>>>>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>>>>>>         1
>>>>>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:31:22 GMT 2013
>>>>>>>>>>>>>>>>>>>>>>>>>>  ?column?
>>>>>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>>>>>>         1
>>>>>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  -bash-4.1$ date;./psql -p 9999 -c "select 1;"
>>>>>>>>>>>>>>>>>>>>>>>>>> edb
>>>>>>>>>>>>>>>>>>>>>>>>>> Fri May 10 00:31:23 GMT 2013
>>>>>>>>>>>>>>>>>>>>>>>>>>  ?column?
>>>>>>>>>>>>>>>>>>>>>>>>>> ----------
>>>>>>>>>>>>>>>>>>>>>>>>>>         1
>>>>>>>>>>>>>>>>>>>>>>>>>> (1 row)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>> Baji Shaik.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 9, 2013 at 4:48 PM, Asif Naeem <
>>>>>>>>>>>>>>>>>>>>>>>>>> asif.naeem at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It seems that customer is using pgpool
>>>>>>>>>>>>>>>>>>>>>>>>>>> configuration file (config.zip.zip) as shared on parature ticket
>>>>>>>>>>>>>>>>>>>>>>>>>>> 15058-20802. It contains following related settings i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  pgpool.conf
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend_flag0 = 'ALLOW_TO_FAILOVER'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend_flag1 = 'ALLOW_TO_FAILOVER'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error = off
>>>>>>>>>>>>>>>>>>>>>>>>>>>> health_check_period = 5
>>>>>>>>>>>>>>>>>>>>>>>>>>>> health_check_timeout = 1
>>>>>>>>>>>>>>>>>>>>>>>>>>>> health_check_max_retries = 2
>>>>>>>>>>>>>>>>>>>>>>>>>>>> health_check_retry_delay = 5
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  Customer reported the following issue i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>> When the slave server got an error during the
>>>>>>>>>>>>>>>>>>>>>>>>>>> healthcheck retries function enabled, pgpool requests in spite of select or
>>>>>>>>>>>>>>>>>>>>>>>>>>> update query won't be accepted any more during the healthcheck is trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>> retry.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  According to pgpool documentation<http://www.pgpool.net/docs/latest/pgpool-en.html>
>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-II periodically tries to connect to the
>>>>>>>>>>>>>>>>>>>>>>>>>>> backends to detect any error on the servers or networks. This error check
>>>>>>>>>>>>>>>>>>>>>>>>>>> procedure is called "health check". If an error is detected, pgpool-II
>>>>>>>>>>>>>>>>>>>>>>>>>>> tries to perform failover or degeneration.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> health_check_timeout
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This parameter serves to prevent the health
>>>>>>>>>>>>>>>>>>>>>>>>>>>> check from waiting for a long time in a case such as unplugged network
>>>>>>>>>>>>>>>>>>>>>>>>>>>> cable.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> health_check_max_retries
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The maximum number of times to retry a failed
>>>>>>>>>>>>>>>>>>>>>>>>>>>> health check before giving up and initiating failover. This setting can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> useful in spotty networks, when it is expected that health checks will fail
>>>>>>>>>>>>>>>>>>>>>>>>>>>> occasionally even when the master is fine. Default is 0, which means do not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> retry. It is advised that you disable fail_over_on_backend_error if you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> want to enable health_check_max_retries.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If true, and an error occurs when
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reading/writing to the backend communication, pgpool-II will trigger the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> fail over procedure. If set to false, pgpool will report an error and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> disconnect the session.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  Customer has enabled failover and seems
>>>>>>>>>>>>>>>>>>>>>>>>>>> following pgpool documentation recommendation to disable
>>>>>>>>>>>>>>>>>>>>>>>>>>> "fail_over_on_backend_error" when "health_check_max_retries" is being used.
>>>>>>>>>>>>>>>>>>>>>>>>>>> As customer is experiencing, It is a feature that pgpool health check
>>>>>>>>>>>>>>>>>>>>>>>>>>> retries to connect to backend server (nodes) to detect errors until it
>>>>>>>>>>>>>>>>>>>>>>>>>>> expires, then triggers failover if required. When node disconnection
>>>>>>>>>>>>>>>>>>>>>>>>>>> happens and customer is not able to connect to pgpool anymore (until health
>>>>>>>>>>>>>>>>>>>>>>>>>>> check complete) because of following code snippet i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  pgpool3.2.1/pool_connection_pool.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>     619 static POOL_CONNECTION_POOL
>>>>>>>>>>>>>>>>>>>>>>>>>>> *new_connection(POOL_CONNECTION_POOL *p)
>>>>>>>>>>>>>>>>>>>>>>>>>>>     620 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>     621         POOL_CONNECTION_POOL_SLOT *s;
>>>>>>>>>>>>>>>>>>>>>>>>>>>     622         int active_backend_count = 0;
>>>>>>>>>>>>>>>>>>>>>>>>>>>     623         int i;
>>>>>>>>>>>>>>>>>>>>>>>>>>>     624
>>>>>>>>>>>>>>>>>>>>>>>>>>>     625         for (i=0;i<NUM_BACKENDS;i++)
>>>>>>>>>>>>>>>>>>>>>>>>>>>     626         {
>>>>>>>>>>>>>>>>>>>>>>>>>>>     627
>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_debug("new_connection: connecting %d backend", i);
>>>>>>>>>>>>>>>>>>>>>>>>>>>     628
>>>>>>>>>>>>>>>>>>>>>>>>>>>     629                 if (!VALID_BACKEND(i))
>>>>>>>>>>>>>>>>>>>>>>>>>>>     630                 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>     631
>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_debug("new_connection: skipping slot %d because backend_status = %d",
>>>>>>>>>>>>>>>>>>>>>>>>>>>     632
>>>>>>>>>>>>>>>>>>>>>>>>>>>    i, BACKEND_INFO(i).backend_status);
>>>>>>>>>>>>>>>>>>>>>>>>>>>     633                         continue;
>>>>>>>>>>>>>>>>>>>>>>>>>>>     634                 }
>>>>>>>>>>>>>>>>>>>>>>>>>>>     635
>>>>>>>>>>>>>>>>>>>>>>>>>>>     636                 s =
>>>>>>>>>>>>>>>>>>>>>>>>>>> malloc(sizeof(POOL_CONNECTION_POOL_SLOT));
>>>>>>>>>>>>>>>>>>>>>>>>>>>     637                 if (s == NULL)
>>>>>>>>>>>>>>>>>>>>>>>>>>>     638                 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>     639
>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_error("new_connection: malloc() failed");
>>>>>>>>>>>>>>>>>>>>>>>>>>>     640                         return NULL;
>>>>>>>>>>>>>>>>>>>>>>>>>>>     641                 }
>>>>>>>>>>>>>>>>>>>>>>>>>>>     642
>>>>>>>>>>>>>>>>>>>>>>>>>>>     643                 if (create_cp(s, i) ==
>>>>>>>>>>>>>>>>>>>>>>>>>>> NULL)
>>>>>>>>>>>>>>>>>>>>>>>>>>>     644                 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>     645                         /* connection
>>>>>>>>>>>>>>>>>>>>>>>>>>> failed. mark this backend down */
>>>>>>>>>>>>>>>>>>>>>>>>>>>     646
>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_error("new_connection: create_cp() failed");
>>>>>>>>>>>>>>>>>>>>>>>>>>>     647
>>>>>>>>>>>>>>>>>>>>>>>>>>>     648                         /* If
>>>>>>>>>>>>>>>>>>>>>>>>>>> fail_over_on_backend_error is true, do failover.
>>>>>>>>>>>>>>>>>>>>>>>>>>>      649                          * Otherwise,
>>>>>>>>>>>>>>>>>>>>>>>>>>> just exit this session.
>>>>>>>>>>>>>>>>>>>>>>>>>>>     650                          */
>>>>>>>>>>>>>>>>>>>>>>>>>>>     651                         if
>>>>>>>>>>>>>>>>>>>>>>>>>>> (pool_config->fail_over_on_backend_error)
>>>>>>>>>>>>>>>>>>>>>>>>>>>     652                         {
>>>>>>>>>>>>>>>>>>>>>>>>>>>     653
>>>>>>>>>>>>>>>>>>>>>>>>>>> notice_backend_error(i);
>>>>>>>>>>>>>>>>>>>>>>>>>>>     654                         }
>>>>>>>>>>>>>>>>>>>>>>>>>>>     655                         child_exit(1);
>>>>>>>>>>>>>>>>>>>>>>>>>>>     656                 }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  If there is error in connection to any of the
>>>>>>>>>>>>>>>>>>>>>>>>>>> node that have valid status (and "fail_over_on_backend_error" option is
>>>>>>>>>>>>>>>>>>>>>>>>>>> disabled), it abort the child process that is making new connection
>>>>>>>>>>>>>>>>>>>>>>>>>>> attempt. That is why pgpool is not allowing new connection to pgpool when
>>>>>>>>>>>>>>>>>>>>>>>>>>> any of node disconnected until node status changed (status change is done
>>>>>>>>>>>>>>>>>>>>>>>>>>> via failover/degeneration).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  If customer enabled
>>>>>>>>>>>>>>>>>>>>>>>>>>> "fail_over_on_backend_error" it will solve customer issue. Now if there is
>>>>>>>>>>>>>>>>>>>>>>>>>>> node disconnection occurs and either health check complete/expires or new
>>>>>>>>>>>>>>>>>>>>>>>>>>> connection attempt made, it will trigger failover.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  Health check behavior can be observed in
>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool 3.2.4 (latest verison) too. I believe it is a pgpool feature that
>>>>>>>>>>>>>>>>>>>>>>>>>>> customer is facing. Please do let me know if I missed something or any
>>>>>>>>>>>>>>>>>>>>>>>>>>> change is required. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>> Asif Naeem
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 9, 2013 at 11:23 AM, Venkatesulu J <
>>>>>>>>>>>>>>>>>>>>>>>>>>> venkatesulu.j at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ahsan,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> We have received below response from the user
>>>>>>>>>>>>>>>>>>>>>>>>>>>> .  Kindly comment on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> *Customer's e-mail: -Quote- *
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for the comment.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> We understood your intention of the question,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the phenomenon shouldn't have occurred if the failover enabled base on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-II source codes. Is this right?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unfortunately, it's very difficult to confirm
>>>>>>>>>>>>>>>>>>>>>>>>>>>> about the details of the customer's test case anymore, because the customer
>>>>>>>>>>>>>>>>>>>>>>>>>>>> has already concluded this issue like the understanding mentioned before.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then based on the customer's conclusion, they asked us to raise this story
>>>>>>>>>>>>>>>>>>>>>>>>>>>> as a bug/enhancement report.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the fact is different from the customer's
>>>>>>>>>>>>>>>>>>>>>>>>>>>> understanding, we have to make it clear about the pgpool behavior without
>>>>>>>>>>>>>>>>>>>>>>>>>>>> customer's feedback/comments, and give them some explanations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> As this issue (originally from the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> #15058-20802) takes very long time, it's about over 3 months since it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>> opened, we think we need to resolve this issue on our side.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for your patience and understanding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> * -Unquote-*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Venkat.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 8, 2013 at 3:23 AM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Venkatesulu,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Further to the last update from the customer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on this issue, can you check if the customer has failover enabled when they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> run into this issue?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, May 7, 2013 at 2:35 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Tue, May 7, 2013 at 2:02 PM, Venkatesulu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> J <venkatesulu.j at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ahsan,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do we have any update on this issue.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Venkate,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  I was hoping Asif would spend sometime on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this on Monday but he wasn't able to since he was trying to wrap up
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something that was working on since last week. We will surely test this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario with the latest pgpool stable version and this week and get back
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to you.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Venkat.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 3, 2013 at 2:46 AM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are going to try and test this issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with pgpool 3.2.3 and if it is fixed in that branch. If it is still not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixed then we already have an issue reported for this on pgpool hackers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Will update on this on Monday.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 3, 2013 at 12:16 AM, Abdul
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sayeed <abdul.sayeed at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  We have received below update from the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> customer. Kindly advice.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  *Customer's Email:*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  *-Quote-*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  We have got an update on this issue from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the customer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  According to the customer saying, they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understood that pgpool does same behavior regardless of the failure node is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> master or slave, which means client requests won't be accept when a node
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> failure happens on master/slave.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  If the customer understanding is right,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they ask us to raise this issue to bugzilla as an enhancement request. If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not, tell us please.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Thanks in advance.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  *-Unquote-*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Abdul Sayeed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 23, 2013 at 5:12 PM, Asif
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Naeem <asif.naeem at enterprisedb.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AFAIR, While testing pgpool 3.2.3 with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> failover enabled with customer scenario, issue don't appear any more
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because failover got triggered when new connection attempt being made, I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hope customer is not going to face this issue with pgpool 3.2.3 as per my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> previous comment on the same email thread i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Wed, Feb 27, 2013 at 5:12 AM, Asif
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Naeem <asif.naeem at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am following it up on the community on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the following issue id i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.pgpool.net/mantisbt/view.php?id=50
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-II community recently released
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> version 3.2.3 (2013/02/18), Main purpose of this release is to fix fatal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problem with pgpool-II 3.2.2's health checking. Now in the case of fail
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> over is enabled it tries to "solve" the customer issue via triggering fail
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> over but if fail over is disabled it shows same old behavior. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Tue, Apr 23, 2013 at 4:00 PM, Abdul
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sayeed <abdul.sayeed at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AFAIU discussing it with you and the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> developer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It seemed to talk about when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DISALLOW_TO_FAILOVER flag was set mainly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Besides, the developer said that "It's a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feature if you disable fail over." as well.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  I continued putting effort for this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because EDB don't recommend failover to customers. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.sraoss.jp/pipermail/pgpool-hackers/2013-April/000185.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> However, the customer didn't get the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> meaning and the point of the discussion,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because the actual customer's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configuration is ALLOW_TO_FAILOVER.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then they didn't see the reason /
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> senario why they faced to have been waiting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until the health_check was finished.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As far as we SIOS looked at the source
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code mentioned below, the reason
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seemed because of prallel_mode setting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which is off on their configuration.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./pgpool-II-3.2.1/main.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 757 if (!pool_config->parallel_mode)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 758 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 759 if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (POOL_DISALLOW_TO_FAILOVER(BACKEND_INFO(sts).flag))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 760 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 761 pool_log("health_check: %d failover
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is canceld because failover is disallowed", sts);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 762 }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 763 else if (retrycnt <=
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_config->health_check_max_retries)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 764 {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 765 /* continue to retry */
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 766 sleep_time =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_config->health_check_retry_delay;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 767 pool_log("health check retry sleep
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> time: %d second(s)", sleep_time);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 768 pool_sleep(sleep_time);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 769 retrying = true;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 770 continue;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 771 }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (snip)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If our understanding is wrong, tell us
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please. Then kindly tell us the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reason or scenario why the customer were
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> waiting until the health_check
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was finished.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *-Quote-*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Abdul Sayeed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Apr 11, 2013 at 1:10 PM, Arshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Arora <arshu.arora at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ahsan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We will share this with SIOS and will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> update you with their feedback.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Arshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Apr 11, 2013 at 1:07 PM, Ahsan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hadi <ahsan.hadi at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Deepanshu,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Is there anything more to be done on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this from our end? As per the discussion on hackers, the behavior that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> customer is seeing is expected when fail over is disabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Ahsan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Apr 11, 2013 at 10:29 AM, Asif
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Naeem <asif.naeem at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Failover seems only available option
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000196.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > AFAIU discussing it with you that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is a feature not a bug. In the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > presented scenario, If any of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> slave got down or missing ( maybe because of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > network issue ), until it become
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> available/up again, pgpool will be non
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > responsive to any new connection
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (with no warning or message). Do you agree
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > ?. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's a feature if you disable fail
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> over.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Tatsuo Ishii
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SRA OSS, Inc. Japan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> English:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.sraoss.co.jp/index_en.php
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Japanese: http://www.sraoss.co.jp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Please do let me know if I missed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something or any more info is required. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Asif Naeem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Apr 8, 2013 at 1:59 PM, Asif
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Naeem <asif.naeem at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Deepanshu,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Sorry for delay, I was working on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other tasks. I have looked at the latest pgpool2 (3.2.3) source code,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> failover seems the only option that can help in customer issue (Although it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seems that EDB don't recommend failover). I have postted my findings on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-hackers available at i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000185.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Please do let me know if I missed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something or any info is required. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Asif Naeem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, Apr 6, 2013 at 11:58 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Deepanshu Sharma <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deepanshu.sharma at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Asif,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Would it be possible for you to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> share with is the link to the post at which this issues is being discussed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on PGpool Hackers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Deepanshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Mar 29, 2013, at 9:58 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ahsan Hadi wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Deepanshu,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Mar 29, 2013 at 1:32 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Deepanshu Sharma <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deepanshu.sharma at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Is there any progress on this?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Looking at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.pgpool.net/mantisbt/view.php?id=50the patch seems to have been rejected.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Yes the patches submitted so far
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have an issue which needs to progressed further on pgpool-hackers. I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> believe Asif submitted those patches to the hackers. In any case we are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going to spend more time on this issue next week to address the issues
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> raised in the patch.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Reagards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Deepanshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Mar 15, 2013, at 4:58 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ahsan Hadi wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  There is some traction on this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the community, Takatsuru-san has looked at the patches submitted by Asif
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and posted an issue caused by the patch. We are going to move the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion to pgpool hackers as suggested by Takatsuru and work on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue identified by him.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Mar 13, 2013 at 2:02 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Mar 13, 2013 at 2:30 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Asif Naeem <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asif.naeem at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Mar 13, 2013 at 1:36 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Katsuji Takatsuru <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> katsuji.takatsuru at enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Ahsan,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cc om,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   As Fujita-san said,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ishii-san did not know that a patch for this issue had posted into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> community.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  We asked him if this patch is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> acceptable, and he is going to do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  So, can you please tell me any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number that he can identify your request?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Katsuji,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Related issue is logged as ID:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0000050<http://www.pgpool.net/mantisbt/view.php?id=50> on pgpool
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bug Tracker. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  There are couple of patches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> submitted by Asif on this thread that needs to be reviewed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Asif Naeem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Katsuji
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On 2013/03/13, at 11:48, Yuji
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <yuji.fujita at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Ahsan,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cc Tom,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you very much.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Takatsuru-san and I had the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> meeting with Ishii-san and his team yesterday
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and he would like to know the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> id or bug number that he can identify on his pgpool web site.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He looks he was not aware of it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Takatsuru-san will send you the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> follow up e-mail on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Will you respond to his quesry?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So that he will communicate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this with Ishii-san directly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yuji
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2013/03/13 11:42), Ahsan Hadi
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Mar 12, 2013 at 2:03
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AM, Tom Kincaid <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tom.kincaid at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Thank you Yuji,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  We just need Ishii to have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> somebody look at the patch Asif Rana submitted to the community.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Asif Naeem submitted the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> patch..
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Mon, Mar 11, 2013 at 4:59
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PM, Yuji <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yuji.fujita at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Tom,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is Yuji.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Takatsuru-san,SE, and myself
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> happens to have the meeting with Ishii-san this afternoon.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We could talk on this from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our end as well.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Takatsuru-san will be able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> update you on the technical side.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for working on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yuji
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2013/03/11 23:45), Tom
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Kincaid wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  OK, can somebody send a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> message to "Tatsuo Ishii" <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ishii at sraoss.co.jp> asking
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the community to review that patch?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Mon, Mar 11, 2013 at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 10:29 AM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 11, 2013 at 5:15
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PM, Tom Kincaid <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tom.kincaid at enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Ahsan / Asif?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Tom,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  We have created a redmine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case for this "30138", there is a possible patch for this issue which is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> attached in the redmine case. This patch is also submitted to the community
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it is not checked in yet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Robert or Bruce can take a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> look at this patch and share there thoughts. Meanwhile Asif is following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this up with the community and also testing the patch in more detail.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  -- Ahsan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Sun, Mar 10, 2013 at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 11:38 PM, Naveed Shaikh <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> naveed.shaikh at enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi All,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Do we have any updates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on this issue.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   Thanks & Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Naveed Shaikh
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The Enterprise PostgreSQL
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Company
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> US: +1-732-331-1320 - UK: +44
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Brazil: +55-2139581371 -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> India: +91-20-30589491
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Website:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   This e-mail message
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (and any attachment) is intended for the use of the individual or entity to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whom it is addressed. This message contains information from EnterpriseDB
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Corporation that may be privileged, confidential, or exempt from disclosure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under applicable law. If you are not the intended recipient or authorized
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to receive this for the intended recipient, any use, dissemination,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> distribution, retention, archiving, or copying of this communication is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly prohibited. If you have received this e-mail in error, please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> notify the sender immediately by reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 4, 2013 at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5:50 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Arshu,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Asif Naeem had
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> submitted a patch to the community which seem to have fixed this issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "cannot connect to master when slave shuts down abruptly and health-check
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is in progress". There has been some discussion on the community since then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it seems that the community is not responding very promptly on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  I have asked Asif to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> follow-up with the community on this issue. In the meantime we can test our
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> patch to get a higher comfort level that it doesn't break anything else.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ahsan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 4, 2013 at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4:19 PM, Arshu Arora <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> arshu.arora at enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We have received a below
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feedback from the user.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *Quote:*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi EnterpriseDB team,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We've got a feedback
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the customer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *** business impact of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this issue ***
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The system facing to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this issue is now providing commercial service,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which is mobile phone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remote management service actually.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Besides, the number of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> users on the service is about 30,000,000, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the company providing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the service is Softbank mobile as you might have been already known.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to the end
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user's saying, since the system is providing the service for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 24/7/365, if there's a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> service unavailable hours they might be accused of something
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for it. Therefore they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recognized the bug as serious problem.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So we'd like you to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think about priority redefinition of this issue.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *Unquote:*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Arshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Mar 1, 2013 at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1:45 AM, Deepanshu Sharma
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deepanshu.sharma at enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adding Katsuji Takatsu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the mail chain he is working with Yuji on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Deepanshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Feb 28, 2013, at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3:29 PM, Deepanshu Sharma wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Tom,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  We had requested Yuji
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to get in touch with the client in order to gage the priority of the issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and he has comeback stating that having a fix for this is critical for them.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am adding Yuji to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this mail chain for his inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Deepanshu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  On Feb 27, 2013, at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 7:23 PM, Asif Naeem wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Do you have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> visibility into other issues that fixed in this release? If there are a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> large number of low risk fixes on other fronts I would like to see if we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can get those through our system.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Hi Tom,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  According to pgpool-II
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3.2.3 release note<http://www.pgpool.net/docs/pgpool-II-3.2.3/NEWS.txt>, there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are the following fixes in this release i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   * Version 3.2.3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       This is a bug
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fix release against pgpool-II 3.2.2. Main purpose
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       of this release
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is to fix fatal problem with pgpool-II 3.2.2's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       health checking.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If all of following conditions are met, pgpool
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       main process
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disappeared and all client connections to pgpool-II
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       hang forever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when failover happens. And the only way to recover
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       from it is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> manualy killing the pgpool child process and restart
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       pgpool-II.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       - health
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checking is enabled
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       - connecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method to PostgreSQL is TCP/IP, not UNIX domain
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>         socket(i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "backend_hostnameN" is not empty string)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> __________________________________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * Bug fixes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Fix
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> connect_inet_domain_socket_by_port() bug introduced in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       3.2.2. (Tatsuo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ishii)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       When non
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> blocking connect() reports EINPROGRESS or EALREADY, it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       calls select(2)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to wait for read or write fd ready. However it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       mistakenly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checks error condition using getsockopt(). It should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       be called when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> select() returns > 0, rather than 0. Because of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       this,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> connect_inet_domain_socket_by_port() could return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       succeeded fd
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> even it actually failed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       And what is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> worse, this health_check() mistakenly believes that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       backend is alive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and tries to write to backend socket, which of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       course fails.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This triggers to call notice_backend_error(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       which sends
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SIGUSR1 signal to pgpool main's parent process. This
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       will result in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> various weird things: for example,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *if you start
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool from a shell, the signal kills the shell.* If you start
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       pgpool in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> background, pgpool's parent is the process #1. As long
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       as you started
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool as non root, it's ok. Even if you start
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       pgpool as root,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> init just reopens /dev/initctl by receiving
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       SIGUSR1. These
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all annoying bugs have been there since pgpool
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       was born. The
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> connect_inet_domain_socket_by_port() bug just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       reveals it. To
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fix this, I modified notice_backend_error and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       child_exit() so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that it does nothing when called from pgpool
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       main process
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself to prevent pgpool from shooting itself in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       the foot.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Fix to show
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_passwd in "SHOW pool_status". (Yugo Nagata)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     - Fix a typo at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configure's help in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configure.in. (Yugo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nagata)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  While working on this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue, it was really uncomfortable when pgpool keep killing my shell that I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used to run it. They fixed it in 3.2.3 version. Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Asif Naeem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 27, 2013
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at 5:12 AM, Asif Naeem <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asif.naeem at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, I am following it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> up on the community on the following issue id i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.pgpool.net/mantisbt/view.php?id=50pgpool-II community recently released version 3.2.3 (2013/02/18), Main
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> purpose of this release is to fix fatal problem with pgpool-II 3.2.2's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> health checking. Now in the case of fail over is enabled it tries to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "solve" the customer issue via triggering fail over but if fail over is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disabled it shows same old behavior. Thanks. Best Regards, Asif Naeem On
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Wed, Feb 27, 2013 at 2:46 PM, Ahsan Hadi <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ahsan.hadi at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: Asif Naeem has bee following up on this issue with the community.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adding Asif for an update. On Wed, Feb 27, 2013 at 2:40 PM, Arshu Arora <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> arshu.arora at enterprisedb.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: Hi Bruce, Would it possible for you to give some inputs on this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue.  Below is the issue reported: We have received below pgpool request
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from one of our Partner Customer(SIOS Technology,Inc). OS version: RHEL5.5
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86_64 Product Version: PPAS 9.2.1.3 Pgpool Version: pgpool-II-3.2.1 Issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Reported: When load_balance mode is on and slave is down, we can not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> connect to pgpool even master is up. Customer's Email: Kindly let us ask
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you about pgpool-II behavior. (Conditions) DB : PPAS 9.2.1.3 OS : RHEL5.5
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86_64 Server: HP ProLiant BL460c G7 x 2 * Streaming Replication (async)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Master/Slave configuration (Phenomenon) When the slave server got an error
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during the healthcheck retries function enabled, pgpool requests in spite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of select or update query won't be accepted any more during the healthcheck
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is trying to retry. (Reason why they ask you) The customer think that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> phenomenon (can't access to the database) shouldn't be happened even though
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it's master/slave configuration, besides enabling the helthcheck retries
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function is required for their system not to disconnect to the DB even when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an instantaneous network interruption is happened. (Additional info)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to the customer saying based on their investigation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pgpool-II-3.2.1 source codes, it seemed that a connection to the slave node
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also happens when an user requests to connect to the master node during the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> slave node is getting error. Then if the connection request fails, users
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't connect to the pgpool any more. The corresponding source codes of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> phenomenon --- pool_connection_pool.c static POOL_CONNECTION_POOL
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *new_connection(POOL_CONNECTION_POOL *p) { POOL_CONNECTION_POOL_SLOT *s;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int active_backend_count = 0; int i; for (i=0;i<NUM_BACKENDS;i++) {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_debug("new_connection: connecting %d backend", i); if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (!VALID_BACKEND(i)) { pool_debug("new_connection: skipping slot %d because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend_status = %d", i, BACKEND_INFO(i).backend_status); continue; } s =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> malloc(sizeof(POOL_CONNECTION_POOL_SLOT)); if (s == NULL) {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_error("new_connection: malloc() failed"); return NULL; } if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (create_cp(s, i) == NULL) { /* connection failed. mark this backend down */
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pool_error("new_connection: create_cp() failed"); /* If fail_over_
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>                                                       ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [Message clipped]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://blogs.enterprisedb.com/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended for the use of the individual or entity to whom it is addressed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Venkatesulu.J.D
>>>>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> US: +1-732-331-1320  - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This e-mail message (and any attachment) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended for the use of the individual or entity to whom it is addressed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message**.*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>>>>>>>>> Venkatesulu.J.D
>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  To reach Support Call:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> US: +1-732-331-1320  - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-30589491
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> *This e-mail message (and any attachment) is
>>>>>>>>>>>>>>>>>>>>>>>>> intended for the use of the individual or entity to whom it is addressed.
>>>>>>>>>>>>>>>>>>>>>>>>> This message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message**.*
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended
>>>>>>>>>>>>>>>>>>>>>>> for the use of the individual or entity to whom it is addressed. This
>>>>>>>>>>>>>>>>>>>>>>> message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>>>>>> Baji Shaik,
>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation,
>>>>>>>>>>>>>>>>>>>>>> The Postgres Database Company.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> To reach Support Call:
>>>>>>>>>>>>>>>>>>>>>> US +1-732-331-1320 or 1-800-235-5891
>>>>>>>>>>>>>>>>>>>>>> UK +44-2033 7198 20 - BRAZIL+55-2129 5813 71 - INDIA
>>>>>>>>>>>>>>>>>>>>>> +91-20-32677197.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>>>>>> Follow us on Twitter :
>>>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended
>>>>>>>>>>>>>>>>>>>>>> for the use of the individual or entity to whom it is addressed. This
>>>>>>>>>>>>>>>>>>>>>> message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution,retention,
>>>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended
>>>>>>>>>>>>>>>>>>>> for the use of the individual or entity to whom it is addressed. This
>>>>>>>>>>>>>>>>>>>> message contains information from EnterpriseDB Corporation that may be
>>>>>>>>>>>>>>>>>>>> privileged, confidential, or exempt from disclosure under applicable law.
>>>>>>>>>>>>>>>>>>>> If you are not the intended recipient or authorized to receive this for the
>>>>>>>>>>>>>>>>>>>> intended recipient, any use, dissemination, distribution, retention,
>>>>>>>>>>>>>>>>>>>> archiving, or copying of this communication is strictly prohibited. If you
>>>>>>>>>>>>>>>>>>>> have received this e-mail in error, please notify the sender immediately by
>>>>>>>>>>>>>>>>>>>> reply e-mail and delete this message.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>>>>>>>>>>> Follow us on Twitter:
>>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended for
>>>>>>>>>>>>>>>>>>> the use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>>>>> Baji Shaik,
>>>>>>>>>>>>>>>>>> EnterpriseDB Corporation,
>>>>>>>>>>>>>>>>>> The Postgres Database Company.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To reach Support Call:
>>>>>>>>>>>>>>>>>> US +1-732-331-1320 or 1-800-235-5891
>>>>>>>>>>>>>>>>>> UK +44-2033 7198 20 - BRAZIL+55-2129 5813 71 - INDIA
>>>>>>>>>>>>>>>>>> +91-20-32677197.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>>>>>>>>>>>>>>>>> Follow us on Twitter :
>>>>>>>>>>>>>>>>>> http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended for
>>>>>>>>>>>>>>>>>> the use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>>>>>>> recipient, any use, dissemination, distribution,retention, archiving, or
>>>>>>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended for
>>>>>>>>>>>>>>>>> the use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Arshu Arora
>>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>>> The Postgres Database Company
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To reach Support Call:
>>>>>>>>>>>>>>> US: +1-732-331-1320  - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-32676535
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>>>>>>>>>>>>>> Follow us on Twitter : http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended for the
>>>>>>>>>>>>>>> use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>>>> recipient, any use, dissemination, distribution,retention, archiving, or
>>>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This e-mail message (and any attachment) is intended for the
>>>>>>>>>>>>>> use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  --
>>>>>>>>>>>> Ahsan Hadi
>>>>>>>>>>>> Snr Director Product Development
>>>>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>>>>> The Enterprise Postgres Company
>>>>>>>>>>>>
>>>>>>>>>>>> Phone: +92-51-8358874
>>>>>>>>>>>> Mobile: +92-333-5162114
>>>>>>>>>>>>
>>>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>>>
>>>>>>>>>>>> This e-mail message (and any attachment) is intended for the
>>>>>>>>>>>> use of the individual or entity to whom it is addressed. This message
>>>>>>>>>>>> contains information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>>>> and delete this message.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Arshu Arora
>>>>>>>>> EnterpriseDB Corporation
>>>>>>>>> The Postgres Database Company
>>>>>>>>>
>>>>>>>>> To reach Support Call:
>>>>>>>>> US: +1-732-331-1320  - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>>> Brazil: +55-2139581371 - India: +91-20-32676535
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>>>>>>>> Follow us on Twitter : http://www.twitter.com/enterprisedb
>>>>>>>>>
>>>>>>>>> This e-mail message (and any attachment) is intended for the use
>>>>>>>>> of the individual or entity to whom it is addressed. This message contains
>>>>>>>>> information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>> recipient, any use, dissemination, distribution,retention, archiving, or
>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>> and delete this message.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Arshu Arora
>>>>>>>> EnterpriseDB Corporation
>>>>>>>> The Postgres Database Company
>>>>>>>>
>>>>>>>> To reach Support Call:
>>>>>>>> US: +1-732-331-1320  - UK: +44 - 2033719820<%2B44%20-%202033719820>
>>>>>>>> Brazil: +55-2139581371 - India: +91-20-32676535
>>>>>>>>
>>>>>>>>
>>>>>>>> Website: www.enterprisedb.com
>>>>>>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>>>>>>> Follow us on Twitter : http://www.twitter.com/enterprisedb
>>>>>>>>
>>>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>>>> the individual or entity to whom it is addressed. This message contains
>>>>>>>> information from EnterpriseDB Corporation that may be privileged,
>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>> recipient, any use, dissemination, distribution,retention, archiving, or
>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>> and delete this message.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>> Thanks & Regards,
>>>>>>> Deepanshu Sharma
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> Tom Kincaid
>>>>>> Vice President Products and Engineering
>>>>>>
>>>>>>
>>>>>> The Postgres Database Company
>>>>>> 2013 HP AllianceOne Partner of the Year Mission Critical Computing
>>>>>> Category
>>>>>> c: 978-828-6006
>>>>>> o:781-357-3209
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Ahsan Hadi
>>>>> Snr Director Product Development
>>>>> EnterpriseDB Corporation
>>>>> The Enterprise Postgres Company
>>>>>
>>>>> Phone: +92-51-8358874
>>>>> Mobile: +92-333-5162114
>>>>>
>>>>> Website: www.enterprisedb.com
>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>
>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>> the individual or entity to whom it is addressed. This message contains
>>>>> information from EnterpriseDB Corporation that may be privileged,
>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>> not the intended recipient or authorized to receive this for the intended
>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>> copying of this communication is strictly prohibited. If you have received
>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>> and delete this message.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Arshu Arora
>>>> EnterpriseDB Corporation
>>>> The Postgres Database Company
>>>>
>>>> Are you updated: Latest version of Postgres Plus Advanced Servers
>>>> 9.2.5.13-1, 9.1.10.17-1.
>>>>
>>>>  To reach Support Call:
>>>> US: +1-732-331-1320  - UK: +44 - 2033719820
>>>> Brazil: +55-2139581371 - India: +91-20-32676535
>>>>
>>>>
>>>> Website: www.enterprisedb.com
>>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>>> Follow us on Twitter : http://www.twitter.com/enterprisedb
>>>>
>>>> This e-mail message (and any attachment) is intended for the use of the
>>>> individual or entity to whom it is addressed. This message contains
>>>> information from EnterpriseDB Corporation that may be privileged,
>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>> not the intended recipient or authorized to receive this for the intended
>>>> recipient, any use, dissemination, distribution,retention, archiving, or
>>>> copying of this communication is strictly prohibited. If you have received
>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>> and delete this message.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Arshu Arora
>>> EnterpriseDB Corporation
>>> The Postgres Database Company
>>>
>>> Are you updated: Latest version of Postgres Plus Advanced Servers
>>> 9.2.5.13-1, 9.1.10.17-1.
>>>
>>> To reach Support Call:
>>> US: +1-732-331-1320  - UK: +44 - 2033719820
>>> Brazil: +55-2139581371 - India: +91-20-32676535
>>>
>>>
>>> Website: www.enterprisedb.com
>>> EnterpriseDB Blog : http://blogs.enterprisedb.com
>>> Follow us on Twitter : http://www.twitter.com/enterprisedb
>>>
>>> This e-mail message (and any attachment) is intended for the use of the
>>> individual or entity to whom it is addressed. This message contains
>>> information from EnterpriseDB Corporation that may be privileged,
>>> confidential, or exempt from disclosure under applicable law. If you are
>>> not the intended recipient or authorized to receive this for the intended
>>> recipient, any use, dissemination, distribution,retention, archiving, or
>>> copying of this communication is strictly prohibited. If you have received
>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>> and delete this message.
>>>
>>>
>>
>>
>> --
>> Ahsan Hadi
>> Snr Director Product Development
>> EnterpriseDB Corporation
>> The Enterprise Postgres Company
>>
>> Phone: +92-51-8358874
>> Mobile: +92-333-5162114
>>
>> Website: www.enterprisedb.com
>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>
>> This e-mail message (and any attachment) is intended for the use of the
>> individual or entity to whom it is addressed. This message contains
>> information from EnterpriseDB Corporation that may be privileged,
>> confidential, or exempt from disclosure under applicable law. If you are
>> not the intended recipient or authorized to receive this for the intended
>> recipient, any use, dissemination, distribution, retention, archiving, or
>> copying of this communication is strictly prohibited. If you have received
>> this e-mail in error, please notify the sender immediately by reply e-mail
>> and delete this message.
>>
>
>
>
> --
>
> Thanks & Regards,
> Sivananda Reddy,
> EnterpriseDB Corporation,
> The Postgres Database Company.
>
> Are you updated: Latest version of Postgres Plus Advanced Servers
> 9.2.5.13-1, 9.1.10.17-1.
>
> To reach Support Call:
> US +1-732-331-1320 or 1-800-235-5891
>  UK +44-2033 7198 20 - BRAZIL+55-2129 5813 71 - INDIA+91-20-32677197.
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog : http://blogs.enterprisedb.com
> Follow us on Twitter : http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of the
> individual or entity to whom it is addressed. This message contains
> information from EnterpriseDB Corporation that may be privileged,
> confidential, or exempt from disclosure under applicable law. If you are
> not the intended recipient or authorized to receive this for the intended
> recipient, any use, dissemination, distribution,retention, archiving, or
> copying of this communication is strictly prohibited. If you have received
> this e-mail in error, please notify the sender immediately by reply e-mail
> and delete this message.
>



-- 
Ahsan Hadi
Snr Director Product Development
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +92-51-8358874
Mobile: +92-333-5162114

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.



-- 
Ahsan Hadi
Snr Director Product Development
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +92-51-8358874
Mobile: +92-333-5162114

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20131120/4fc2a965/attachment-0001.html>


More information about the pgpool-hackers mailing list