[pgpool-hackers: 420] Re: Fwd: Issue: about redundancy of pgpool-II, Ticket# 15058-20802, Customer: SIOS Engineers, Account: SIOS Technology, Inc.
Tatsuo Ishii
ishii at postgresql.org
Wed Nov 20 23:40:05 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?
Each pgpool process creates connections to not only master but
slaves. Clients feel free to send read and write queries. If a query
is a writing one, it should be sent to master. If a query is reading
one, it might be sent to slave because of load balancing. After all,
you cannot say "this client connects to master (only)".
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> -- 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.
More information about the pgpool-hackers
mailing list