Обсуждение: Cannot reach pg server using -h localhost
Hi,
From the terminal in Mac OS X Yosemite, connecting to homebrew
installed 9.4.4, I have a problem if I specify the host (I know this
comes up all the time, bear with me as I have done a fair amount of
digging already). This works:
psql -Umyuser -d mydb
sql (9.3.5)
Type "help" for help.
myuser=#
Server log shows:
[unknown] LOG: connection received: host=[local]
myuser [local]LOG: connection authorized: user=myuser database=myuser
So that's all good. If I use -h it doesn't work:
psql -Umyuser -d mydb -h localhost
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Server log:
[unknown] LOG: connection received: host=::1 port=51186
(... and that's it, no connection authorized line)
I've checked the normal things people suggest, e.g. postgresql.conf:
listen_addresses = 'localhost' # also '*', '127.0.0.1', '::1'
port = 5432
and pg_hba.conf:
# IPv4 local connections:
host all all 127.0.0.1/32 trust
host all all localhost trust
# IPv6 local connections:
host all all ::1/128 trust
And psql and pg_ctl are pointing to the same installations:
~ which psql
/usr/local/bin/psql
~ ll /usr/local/bin/psql
/usr/local/bin/psql -> ../Cellar/postgresql/9.4.4/bin/psql
~ which pg_ctl
/usr/local/bin/pg_ctl
~ ll /usr/local/bin/pg_ctl
/usr/local/bin/pg_ctl -> ../Cellar/postgresql/9.4.4/bin/pg_ctl
People have suggested checking for stuff on my machine that could
close connections. The Mac OS firewall is off and so is pf (Mac OS
packet filter).
This is all after upgrading (I had the same problem with 9.3.5) and
reinstalling.
Anyone got more clues for me?
Regards,
Fritz
On 07/21/2015 10:09 AM, Fritz Meissner wrote: > Hi, > >From the terminal in Mac OS X Yosemite, connecting to homebrew > installed 9.4.4, I have a problem if I specify the host (I know this > comes up all the time, bear with me as I have done a fair amount of > digging already). This works: > > psql -Umyuser -d mydb > sql (9.3.5) > Type "help" for help. > > myuser=# > > Server log shows: > > [unknown] LOG: connection received: host=[local] > myuser [local]LOG: connection authorized: user=myuser database=myuser > > So that's all good. If I use -h it doesn't work: > > psql -Umyuser -d mydb -h localhost > psql: server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > > Server log: > > [unknown] LOG: connection received: host=::1 port=51186 > (... and that's it, no connection authorized line) So what happens if you do?: psql -U myuser -d mydb -h 127.0.0.1 > > I've checked the normal things people suggest, e.g. postgresql.conf: > > listen_addresses = 'localhost' # also '*', '127.0.0.1', '::1' > port = 5432 > > and pg_hba.conf: > > # IPv4 local connections: > host all all 127.0.0.1/32 trust > host all all localhost trust > # IPv6 local connections: > host all all ::1/128 trust > > And psql and pg_ctl are pointing to the same installations: > > ~ which psql > /usr/local/bin/psql > ~ ll /usr/local/bin/psql > /usr/local/bin/psql -> ../Cellar/postgresql/9.4.4/bin/psql > ~ which pg_ctl > /usr/local/bin/pg_ctl > ~ ll /usr/local/bin/pg_ctl > /usr/local/bin/pg_ctl -> ../Cellar/postgresql/9.4.4/bin/pg_ctl > > People have suggested checking for stuff on my machine that could > close connections. The Mac OS firewall is off and so is pf (Mac OS > packet filter). > > This is all after upgrading (I had the same problem with 9.3.5) and > reinstalling. > > Anyone got more clues for me? > > Regards, > Fritz > > -- Adrian Klaver adrian.klaver@aklaver.com
> So that's all good. If I use -h it doesn't work: > > psql -Umyuser -d mydb -h localhost > listen_addresses = 'localhost' # also '*', '127.0.0.1', '::1' Use netstat to look what IP postgres actually binds to. OS X uses the BSD syntax: netstat -an For example on my Mac (not homebrew): tcp4 0 0 127.0.0.1.5432 *.* LISTEN tcp6 0 0 ::1.5432 *.* LISTEN Bye, Chris.
On 07/21/2015 10:40 AM, Fritz Meissner wrote: CCing list > On Tue, Jul 21, 2015 at 7:30 PM, Adrian Klaver > <adrian.klaver@aklaver.com> wrote: > >> So what happens if you do?: >> >> psql -U myuser -d mydb -h 127.0.0.1 >> > > Same thing. Pause for about 30 seconds and then "server closed the > connection unexpectedly". Server log just shows: > > [unknown] LOG: connection received: host=127.0.0.1 port=51919 > So what is in your hosts file? -- Adrian Klaver adrian.klaver@aklaver.com
> Use netstat to look what IP postgres actually binds to. Nothing unusual: ~ netstat -an | grep 5432 tcp4 0 0 *.5432 *.* LISTEN tcp6 0 0 *.5432 *.* LISTEN 9767b1c9fd5d8ab1 stream 0 0 9767b1ca01d63a21 0 0 0 /tmp/.s.PGSQL.5432
Hosts file: 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost On Tue, Jul 21, 2015 at 7:42 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > On 07/21/2015 10:40 AM, Fritz Meissner wrote: > > CCing list >> >> On Tue, Jul 21, 2015 at 7:30 PM, Adrian Klaver >> <adrian.klaver@aklaver.com> wrote: >> >>> So what happens if you do?: >>> >>> psql -U myuser -d mydb -h 127.0.0.1 >>> >> >> Same thing. Pause for about 30 seconds and then "server closed the >> connection unexpectedly". Server log just shows: >> >> [unknown] LOG: connection received: host=127.0.0.1 port=51919 >> > > So what is in your hosts file? > > -- > Adrian Klaver > adrian.klaver@aklaver.com
>> Use netstat to look what IP postgres actually binds to. > > Nothing unusual: > > ~ netstat -an | grep 5432 > tcp4 0 0 *.5432 *.* LISTEN > tcp6 0 0 *.5432 *.* LISTEN > 9767b1c9fd5d8ab1 stream 0 0 9767b1ca01d63a21 > 0 0 0 /tmp/.s.PGSQL.5432 > and if you have it listen to 127.0.0.1, you see 127.0.0.1 in netstat? and psql -h 127.0.0.1 still fails? is lo0 still there (ifconfig)? Bye, Chris.
Fritz Meissner <fritz.meissner@gmail.com> writes: >> From the terminal in Mac OS X Yosemite, connecting to homebrew > installed 9.4.4, I have a problem if I specify the host (I know this > comes up all the time, bear with me as I have done a fair amount of > digging already). This works: This rang a bell with me, and a bit of digging found this thread: http://www.postgresql.org/message-id/flat/6804.1413911806@sss.pgh.pa.us While that's not the same symptom you're describing, it does point up that OS X will expand "localhost" as pretty much "whatever it says in /etc/hosts". You might want to make sure that that expansion is sane, ie 127.0.0.1 and ::1 and nothing else. On my not-misbehaving-now Yosemite laptop, /etc/hosts contains ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost However, assuming that that's not your problem, I'd suggest cranking up log_min_messages to DEBUG5 and seeing if anything more gets reported in the postmaster log. Another thing worth checking is whether "-h 127.0.0.1" and "-h ::1" behave the same as "-h localhost". That would help rule out (or not) DNS issues. regards, tom lane
> and if you have it listen to 127.0.0.1, you see 127.0.0.1 in netstat?
Yes, netstat reflects exactly what I have in listen_addresses:
listen_addresses = '127.0.0.1, ::1'
~ netstat -an | grep 5432
tcp6 0 0 ::1.5432 *.* LISTEN
tcp4 0 0 127.0.0.1.5432 *.* LISTEN
If it's just '127.0.0.1' it just lists the tcp4 line.
> and psql -h 127.0.0.1 still fails?
Yes.
> is lo0 still there (ifconfig)?
~ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=1<PERFORMNUD>
On 07/21/2015 11:00 AM, Fritz Meissner wrote: >> and if you have it listen to 127.0.0.1, you see 127.0.0.1 in netstat? > > Yes, netstat reflects exactly what I have in listen_addresses: > > listen_addresses = '127.0.0.1, ::1' > > ~ netstat -an | grep 5432 > tcp6 0 0 ::1.5432 *.* LISTEN > tcp4 0 0 127.0.0.1.5432 *.* LISTEN > > If it's just '127.0.0.1' it just lists the tcp4 line. > >> and psql -h 127.0.0.1 still fails? > > Yes. > >> is lo0 still there (ifconfig)? > > ~ ifconfig lo0 > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > options=3<RXCSUM,TXCSUM> > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > nd6 options=1<PERFORMNUD> > > So what happens if you?: ping 127.0.0.1 ping localhost -- Adrian Klaver adrian.klaver@aklaver.com
> > So what happens if you?: > > ping 127.0.0.1 ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.162 ms ... > ping localhost ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.038 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.128 ms ...
On 07/21/2015 12:57 PM, Fritz Meissner wrote:
>>
>> So what happens if you?:
>>
>> ping 127.0.0.1
>
> ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1): 56 data bytes
> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.044 ms
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.162 ms
> ...
>
>> ping localhost
>
> ping localhost
> PING localhost (127.0.0.1): 56 data bytes
> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.038 ms
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.128 ms
> ...
>
>
Just realized that my suggestion above was redundant, because of this:
"
psql -Umyuser -d mydb -h localhost
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Server log:
[unknown] LOG: connection received: host=::1 port=51186
(... and that's it, no connection authorized line)
> So what happens if you do?:
>
> psql -U myuser -d mydb -h 127.0.0.1
>
Same thing. Pause for about 30 seconds and then "server closed the
connection unexpectedly". Server log just shows:
[unknown] LOG: connection received: host=127.0.0.1 port=51919
So psql -h <whatever> is reaching the server, it is failing at that
point though.
"
<Scratches head>
1) Can you access the Postgres server from another machine?
2) I know in your original post you did a which on psql, but is there
more then one instance/install of Postgres on this machine?
The reason I ask is this from the original post:
psql -Umyuser -d mydb
sql (9.3.5)
Type "help" for help.
myuser=#
That indicates a 9.3.5 version of psql. Not sure if that is the current
state or a cut and paste from when you said you where running 9.3.5,
before installing 9.4?
--
Adrian Klaver
adrian.klaver@aklaver.com
> 2) I know in your original post you did a which on psql, but is there more > then one instance/install of Postgres on this machine? > > The reason I ask is this from the original post: > > psql -Umyuser -d mydb > sql (9.3.5) > Type "help" for help. > > myuser=# > Yeah sorry, that's a copy/paste from before I upgraded out of desperation. Same thing was happening on 9.3.5 and 9.4.4. Currently: psql (9.4.4) Type "help" for help. myuser=#
Hi,
just to be 100% sure everything works upt to the TCP layer...
0. Stop postgres.
1. Open a terminal, enter:
nc -l 5432
and leave that running.
2. Open another terminal and enter:
nc 127.0.0.1 5432
follow up with some text such as "hello" and then hit CTRL-D
So... did "hello" show up in the first Terminal or not? (it should)
Bye,
Chris.
This is interesting, I tried nc a few times. Inconsistent results: - most of the time the first line doesn't get through, even after a long wait - on sending a second line from the client both lines appear instantly, and it's 100% from there on - or I can send a line from the server. The first line from client is still lost but both ends are 100% after that - 1/10 "sessions" behave perfectly BTW ^D just ends the session without sending anything, I'm hitting enter to send instead. On Tue, Jul 21, 2015 at 11:05 PM, Chris Mair <chris@1006.org> wrote: > Hi, > > just to be 100% sure everything works upt to the TCP layer... > > 0. Stop postgres. > > 1. Open a terminal, enter: > > nc -l 5432 > > and leave that running. > > 2. Open another terminal and enter: > > nc 127.0.0.1 5432 > > follow up with some text such as "hello" and then hit CTRL-D > > So... did "hello" show up in the first Terminal or not? (it should) > > Bye, > Chris. > >
On 07/21/2015 01:58 PM, Fritz Meissner wrote: >> 2) I know in your original post you did a which on psql, but is there more >> then one instance/install of Postgres on this machine? >> >> The reason I ask is this from the original post: >> >> psql -Umyuser -d mydb >> sql (9.3.5) >> Type "help" for help. >> >> myuser=# >> > > Yeah sorry, that's a copy/paste from before I upgraded out of > desperation. Same thing was happening on 9.3.5 and 9.4.4. Currently: > > psql (9.4.4) > Type "help" for help. > > myuser=# > Well that would have been too easy. Have you tried Tom's suggestion?: "However, assuming that that's not your problem, I'd suggest cranking up log_min_messages to DEBUG5 and seeing if anything more gets reported in the postmaster log. " -- Adrian Klaver adrian.klaver@aklaver.com
> This is interesting, I tried nc a few times. Inconsistent results: > > - most of the time the first line doesn't get through, even after a long wait > - on sending a second line from the client both lines appear > instantly, and it's 100% from there on > - or I can send a line from the server. The first line from client is > still lost but both ends are 100% after that > - 1/10 "sessions" behave perfectly The plot thickens... Here, on OS X 10.10.4 it works every time and every line entered shows up in terminal 1 instantly (as it should). If you ping 127.0.0.1 for some time you do have 0% loss, right? At this point I'd try to look at the OS X logs. Firewall is off right? Try to stop other software (any virtualization software, obscure network tools?)... What happens if you use the IP of en0, en1, ..., enX... instead of 127.0.0.1? Rebooting doesn't help (Windows docet)? When the first line doesn't get through, does it show up in the Recv-Q Send-Q fields in netstat -an (provided the connection shows up at all)? When you keep a third terminal open running sudo tcpdump -n -i lo0 while you do the nc thing, do you see anything? > BTW ^D just ends the session without sending anything, I'm hitting > enter to send instead. Oh yes, I wasn't clear on that... Bye, Chris.
Logging at debug5, hopefully it will mean more to you than to me. Local connection connects and I quit in a few seconds. -h localhost takes 90+ seconds to be closed by the server. In the longer duration there is a lot more logged, seems like unrelated auto chatter. I turned autovacuum off in postgresql.conf in the hope that it would reduce the chatter, seems unsuccesful. psql -Umyuser -dmydb 2015-07-22 12:00:51.175 CEST DEBUG: forked new backend, pid=5923 socket=12 2015-07-22 12:00:51.175 CEST [unknown] LOG: connection received: host=[local] 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: postgres child[5923]: starting with ( 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: postgres 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: ) 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: InitPostgres 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: my backend ID is 2 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: StartTransaction 2015-07-22 12:00:51.175 CEST myuser [local]DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:00:51.176 CEST myuser [local]LOG: connection authorized: user=myuser database=mydb 2015-07-22 12:00:51.179 CEST myuser [local]DEBUG: CommitTransaction 2015-07-22 12:00:51.179 CEST myuser [local]DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:00:59.896 CEST myuser [local]DEBUG: shmem_exit(0): 1 before_shmem_exit callbacks to make 2015-07-22 12:00:59.896 CEST myuser [local]DEBUG: shmem_exit(0): 6 on_shmem_exit callbacks to make 2015-07-22 12:00:59.896 CEST myuser [local]DEBUG: proc_exit(0): 4 callbacks to make 2015-07-22 12:00:59.897 CEST myuser [local]LOG: disconnection: session time: 0:00:08.721 user=myuser database=mydb host=[local] 2015-07-22 12:00:59.897 CEST myuser [local]DEBUG: exit(0) 2015-07-22 12:00:59.897 CEST myuser [local]DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make 2015-07-22 12:00:59.897 CEST myuser [local]DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make 2015-07-22 12:00:59.897 CEST myuser [local]DEBUG: proc_exit(-1): 0 callbacks to make 2015-07-22 12:00:59.898 CEST DEBUG: reaping dead processes 2015-07-22 12:00:59.898 CEST DEBUG: server process (PID 5923) exited with exit code 0 **************************************************************************** psql -Umyuser -dmyuser -h localhost 2015-07-22 12:02:20.422 CEST DEBUG: forked new backend, pid=5941 socket=12 2015-07-22 12:02:20.422 CEST [unknown] LOG: connection received: host=::1 port=51255 2015-07-22 12:02:27.393 CEST DEBUG: StartTransaction 2015-07-22 12:02:27.393 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:02:27.393 CEST DEBUG: CommitTransaction 2015-07-22 12:02:27.393 CEST DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:02:27.393 CEST DEBUG: received inquiry for database 0 2015-07-22 12:02:27.393 CEST DEBUG: writing stats file "pg_stat_tmp/global.stat" 2015-07-22 12:02:27.394 CEST DEBUG: writing stats file "pg_stat_tmp/db_0.stat" 2015-07-22 12:02:27.406 CEST DEBUG: InitPostgres 2015-07-22 12:02:27.406 CEST DEBUG: my backend ID is 2 2015-07-22 12:02:27.407 CEST DEBUG: StartTransaction 2015-07-22 12:02:27.407 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:02:27.411 CEST DEBUG: CommitTransaction 2015-07-22 12:02:27.411 CEST DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:02:27.411 CEST DEBUG: autovacuum: processing database “mydb” 2015-07-22 12:02:27.411 CEST DEBUG: received inquiry for database 16384 2015-07-22 12:02:27.411 CEST DEBUG: writing stats file "pg_stat_tmp/global.stat" 2015-07-22 12:02:27.411 CEST DEBUG: writing stats file "pg_stat_tmp/db_16384.stat" 2015-07-22 12:02:27.422 CEST DEBUG: StartTransaction 2015-07-22 12:02:27.423 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:02:27.423 CEST DEBUG: pg_statistic: vac: 0 (threshold 130), anl: 0 (threshold 90) 2015-07-22 12:02:27.423 CEST DEBUG: pg_type: vac: 0 (threshold 118), anl: 0 (threshold 84) 2015-07-22 12:02:27.423 CEST DEBUG: pg_authid: vac: 0 (threshold 50), anl: 0 (threshold 50) 2015-07-22 12:02:27.423 CEST DEBUG: pg_attribute: vac: 0 (threshold 512), anl: 0 (threshold 281) 2015-07-22 12:02:27.423 CEST DEBUG: pg_proc: vac: 0 (threshold 587), anl: 0 (threshold 318) 2015-07-22 12:02:27.423 CEST DEBUG: pg_index: vac: 0 (threshold 73), anl: 0 (threshold 61) 2015-07-22 12:02:27.423 CEST DEBUG: pg_opclass: vac: 0 (threshold 76), anl: 0 (threshold 63) 2015-07-22 12:02:27.423 CEST DEBUG: pg_am: vac: 0 (threshold 51), anl: 0 (threshold 50) 2015-07-22 12:02:27.423 CEST DEBUG: pg_amop: vac: 0 (threshold 137), anl: 0 (threshold 94) 2015-07-22 12:02:27.423 CEST DEBUG: pg_amproc: vac: 0 (threshold 119), anl: 0 (threshold 84) 2015-07-22 12:02:27.423 CEST DEBUG: pg_database: vac: 0 (threshold 50), anl: 0 (threshold 50) 2015-07-22 12:02:27.423 CEST DEBUG: pg_cast: vac: 0 (threshold 90), anl: 0 (threshold 70) 2015-07-22 12:02:27.423 CEST DEBUG: pg_namespace: vac: 0 (threshold 51), anl: 0 (threshold 51) 2015-07-22 12:02:27.423 CEST DEBUG: pg_tablespace: vac: 0 (threshold 50), anl: 0 (threshold 50) 2015-07-22 12:02:27.423 CEST DEBUG: pg_class: vac: 0 (threshold 109), anl: 0 (threshold 80) 2015-07-22 12:02:27.423 CEST DEBUG: CommitTransaction 2015-07-22 12:02:27.423 CEST DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:02:27.423 CEST DEBUG: shmem_exit(0): 1 before_shmem_exit callbacks to make 2015-07-22 12:02:27.423 CEST DEBUG: shmem_exit(0): 7 on_shmem_exit callbacks to make 2015-07-22 12:02:27.423 CEST DEBUG: proc_exit(0): 2 callbacks to make 2015-07-22 12:02:27.423 CEST DEBUG: exit(0) 2015-07-22 12:02:27.423 CEST DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make 2015-07-22 12:02:27.423 CEST DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make 2015-07-22 12:02:27.423 CEST DEBUG: proc_exit(-1): 0 callbacks to make 2015-07-22 12:02:27.424 CEST DEBUG: reaping dead processes 2015-07-22 12:02:27.424 CEST DEBUG: server process (PID 5943) exited with exit code 0 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: shmem_exit(1): 0 before_shmem_exit callbacks to make 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: shmem_exit(1): 0 on_shmem_exit callbacks to make 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: proc_exit(1): 1 callbacks to make 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: exit(1) 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make 2015-07-22 12:03:20.426 CEST [unknown] ::1(51255)DEBUG: proc_exit(-1): 0 callbacks to make 2015-07-22 12:03:20.426 CEST DEBUG: reaping dead processes 2015-07-22 12:03:20.426 CEST DEBUG: server process (PID 5941) exited with exit code 1 2015-07-22 12:03:27.395 CEST DEBUG: StartTransaction 2015-07-22 12:03:27.396 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:03:27.396 CEST DEBUG: CommitTransaction 2015-07-22 12:03:27.396 CEST DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:03:27.396 CEST DEBUG: received inquiry for database 0 2015-07-22 12:03:27.396 CEST DEBUG: writing stats file "pg_stat_tmp/global.stat" 2015-07-22 12:03:27.396 CEST DEBUG: writing stats file "pg_stat_tmp/db_0.stat" 2015-07-22 12:03:27.409 CEST DEBUG: InitPostgres 2015-07-22 12:03:27.409 CEST DEBUG: my backend ID is 2 2015-07-22 12:03:27.409 CEST DEBUG: StartTransaction 2015-07-22 12:03:27.409 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:03:27.413 CEST DEBUG: CommitTransaction 2015-07-22 12:03:27.413 CEST DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:03:27.413 CEST DEBUG: autovacuum: processing database "mydb" 2015-07-22 12:03:27.413 CEST DEBUG: received inquiry for database 16384 2015-07-22 12:03:27.413 CEST DEBUG: writing stats file "pg_stat_tmp/global.stat" 2015-07-22 12:03:27.413 CEST DEBUG: writing stats file "pg_stat_tmp/db_16384.stat" 2015-07-22 12:03:27.424 CEST DEBUG: StartTransaction 2015-07-22 12:03:27.424 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:03:27.425 CEST DEBUG: pg_statistic: vac: 0 (threshold 130), anl: 0 (threshold 90) 2015-07-22 12:03:27.425 CEST DEBUG: pg_type: vac: 0 (threshold 118), anl: 0 (threshold 84) 2015-07-22 12:03:27.425 CEST DEBUG: pg_authid: vac: 0 (threshold 50), anl: 0 (threshold 50) 2015-07-22 12:03:27.425 CEST DEBUG: pg_attribute: vac: 0 (threshold 512), anl: 0 (threshold 281) 2015-07-22 12:03:27.425 CEST DEBUG: pg_proc: vac: 0 (threshold 587), anl: 0 (threshold 318) 2015-07-22 12:03:27.425 CEST DEBUG: pg_index: vac: 0 (threshold 73), anl: 0 (threshold 61) 2015-07-22 12:03:27.425 CEST DEBUG: pg_opclass: vac: 0 (threshold 76), anl: 0 (threshold 63) 2015-07-22 12:03:27.425 CEST DEBUG: pg_am: vac: 0 (threshold 51), anl: 0 (threshold 50) 2015-07-22 12:03:27.425 CEST DEBUG: pg_amop: vac: 0 (threshold 137), anl: 0 (threshold 94) 2015-07-22 12:03:27.425 CEST DEBUG: pg_amproc: vac: 0 (threshold 119), anl: 0 (threshold 84) 2015-07-22 12:03:27.425 CEST DEBUG: pg_database: vac: 0 (threshold 50), anl: 0 (threshold 50) 2015-07-22 12:03:27.425 CEST DEBUG: pg_cast: vac: 0 (threshold 90), anl: 0 (threshold 70) 2015-07-22 12:03:27.425 CEST DEBUG: pg_namespace: vac: 0 (threshold 51), anl: 0 (threshold 51) 2015-07-22 12:03:27.425 CEST DEBUG: pg_tablespace: vac: 0 (threshold 50), anl: 0 (threshold 50) 2015-07-22 12:03:27.425 CEST DEBUG: pg_class: vac: 0 (threshold 109), anl: 0 (threshold 80) 2015-07-22 12:03:27.425 CEST DEBUG: CommitTransaction 2015-07-22 12:03:27.425 CEST DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2015-07-22 12:03:27.425 CEST DEBUG: shmem_exit(0): 1 before_shmem_exit callbacks to make 2015-07-22 12:03:27.425 CEST DEBUG: shmem_exit(0): 7 on_shmem_exit callbacks to make 2015-07-22 12:03:27.425 CEST DEBUG: proc_exit(0): 2 callbacks to make 2015-07-22 12:03:27.425 CEST DEBUG: exit(0) Fritz On Wed, Jul 22, 2015 at 12:05 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > On 07/21/2015 01:58 PM, Fritz Meissner wrote: >>> >>> 2) I know in your original post you did a which on psql, but is there >>> more >>> then one instance/install of Postgres on this machine? >>> >>> The reason I ask is this from the original post: >>> >>> psql -Umyuser -d mydb >>> sql (9.3.5) >>> Type "help" for help. >>> >>> myuser=# >>> >> >> Yeah sorry, that's a copy/paste from before I upgraded out of >> desperation. Same thing was happening on 9.3.5 and 9.4.4. Currently: >> >> psql (9.4.4) >> Type "help" for help. >> >> myuser=# >> > > Well that would have been too easy. > > Have you tried Tom's suggestion?: > > > "However, assuming that that's not your problem, I'd suggest cranking up > log_min_messages to DEBUG5 and seeing if anything more gets reported > in the postmaster log. > " > > -- > Adrian Klaver > adrian.klaver@aklaver.com
SOLVED! With firewall off and pf disabled I spotted a process intended to keep an audit trail of Internet access. I uninstalled it and hey presto. Thanks for your help, everyone! Glad to see my macbook is not haunted. Regards, Fritz On Wed, Jul 22, 2015 at 9:23 AM, Chris Mair <chris@1006.org> wrote: > The plot thickens... > > Here, on OS X 10.10.4 it works every time and every line entered shows > up in terminal 1 instantly (as it should). > > If you ping 127.0.0.1 for some time you do have 0% loss, right? > > At this point I'd try to look at the OS X logs. Firewall is off right? > Try to stop other software (any virtualization software, obscure network > tools?)... >
> SOLVED! > Glad to see my macbook is not haunted. Calling a priest would have been my next suggestion... ;) Bye, Chris.