The intriguing error message here is "could not find block containing chunk 0000000001176B70", which is coming from either the server or more likely, the debugger plugin.
Korry - you're far more familiar with that code than me; any idea what could be causing this? On Sat, Feb 13, 2016 at 2:13 PM, Stefan Stefanov <stefanov...@abv.bg> wrote: > Hi Dave, this part of pg_log/postgresql-2016-02-13_000000.log might help. > > 2016-02-13 16:05:23 EET ERROR: select() failed waiting for target > 2016-02-13 16:05:23 EET 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_over($1::INTEGER) p > 2016-02-13 16:05:26 EET WARNING: unrecognized message > > 2016-02-13 16:05:26 EET CONTEXT: PL/pgSQL function playground.dbg_test() > line 8 at RAISE > 2016-02-13 16:05:26 EET ERROR: could not find block containing chunk > 0000000001176B70 > 2016-02-13 16:05:26 EET CONTEXT: PL/pgSQL function playground.dbg_test() > line 8 at RAISE > 2016-02-13 16:05:26 EET STATEMENT: SELECT * FROM playground.dbg_test() > 2016-02-13 16:06:02 EET LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2016-02-13 16:06:02 EET LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2016-02-13 16:06:02 EET LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > 2016-02-13 16:06:02 EET ERROR: debugger connection(client side) terminated > 2016-02-13 16:06:02 EET STATEMENT: SELECT * FROM pldbg_abort_target(1) > 2016-02-13 16:06:02 EET LOG: could not send data to client: No connection > could be made because the target machine actively refused it. > > > 2016-02-13 16:06:02 EET STATEMENT: SELECT * FROM pldbg_abort_target(1) > 2016-02-13 16:06:02 EET FATAL: connection to client lost > 2016-02-13 16:06:02 EET LOG: could not receive data from client: No > connection could be made because the target machine actively refused it. > > > > Sincerely, Stefan > > > > >-------- Оригинално писмо -------- > >От: Dave Page dp...@pgadmin.org > >Относно: Re: [pgadmin-support] Debugger freeze > >До: Stefan Stefanov <stefanov...@abv.bg> > >Изпратено на: 12.02.2016 15:45 > > Hi > > On Thu, Feb 11, 2016 at 6:36 PM, Stefan Stefanov <stefanov...@abv.bg> > wrote: > > Dear Sir or Madam, > I am writing to report a bug in pgadmin III 1.22.0 running on Windows 7 > x64 connected to PostgreSQL 9.5.0 VC++ build 1800, 64 bit. > To reproduce the bug create this trivial function using SQL query editor. > The example is in "playground" schema. > > create function playground.dbg_test() returns void as > $$ > declare > i integer; > t text; > begin > for i in 1 .. 100 loop > t := 'XYZ' || to_char(i, '999'); > raise notice 'Round %', t; > end loop; > end; > $$ language plpgsql; > > Right-click the function in Object browser then debug. Step a few times > through the loop then take some time doing other things in pgadmin iii > (browse data, run queries etc.) then return to the debug window and step > again a few times. The debug window usually freezes (debug.png). > Two locks remain (server status.png). The server may be cleared by > cancelling the query of the global listener (pid 7748 in the example) but > then pgadmin windows stop responding. > > This is preventing me from using the debugger and I need it badly. > > > I've tried to reproduce this but am unable, even letting my machine go > into powersave mode while the function is running. > > Can anyone else reproduce? > > Stefan, could it be that you're suffering from network disconnections? > pgAdmin 3 really doesn't like them, and unfortunately it's a hard problem > to fix given the current code structure (it's one of the things we're > fixing in pgAdmin 4 which is completely new). > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
