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

Поиск
Список
Период
Сортировка
От Stefan Stefanov
Тема Re: PgAdmin Debugger problem 56C2437D.4030603@enterprisedb.com (view raw or whole thread)
Дата
Msg-id 1575985064.169889.1459713076190.JavaMail.apache@nm32.abv.bg
обсуждение исходный текст
Ответ на PgAdmin Debugger problem 56C2437D.4030603@enterprisedb.com (view raw or whole thread)  ("Marc Daelemans" <marc@daelemans.com>)
Список pgadmin-support
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> 

В списке pgadmin-support по дате отправления:

Предыдущее
От: "Marc Daelemans"
Дата:
Сообщение: PgAdmin Debugger problem 56C2437D.4030603@enterprisedb.com (view raw or whole thread)
Следующее
От: Dave Page
Дата:
Сообщение: Re: pgAdmin still doesn't support Japanese in grid view on the Mac