Re: [pgadmin-hackers] [pgadmin-support] pgAdmin 1.18.0 + slony-I 2.2.0 + PG 9.3

2014-02-10 Thread Dave Page 
Ashesh; can you review this please?

Thanks.


On Fri, Feb 7, 2014 at 9:17 AM, Dinesh Kumar
wrote:

> Hi Dave/Team,
>
> I would like to take the owner ship of this patch from now onwards.
>
> Sorry for my previous test case result, which is an improper one from my
> side. I believe, i need to configure the same slony version on PG 9.2 as
> well. It seems an expected behaviour if the slony version is not match.
>
> And also i have fixed one small version bug as below.
>
> BUG Details
> --
> After configuring the slony on PG 9.2 server follow the below steps.
>
> 1. Launch pgadmin III
> 2. Add New server and Right Click on Slony cluster node
> 3. Click on Restart node
> 4. Error occurred regarding procpid does not exist. (Image is attached)
>
> I have fixed this trivial bug on top of Neel's patch, and sending single
> patch for these two issues.
>
> Kindly let me know, if i miss anything here.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>
> --
> *Dinesh Kumar*
> Software Engineer
>
> Ph: +918087463317
>  Skype ID: dinesh.kumar432
> www.enterprisedb.co 
> m
>
> *Follow us on Twitter*
> @EnterpriseDB
>
> Visit EnterpriseDB for tutorials, webinars, 
> whitepapers and
> more 
>
>
> On Tue, Dec 10, 2013 at 2:49 AM, Dinesh Kumar <
> dinesh.ku...@enterprisedb.com> wrote:
>
>> Hi Neel,
>>
>> On Mon, Nov 11, 2013 at 6:46 PM, Neel Patel 
>> wrote:
>>
>>> Hi Ashesh,
>>>
>>> Please find the updated patch with below fix.
>>>
>>> -- Fix for slony version 1.2.23 with PG 9.0
>>> -- Picking the correct version of slony1_base.xxx.sql
>>> -- Fix the error "no schema has been selected to create in". It gives
>>> error after deleting the slony cluster and again create thenew slony
>>> cluster.
>>> -- Fix for function storeNode() API which is accepting three arguments
>>> in slony version 1.1 and 1.2 and two arguments in
>>>slony version 2.0 and above.
>>>
>>> Please let me know for any comments.
>>>
>>
>> I have tested this patch, and seems working fine. I have found one small
>> issue when i try to create a new slony cluster with PG 9.2. When i am
>> trying to create a new cluster in PG 9.2 by setting the slony-path of PG
>> 9.3, then it' showing the
>> "ERROR:  could not access file "$libdir/slony1_funcs.2.2.0": No such file
>> or directory".
>>
>> Could you look into this as well.
>>
>> Thanks,
>> Dinesh
>>
>>
>>>
>>> Thanks,
>>> Neel Patel
>>>
>>>
>>> On Thu, Oct 31, 2013 at 9:41 AM, Neel Patel >> > wrote:
>>>
 Hi,

 Thanks Ashesh.

 I will check and let you know.

 Thanks,
 Neel Patel


 On Wed, Oct 30, 2013 at 5:19 PM, Ashesh Vashi <
 ashesh.va...@enterprisedb.com> wrote:

> Hi Neel,
>
> I test the patch with following slony-I versions:
> 1.2.27  (not working with PG 9.0)
> 2.0.x(not picking correct slony1_base.xxx.sql - as per comment, it
> should pick slony1_base.v84.sql with PG 8.4 and above, but picking
> slony1_base.v83.sql)
>
> I have not tested further.
> Can you please take a look at it?
>
>
>
> On Tue, Oct 29, 2013 at 3:38 PM, Dave Page  > wrote:
>
>> Ashesh, can you look at this one as well please? Thanks.
>>
>> On Tue, Oct 22, 2013 at 8:34 AM, Neel Patel <
>> neel.pa...@enterprisedb.com> wrote:
>> > Hi Dave,
>> >
>> > We have fixed the below two issues to support in Slony version
>> 2.2.0 with PG
>> > 9.3 in pgAdmin.
>> >
>> > Issue 1:-
>> >
>> > Bug to reproduce:-
>> >
>> > - Install PG 9.3 and slony 2.2.0
>> > - Right click on database and click on option "New slony-I
>> cluster..."
>> > - In the dialog we are able to see the error in status bar saying
>> "Slony-I
>> > creation scripts not available; only joining possible"
>> >
>> > Solution :-
>> >
>> > As per the above conversation in new version of slony 2.2.0
>> installation
>> > name of the sql files got changed so it is not able to find the
>> current
>> > slony version.
>> >
>> >
>> > Issue 2:-
>> >
>> > "storenode" API contains three argument in slony version 1.1 and
>> 1.2 but in
>> > slony version 2.0 onwards it contains only two arguments so that
>> issue also
>> > fixed.
>> >
>> >
>> > As per our knowledge we have tested this patch in slony 2.2.0 with
>> PG 9.3.
>> >
>> > Can anyone please test this patch and let us know if any bugs.
>> >
>> >
>> > Thanks,
>> > Neel Patel
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Oct 11, 2013 at 5:17 PM, Neel Patel <
>> neel.pa...@enterprisedb.com>
>> > wrote:
>> >>
>> >> Hi Sven,
>> >>
>> >> No idea regarding the next release.
>> >>
>> >> Thanks,
>> >> Neel Patel
>> >>

Re: [pgadmin-hackers] debugger.c tries to set log_min_messages, why?

2014-02-10 Thread Ashesh Vashi 
On Sat, Feb 8, 2014 at 10:49 PM, Guillaume Lelarge
wrote:

> Hi,
>
> Just a quick question. If you try to use the debugger, it executes a
> "SET log_min_messages TO fatal", which denies any regular user to debug
> his own functions. And actually, I don't see any reason why it should
> set log_min_messages. If there is, which is it?
>
When redesigning the debugger, I did not modify the existing connection
settings without much thoughts.
After reading this mail, I couldn't agree more with you. It shouldn't be
there.

>
> Thanks.
>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company


*http://www.linkedin.com/in/asheshvashi*

Re: [pgadmin-hackers] debugger.c tries to set log_min_messages, why?

2014-02-10 Thread Ashesh Vashi 
On Mon, Feb 10, 2014 at 9:54 PM, Guillaume Lelarge
wrote:

> On Mon, 2014-02-10 at 21:46 +0530, Ashesh Vashi wrote:
> > On Sat, Feb 8, 2014 at 10:49 PM, Guillaume Lelarge
> > wrote:
> >
> > > Hi,
> > >
> > > Just a quick question. If you try to use the debugger, it executes a
> > > "SET log_min_messages TO fatal", which denies any regular user to debug
> > > his own functions. And actually, I don't see any reason why it should
> > > set log_min_messages. If there is, which is it?
> > >
> > When redesigning the debugger, I did not modify the existing connection
> > settings without much thoughts.
> > After reading this mail, I couldn't agree more with you. It shouldn't be
> > there.
> >
>
> Good to know. Are you working on this, or should I provide a patch?
>
I will do it.
Thanks

>
>
> --
> Guillaume
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>
>


-- 
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company



*http://www.linkedin.com/in/asheshvashi*

Re: [pgadmin-hackers] debugger.c tries to set log_min_messages, why?

2014-02-10 Thread Guillaume Lelarge 
On Mon, 2014-02-10 at 21:46 +0530, Ashesh Vashi wrote:
> On Sat, Feb 8, 2014 at 10:49 PM, Guillaume Lelarge
> wrote:
> 
> > Hi,
> >
> > Just a quick question. If you try to use the debugger, it executes a
> > "SET log_min_messages TO fatal", which denies any regular user to debug
> > his own functions. And actually, I don't see any reason why it should
> > set log_min_messages. If there is, which is it?
> >
> When redesigning the debugger, I did not modify the existing connection
> settings without much thoughts.
> After reading this mail, I couldn't agree more with you. It shouldn't be
> there.
> 

Good to know. Are you working on this, or should I provide a patch?


-- 
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com



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

Re: [pgadmin-hackers] debugger.c tries to set log_min_messages, why?

2014-02-10 Thread Guillaume Lelarge 
On Mon, 2014-02-10 at 21:59 +0530, Ashesh Vashi wrote:
> On Mon, Feb 10, 2014 at 9:54 PM, Guillaume Lelarge
> wrote:
> 
> > On Mon, 2014-02-10 at 21:46 +0530, Ashesh Vashi wrote:
> > > On Sat, Feb 8, 2014 at 10:49 PM, Guillaume Lelarge
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Just a quick question. If you try to use the debugger, it executes a
> > > > "SET log_min_messages TO fatal", which denies any regular user to debug
> > > > his own functions. And actually, I don't see any reason why it should
> > > > set log_min_messages. If there is, which is it?
> > > >
> > > When redesigning the debugger, I did not modify the existing connection
> > > settings without much thoughts.
> > > After reading this mail, I couldn't agree more with you. It shouldn't be
> > > there.
> > >
> >
> > Good to know. Are you working on this, or should I provide a patch?
> >
> I will do it.
> Thanks
> 

OK, thanks, Ashesh :)


-- 
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com



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

[pgadmin-hackers] PATCH: Fix bug in inherited column definition

2014-02-10 Thread J.F. Oster 
Hello!

Please see attached screenshot and a patch to fix that.

There are 6 system columns (tableoid,cmax,xmax,cmin,xmin,ctid) which
are counted before inherited columns go.
Steps to reproduce:
 1. Connect to database
 2. Create table parenttable (f1 integer, f2 integer,... and so on)
 3. Create table childtable inherits (parenttable)
 4. In "Options - UI Miscellaneous" enable "Show System Objects in the
 treeview".
 5. See definition of childtable.

Also free up memory taken by pgSet *inhtables.
 
-- 
Best regards,
 J.F.<>

140210_inherited_columns.patch
Description: Binary data

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

Re: [pgadmin-hackers] [pgadmin-support] pgAdmin 1.18.0 + slony-I 2.2.0 + PG 9.3

2014-02-10 Thread Ashesh Vashi 
Sure


On Mon, Feb 10, 2014 at 8:00 PM, Dave Page  wrote:

> Ashesh; can you review this please?
>
> Thanks.
>
>
> On Fri, Feb 7, 2014 at 9:17 AM, Dinesh Kumar <
> dinesh.ku...@enterprisedb.com> wrote:
>
>> Hi Dave/Team,
>>
>> I would like to take the owner ship of this patch from now onwards.
>>
>> Sorry for my previous test case result, which is an improper one from my
>> side. I believe, i need to configure the same slony version on PG 9.2 as
>> well. It seems an expected behaviour if the slony version is not match.
>>
>> And also i have fixed one small version bug as below.
>>
>> BUG Details
>> --
>> After configuring the slony on PG 9.2 server follow the below steps.
>>
>> 1. Launch pgadmin III
>> 2. Add New server and Right Click on Slony cluster node
>> 3. Click on Restart node
>> 4. Error occurred regarding procpid does not exist. (Image is attached)
>>
>> I have fixed this trivial bug on top of Neel's patch, and sending single
>> patch for these two issues.
>>
>> Kindly let me know, if i miss anything here.
>>
>> Thanks in advance.
>>
>> Regards,
>> Dinesh
>>
>> --
>> *Dinesh Kumar*
>> Software Engineer
>>
>> Ph: +918087463317
>>  Skype ID: dinesh.kumar432
>> www.enterprisedb.co 
>> m
>>
>> *Follow us on Twitter*
>> @EnterpriseDB
>>
>> Visit EnterpriseDB for tutorials, webinars, 
>> whitepapers and
>> more 
>>
>>
>> On Tue, Dec 10, 2013 at 2:49 AM, Dinesh Kumar <
>> dinesh.ku...@enterprisedb.com> wrote:
>>
>>> Hi Neel,
>>>
>>> On Mon, Nov 11, 2013 at 6:46 PM, Neel Patel >> > wrote:
>>>
 Hi Ashesh,

 Please find the updated patch with below fix.

 -- Fix for slony version 1.2.23 with PG 9.0
 -- Picking the correct version of slony1_base.xxx.sql
 -- Fix the error "no schema has been selected to create in". It gives
 error after deleting the slony cluster and again create thenew slony
 cluster.
 -- Fix for function storeNode() API which is accepting three arguments
 in slony version 1.1 and 1.2 and two arguments in
slony version 2.0 and above.

 Please let me know for any comments.

>>>
>>> I have tested this patch, and seems working fine. I have found one small
>>> issue when i try to create a new slony cluster with PG 9.2. When i am
>>> trying to create a new cluster in PG 9.2 by setting the slony-path of PG
>>> 9.3, then it' showing the
>>> "ERROR:  could not access file "$libdir/slony1_funcs.2.2.0": No such
>>> file or directory".
>>>
>>> Could you look into this as well.
>>>
>>> Thanks,
>>> Dinesh
>>>
>>>

 Thanks,
 Neel Patel


 On Thu, Oct 31, 2013 at 9:41 AM, Neel Patel <
 neel.pa...@enterprisedb.com> wrote:

> Hi,
>
> Thanks Ashesh.
>
> I will check and let you know.
>
> Thanks,
> Neel Patel
>
>
> On Wed, Oct 30, 2013 at 5:19 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Neel,
>>
>> I test the patch with following slony-I versions:
>> 1.2.27  (not working with PG 9.0)
>> 2.0.x(not picking correct slony1_base.xxx.sql - as per comment,
>> it should pick slony1_base.v84.sql with PG 8.4 and above, but picking
>> slony1_base.v83.sql)
>>
>> I have not tested further.
>> Can you please take a look at it?
>>
>>
>>
>> On Tue, Oct 29, 2013 at 3:38 PM, Dave Page <
>> dave.p...@enterprisedb.com> wrote:
>>
>>> Ashesh, can you look at this one as well please? Thanks.
>>>
>>> On Tue, Oct 22, 2013 at 8:34 AM, Neel Patel <
>>> neel.pa...@enterprisedb.com> wrote:
>>> > Hi Dave,
>>> >
>>> > We have fixed the below two issues to support in Slony version
>>> 2.2.0 with PG
>>> > 9.3 in pgAdmin.
>>> >
>>> > Issue 1:-
>>> >
>>> > Bug to reproduce:-
>>> >
>>> > - Install PG 9.3 and slony 2.2.0
>>> > - Right click on database and click on option "New slony-I
>>> cluster..."
>>> > - In the dialog we are able to see the error in status bar saying
>>> "Slony-I
>>> > creation scripts not available; only joining possible"
>>> >
>>> > Solution :-
>>> >
>>> > As per the above conversation in new version of slony 2.2.0
>>> installation
>>> > name of the sql files got changed so it is not able to find the
>>> current
>>> > slony version.
>>> >
>>> >
>>> > Issue 2:-
>>> >
>>> > "storenode" API contains three argument in slony version 1.1 and
>>> 1.2 but in
>>> > slony version 2.0 onwards it contains only two arguments so that
>>> issue also
>>> > fixed.
>>> >
>>> >
>>> > As per our knowledge we have tested this patch in slony 2.2.0 with
>>> PG 9.3.
>>> >
>>> > Can anyone please test this patch and let us know if any bugs.
>>> >
>>> >
>>> >