Re: [pgadmin-support] Debugger freeze

[Stefan Stefanov]

 
 
   Hi,
  

  
This function and any other function work as usual outside of the debugger. 
Actually I found the problem when debugging a 'real' function. This one is just 
for the sake of a clean test.
  
It seems that the delay causes the failure. I did this: start a debug session 
and loop quickly through the function body a hundred times step by step. It 
finished normally. Then started again then looped ten times then left it for 
about 3 minutes (the debug window did not lose focus) and then it froze with 
(2016-02-15 21:35:06 EET


 ERROR


 could not find block containing chunk 01357490) in the log.
  

  
I am not sure whether the problem first appeared on 9.5 or before. Please allow 
for some time to test on another server instance.
  

  
Sincerely, Stefan
  

  

  

  
 > Оригинално писмо  
  
 >От: Korry Douglas korry.doug...@enterprisedb.com 
  
 >Относно: Re: [pgadmin-support] Debugger freeze 
  
 >До: Dave Page   
  
 >Изпратено на: 15.02.2016 18:01 
  

  
 
   
As Dave mentioned, the interesting error message is probably this one: 
   
 

 could not find block containing chunk 01176B70 

 
 That error occurs when the database server is trying to free a chunk of 
memory from a MemoryContext, but can't find the chunk within the context that 
owns the chunk.
 
   
 
   
 There is no legitimate reason that this can happen (in other words, it's a 
bug). 
   
 
   
 In you description you say: 
   
 

 Step a few times through the loop then take some time doing other things 
in pgadmin iii 

 
 Do you think it's the delay that makes it fail?
 Or is it perhaps the other activity (browsing other data, running queries)?


 What happens if you let the debug session sit idle for a few minutes and then 
try stepping through your code?
 
   
 
   
 And (apologies if you've already answered these questions), can you run the 
sample function (dbg_test()) without the debugger?
 Can you debug other functions?
 Is this failure new with PG 9.5? 
   
 
   
 Thanks. 
   
 
   
 
   
 


 


 


 


 


 -- Korry 
   
 


 
   
 
   
 
   
 



 The intriguing error message here is "could not find block containing 
chunk 01176B70", 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_00.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 01176B70 
 
 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.

Re: [pgadmin-support] Debugger freeze

[Stefan Stefanov]

Hi,
dbg_test() debugs happily on the same Pgadmin iii connected to Postgresql 9.2.8 
compiled by VC++ build 1600 32-bit running on windows-7 32-bit. 
Sincerely, 

Stefan







 > Оригинално писмо 

 >От: Korry Douglas korry.doug...@enterprisedb.com

 >Относно: Re: [pgadmin-support] Debugger freeze

 >До: Dave Page  

 >Изпратено на: 15.02.2016 18:01



   
 
  
   
   As Dave mentioned, the interesting error message is probably this one:
   
 

could not find block containing chunk 01176B70

 
 That error occurs when the database server is trying to free a chunk of 
memory from a MemoryContext, but can't find the chunk within the context that 
owns the chunk.
 
   
 
   
 There is no legitimate reason that this can happen (in other words, it's a 
bug).
   
 
   
 In you description you say: 
   
 

Step a few times through the loop then take some time doing other things in 
pgadmin iii

 
 Do you think it's the delay that makes it fail?
 Or is it perhaps the other activity (browsing other data, running queries)?


 What happens if you let the debug session sit idle for a few minutes and then 
try stepping through your code?
 
   
 
   
 And (apologies if you've already answered these questions), can you run the 
sample function (dbg_test()) without the debugger?
 Can you debug other functions?
 Is this failure new with PG 9.5?
   
 
   
 Thanks.
   
 
   
 
   
 


 


 


 


 


 -- Korry
   
 


 
   
 
   
 
   
 



The intriguing error message here is "could not find block containing chunk 
01176B70", 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_00.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 01176B70
 
 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 ed

Re: [pgadmin-support] Debugger freeze

[Korry Douglas]

Like Dave, I am not able to replicate the problem.  However, I tested 
with a Linux version of the database server and a Linux version of pgAdmin.


Dave, did you test on Windows or Linux?

Stefan - did you compile these packages (the database server and 
pgAdmin) yourself?  Or did you download and install a pre-built installer?


-- Korry


Hi,

This function and any other function work as usual outside of the 
debugger. Actually I found the problem when debugging a 'real' 
function. This one is just for the sake of a clean test.
It seems that the delay causes the failure. I did this: start a debug 
session and loop quickly through the function body a hundred times 
step by step. It finished normally. Then started again then looped ten 
times then left it for about 3 minutes (the debug window did not lose 
focus) and then it froze with (2016-02-15 21:35:06 EETERROR
could not find block containing chunk 01357490) in the log.


I am not sure whether the problem first appeared on 9.5 or before. 
Please allow for some time to test on another server instance.


Sincerely, Stefan



> Оригинално писмо 
>От: Korry Douglas korry.doug...@enterprisedb.com
>Относно: Re: [pgadmin-support] Debugger freeze
>До: Dave Page 
>Изпратено на: 15.02.2016 18:01

As Dave mentioned, the interesting error message is probably this one:

could not find block containing chunk 01176B70

That error occurs when the database server is trying to free a chunk 
of memory from a MemoryContext, but can't find the chunk within the 
context that owns the chunk.


There is no legitimate reason that this can happen (in other words, 
it's a bug).


In you description you say:

Step a few times through the loop then take some time doing other
things in pgadmin iii

Do you think it's the delay that makes it fail?  Or is it perhaps the 
other activity (browsing other data, running queries)?What happens 
if you let the debug session sit idle for a few minutes and then try 
stepping through your code?


And (apologies if you've already answered these questions), can you 
run the sample function (dbg_test()) without the debugger? Can you 
debug other functions?  Is this failure new with PG 9.5?


Thanks.


-- Korry



The intriguing error message here is "could not find block
containing chunk 01176B70", 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
 wrote:

Hi Dave, this part of pg_log/postgresql-2016-02-13_00.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 01176B70
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

Re: [pgadmin-support] Debugger freeze

[Stefan Stefanov]

Korry,
I used EDB graphic installer.
Sincerely, 

Stefan






 > Оригинално писмо 

 >От: Korry Douglas korry.doug...@enterprisedb.com

 >Относно: Re: [pgadmin-support] Debugger freeze

 >До: Stefan Stefanov  

 >Изпратено на: 15.02.2016 23:30



   
 
  
   
   
 Like Dave, I am not able to replicate the problem.
 However, I tested with a Linux version of the database server and a Linux 
version of pgAdmin.
   
 
   
 Dave, did you test on Windows or Linux?
   
 
   
 Stefan - did you compile these packages (the database server and pgAdmin) 
yourself?
 Or did you download and install a pre-built installer?
   
 
   
 


 


 


 -- Korry
   
 
   
 

   
Hi, 
   
 
   
 This function and any other function work as usual outside of the debugger. 
Actually I found the problem when debugging a 'real' function. This one is just 
for the sake of a clean test. 
   
 It seems that the delay causes the failure. I did this: start a debug session 
and loop quickly through the function body a hundred times step by step. It 
finished normally. Then started again then looped ten times then left it for 
about 3 minutes (the debug window did not lose focus) and then it froze with 
(2016-02-15 21:35:06 EET


 ERROR


 could not find block containing chunk 01357490) in the log. 
   
 
   
 I am not sure whether the problem first appeared on 9.5 or before. Please 
allow for some time to test on another server instance. 
   
 
   
 Sincerely, Stefan 
   
 
   
 
   
 
   
 > Оригинално писмо  
   
 >От: Korry Douglas 
korry.doug...@enterprisedb.com  
   
 >Относно: Re: [pgadmin-support] Debugger freeze 
   
 >До: Dave Page 
   
   
 >Изпратено на: 15.02.2016 18:01 
   
 
   
 

 As Dave mentioned, the interesting error message is probably this one: 

 
 
  could not find block containing chunk 01176B70 
 
 
  That error occurs when the database server is trying to free a chunk of 
memory from a MemoryContext, but can't find the chunk within the context that 
owns the chunk.
 

 

 There is no legitimate reason that this can happen (in other words, it's a 
bug). 

 

 In you description you say: 

 
 
  Step a few times through the loop then take some time doing other things 
in pgadmin iii 
 
 
  Do you think it's the delay that makes it fail?
 Or is it perhaps the other activity (browsing other data, running queries)?


 What happens if you let the debug session sit idle for a few minutes and then 
try stepping through your code?
 

 

 And (apologies if you've already answered these questions), can you run the 
sample function (dbg_test()) without the debugger?
 Can you debug other functions?
 Is this failure new with PG 9.5? 

 

 Thanks. 

 

 

 


 


 


 


 


 -- Korry 

 


 

 

 

 
 
 
 
  The intriguing error message here is "could not find block containing 
chunk 01176B70", 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_00.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 01176B70 
  
 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. 
   

Re: [pgadmin-support] Copy & paste key commands not working correctly

[johannes graën]

On Tue, Feb 9, 2016 at 2:55 PM, Gabriel Sánchez
 wrote:
> The same happens to me. Although copying and waiting usually works for me.

I've got a new clue. Although cut + paste inserts the wrong text, the
cutted text is available to other programs afterwards. So my guess
would be that pgadmin just uses the wrong clipboard to insert from.


-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [pgadmin-support] Debugger freeze

[Dave Page]

On Mon, Feb 15, 2016 at 9:30 PM, Korry Douglas <
korry.doug...@enterprisedb.com> wrote:

>
> Like Dave, I am not able to replicate the problem.  However, I tested with
> a Linux version of the database server and a Linux version of pgAdmin.
>
> Dave, did you test on Windows or Linux?
>

I tested on pgAdmin on Windows 7 and Mac OS X 10.11.3, using git master in
both cases (none of the debugger code has changed since release).

Both were connecting to the EDB 9.4.0 (yeah, I know - it's my laptop)
server on the Mac.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] Copy & paste key commands not working correctly

[Dave Page]

On Tue, Feb 16, 2016 at 8:13 AM, johannes graën  wrote:

> On Tue, Feb 9, 2016 at 2:55 PM, Gabriel Sánchez
>  wrote:
> > The same happens to me. Although copying and waiting usually works for
> me.
>
> I've got a new clue. Although cut + paste inserts the wrong text, the
> cutted text is available to other programs afterwards. So my guess
> would be that pgadmin just uses the wrong clipboard to insert from.


pgAdmin just registers the shortcut (Ctrl+V) as part of the menu item,
therefore they call exactly the same code.

My best guess is that when you use Ctrl+V, some other control on the window
actually has focus and is "swallowing" the keypress before our code sees
it. Can you confirm that the SQL textbox is definitely the focussed control
when you hit Ctrl+V? Does it work properly then?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] DEFAULT PRIVILEGES incorrect

[Sanket Mehta]

Hi Dave,

Below is my understanding of this issue:

In ALTER DEFAULT PRIVLEGES statement, "FOR ROLE  "part is
missing.

as per postgresql documentation target_name should follow below rule:

target_name:
The name of an existing role of which the current role is a member. If FOR
ROLE is omitted, the current role is assumed.

So target_name should be owner of this schema which is "foo".


Please let me know if I am right in my understanding or something is
missing.



Regards,
Sanket Mehta
Sr Software engineer
Enterprisedb

On Wed, Feb 10, 2016 at 3:53 PM, Sanket Mehta  wrote:

> Hi Dave,
>
> Sure I will look into it and get back.
>
> Regards,
> Sanket Mehta
> Sr Software engineer
> Enterprisedb
>
> On Wed, Feb 10, 2016 at 3:03 PM, Dave Page  wrote:
>
>> Sanket - can you take a look at this when you get a minute please?
>>
>> Thanks.
>>
>> On Wed, Feb 10, 2016 at 4:23 AM, Erwin Brandstetter 
>> wrote:
>> > This bug has not been addressed in pgAdmin 1.22.0, yet.
>> >
>> > If I run this as user postgres:
>> >
>> > ALTER DEFAULT PRIVILEGES FOR ROLE foo IN SCHEMA test
>> > GRANT SELECT ON TABLES
>> > TO bar;
>> >
>> > Then the SQL pane says (still as user postgres):
>> >
>> > ALTER DEFAULT PRIVILEGES IN SCHEMA test
>> > GRANT SELECT ON TABLES
>> > TO bar;
>> >
>> > Which is incorrect and misleading.
>> >
>> > Regards
>> >
>> > Erwin
>> >
>> > On Thu, Aug 13, 2015 at 2:45 PM, Erwin Brandstetter > >
>> > wrote:
>> >>
>> >> The display of ALTER DEFAULT PRIVILEGES statements can be incorrect.
>> >>
>> >> I reported this bug in 2013, but it seems like it never got through:
>> >> http://www.postgresql.org/message-id/528c2d00.6010...@falter.at
>> >>
>> >> Details, with steps to reproduce:
>> >> https://redmine.postgresql.org/issues/694
>> >>
>> >> Just tested with version 1.20 again and the situation seems unchanged.
>> >>
>> >> Regards
>> >> Erwin
>> >
>> >
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>

Re: [pgadmin-support] PgAdmin III 1.22 crashes, bug riport

[Dave Page]

On Mon, Feb 15, 2016 at 9:53 PM, Crain, Andrew 
wrote:

> Dave,
> I’ve been using the test build for several hours, longer than the typical
> interval between crashes, and have had no problems, including upon
> returning to the UI after a connection has become stale, which is when the
> problem typically occurs.
> Thanks!
> Andy
>

Great, that's promising! Did you get any reconnects during that time? The
changes I made should avoid crashes in a couple of circumstances I
speculated might be getting hit, but those circumstances would have still
led to a reconnect message.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] Copy & paste key commands not working correctly

[johannes graën]

On Tue, Feb 16, 2016 at 11:52 AM, Dave Page  wrote:
> My best guess is that when you use Ctrl+V, some other control on the window
> actually has focus and is "swallowing" the keypress before our code sees it.
> Can you confirm that the SQL textbox is definitely the focussed control when
> you hit Ctrl+V? Does it work properly then?

I'm navigating inside the textbox with the cursor keys when I do cut &
paste, so it definitely has the focus.


-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [pgadmin-support] Copy & paste key commands not working correctly

[Dave Page]

On Tue, Feb 16, 2016 at 10:57 AM, johannes graën 
wrote:

> On Tue, Feb 16, 2016 at 11:52 AM, Dave Page  wrote:
> > My best guess is that when you use Ctrl+V, some other control on the
> window
> > actually has focus and is "swallowing" the keypress before our code sees
> it.
> > Can you confirm that the SQL textbox is definitely the focussed control
> when
> > you hit Ctrl+V? Does it work properly then?
>
> I'm navigating inside the textbox with the cursor keys when I do cut &
> paste, so it definitely has the focus.
>

Hmm. I just spent time here trying to reproduce this on RHEL 7 and it seems
to work fine there.

Where did your build come from? What version of wxWidgets is it using?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] DEFAULT PRIVILEGES incorrect

[Dave Page]

On Tue, Feb 16, 2016 at 10:53 AM, Sanket Mehta <
sanket.me...@enterprisedb.com> wrote:

> Hi Dave,
>
> Below is my understanding of this issue:
>
> In ALTER DEFAULT PRIVLEGES statement, "FOR ROLE  "part is
> missing.
>

That's what Erwin has reported, yes.


>
> as per postgresql documentation target_name should follow below rule:
>
> target_name:
> The name of an existing role of which the current role is a member. If FOR
> ROLE is omitted, the current role is assumed.
>
> So target_name should be owner of this schema which is "foo".
>

I don't think the owner has anything to do with it. It says the name of an
existing role (of which the current role is a member), or the current role
if unspecified.


>
>
> Please let me know if I am right in my understanding or something is
> missing.
>
>
>
> Regards,
> Sanket Mehta
> Sr Software engineer
> Enterprisedb
>
> On Wed, Feb 10, 2016 at 3:53 PM, Sanket Mehta <
> sanket.me...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Sure I will look into it and get back.
>>
>> Regards,
>> Sanket Mehta
>> Sr Software engineer
>> Enterprisedb
>>
>> On Wed, Feb 10, 2016 at 3:03 PM, Dave Page  wrote:
>>
>>> Sanket - can you take a look at this when you get a minute please?
>>>
>>> Thanks.
>>>
>>> On Wed, Feb 10, 2016 at 4:23 AM, Erwin Brandstetter 
>>> wrote:
>>> > This bug has not been addressed in pgAdmin 1.22.0, yet.
>>> >
>>> > If I run this as user postgres:
>>> >
>>> > ALTER DEFAULT PRIVILEGES FOR ROLE foo IN SCHEMA test
>>> > GRANT SELECT ON TABLES
>>> > TO bar;
>>> >
>>> > Then the SQL pane says (still as user postgres):
>>> >
>>> > ALTER DEFAULT PRIVILEGES IN SCHEMA test
>>> > GRANT SELECT ON TABLES
>>> > TO bar;
>>> >
>>> > Which is incorrect and misleading.
>>> >
>>> > Regards
>>> >
>>> > Erwin
>>> >
>>> > On Thu, Aug 13, 2015 at 2:45 PM, Erwin Brandstetter <
>>> brsaw...@gmail.com>
>>> > wrote:
>>> >>
>>> >> The display of ALTER DEFAULT PRIVILEGES statements can be incorrect.
>>> >>
>>> >> I reported this bug in 2013, but it seems like it never got through:
>>> >> http://www.postgresql.org/message-id/528c2d00.6010...@falter.at
>>> >>
>>> >> Details, with steps to reproduce:
>>> >> https://redmine.postgresql.org/issues/694
>>> >>
>>> >> Just tested with version 1.20 again and the situation seems unchanged.
>>> >>
>>> >> Regards
>>> >> Erwin
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> 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

Re: [pgadmin-support] DEFAULT PRIVILEGES incorrect

[Sanket Mehta]

On Tue, Feb 16, 2016 at 4:34 PM, Dave Page  wrote:

>
>
> On Tue, Feb 16, 2016 at 10:53 AM, Sanket Mehta <
> sanket.me...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Below is my understanding of this issue:
>>
>> In ALTER DEFAULT PRIVLEGES statement, "FOR ROLE  "part is
>> missing.
>>
>
> That's what Erwin has reported, yes.
>
>
>>
>> as per postgresql documentation target_name should follow below rule:
>>
>> target_name:
>> The name of an existing role of which the current role is a member. If FOR
>> ROLE is omitted, the current role is assumed.
>>
>> So target_name should be owner of this schema which is "foo".
>>
>
> I don't think the owner has anything to do with it. It says the name of an
> existing role (of which the current role is a member), or the current role
> if unspecified.
>

In that case, it should be FOR ROLE 'postgres' as postgres is the current
role.

>
>
>>
>>
>> Please let me know if I am right in my understanding or something is
>> missing.
>>
>>
>>
>> Regards,
>> Sanket Mehta
>> Sr Software engineer
>> Enterprisedb
>>
>> On Wed, Feb 10, 2016 at 3:53 PM, Sanket Mehta <
>> sanket.me...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> Sure I will look into it and get back.
>>>
>>> Regards,
>>> Sanket Mehta
>>> Sr Software engineer
>>> Enterprisedb
>>>
>>> On Wed, Feb 10, 2016 at 3:03 PM, Dave Page  wrote:
>>>
 Sanket - can you take a look at this when you get a minute please?

 Thanks.

 On Wed, Feb 10, 2016 at 4:23 AM, Erwin Brandstetter 
 wrote:
 > This bug has not been addressed in pgAdmin 1.22.0, yet.
 >
 > If I run this as user postgres:
 >
 > ALTER DEFAULT PRIVILEGES FOR ROLE foo IN SCHEMA test
 > GRANT SELECT ON TABLES
 > TO bar;
 >
 > Then the SQL pane says (still as user postgres):
 >
 > ALTER DEFAULT PRIVILEGES IN SCHEMA test
 > GRANT SELECT ON TABLES
 > TO bar;
 >
 > Which is incorrect and misleading.
 >
 > Regards
 >
 > Erwin
 >
 > On Thu, Aug 13, 2015 at 2:45 PM, Erwin Brandstetter <
 brsaw...@gmail.com>
 > wrote:
 >>
 >> The display of ALTER DEFAULT PRIVILEGES statements can be incorrect.
 >>
 >> I reported this bug in 2013, but it seems like it never got through:
 >> http://www.postgresql.org/message-id/528c2d00.6010...@falter.at
 >>
 >> Details, with steps to reproduce:
 >> https://redmine.postgresql.org/issues/694
 >>
 >> Just tested with version 1.20 again and the situation seems
 unchanged.
 >>
 >> Regards
 >> Erwin
 >
 >



 --
 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
>

Re: [pgadmin-support] DEFAULT PRIVILEGES incorrect

[Dave Page]

On Tue, Feb 16, 2016 at 11:06 AM, Sanket Mehta <
sanket.me...@enterprisedb.com> wrote:

>
> On Tue, Feb 16, 2016 at 4:34 PM, Dave Page  wrote:
>
>>
>>
>> On Tue, Feb 16, 2016 at 10:53 AM, Sanket Mehta <
>> sanket.me...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> Below is my understanding of this issue:
>>>
>>> In ALTER DEFAULT PRIVLEGES statement, "FOR ROLE  "part is
>>> missing.
>>>
>>
>> That's what Erwin has reported, yes.
>>
>>
>>>
>>> as per postgresql documentation target_name should follow below rule:
>>>
>>> target_name:
>>> The name of an existing role of which the current role is a member. If FOR
>>> ROLE is omitted, the current role is assumed.
>>>
>>> So target_name should be owner of this schema which is "foo".
>>>
>>
>> I don't think the owner has anything to do with it. It says the name of
>> an existing role (of which the current role is a member), or the current
>> role if unspecified.
>>
>
> In that case, it should be FOR ROLE 'postgres' as postgres is the current
> role.
>

No, because in  Erwin's example he has this:

SET ROLE foo;



>
>>
>>>
>>>
>>> Please let me know if I am right in my understanding or something is
>>> missing.
>>>
>>>
>>>
>>> Regards,
>>> Sanket Mehta
>>> Sr Software engineer
>>> Enterprisedb
>>>
>>> On Wed, Feb 10, 2016 at 3:53 PM, Sanket Mehta <
>>> sanket.me...@enterprisedb.com> wrote:
>>>
 Hi Dave,

 Sure I will look into it and get back.

 Regards,
 Sanket Mehta
 Sr Software engineer
 Enterprisedb

 On Wed, Feb 10, 2016 at 3:03 PM, Dave Page  wrote:

> Sanket - can you take a look at this when you get a minute please?
>
> Thanks.
>
> On Wed, Feb 10, 2016 at 4:23 AM, Erwin Brandstetter <
> brsaw...@gmail.com> wrote:
> > This bug has not been addressed in pgAdmin 1.22.0, yet.
> >
> > If I run this as user postgres:
> >
> > ALTER DEFAULT PRIVILEGES FOR ROLE foo IN SCHEMA test
> > GRANT SELECT ON TABLES
> > TO bar;
> >
> > Then the SQL pane says (still as user postgres):
> >
> > ALTER DEFAULT PRIVILEGES IN SCHEMA test
> > GRANT SELECT ON TABLES
> > TO bar;
> >
> > Which is incorrect and misleading.
> >
> > Regards
> >
> > Erwin
> >
> > On Thu, Aug 13, 2015 at 2:45 PM, Erwin Brandstetter <
> brsaw...@gmail.com>
> > wrote:
> >>
> >> The display of ALTER DEFAULT PRIVILEGES statements can be incorrect.
> >>
> >> I reported this bug in 2013, but it seems like it never got through:
> >> http://www.postgresql.org/message-id/528c2d00.6010...@falter.at
> >>
> >> Details, with steps to reproduce:
> >> https://redmine.postgresql.org/issues/694
> >>
> >> Just tested with version 1.20 again and the situation seems
> unchanged.
> >>
> >> Regards
> >> Erwin
> >
> >
>
>
>
> --
> 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
>>
>
>


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] Copy & paste key commands not working correctly

[johannes graën]

On Tue, Feb 16, 2016 at 12:00 PM, Dave Page  wrote:
> Where did your build come from? What version of wxWidgets is it using?

It's an official Arch package:
https://www.archlinux.org/packages/community/x86_64/pgadmin3/

The wxWidgets version is 2.8.12.1:
https://www.archlinux.org/packages/extra/x86_64/wxgtk2.8/


-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [pgadmin-support] DEFAULT PRIVILEGES incorrect

[Erwin Brandstetter]

Hi Sanket!

The point is that "FOR ROLE foo" can only be omitted in the DDL command if
the *current *role is identical to the role for which it applies.

I would strongly advise not to try and build in this syntax shortcut at
all. It should be much simpler and less error prone to always add the
appropriate FOR ROLE clause in the reverse engineered DDL.

Currently this is missing and effectively incorrect.

Regards
Erwin

On Tue, Feb 16, 2016 at 12:11 PM, Dave Page  wrote:

>
>
> On Tue, Feb 16, 2016 at 11:06 AM, Sanket Mehta <
> sanket.me...@enterprisedb.com> wrote:
>
>>
>> On Tue, Feb 16, 2016 at 4:34 PM, Dave Page  wrote:
>>
>>>
>>>
>>> On Tue, Feb 16, 2016 at 10:53 AM, Sanket Mehta <
>>> sanket.me...@enterprisedb.com> wrote:
>>>
 Hi Dave,

 Below is my understanding of this issue:

 In ALTER DEFAULT PRIVLEGES statement, "FOR ROLE  "part is
 missing.

>>>
>>> That's what Erwin has reported, yes.
>>>
>>>

 as per postgresql documentation target_name should follow below rule:

 target_name:
 The name of an existing role of which the current role is a member. If FOR
 ROLE is omitted, the current role is assumed.

 So target_name should be owner of this schema which is "foo".

>>>
>>> I don't think the owner has anything to do with it. It says the name of
>>> an existing role (of which the current role is a member), or the current
>>> role if unspecified.
>>>
>>
>> In that case, it should be FOR ROLE 'postgres' as postgres is the current
>> role.
>>
>
> No, because in  Erwin's example he has this:
>
> SET ROLE foo;
>
>
>
>>
>>>


 Please let me know if I am right in my understanding or something is
 missing.



 Regards,
 Sanket Mehta
 Sr Software engineer
 Enterprisedb

 On Wed, Feb 10, 2016 at 3:53 PM, Sanket Mehta <
 sanket.me...@enterprisedb.com> wrote:

> Hi Dave,
>
> Sure I will look into it and get back.
>
> Regards,
> Sanket Mehta
> Sr Software engineer
> Enterprisedb
>
> On Wed, Feb 10, 2016 at 3:03 PM, Dave Page  wrote:
>
>> Sanket - can you take a look at this when you get a minute please?
>>
>> Thanks.
>>
>> On Wed, Feb 10, 2016 at 4:23 AM, Erwin Brandstetter <
>> brsaw...@gmail.com> wrote:
>> > This bug has not been addressed in pgAdmin 1.22.0, yet.
>> >
>> > If I run this as user postgres:
>> >
>> > ALTER DEFAULT PRIVILEGES FOR ROLE foo IN SCHEMA test
>> > GRANT SELECT ON TABLES
>> > TO bar;
>> >
>> > Then the SQL pane says (still as user postgres):
>> >
>> > ALTER DEFAULT PRIVILEGES IN SCHEMA test
>> > GRANT SELECT ON TABLES
>> > TO bar;
>> >
>> > Which is incorrect and misleading.
>> >
>> > Regards
>> >
>> > Erwin
>> >
>> > On Thu, Aug 13, 2015 at 2:45 PM, Erwin Brandstetter <
>> brsaw...@gmail.com>
>> > wrote:
>> >>
>> >> The display of ALTER DEFAULT PRIVILEGES statements can be
>> incorrect.
>> >>
>> >> I reported this bug in 2013, but it seems like it never got
>> through:
>> >> http://www.postgresql.org/message-id/528c2d00.6010...@falter.at
>> >>
>> >> Details, with steps to reproduce:
>> >> https://redmine.postgresql.org/issues/694
>> >>
>> >> Just tested with version 1.20 again and the situation seems
>> unchanged.
>> >>
>> >> Regards
>> >> Erwin
>> >
>> >
>>
>>
>>
>> --
>> 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
>>>
>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-support] PgAdmin III 1.22 crashes, bug riport

[Dave Page]

Hi

On Tue, Feb 16, 2016 at 3:36 AM, Strauch, Sheldon 
wrote:

> Hi Dave,
>
> PFA another dump attached.
>
> This happened again while resizing an SQL window with a moderate-sized
> query and a data grid with one column that is extremely large text.
>

I've just spent 20 minutes or so playing with a very large query result and
SQL script that's nearly 1MB in size, and I cannot get it to crash at all
here. Do you have access to another machine that you could try to reproduce
this one on?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] Copy & paste key commands not working correctly

[Dave Page]

On Tue, Feb 16, 2016 at 11:06 AM, johannes graën 
wrote:

> On Tue, Feb 16, 2016 at 12:00 PM, Dave Page  wrote:
> > Where did your build come from? What version of wxWidgets is it using?
>
> It's an official Arch package:
> https://www.archlinux.org/packages/community/x86_64/pgadmin3/


Huh, they have some weird dependencies listed there, that should not be
needed. That's not a problem though.


>
>
> The wxWidgets version is 2.8.12.1:
> https://www.archlinux.org/packages/extra/x86_64/wxgtk2.8/
>

That should be OK (some distros have started using wxWidgets 3, which we
don't fully support).

I've done some more testing on CentOS 6, and cannot reproduce a problem
there either. I'm beginning to wonder if it's something more
distro-specific, perhaps related to the version of GTK in use, or the
window manager. That makes it *far* more difficult to track down
unfortunately.

Are you in a position to be able to install the EDB PostgreSQL installer?
I'm curious to know if the build of pgAdmin that's included with that works
OK. It was built against a fairly old version of GTK for maximum
compatibility with different distros.

http://www.enterprisedb.com/products-services-training/pgdownload

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] Copy & paste key commands not working correctly

[Gabriel Sánchez]

On Feb 16, 2016 7:04 AM, "Dave Page"  wrote:
>
>
>
> On Tue, Feb 16, 2016 at 11:06 AM, johannes graën 
wrote:
>>
>> On Tue, Feb 16, 2016 at 12:00 PM, Dave Page  wrote:
>> > Where did your build come from? What version of wxWidgets is it using?
>>
>> It's an official Arch package:
>> https://www.archlinux.org/packages/community/x86_64/pgadmin3/
>
>
> Huh, they have some weird dependencies listed there, that should not be
needed. That's not a problem though.
>
>>
>>
>>
>> The wxWidgets version is 2.8.12.1:
>> https://www.archlinux.org/packages/extra/x86_64/wxgtk2.8/
>
>
> That should be OK (some distros have started using wxWidgets 3, which we
don't fully support).
>
> I've done some more testing on CentOS 6, and cannot reproduce a problem
there either. I'm beginning to wonder if it's something more
distro-specific, perhaps related to the version of GTK in use, or the
window manager. That makes it *far* more difficult to track down
unfortunately.
>
> Are you in a position to be able to install the EDB PostgreSQL installer?
I'm curious to know if the build of pgAdmin that's included with that works
OK. It was built against a fairly old version of GTK for maximum
compatibility with different distros.
>
> http://www.enterprisedb.com/products-services-training/pgdownload
>
>

I have the problem in Kububtu with the version downloaded from edb. As far
as I can tell, pgAdmin is not copying text when I hit copy either by
keyboard, shortcut, or menu. I checked my clipboard manager last time this
happened and the text was not there. Again, it doesn't happen always, but
it persists in a pgAdmin window once it begins to happen, and the copy does
happen eventually. Other laggy behavior showing up when this happens (such
as taking a full second to respond to a key press, and not registering all
key presses when this happens and I nevertheless type fast) suggests to me
that the problem is very slow cursor movement or text processing.

I have been trying to notice a pattern of what triggers it, but have not
seen any. It does happen often on windows with long queries and after
several copy paste ops within the window or between pgAdmin windows. But
not always. However I use many other programs and only see this bug with
pgAdmin.

Just want to add my thanks for this project, Dave. Great program, and I'm
looking forward to v4!

> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Re: [pgadmin-support] DEFAULT PRIVILEGES incorrect

[Sanket Mehta]

Hi,

I have evaluated the code and found another issue while trying to resolve
this bug.

Lets assume we have created 3 roles foo1, foo2 and bar1 and one schema
"test".
Now using foo1 role we have given SELECT privileges to bar1 as mentioned
below:

SELECT ROLE foo1;
ALTER DEFAULT PRIVILEGES IN SCHEMA test
GRANT SELECT ON TABLES TO bar1;
RESET ROLE;

And using foo2 role we have given ALL privileges to bar1:
SELECT ROLE foo2;
ALTER DEFAULT PRIVILEGES IN SCHEMA test
GRANT ALL ON TABLES TO bar1;
RESET ROLE;

so if you look at the output of pg_default_acl table, it will look as below:

   defaclroleschema  defobjtype   defaclacl
---
  21633  21637  r (table)  {bar1=r/foo1}
  21634  21637  r (table)  {bar1=arwdDxt/foo2}

where 21633 is oid of foo1 and 21634 is oid of foo2 and 21637 is oid of
test3.

So now we will have 2 granters(foo1, foo2) and 1 grantee(bar1) on schema
test

so to resolve the main issue mentioned by Erwin we have to show 2 ALTER
DEFAULT PRIVILEGES statement for both granter role in reversed engineering
query.

This solution will create another issue in property dialog of schema.

In property dialog -> default privileges tab -> roles and privileges are
listed only for current role but not for all granters.
so in our case only for current role (lets assume its foo1) it will show
default privileges but not for granter foo2.

I think resolving this issue is itself a big project which would take a lot
of time.

Let me know your thoughts on the same.





Regards,
Sanket Mehta
Sr Software engineer
Enterprisedb

On Tue, Feb 16, 2016 at 4:55 PM, Erwin Brandstetter 
wrote:

> Hi Sanket!
>
> The point is that "FOR ROLE foo" can only be omitted in the DDL command if
> the *current *role is identical to the role for which it applies.
>
> I would strongly advise not to try and build in this syntax shortcut at
> all. It should be much simpler and less error prone to always add the
> appropriate FOR ROLE clause in the reverse engineered DDL.
>
> Currently this is missing and effectively incorrect.
>
> Regards
> Erwin
>
> On Tue, Feb 16, 2016 at 12:11 PM, Dave Page  wrote:
>
>>
>>
>> On Tue, Feb 16, 2016 at 11:06 AM, Sanket Mehta <
>> sanket.me...@enterprisedb.com> wrote:
>>
>>>
>>> On Tue, Feb 16, 2016 at 4:34 PM, Dave Page  wrote:
>>>


 On Tue, Feb 16, 2016 at 10:53 AM, Sanket Mehta <
 sanket.me...@enterprisedb.com> wrote:

> Hi Dave,
>
> Below is my understanding of this issue:
>
> In ALTER DEFAULT PRIVLEGES statement, "FOR ROLE  "part is
> missing.
>

 That's what Erwin has reported, yes.


>
> as per postgresql documentation target_name should follow below rule:
>
> target_name:
> The name of an existing role of which the current role is a member. If FOR
> ROLE is omitted, the current role is assumed.
>
> So target_name should be owner of this schema which is "foo".
>

 I don't think the owner has anything to do with it. It says the name of
 an existing role (of which the current role is a member), or the current
 role if unspecified.

>>>
>>> In that case, it should be FOR ROLE 'postgres' as postgres is the
>>> current role.
>>>
>>
>> No, because in  Erwin's example he has this:
>>
>> SET ROLE foo;
>>
>>
>>
>>>

>
>
> Please let me know if I am right in my understanding or something is
> missing.
>
>
>
> Regards,
> Sanket Mehta
> Sr Software engineer
> Enterprisedb
>
> On Wed, Feb 10, 2016 at 3:53 PM, Sanket Mehta <
> sanket.me...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Sure I will look into it and get back.
>>
>> Regards,
>> Sanket Mehta
>> Sr Software engineer
>> Enterprisedb
>>
>> On Wed, Feb 10, 2016 at 3:03 PM, Dave Page  wrote:
>>
>>> Sanket - can you take a look at this when you get a minute please?
>>>
>>> Thanks.
>>>
>>> On Wed, Feb 10, 2016 at 4:23 AM, Erwin Brandstetter <
>>> brsaw...@gmail.com> wrote:
>>> > This bug has not been addressed in pgAdmin 1.22.0, yet.
>>> >
>>> > If I run this as user postgres:
>>> >
>>> > ALTER DEFAULT PRIVILEGES FOR ROLE foo IN SCHEMA test
>>> > GRANT SELECT ON TABLES
>>> > TO bar;
>>> >
>>> > Then the SQL pane says (still as user postgres):
>>> >
>>> > ALTER DEFAULT PRIVILEGES IN SCHEMA test
>>> > GRANT SELECT ON TABLES
>>> > TO bar;
>>> >
>>> > Which is incorrect and misleading.
>>> >
>>> > Regards
>>> >
>>> > Erwin
>>> >
>>> > On Thu, Aug 13, 2015 at 2:45 PM, Erwin Brandstetter <
>>> brsaw...@gmail.com>
>>> > wrote:
>>> >>
>>> >> The display of ALTER DEFAULT PRIVILEGES statements can be
>>> incorrect.
>>> >>
>>> >> I reported this bug in 2013, but it seems l

Re: [pgadmin-support] PgAdmin III 1.22 crashes, bug riport

[Crain, Andrew]

Dave,
Yes, I did get reconnects, several times (expected), and not one caused a 
crash. Looks like you nailed it.
Thanks!
Andy

From: Dave Page mailto:dp...@pgadmin.org>>
Date: Tuesday, February 16, 2016 at 5:54 AM
To: "Crain, Andrew" 
mailto:acr...@cincinna.gannett.com>>
Cc: "Strauch, Sheldon" mailto:sstra...@enova.com>>, 
"pgadmin-support@postgresql.org" 
mailto:pgadmin-support@postgresql.org>>
Subject: Re: PgAdmin III 1.22 crashes, bug riport



On Mon, Feb 15, 2016 at 9:53 PM, Crain, Andrew 
mailto:acr...@cincinna.gannett.com>> wrote:
Dave,
I’ve been using the test build for several hours, longer than the typical 
interval between crashes, and have had no problems, including upon returning to 
the UI after a connection has become stale, which is when the problem typically 
occurs.
Thanks!
Andy

Great, that's promising! Did you get any reconnects during that time? The 
changes I made should avoid crashes in a couple of circumstances I speculated 
might be getting hit, but those circumstances would have still led to a 
reconnect message.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-support] Copy & paste key commands not working correctly

[Gabriel E . Sánchez Martínez]

On 02/16/2016 07:23 AM, Gabriel Sánchez wrote:



On Feb 16, 2016 7:04 AM, "Dave Page" > wrote:

>
>
>
> On Tue, Feb 16, 2016 at 11:06 AM, johannes graën 
mailto:johan...@selfnet.de>> wrote:

>>
>> On Tue, Feb 16, 2016 at 12:00 PM, Dave Page > wrote:
>> > Where did your build come from? What version of wxWidgets is it 
using?

>>
>> It's an official Arch package:
>> https://www.archlinux.org/packages/community/x86_64/pgadmin3/
>
>
> Huh, they have some weird dependencies listed there, that should not 
be needed. That's not a problem though.

>
>>
>>
>>
>> The wxWidgets version is 2.8.12.1 :
>> https://www.archlinux.org/packages/extra/x86_64/wxgtk2.8/
>
>
> That should be OK (some distros have started using wxWidgets 3, 
which we don't fully support).

>
> I've done some more testing on CentOS 6, and cannot reproduce a 
problem there either. I'm beginning to wonder if it's something more 
distro-specific, perhaps related to the version of GTK in use, or the 
window manager. That makes it *far* more difficult to track down 
unfortunately.

>
> Are you in a position to be able to install the EDB PostgreSQL 
installer? I'm curious to know if the build of pgAdmin that's included 
with that works OK. It was built against a fairly old version of GTK 
for maximum compatibility with different distros.

>
> http://www.enterprisedb.com/products-services-training/pgdownload
>
>

I have the problem in Kububtu with the version downloaded from edb. As 
far as I can tell, pgAdmin is not copying text when I hit copy either 
by keyboard, shortcut, or menu. I checked my clipboard manager last 
time this happened and the text was not there. Again, it doesn't 
happen always, but it persists in a pgAdmin window once it begins to 
happen, and the copy does happen eventually. Other laggy behavior 
showing up when this happens (such as taking a full second to respond 
to a key press, and not registering all key presses when this happens 
and I nevertheless type fast) suggests to me that the problem is very 
slow cursor movement or text processing.


I have been trying to notice a pattern of what triggers it, but have 
not seen any. It does happen often on windows with long queries and 
after several copy paste ops within the window or between pgAdmin 
windows. But not always. However I use many other programs and only 
see this bug with pgAdmin.


Just want to add my thanks for this project, Dave. Great program, and 
I'm looking forward to v4!




Following up, I upgraded from 1.20 to 1.22.1 from a fresh EDB download.  
I opened a query window, copied in some text, and began copy-pasting and 
typing randomly, and was able to reproduce the bug within a minute.  I 
recorded video, which you can get here:


http://www.filedropper.com/screencast2016-02-16100737

You can see that I am selecting text.  Following every selection, I 
quickly do a copy, and then I move the cursor somewhere and do a paste.  
I also type random keys.  Everything works as expected until about 0:34, 
when I try to paste and it doesn't.  Then I type quickly "asdfjkl;" many 
times, and you can see only a few of those keys are typed, and the 
response is laggy.  I try pasting several times again in the lines 
below, but it still doesn't work (0:40).  I type again, and response 
seems to be a bit better.  I try paste again and this time it works 
(0:46).  While on this video it seems to have recovered, my experience 
has been that it doesn't.  It's especially annoying when you have a 
session with temporary tables that take a long time to prepare, because 
it costs time to start a new session and re-make the temporary tables.


Once again, many thanks for your attention to this.


> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Re: [pgadmin-support] PgAdmin III 1.22 crashes, bug riport

[Dave Page]

Cool - thanks. I'll go commit that patch :-)

On Tue, Feb 16, 2016 at 3:11 PM, Crain, Andrew 
wrote:

> Dave,
> Yes, I did get reconnects, several times (expected), and not one caused a
> crash. Looks like you nailed it.
> Thanks!
> Andy
>
> From: Dave Page 
> Date: Tuesday, February 16, 2016 at 5:54 AM
> To: "Crain, Andrew" 
> Cc: "Strauch, Sheldon" , "
> pgadmin-support@postgresql.org" 
> Subject: Re: PgAdmin III 1.22 crashes, bug riport
>
>
>
> On Mon, Feb 15, 2016 at 9:53 PM, Crain, Andrew <
> acr...@cincinna.gannett.com> wrote:
>
>> Dave,
>> I’ve been using the test build for several hours, longer than the typical
>> interval between crashes, and have had no problems, including upon
>> returning to the UI after a connection has become stale, which is when the
>> problem typically occurs.
>> Thanks!
>> Andy
>>
>
> Great, that's promising! Did you get any reconnects during that time? The
> changes I made should avoid crashes in a couple of circumstances I
> speculated might be getting hit, but those circumstances would have still
> led to a reconnect message.
>
> --
> 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

Re: [pgadmin-support] Copy & paste key commands not working correctly

[johannes graën]

On Tue, Feb 16, 2016 at 1:04 PM, Dave Page  wrote:
> Are you in a position to be able to install the EDB PostgreSQL installer?
> I'm curious to know if the build of pgAdmin that's included with that works
> OK. It was built against a fairly old version of GTK for maximum
> compatibility with different distros.

I tried that, but pgadmin won't be executed because of a library
missing which is not available on my system.


-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support