El día Montag, Mai 11, 2020 a las 02:41:29 -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > Below is the exchange. The visible strings are: 'sisis' (the PG user),
> > 'sisis123' (its password in PG, a dummy password used for testing) and
> > 'srap32dxr1' the hostname. The server is terminat
El día Montag, Mai 11, 2020 a las 02:41:29 -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > Below is the exchange. The visible strings are: 'sisis' (the PG user),
> > 'sisis123' (its password in PG, a dummy password used for testing) and
> > 'srap32dxr1' the hostname. The server is terminat
Matthias Apitz writes:
> Below is the exchange. The visible strings are: 'sisis' (the PG user),
> 'sisis123' (its password in PG, a dummy password used for testing) and
> 'srap32dxr1' the hostname. The server is terminating the connection with
> a F-pkg:
[ squint... ] That looks nothing like a P
El día Montag, Mai 11, 2020 a las 06:24:52 +0200, Matthias Apitz escribió:
> Ah, yes. As this is just a dev host only, I set 'chmod 4755 /usr/bin/lsof'
> and now I see, the connecting client is one of our Java tools and I can
> look at the problem from this side.
>
With the knowledge which Java
El día Montag, Mai 11, 2020 a las 09:50:12 -0400, Tom Lane escribió:
>
> > postmaste 14622 postgres9u IPv4 131903453 0t0 TCP
> > srap32dxr1.dev.oclc.org:5432->srap32dxr1.dev.oclc.org:44836 (ESTABLISHED)
>
> OK, so it's gotten a TCP not Unix-socket connection; that's already
Matthias Apitz writes:
> I launched a shell script to get some more information in this case:
ok
> The process with the PID in question is 'postmaster':
Yeah, this should actually be a newly-forked postmaster child process,
but it won't have done anything yet to change its ps-visible command
li
El día Sonntag, Mai 10, 2020 a las 11:33:41 -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > 1. In addition to the above code, can I get somehow the connecting client's
> > PID? If
>
> Not in any portable way. If you believe that the offending client is on
> the local system, you could t
Matthias Apitz writes:
> 1. In addition to the above code, can I get somehow the connecting client's
> PID? If
Not in any portable way. If you believe that the offending client is on
the local system, you could try building something involving netstat,
lsof, etc. getpeereid() might be useful t
El día Dienstag, April 28, 2020 a las 10:10:18 +0200, Matthias Apitz escribió:
>
> I've added the proposed log line to the server code in
> src/backend/libpq/pqcomm.c
> and restarted the server with this. In the log file
> /data/postgresql11/data/serverlog
> are other messages about length of p
El día martes, mayo 05, 2020 a las 04:18:02p. m. -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > El día lunes, abril 27, 2020 a las 09:40:39a. m. -0400, Tom Lane escribió:
> >> If you're in a position to run a modified server, you could try
> >> inserting a debug log message:
>
> > I've a
Matthias Apitz writes:
> El día lunes, abril 27, 2020 a las 09:40:39a. m. -0400, Tom Lane escribió:
>> If you're in a position to run a modified server, you could try
>> inserting a debug log message:
> I've added the printout of the length in this case and another one, and
> see this in the serv
El día lunes, abril 27, 2020 a las 09:40:39a. m. -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > El día Montag, April 27, 2020 a las 08:40:04 -0400, Tom Lane escribió:
> >> Can you get a stack trace from the connected backend?
>
> > (gdb) bt
> > #0 0x7fd567776000 in epoll_pwait () fr
I've added the proposed log line to the server code in
src/backend/libpq/pqcomm.c
and restarted the server with this. In the log file
/data/postgresql11/data/serverlog
are other messages about length of packages, like:
2020-04-28 09:49:49.877 CEST [16229] LOG: invalid length of startup packet
Matthias Apitz writes:
> As the client seems to be waiting on the server and the server on the
> client... could it have been caused by this in /etc/hosts (what our IT
> department configured):
Doubt it. Your connection evidently got through (at least) the
authentication exchange, so basic data
Matthias Apitz writes:
> El día Montag, April 27, 2020 a las 08:40:04 -0400, Tom Lane escribió:
>> Can you get a stack trace from the connected backend?
> (gdb) bt
> #0 0x7fd567776000 in epoll_pwait () from /lib64/libc.so.6
> #1 0x0084476c in WaitEventSetWaitBlock ()
> #2 0x000
As the client seems to be waiting on the server and the server on the
client... could it have been caused by this in /etc/hosts (what our IT
department configured):
/etc/hosts:
127.0.0.1 localhost
# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback
i.e. the
El día Montag, April 27, 2020 a las 08:40:04 -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > I encounter from time to time that one of our ESQL/C clients hangs with
> > the details described below for ever, while accessing on startup a table
> > 'sisisinst' which has only some 50 rows, al
Matthias Apitz writes:
> I encounter from time to time that one of our ESQL/C clients hangs with
> the details described below for ever, while accessing on startup a table
> 'sisisinst' which has only some 50 rows, all of CHAR columns. Other ESQL/C
> clients
> start up fine (they all check this
Hello,
I encounter from time to time that one of our ESQL/C clients hangs with
the details described below for ever, while accessing on startup a table
'sisisinst' which has only some 50 rows, all of CHAR columns. Other ESQL/C
clients
start up fine (they all check this table 'sisisinst' on sta
19 matches
Mail list logo
