Обсуждение: pg_locks.transaction field type

Поиск
Список
Период
Сортировка

pg_locks.transaction field type

От
Joseph Shraibman
Дата:
I have a method in my rmi server that takes a query and returns an
Object[][].  I had this query:

SELECT (select relname from pg_catalog.pg_class where relfilenode =
relation) as relname, * FROM pg_locks;

After upgrading from 7.4 to 8.0 I was getting this problem:
WARNING: Servlet.service() for servlet jsp threw exception
java.rmi.UnmarshalException: error unmarshalling return; nested
exception is:
         java.lang.ClassNotFoundException: org.postgresql.util.PGobject
(no security manager: RMI class loader disabled)


The problem seems to be the "transaction" field.  It looks like a number
type, but I can't really tell because "\d pg_catalog" doesn't work in psql.

So what's the difference between 7.4.7 and 8.0.3?  Is it that 7.4.7
never returned anything in the transaction field?  Is it a jdbc bug that
is returning the answer as org.postgresql.util.PGobject instead of some
kind of Number?

Re: pg_locks.transaction field type

От
Oliver Jowett
Дата:
Joseph Shraibman wrote:
> Is it a jdbc bug that
> is returning the answer as org.postgresql.util.PGobject instead of some
> kind of Number?

The column's type is 'xid' which the driver doesn't currently handle, so
it gets put into the "wrap it in PGobject" bucket.

I'm not sure what's changed between 7.4 & 8.0 -- did you also change
JDBC driver versions?

Perhaps your server should convert instances of PGobject to their string
representations before returning them across RMI.

-O

Re: pg_locks.transaction field type

От
Joseph Shraibman
Дата:

Oliver Jowett wrote:
> Joseph Shraibman wrote:
>
>> Is it a jdbc bug that is returning the answer as
>> org.postgresql.util.PGobject instead of some kind of Number?
>
>
> The column's type is 'xid' which the driver doesn't currently handle, so
> it gets put into the "wrap it in PGobject" bucket.

Is xid a type of number?
>
> I'm not sure what's changed between 7.4 & 8.0 -- did you also change
> JDBC driver versions?

yes
>
> Perhaps your server should convert instances of PGobject to their string
> representations before returning them across RMI.

That's what I'll do.  Are there any other classes besides
org.postgresql.util.PGobject that I have to worry about?

Re: pg_locks.transaction field type

От
Oliver Jowett
Дата:
Joseph Shraibman wrote:

>> The column's type is 'xid' which the driver doesn't currently handle,
>> so it gets put into the "wrap it in PGobject" bucket.
>
> Is xid a type of number?

It's an internal backend type; I'm not familiar with the details.

>> Perhaps your server should convert instances of PGobject to their
>> string representations before returning them across RMI.
>
> That's what I'll do.  Are there any other classes besides
> org.postgresql.util.PGobject that I have to worry about?

There are other classes for things like intervals and the geometric
types, but they should all be subclasses of PGobject.

-O

Re: [GENERAL] pg_locks.transaction field type

От
Joseph Shraibman
Дата:
So basically what needs to be changed is  TypeInfoCache.java & Oid.java

Alvaro Herrera wrote:
> On Thu, Aug 18, 2005 at 03:55:43PM +1200, Oliver Jowett wrote:
>
>>Joseph Shraibman wrote:
>>
>>
>>>>The column's type is 'xid' which the driver doesn't currently handle,
>>>>so it gets put into the "wrap it in PGobject" bucket.
>>>
>>>Is xid a type of number?
>>
>>It's an internal backend type; I'm not familiar with the details.
>
>
> It's an unsigned 4 byte integer.
>

Re: [GENERAL] pg_locks.transaction field type

От
Alvaro Herrera
Дата:
On Thu, Aug 18, 2005 at 03:55:43PM +1200, Oliver Jowett wrote:
> Joseph Shraibman wrote:
>
> >>The column's type is 'xid' which the driver doesn't currently handle,
> >>so it gets put into the "wrap it in PGobject" bucket.
> >
> >Is xid a type of number?
>
> It's an internal backend type; I'm not familiar with the details.

It's an unsigned 4 byte integer.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)