Hi Marc,
I tried your suggested solution (superuser_reserved_connections = 10)
It did make a change. My session was freezing whenever I tried to change the
value of a local variable before the change and not after that.
Unfortunately the original issue remained.
BTW everything works fine on EDB 9.2.15 server on win7-32b and Pgadmin-iii
1.22.0 on win7-64b
Sincerely,
Stefan
>-------- Оригинално писмо --------
>От: "Marc Daelemans" m...@daelemans.com
>Относно: PgAdmin Debugger problem 56c2437d.4030...@enterprisedb.com (view
>raw or whole thread)
>До:
>Изпратено на: 03.04.2016 18:10
.abv-omExternalClass p.MsoNormal { margin: 0.0cm; font-size: 11.0pt;
font-family: 'Calibri', 'sans-serif'; } .abv-omExternalClass a:link { color:
#0000ff; } .abv-omExternalClass a:visited { color: #800080; }
.abv-omExternalClass span.EmailStyle17 { font-family: 'Calibri', 'sans-serif';
color: windowtext; } .abv-omExternalClass .MsoChpDefault { font-family:
'Calibri', 'sans-serif'; } .abv-omExternalClass div.WordSection1 { }
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 ) : 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 .
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
cell +32 475 421 413
tel
+32 16 39 10 15
