PgAdmin Debugger problem 56C2437D.4030603@enterprisedb.com (view raw or whole thread)

Korry,

I could not find an entry point in the Postgres message board, which is why
I take the liberty of just mailing you.

For quite some time I experienced a problem similar to Stefan Stefanov's
(56C2437D(dot)4030603(at)enterprisedb(dot)com ) : the debugger freezes after a few
step-into clicks, and the only way to get out is to force a crash. In
Stefan's case it apparently took somewhat longer; in my case the freeze
occurred as soon as the function hit a more complex query.

The postgres log and the Windows (Win7 Professional SP1) event log referred
to:

2016-04-03 12:59:30 CEST STATEMENT: SELECT

p.func, p.targetName, p.linenumber,

pldbg_get_source($1::INTEGER, p.func) AS
src,

(SELECT

s.args

FROM pldbg_get_stack($1::INTEGER) s

WHERE s.func = p.func) AS args

FROM pldbg_step_into($1::INTEGER) p

2016-04-03 13:07:04 CEST ERROR: debugger connection(client side) terminated

2016-04-03 13:07:04 CEST STATEMENT: SELECT

p.func, p.targetName, p.linenumber,

pldbg_get_source($1::INTEGER, p.func) AS
src,

(SELECT

s.args

FROM pldbg_get_stack($1::INTEGER) s

WHERE s.func = p.func) AS args

FROM pldbg_step_into($1::INTEGER) p

2016-04-03 13:07:04 CEST LOG: could not send data to client: No connection
could be made because the target machine actively refused it.

2016-04-03 13:07:04 CEST STATEMENT: SELECT

p.func, p.targetName, p.linenumber,

pldbg_get_source($1::INTEGER, p.func) AS
src,

(SELECT

s.args

FROM pldbg_get_stack($1::INTEGER) s

WHERE s.func = p.func) AS args

FROM pldbg_step_into($1::INTEGER) p

2016-04-03 13:07:04 CEST FATAL: connection to client lost

The second highlighted error message can be found here
<http://dcmediads.freshdesk.com/support/solutions/articles/147744-what-does-
connection-refused-no-connection-could-be-made-because-the-target-machine-ac
tively-refuse> . With Telnet producing a sluggish response, the best
candidate was

WSAECONNREFUSED
10061
Connection refused.
No connection could be made because the target computer actively refused it.
This usually results from trying to connect to a service that is inactive on
the foreign host-that is, one with no server application running.

I first suspected a bug related to pldbg_attach_to_port(), but there I was
at my wit's end.

Later I checked all the connection related server settings in
postgresql.conf, and found

max_connections = 100 and (the default setting)

superuser_reserved_connections = 3 (the default setting)

I doubled both to 200 and 6 resp. and this seems to have solved the problem.
My suspicion is that it is the superuser_reserved_connections option that
made the difference because the debugger is reserved for superusers.

You and your colleagues could not reproduce the error because you most
probably had already upgraded the superuser_reserved_connections setting.

If I may make a suggestion for poor PG beginners like myself: why not make a
few 'standard' postgresql.conf configurations part of the installation
process? It could e.g. contain all settings for a single machine developer,
and some other frequently used configurations. Or even better: a Postgres
configurator that asks a few questions about hardware, network
configuration, Python / C interfaces, debugger etc.. and then produce a semi
tailor-made postgresql.conf file. This would also create the possibility to
pre-install the debugger for all superusers. It would save a lot of
headaches in a stage where new users have not yet read all the fine details
of the full documentation. Also throw a few installation hints:

0. Uninstall postgres using control panel - keep C:\Pg\data directory
(Windows does not like user data in Program Files .)

1. Download the Windows installation file

2. Disable firewalls ( Privatefirewall / Windows firewall . )

3. Disable Antivirus

4. Start the Installer in ADMINISTRATOR mode !!

5. restart computer

(I might have copied this from somewhere .).

Another idea is to create a warning for the presence of more than one copy
of postgresql.conf (e.g. in the user data directory c:\pg\data .) and
C:\Program Files\PostgreSQL\9.4 (as a leftover of an initial installation).
It has taken me a while to figure out why the postgresql.conf changes I made
did not work as expected .

I hope this is useful. Feel free to use this as you see fit.

Best regards,

Marc

<mailto:marc(at)daelemans(dot)com> marc(at)daelemans(dot)com

cell +32 475 421 413

tel +32 16 39 10 15