[pgpool-hackers: 423] Re: Fwd: Issue: about redundancy of pgpool-II, Ticket# 15058-20802, Customer: SIOS Engineers, Account: SIOS Technology, Inc.
Tatsuo Ishii
ishii at postgresql.org
Fri Nov 22 00:09:27 JST 2013
> On Wed, Nov 20, 2013 at 7:40 PM, Tatsuo Ishii <ishii at postgresql.org> wrote:
>
>> > 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)".
>>
>
> So if your client is connected to the master and you kill the slave node
> and then do a write query, should that execute fine even if the failover
> operation is in process? Attached is my pgpool configuration file, if i
> create a edb-psql connection through pgpool..
>
> edb=# show pool_nodes;
> node_id | hostname | port | status | lb_weight | role
> ---------+-----------+------+--------+-----------+--------
> 0 | localhost | 5444 | 2 | 0.500000 | master
> 1 | localhost | 5555 | 2 | 0.500000 | slave
> (2 rows)
>
> edb=# select version;
> version
>
> ----------------------------------------------------------------------------------------------------------------
> EnterpriseDB 9.4.0.0 on x86_64-unknown-linux-gnu, compiled by gcc
> (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3, 64-bit
> (1 row)
>
> As you can see, I am connected to the master node.
>
> I go ahead and kill the slave node then i do a insert query and i get a
> server closed message as shown below.
>
> edb=# insert into foo values (123);
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !>
>
> Is that expected?
Yes, because the pgpool child process was terminated by the failover
event triggered by that the slave was killed by you.
--
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.
>>
>
>
>
> --
> 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