Pgadmin - OID out of range error in PgAdmin 3 1.4.3

Author

OID out of range error in PgAdmin 3 1.4.3

Joost Kraaijeveld

2006-10-25, 8:27 am

If I select a database server in the tree and than select the "Depends
on" of "Referenced by" tabs in the right window I get: "ERROR: OID out
of range".

Is this a problem with PgAdmin or is there something wrong with my
database servers?

BTW: after boosting the logging to "Error,Notices,SQL" to find out the
query PgAdmin I noticed that long queries do not get completely in log
but are truncated. Is that a bug or by design?

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Dave Page

2006-10-25, 8:27 am

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of
> Joost Kraaijeveld
> Sent: 23 October 2006 06:50
> To: pgadmin-support@postgresql.org
> Subject: [pgadmin-support] OID out of range error in PgAdmin 3 1.4.3
>
> If I select a database server in the tree and than select the "Depends
> on" of "Referenced by" tabs in the right window I get:
> "ERROR: OID out
> of range".
>
> Is this a problem with PgAdmin or is there something wrong with my
> database servers?

It's not a bug I recall, and it doesn't occur in SVN trunk or 1.4.3 on
my system. Can you see the query it's running in the logs?

> BTW: after boosting the logging to "Error,Notices,SQL" to find out the
> query PgAdmin I noticed that long queries do not get completely in log
> but are truncated. Is that a bug or by design?

They currently get chopped at about 1Kb.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Joost Kraaijeveld

2006-10-25, 8:27 am

On Mon, 2006-10-23 at 09:01 +0100, Dave Page wrote:
>
>
> It's not a bug I recall, and it doesn't occur in SVN trunk or 1.4.3 on
> my system. Can you see the query it's running in the logs?
Yes, be it that it is (partly) chopped of:

2006-10-23 10:12:11 QUERY : Set query (172.31.1.1:5432): SELECT DISTINCT deptype, refclassid, cl.relkind,
CASE WHEN cl.relkind IS NOT NULL THEN cl.relkind
WHEN tg.oid IS NOT NULL THEN 'T'::text
WHEN ty.oid IS NOT NULL THEN 'y'::text
WHEN ns.oid IS NOT NULL THEN 'n'::text
WHEN pr.oid IS NOT NULL THEN 'p'::text
WHEN la.oid IS NOT NULL THEN 'l'::text
WHEN rw.oid IS NOT NULL THEN 'R'::text
WHEN co.oid IS NOT NULL THEN 'C'::text || contype
ELSE '' END AS type,
COALESCE(coc.relname, clrw.relname) AS ownertable,
COALESCE(cl.relname, conname, proname, tgname, typname, lanname, rulename, ns.nspname) AS refname,
COALESCE(nsc.nspname, nso.nspname, nsp.nspname, nst.nspname, nsrw.nspname) AS nspname
FROM pg_depend dep
LEFT JOIN pg_class cl ON dep.refobjid=cl.oid
LEFT JOIN pg_namespace nsc ON cl.relnamespace=nsc.oid
LEFT JOIN pg_proc pr on dep.refobjid=pr.oid
LEFT JOIN pg_namespace nsp ON pronamespace=nsp.oid
LEFT J
2006-10-23 10:12:11 ERROR : ERROR: OID out of range

2006-10-23 10:12:12 QUERY : Set query (172.31.1.1:5432): SELECT rolname AS refname, refclassid, deptype
FROM pg_shdepend dep
LEFT JOIN pg_roles r ON refclassid=1260 AND refobjid=r.oid
WHERE dep. objid=416611827821::
oid
ORDER BY 1
2006-10-23 10:12:12 ERROR : ERROR: OID out of range

BTW: I am running 64-bit Debian Linux Etch with PostgreSQL 8.1.4.

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Dave Page

2006-10-25, 8:27 am

> -----Original Message-----
> From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.nl]
> Sent: 23 October 2006 09:16
> To: Dave Page
> Cc: pgadmin-support@postgresql.org
> Subject: RE: [pgadmin-support] OID out of range error in
> PgAdmin 3 1.4.3
>
> On Mon, 2006-10-23 at 09:01 +0100, Dave Page wrote:
> PgAdmin 3 1.4.3
> the "Depends
> or 1.4.3 on
> Yes, be it that it is (partly) chopped of:
>
> 2006-10-23 10:12:11 QUERY : Set query (172.31.1.1:5432):
> SELECT DISTINCT deptype, refclassid, cl.relkind,
> CASE WHEN cl.relkind IS NOT NULL THEN cl.relkind
> WHEN tg.oid IS NOT NULL THEN 'T'::text
> WHEN ty.oid IS NOT NULL THEN 'y'::text
> WHEN ns.oid IS NOT NULL THEN 'n'::text
> WHEN pr.oid IS NOT NULL THEN 'p'::text
> WHEN la.oid IS NOT NULL THEN 'l'::text
> WHEN rw.oid IS NOT NULL THEN 'R'::text
> WHEN co.oid IS NOT NULL THEN 'C'::text || contype
> ELSE '' END AS type,
> COALESCE(coc.relname, clrw.relname) AS ownertable,
> COALESCE(cl.relname, conname, proname, tgname,
> typname, lanname, rulename, ns.nspname) AS refname,
> COALESCE(nsc.nspname, nso.nspname, nsp.nspname,
> nst.nspname, nsrw.nspname) AS nspname
> FROM pg_depend dep
> LEFT JOIN pg_class cl ON dep.refobjid=cl.oid
> LEFT JOIN pg_namespace nsc ON cl.relnamespace=nsc.oid
> LEFT JOIN pg_proc pr on dep.refobjid=pr.oid
> LEFT JOIN pg_namespace nsp ON pronamespace=nsp.oid
> LEFT J
> 2006-10-23 10:12:11 ERROR : ERROR: OID out of range
>
> 2006-10-23 10:12:12 QUERY : Set query (172.31.1.1:5432):
> SELECT rolname AS refname, refclassid, deptype
> FROM pg_shdepend dep
> LEFT JOIN pg_roles r ON refclassid=1260 AND refobjid=r.oid
> WHERE dep. objid=416611827821::
oid
> ORDER BY 1
> 2006-10-23 10:12:12 ERROR : ERROR: OID out of range
>
>
> BTW: I am running 64-bit Debian Linux Etch with PostgreSQL 8.1.4.

Yeah - on further thought (and a coffee), there's no reason to try to
find dependent or dependency information for a server anyway - and in
fact, what's probably happening is that it's actually trying to find it
for some random OID because a server object never gets one assigned.

I've made a change in SVN trunk to avoid querying for
dependent/dependency information for server objects.

Thanks, Dave.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Sponsored Links