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

<div class="moz-cite-prefix"><br /><br /> Hi Marc - sorry for the delay in replying to you.  I'm working on replicating
theproblem.  Will let you know if I have any difficulties (I'm working on setting up a Windows build environment with
theproper versions now).<br /><br /><br />             -- Korry<br /><br /></div><blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAIO%2F7QVkeRdDjCXHmkVy+72CvgAAEAAAAHYB%2FzWungdFhvUQjCdAFCYBAAAAAA==@daelemans.com"
type="cite"><divclass="WordSection1"><p class="MsoNormal">Korry,<p class="MsoNormal"> <p class="MsoNormal">I could not
findan entry point in the Postgres message board, which is why I take the liberty of just mailing you.<p
class="MsoNormal"> <pclass="MsoNormal">For quite some time I experienced a problem similar to Stefan Stefanov’s (<a
href="mailto:56C2437D.4030603@enterprisedb.com"moz-do-not-send="true">56C2437D.4030603@enterprisedb.com</a> ) : the
debuggerfreezes after a few step-into clicks, and the only way to get out is to force a crash. In Stefan’s case it
apparentlytook somewhat longer; in my case the freeze occurred as soon as the function hit a more complex query.<p
class="MsoNormal"> <pclass="MsoNormal">The postgres log and the Windows (Win7 Professional SP1) event log referred
to:<pclass="MsoNormal"> <p class="MsoNormal">2016-04-03 12:59:30 CEST STATEMENT:  SELECT<p
class="MsoNormal">                               p.func, p.targetName, p.linenumber,<p
class="MsoNormal">                               pldbg_get_source($1::INTEGER, p.func) AS src,<p
class="MsoNormal">                               (SELECT<p
class="MsoNormal">                                               s.args<p
class="MsoNormal">                               FROM pldbg_get_stack($1::INTEGER) s<p
class="MsoNormal">                               WHERE s.func = p.func) AS args<p class="MsoNormal">               
FROMpldbg_step_into($1::INTEGER) p<p class="MsoNormal">2016-04-03 13:07:04 CEST ERROR:  <span>debugger
connection(clientside) terminated</span><p class="MsoNormal">2016-04-03 13:07:04 CEST STATEMENT:  SELECT<p
class="MsoNormal">                               p.func, p.targetName, p.linenumber,<p
class="MsoNormal">                               pldbg_get_source($1::INTEGER, p.func) AS src,<p
class="MsoNormal">                               (SELECT<p class="MsoNormal">                               
               s.args<p class="MsoNormal">                                FROM pldbg_get_stack($1::INTEGER) s<p
class="MsoNormal">                               WHERE s.func = p.func) AS args<p class="MsoNormal">               
FROMpldbg_step_into($1::INTEGER) p<p class="MsoNormal">2016-04-03 13:07:04 CEST LOG:  <span>could not send data to
client:No connection could be made because the target machine actively refused it.</span><p
class="MsoNormal">               <p class="MsoNormal">2016-04-03 13:07:04 CEST STATEMENT:  SELECT<p
class="MsoNormal">                               p.func, p.targetName, p.linenumber,<p
class="MsoNormal">                               pldbg_get_source($1::INTEGER, p.func) AS src,<p
class="MsoNormal">                               (SELECT<p
class="MsoNormal">                                               s.args<p
class="MsoNormal">                               FROM pldbg_get_stack($1::INTEGER) s<p
class="MsoNormal">                               WHERE s.func = p.func) AS args<p class="MsoNormal">               
FROMpldbg_step_into($1::INTEGER) p<p class="MsoNormal">2016-04-03 13:07:04 CEST FATAL:  <span>connection to client
lost</span><pclass="MsoNormal"> <p class="MsoNormal">The second highlighted error message can be found <a
href="http://dcmediads.freshdesk.com/support/solutions/articles/147744-what-does-connection-refused-no-connection-could-be-made-because-the-target-machine-actively-refuse"
moz-do-not-send="true">here</a>.  With Telnet producing a sluggish response, the best candidate was <p
class="MsoNormal"><br/><span>WSAECONNREFUSED<br /> 10061 <br /> Connection refused.<br /> No connection could be made
becausethe target computer actively refused it. This usually results from trying to connect to a service that is
inactiveon the foreign host—that is, one with no server application running.</span><p class="MsoNormal"> <p
class="MsoNormal">Ifirst suspected a bug related to pldbg_attach_to_port(), but there I was at my wit’s end.<p
class="MsoNormal"> <pclass="MsoNormal">Later I checked all the connection related server settings in postgresql.conf,
andfound <p class="MsoNormal"> <p class="MsoNormal"><span>max_connections = 100 </span>and                        (the
defaultsetting)<p class="MsoNormal"><span>superuser_reserved_connections = 3</span>      (the default setting)<p
class="MsoNormal"> <pclass="MsoNormal"><span>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
debuggeris reserved for superusers.</span><p class="MsoNormal"> <p class="MsoNormal">You and your colleagues could not
reproducethe error because you most probably had already upgraded the superuser_reserved_connections setting.<p
class="MsoNormal"> <pclass="MsoNormal">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
singlemachine developer, and some other frequently used configurations. Or even better: a Postgres configurator that
asksa few questions about hardware, network configuration, Python / C interfaces, debugger etc.. and then produce a
semitailor-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
fulldocumentation. Also throw a few installation hints:<p class="MsoNormal"><span>0. Uninstall postgres using control
panel- keep C:\Pg\data directory (Windows does not like user data in Program Files …)</span><p
class="MsoNormal"><span>1.Download the Windows installation file</span><p class="MsoNormal"><span>2. Disable firewalls
(Privatefirewall / Windows firewall … )</span><p class="MsoNormal"><span>3. Disable Antivirus</span><p
class="MsoNormal"><span>4.Start the Installer in ADMINISTRATOR mode !!</span><p class="MsoNormal"><span lang="NL-BE">5.
restartcomputer</span><p class="MsoNormal">(I might have copied this from somewhere …). <p class="MsoNormal"> <p
class="MsoNormal">Anotheridea is to create a warning for the presence of more than one copy of postgresql.conf (e.g. in
theuser data directory c:\pg\data …) and C:\Program Files\PostgreSQL\9.4 (as a leftover of an initial installation). It
hastaken me a while to figure out why the postgresql.conf changes I made did not work as expected …<p
class="MsoNormal"> <pclass="MsoNormal">I hope this is useful. Feel free to use this as you see fit.<p
class="MsoNormal"> <pclass="MsoNormal">Best regards,<p class="MsoNormal">Marc<p class="MsoNormal"> <p
class="MsoNormal"><spanlang="NL-BE"><a href="mailto:marc@daelemans.com"
moz-do-not-send="true"><span>marc@daelemans.com</span></a></span><pclass="MsoNormal"><span lang="NL-BE">cell +32 475
421413</span><p class="MsoNormal"><span lang="NL-BE">tel   +32 16 39 10 15</span><p
class="MsoNormal"> </div></blockquote><br/>