Hi Marc - sorry for the delay in replying to you. I'm working on
replicating the problem. Will let you know if I have any difficulties
(I'm working on setting up a Windows build environment with the proper
versions now).
-- Korry
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.4030...@enterprisedb.com
<mailto:56c2437d.4030...@enterprisedb.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-actively-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
m...@daelemans.com <mailto:m...@daelemans.com>
cell +32 475 421 413
tel +32 16 39 10 15
