| From: | Josh berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us>, Euler Taveira <euler(at)timbira(dot)com(dot)br> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Devrim Gunduz <devrim(at)gunduz(dot)org>, pgsql-advocacy <pgsql-advocacy(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Subject: | Re: 9.6 -> 10.0 |
| Date: | 2016-05-13 20:45:04 |
| Message-ID: | 57363CD0.2030602@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-advocacy |
On 05/13/2016 01:41 PM, Bruce Momjian wrote:
> On Thu, May 12, 2016 at 02:07:04PM -0300, Euler Taveira wrote:
>> On 12-05-2016 13:09, Bruce Momjian wrote:
>>> That is an interesting approach. How many applications are prepared to
>>> re-sent a transaction block based on the error returned by pgbouncer in
>>> this case?
>>>
>> FYI, pgBouncer does not error out transactions. While in PAUSE mode,
>> pgBouncer waits for the current transactions to finish and the new ones
>> are put in a wait queue. After the RESUME command, pgBouncer sends the
>> transaction in the wait queue. Of course, if your application has a
>> response timeout you will see cancellations.
>
> Oh, that seems useful.
>
The missing feature is that you can never forceably terminate the
connections to the old master without restarting pgbouncer. And if you
just shut down the old database server, with some clients still
connected, pgbouncer goes into "error mode" and starts denying some
legit connections. So there's still work to be done here.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Damien Clochard | 2016-05-13 22:15:28 | Re: 20th anniversary posters |
| Previous Message | Bruce Momjian | 2016-05-13 20:41:23 | Re: 9.6 -> 10.0 |