Обсуждение: client conx problems, 7.3.2

Folks,

I'm getting this on large inserts when connecting via perl's DBD::Pg using
on *both* hostssl and host access methods:

Feb 26 10:57:23 scylla postgres[25273]: [1] LOG:  connection received:
host=127.0.0.1 port=35399
Feb 26 10:57:23 scylla postgres[25273]: [2] LOG:  connection authorized:
user=xxxx database=xxxx
Feb 26 10:57:46 scylla postgres[25273]: [3] LOG:  SSL renegotiation
failure
Feb 26 10:57:46 scylla postgres[25273]: [4] LOG:  SSL error: unexpected
record
Feb 26 10:57:46 scylla postgres[25273]: [5] LOG:  pq_flush: send() failed:
Connection reset by peer
Feb 26 10:57:46 scylla postgres[25273]: [6] FATAL:  Socket command type ^V
unknown

Not sure why I'd even see such a thing over an unencrypted host auth,
especially after removing any possible hostssl access and restarting
posgresql.

Also, when autocommit is off, it happens sooner and more often.  When it's
on, still happens, but less often.

(Linux, static binaries, i686, from source, RedHat 8.0.)

Thanks,
RC

Randy Cone
Horn Point Laboratory
University of Maryland Center for Environmental Science
phone#: 410-221-8330    fax#:410-221-8490

Randy Cone <cone@hpl.umces.edu> writes:
> I'm getting this on large inserts when connecting via perl's DBD::Pg using
> on *both* hostssl and host access methods:

> Feb 26 10:57:23 scylla postgres[25273]: [1] LOG:  connection received:
> host=127.0.0.1 port=35399
> Feb 26 10:57:23 scylla postgres[25273]: [2] LOG:  connection authorized:
> user=xxxx database=xxxx
> Feb 26 10:57:46 scylla postgres[25273]: [3] LOG:  SSL renegotiation
> failure

You sure you are on 7.3.2 --- at both ends?  This looks like the problem
allegedly fixed by this patch:

2003-01-08 18:18  momjian

    * src/: backend/libpq/be-secure.c, interfaces/libpq/fe-secure.c
    (REL7_3_STABLE), backend/libpq/be-secure.c,
    interfaces/libpq/fe-secure.c: The second was that renegotiation was
    just plain broken.  I can't believe I didn't notice this before --
    once 64k was sent to/from the server the client would crash.
    Basicly, in 7.3 the server SSL code set the initial state to "about
    to renegotiate" without actually starting the renegotiation.  In
    addition, the server and client didn't properly handle the
    SSL_ERROR_WANT_(READ|WRITE) error.  This is fixed in the second
    patch.

    Nathan Mueller

which is in 7.3.2 but not earlier releases.

I dunno anything about SSL, so if it is still broken I can't help
... but you could try Nathan Mueller ...

            regards, tom lane

On Wed, 26 Feb 2003, Tom Lane wrote:

> Randy Cone <cone@hpl.umces.edu> writes:
> > I'm getting this on large inserts when connecting via perl's DBD::Pg using

[...]

> You sure you are on 7.3.2 --- at both ends?  This looks like the problem
> allegedly fixed by this patch:
>

[...]

>     Nathan Mueller
>
> which is in 7.3.2 but not earlier releases.
>
> I dunno anything about SSL, so if it is still broken I can't help
> ... but you could try Nathan Mueller ...

Tom,

Yes, just checked client and server versions!

Thanks for your quick reply!  Actually, the aforementioned problem was
much worse in 7.3.1, and I thought is was fixed in the current version.
However, after about 200,000 insertions what seems to be the same problem
shows up again.

What's particularly irksome is that this happens even when no SSL is
supposed to be used at all, i.e. simple tcp/ip host based client connect.

RC

Randy Cone <cone@hpl.umces.edu> writes:
> What's particularly irksome is that this happens even when no SSL is
> supposed to be used at all, i.e. simple tcp/ip host based client connect.

Hard to see how that could happen, unless some SSL logic has snuck into
the non-SSL code path --- but then I'd expect it to fail immediately.

Are you sure you turned off SSL? (I am not sure it's possible to do that
just by altering pg_hba.conf --- you can force SSL that way, but not
forbid it.)

            regards, tom lane

On Wed, 26 Feb 2003, Tom Lane wrote:

> Are you sure you turned off SSL? (I am not sure it's possible to do that
> just by altering pg_hba.conf --- you can force SSL that way, but not
> forbid it.)

Ah, my mistake.  I was wrong in thinking going from hostssl to host
in pg_hba.conf would force non-SSL conx.  I'm trying this large population
of points using Unix domain sockets now, then will try to force non-SSL
host based conx later.

Thanks again,
RC

Tom Lane wrote:
> Randy Cone <cone@hpl.umces.edu> writes:
> > What's particularly irksome is that this happens even when no SSL is
> > supposed to be used at all, i.e. simple tcp/ip host based client connect.
>
> Hard to see how that could happen, unless some SSL logic has snuck into
> the non-SSL code path --- but then I'd expect it to fail immediately.
>
> Are you sure you turned off SSL? (I am not sure it's possible to do that
> just by altering pg_hba.conf --- you can force SSL that way, but not
> forbid it.)

This is a known SSL issue, that if the client and server support SSL,
they use it even if you don't have SSL configured in pg_hba.conf.  We
had that discussion about allowing folks to control that from the client
and server and a few months ago.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073