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

Hi Marc - sorry for the delay in replying to you. I'm working on
replicating the problem. Will let you know if I have any difficulties
(I'm working on setting up a Windows build environment with the proper
versions now).

-- Korry

> 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
> <mailto: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
> <http://dcmediads.freshdesk.com/support/solutions/articles/147744-what-does-connection-refused-no-connection-could-be-made-because-the-target-machine-actively-refuse>
> . 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 <mailto:marc(at)daelemans(dot)com>
>
> cell +32 475 421 413
>
> tel +32 16 39 10 15
>