Thread: pg admin 92 beta 3 - bug report - row number 19 is out of range 0..18
With reference to: http://www.postgresql.org/message-id/A98BBDA7653C7241BE0BCF46AF5A043EED8FEFEE@M4EXCHDB1.m4systems.com OS: CentOS-6.3 Arch: x86_64 pgadmin3_92.x86_64 1.16.1-4.rhel6 @pgdg92 I have this exact error occurring on the released version of pg_admin3_92. When notices are enabled in the Miscellaneous UI options and I visit PostgreSQl(pg_catalog) under server/postgres/ then I get a series of modal message boxes stating that row number 19 is out of range 0..18, each of which must be manually closed before proceeding. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
On Thu, Feb 21, 2013 at 4:13 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote: > With reference to: > http://www.postgresql.org/message-id/A98BBDA7653C7241BE0BCF46AF5A043EED8FEFEE@M4EXCHDB1.m4systems.com > > OS: CentOS-6.3 > Arch: x86_64 > pgadmin3_92.x86_64 1.16.1-4.rhel6 @pgdg92 > > I have this exact error occurring on the released version of > pg_admin3_92. When notices are enabled in the Miscellaneous UI > options and I visit PostgreSQl(pg_catalog) under server/postgres/ then > I get a series of modal message boxes stating that row number 19 is > out of range 0..18, each of which must be manually closed before > proceeding. Thanks - turning on notices was the key to finding this. I've committed a fix for 1.16.2 and later. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: pg admin 92 beta 3 - bug report - row number 19 is out of range 0..18
From
"James B. Byrne"
Date:
On Fri, February 22, 2013 09:09, Dave Page wrote: > > Thanks - turning on notices was the key to finding this. I've > committed a fix for 1.16.2 and later. > Glad I was of some help. I have another anomaly to report as well: OS: CentOS-6.3 Arch: x86_64 pgadmin3_92.x86_64 1.16.1-4.rhel6 @pgdg92 postgresql92-server.x86_64 9.2.3-2PGDG.rhel6 @pgdg92 The owner of the plpgsql language extension is not shown in the properties window of that object when it is included in a database. The owner property is always blank no matter which user id actually owns it. This is true for template1 and any user database. Also, is there a reason that template0 elements are not available for display or manipulation from pgadmin3 when they are in psql? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Hi On Fri, Feb 22, 2013 at 3:37 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote: > > On Fri, February 22, 2013 09:09, Dave Page wrote: > >> >> Thanks - turning on notices was the key to finding this. I've >> committed a fix for 1.16.2 and later. >> > > Glad I was of some help. > > I have another anomaly to report as well: > > OS: CentOS-6.3 > Arch: x86_64 > pgadmin3_92.x86_64 1.16.1-4.rhel6 @pgdg92 > postgresql92-server.x86_64 9.2.3-2PGDG.rhel6 @pgdg92 > > The owner of the plpgsql language extension is not shown in the > properties window of that object when it is included in a database. > The owner property is always blank no matter which user id actually > owns it. This is true for template1 and any user database. I see the owner here. What does the following query return for you? SELECT lan.oid, lan.lanname, lanpltrusted, lanacl, hp.proname as lanproc, vp.proname as lanval, description, pg_get_userbyid(lan.lanowner) as languageowner FROM pg_language lan JOIN pg_proc hp on hp.oid=lanplcallfoid LEFT OUTER JOINpg_proc vp on vp.oid=lanvalidator LEFT OUTER JOIN pg_description des ON des.objoid=lan.oid AND des.objsubid=0WHERE lanisplIS TRUEORDER BY lanname > Also, is there a reason that template0 elements are not available for > display or manipulation from pgadmin3 when they are in psql? They're not available in any client unless you've been playing with the default catalog entries. As a general rule template0 should never be touched - it's your last chance way to create a completely clean database. Here's what happens if you try to access template0 in a default configuration: postgres=# \connect template0 FATAL: database "template0" is not currently accepting connections Previous connection kept postgres=# -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Feb 22, 2013 at 5:55 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote: > On Fri, February 22, 2013 11:45, Dave Page wrote: > >> >> I see the owner here. What does the following query return for you? >> >> SELECT lan.oid, lan.lanname, lanpltrusted, lanacl, hp.proname as >> lanproc, vp.proname as lanval, description, >> pg_get_userbyid(lan.lanowner) as languageowner >> FROM pg_language lan >> JOIN pg_proc hp on hp.oid=lanplcallfoid >> LEFT OUTER JOIN pg_proc vp on vp.oid=lanvalidator >> LEFT OUTER JOIN pg_description des ON des.objoid=lan.oid AND >> des.objsubid=0 >> WHERE lanispl IS TRUE >> ORDER BY lanname >> > > gives: > > 21117;"plpgsql";t;"";"plpgsql_call_handler";"plpgsql_validator";"PL/pgSQL > procedural language";"hll_theheart_db_devl" > > Which is the same thing I get in psql, so not much of a suprise there. > > However, I was referring to the Extensions Property Window display > contents. This shows the owner column empty for the plpgsql language > in the upper right pane; as shown in the attached screen shot. Ahh, gotcha. Thanks - fixed. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company