On Thu, Sep 15, 2011 at 11:58 AM, Lonni J Friedman wrote:
> On Thu, Sep 15, 2011 at 8:57 AM, Johnny Tan wrote:
>> Lonni, given how easy pgbouncer is to setup, it may be worth doing a
>> quick proof-of-concept with it and see if you get similar EOF errors
>> there. If so, I think that would elimin
On Thu, Sep 15, 2011 at 8:57 AM, Johnny Tan wrote:
> On Wed, Sep 14, 2011 at 9:12 PM, Lonni J Friedman wrote:
>> On Wed, Sep 14, 2011 at 6:00 PM, Tatsuo Ishii wrote:
On Wed, Sep 14, 2011 at 4:22 PM, Tatsuo Ishii wrote:
I'm pretty sure that's not the case as the messages stop whene
On Wed, Sep 14, 2011 at 9:12 PM, Lonni J Friedman wrote:
> On Wed, Sep 14, 2011 at 6:00 PM, Tatsuo Ishii wrote:
>>> On Wed, Sep 14, 2011 at 4:22 PM, Tatsuo Ishii wrote:
>>> I'm pretty sure that's not the case as the messages stop whenever
>>> pgpool isn't running, they were not present p
On Wed, Sep 14, 2011 at 6:00 PM, Tatsuo Ishii wrote:
>> On Wed, Sep 14, 2011 at 4:22 PM, Tatsuo Ishii wrote:
>> I'm pretty sure that's not the case as the messages stop whenever
>> pgpool isn't running, they were not present prior to using pgpool, and
>> pg_hba.conf is setup such that
> On Wed, Sep 14, 2011 at 4:22 PM, Tatsuo Ishii wrote:
> I'm pretty sure that's not the case as the messages stop whenever
> pgpool isn't running, they were not present prior to using pgpool, and
> pg_hba.conf is setup such that the database servers only accept
> connections from e
On Wed, Sep 14, 2011 at 4:22 PM, Tatsuo Ishii wrote:
I'm pretty sure that's not the case as the messages stop whenever
pgpool isn't running, they were not present prior to using pgpool, and
pg_hba.conf is setup such that the database servers only accept
connections from each ot
>>> I'm pretty sure that's not the case as the messages stop whenever
>>> pgpool isn't running, they were not present prior to using pgpool, and
>>> pg_hba.conf is setup such that the database servers only accept
>>> connections from each other, and the server running pgpool. None of
>>> these ser
On Wed, Sep 14, 2011 at 3:56 PM, Tatsuo Ishii wrote:
>> On Tue, Sep 13, 2011 at 8:48 PM, Tatsuo Ishii wrote:
On Mon, Sep 12, 2011 at 6:47 PM, Lonni J Friedman
wrote:
> On Mon, Sep 12, 2011 at 6:39 PM, Tatsuo Ishii wrote:
I couldn't find anything possibly related to your
> On Tue, Sep 13, 2011 at 8:48 PM, Tatsuo Ishii wrote:
>>> On Mon, Sep 12, 2011 at 6:47 PM, Lonni J Friedman
>>> wrote:
On Mon, Sep 12, 2011 at 6:39 PM, Tatsuo Ishii wrote:
>>> I couldn't find anything possibly related to your problem at a first
>>> grance(in theory client_idle_lim
On Tue, Sep 13, 2011 at 8:48 PM, Tatsuo Ishii wrote:
>> On Mon, Sep 12, 2011 at 6:47 PM, Lonni J Friedman wrote:
>>> On Mon, Sep 12, 2011 at 6:39 PM, Tatsuo Ishii wrote:
>> I couldn't find anything possibly related to your problem at a first
>> grance(in theory client_idle_limit and auth
> On Mon, Sep 12, 2011 at 6:47 PM, Lonni J Friedman wrote:
>> On Mon, Sep 12, 2011 at 6:39 PM, Tatsuo Ishii wrote:
> I couldn't find anything possibly related to your problem at a first
> grance(in theory client_idle_limit and authentication_timeout are not
> related but you might wan
On Mon, Sep 12, 2011 at 6:47 PM, Lonni J Friedman wrote:
> On Mon, Sep 12, 2011 at 6:39 PM, Tatsuo Ishii wrote:
I couldn't find anything possibly related to your problem at a first
grance(in theory client_idle_limit and authentication_timeout are not
related but you might want to c
On Mon, Sep 12, 2011 at 6:39 PM, Tatsuo Ishii wrote:
>>> I couldn't find anything possibly related to your problem at a first
>>> grance(in theory client_idle_limit and authentication_timeout are not
>>> related but you might want to change them to see anything could be
>>> changed).
>>
>> OK, I'l
>> I couldn't find anything possibly related to your problem at a first
>> grance(in theory client_idle_limit and authentication_timeout are not
>> related but you might want to change them to see anything could be
>> changed).
>
> OK, I'll give that a try. Should I just try increasing them by 10
On Mon, Sep 12, 2011 at 5:14 PM, Tatsuo Ishii wrote:
>> On Mon, Sep 12, 2011 at 4:16 PM, Tatsuo Ishii wrote:
Yes, all connections defined in pool_hba.conf are trust auth.
However, I also have
health_check_period = 0
in pgpool.conf, so I'd assume that no health checks are being
> On Mon, Sep 12, 2011 at 4:16 PM, Tatsuo Ishii wrote:
>>> Yes, all connections defined in pool_hba.conf are trust auth.
>>> However, I also have
>>> health_check_period = 0
>>> in pgpool.conf, so I'd assume that no health checks are being performed?
>>
>> Have you changed child_life_time or somet
On Mon, Sep 12, 2011 at 4:16 PM, Tatsuo Ishii wrote:
>> Yes, all connections defined in pool_hba.conf are trust auth.
>> However, I also have
>> health_check_period = 0
>> in pgpool.conf, so I'd assume that no health checks are being performed?
>
> Have you changed child_life_time or something fro
> Yes, all connections defined in pool_hba.conf are trust auth.
> However, I also have
> health_check_period = 0
> in pgpool.conf, so I'd assume that no health checks are being performed?
Have you changed child_life_time or something from defaults? I would
like to take a look at your pgpool.conf.
On Mon, Sep 12, 2011 at 3:34 AM, Toshihiro Kitagawa
wrote:
> Hi,
>
>> However, I'm see tons (dozens every minute) of the
>> following in my postgresql server logs:
>> LOG: unexpected EOF on client connection
>
> I found recently that it occurs if you specify the role that needs a
> password to he
Hi,
> However, I'm see tons (dozens every minute) of the
> following in my postgresql server logs:
> LOG: unexpected EOF on client connection
I found recently that it occurs if you specify the role that needs a
password to health_check_user.
Is your health_check_user trust authentication?
--
On Sun, Sep 4, 2011 at 5:36 PM, Rosser Schwarz wrote:
> "Unexpected EOF" doesn't mean a postgres backend is failing; it
> typically means that a client has disconnected from its backend
> without closing out the session. (E.g., connect via psql, then kill
> the psql process -- not the backend! --
"Unexpected EOF" doesn't mean a postgres backend is failing; it
typically means that a client has disconnected from its backend
without closing out the session. (E.g., connect via psql, then kill
the psql process -- not the backend! -- and you'll see an "Unexpected
EOF".)
As for why you're only s
Thanks for your reply. That doesn't appear to be the problem. While
logged onto the server where pgpool is running, I can successfully
invoke psql to connect directly to both of the standby servers (using
port 5432). Also, I'm not seeing any errors in the pgpool log, where
I'd expect to see some
No one has any ideas or suggestions?
On Fri, Sep 2, 2011 at 6:44 PM, Lonni J Friedman wrote:
> Greetings,
> I just deployed a postgresql-9.0.4 cluster (1 master, 2 hot
> standby's), with pgpool-II-3.0.4 (all running on Linux-x86_64
> servers). I'm currently only using pgpool for load balancing,
24 matches
Mail list logo
