Обсуждение: PgAdmin Debugger problem 56C2437D.4030603@enterprisedb.com (view raw or whole thread)

Поиск
Список
Период
Сортировка

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

От
"Marc Daelemans"
Дата:
<div class="WordSection1"><p class="MsoNormal">Korry,<p class="MsoNormal"> <p class="MsoNormal">I could not find an
entrypoint in the Postgres message board, which is why I take the liberty of just mailing you.<p class="MsoNormal"> <p
class="MsoNormal">Forquite some time I experienced a problem similar to Stefan Stefanov’s (<a
href="mailto:56C2437D.4030603@enterprisedb.com">56C2437D.4030603@enterprisedb.com</a>) : the debugger freezes after a
fewstep-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.<p class="MsoNormal"> <p
class="MsoNormal">Thepostgres log and the Windows (Win7 Professional SP1) event log referred to:<p
class="MsoNormal"> <pclass="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
style="background:yellow;mso-highlight:yellow">debuggerconnection(client side) terminated</span><p
class="MsoNormal">2016-04-0313: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
style="background:yellow;mso-highlight:yellow">couldnot send data to client: No connection could be made because the
targetmachine actively refused it.</span><p class="MsoNormal">                <p class="MsoNormal">2016-04-03 13:07:04
CESTSTATEMENT:  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
style="background:yellow;mso-highlight:yellow">connectionto client lost</span><p class="MsoNormal"> <p
class="MsoNormal">Thesecond 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">here</a>
. With Telnet producing a sluggish response, the best candidate was <p class="MsoNormal"><br /><span
style="color:#C0504D">WSAECONNREFUSED<br/>10061 <br />Connection refused.<br />No connection could be made because the
targetcomputer actively refused it. This usually results from trying to connect to a service that is inactive on the
foreignhost—that is, one with no server application running.</span><p class="MsoNormal"> <p class="MsoNormal">I first
suspecteda bug related to pldbg_attach_to_port(), but there I was at my wit’s end.<p class="MsoNormal"> <p
class="MsoNormal">LaterI checked all the connection related server settings in postgresql.conf, and found <p
class="MsoNormal"> <pclass="MsoNormal"><span style="background:aqua;mso-highlight:aqua">max_connections = 100
</span>and                       (the default setting)<p class="MsoNormal"><span
style="background:aqua;mso-highlight:aqua">superuser_reserved_connections= 3</span>      (the default setting)<p
class="MsoNormal"> <pclass="MsoNormal"><span style="background:aqua;mso-highlight:aqua">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
thatmade the difference because the debugger is reserved for superusers.</span><p class="MsoNormal"> <p
class="MsoNormal">Youand your colleagues could not reproduce the error because you most probably had already upgraded
thesuperuser_reserved_connections setting.<p class="MsoNormal"> <p class="MsoNormal">If I may make a suggestion for
poorPG 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
thepossibility to pre-install the debugger for all superusers. It would save a lot of headaches in a stage where new
usershave not yet read all the fine details of the full documentation. Also throw a few installation hints:<p
class="MsoNormal"style="text-autospace:none"><span style="font-family:"Courier New"">0. Uninstall postgres using
controlpanel - keep C:\Pg\data directory (Windows does not like user data in Program Files …)</span><p
class="MsoNormal"style="text-autospace:none"><span style="font-family:"Courier New"">1. Download the Windows
installationfile</span><p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New"">2.
Disablefirewalls ( Privatefirewall / Windows firewall … )</span><p class="MsoNormal" style="text-autospace:none"><span
style="font-family:"CourierNew"">3. Disable Antivirus</span><p class="MsoNormal" style="text-autospace:none"><span
style="font-family:"CourierNew"">4. Start the Installer in ADMINISTRATOR mode !!</span><p class="MsoNormal"><span
lang="NL-BE"style="font-family:"Courier New"">5. restart computer</span><p class="MsoNormal">(I might have copied this
fromsomewhere …). <p class="MsoNormal"> <p class="MsoNormal">Another idea is to create a warning for the presence of
morethan one copy of postgresql.conf (e.g. in the user data directory c:\pg\data …) and C:\Program Files\PostgreSQL\9.4
(asa leftover of an initial installation). It has taken me a while to figure out why the postgresql.conf changes I made
didnot work as expected …<p class="MsoNormal"> <p class="MsoNormal">I hope this is useful. Feel free to use this as you
seefit.<p class="MsoNormal"> <p class="MsoNormal">Best regards,<p class="MsoNormal">Marc<p class="MsoNormal"> <p
class="MsoNormal"><spanlang="NL-BE"><a href="mailto:marc@daelemans.com"><span
style="color:blue">marc@daelemans.com</span></a></span><pclass="MsoNormal"><span lang="NL-BE">cell +32 475 421
413</span><pclass="MsoNormal"><span lang="NL-BE">tel   +32 16 39 10 15</span><p class="MsoNormal"> </div> 

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

От
Stefan Stefanov
Дата:
Hi Marc,<br /><br />I tried your suggested solution (superuser_reserved_connections = 10)<br />It did make a change.
Mysession was freezing whenever I tried to change the value of a local variable before the change and not after
that.<br/>Unfortunately the original issue remained.<br />BTW everything works fine on EDB 9.2.15 server on win7-32b
andPgadmin-iii 1.22.0 on win7-64b<br /><br />Sincerely, Stefan<br /><br /> >-------- Оригинално писмо -------- <br
/>>От: "Marc Daelemans" marc@daelemans.com <br /> >Относно: PgAdmin Debugger problem
56C2437D.4030603@enterprisedb.com(view raw or whole thread) <br /> >До: <korry.douglas@enterprisedb.com> <br
/>>Изпратено на: 03.04.2016 18:10 <br /><br /><style>.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{ } </style><div class=""><p class="">Korry,<p class=""> <p class="">I could not find an entry point in
thePostgres message board, which is why I take the liberty of just mailing you.<p class=""> <p class="">For quite some
timeI experienced a problem similar to Stefan Stefanov’s (<a href="javascript:
internSendMess('56C2437D.4030603@enterprisedb.com')">56C2437D.4030603@enterprisedb.com</a>) : the debugger freezes
aftera few step-into clicks, and the only way to get out is to force a crash. In Stefan’s case it apparently took
somewhatlonger; in my case the freeze occurred as soon as the function hit a more complex query.<p class=""> <p
class="">Thepostgres log and the Windows (Win7 Professional SP1) event log referred to:<p class=""> <p
class="">2016-04-0312:59:30 CEST STATEMENT:  SELECT<p class="">                                p.func, p.targetName,
p.linenumber,<pclass="">                                pldbg_get_source($1::INTEGER, p.func) AS src,<p
class="">                               (SELECT<p class="">                                                s.args<p
class="">                               FROM pldbg_get_stack($1::INTEGER) s<p class="">                               
WHEREs.func = p.func) AS args<p class="">                FROM pldbg_step_into($1::INTEGER) p<p class="">2016-04-03
13:07:04CEST ERROR:  <span style="background:#ffff00;">debugger connection(client side) terminated</span><p
class="">2016-04-0313:07:04 CEST STATEMENT:  SELECT<p class="">                                p.func, p.targetName,
p.linenumber,<pclass="">                                pldbg_get_source($1::INTEGER, p.func) AS src,<p
class="">                               (SELECT<p class="">                                                s.args<p
class="">                               FROM pldbg_get_stack($1::INTEGER) s<p class="">                               
WHEREs.func = p.func) AS args<p class="">                FROM pldbg_step_into($1::INTEGER) p<p class="">2016-04-03
13:07:04CEST LOG:  <span style="background:#ffff00;">could not send data to client: No connection could be made because
thetarget machine actively refused it.</span><p class="">                <p class="">2016-04-03 13:07:04 CEST
STATEMENT: SELECT<p class="">                                p.func, p.targetName, p.linenumber,<p
class="">                               pldbg_get_source($1::INTEGER, p.func) AS src,<p
class="">                               (SELECT<p class="">                                                s.args<p
class="">                               FROM pldbg_get_stack($1::INTEGER) s<p class="">                               
WHEREs.func = p.func) AS args<p class="">                FROM pldbg_step_into($1::INTEGER) p<p class="">2016-04-03
13:07:04CEST FATAL:  <span style="background:#ffff00;">connection to client lost</span><p class=""> <p class="">The
secondhighlighted 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"
target="_blank">here</a>.  With Telnet producing a sluggish response, the best candidate was <p class=""><br /><span
style="color:#c0504d;">WSAECONNREFUSED<br/>10061 <br />Connection refused.<br />No connection could be made because the
targetcomputer actively refused it. This usually results from trying to connect to a service that is inactive on the
foreignhost—that is, one with no server application running.</span><p class=""> <p class="">I first suspected a bug
relatedto pldbg_attach_to_port(), but there I was at my wit’s end.<p class=""> <p class="">Later I checked all the
connectionrelated server settings in postgresql.conf, and found <p class=""> <p class=""><span
style="background:#00ffff;">max_connections= 100 </span>and                        (the default setting)<p
class=""><spanstyle="background:#00ffff;">superuser_reserved_connections = 3</span>      (the default setting)<p
class=""> <pclass=""><span style="background:#00ffff;">I doubled both to 200 and 6 resp. and this seems to have solved
theproblem. My suspicion is that it is the superuser_reserved_connections option that made the difference because the
debuggeris reserved for superusers.</span><p class=""> <p class="">You and your colleagues could not reproduce the
errorbecause you most probably had already upgraded the superuser_reserved_connections setting.<p class=""> <p
class="">IfI may make a suggestion for poor PG beginners like myself: why not make a few ‘standard’ postgresql.conf
configurationspart of the installation process? It could e.g. contain all settings for a single machine developer, and
someother 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.conffile.  This would also create the possibility to pre-install the debugger for all superusers. It would
savea lot of headaches in a stage where new users have not yet read all the fine details of the full documentation.
Alsothrow a few installation hints:<p class="" style=""><span style="font-family:'Courier New';">0. Uninstall postgres
usingcontrol panel - keep C:\Pg\data directory (Windows does not like user data in Program Files …)</span><p class=""
style=""><spanstyle="font-family:'Courier New';">1. Download the Windows installation file</span><p class=""
style=""><spanstyle="font-family:'Courier New';">2. Disable firewalls ( Privatefirewall / Windows firewall … )</span><p
class=""style=""><span style="font-family:'Courier New';">3. Disable Antivirus</span><p class="" style=""><span
style="font-family:'CourierNew';">4. Start the Installer in ADMINISTRATOR mode !!</span><p class=""><span
style="font-family:'CourierNew';">5. restart computer</span><p class="">(I might have copied this from somewhere …). <p
class=""> <pclass="">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 …<p
class=""> <pclass="">I hope this is useful. Feel free to use this as you see fit.<p class=""> <p class="">Best
regards,<pclass="">Marc<p class=""> <p class=""><span><a href="javascript: internSendMess('marc@daelemans.com')"><span
style="color:#0000ff;">marc@daelemans.com</span></a></span><pclass=""><span>cell +32 475 421 413</span><p
class=""><span>tel  +32 16 39 10 15</span><p class=""> </div> 

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

От
Korry Douglas
Дата:
<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/>