Cannot reach pg server using -h localhost

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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:
/messages/by-id/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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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>

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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
...

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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=#

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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?)...

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

SOLVED!

Glad to see my macbook is not haunted.

Calling a priest would have been my next suggestion... ;)

Bye,
Chris.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general