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

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" marc(at)daelemans(dot)com

>Относно: PgAdmin Debugger problem 56C2437D(dot)4030603(at)enterprisedb(dot)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(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 .
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


marc(at)daelemans(dot)com
cell +32 475 421 413
tel

+32 16 39 10 15