hi ,
I am facing this below issue can u suggest me a solution to retcify
this probleem at earliest.
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs
(04/11/2008))): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLExc
Kris,
I get the same error. I've verified the table name and the primary key. The
interesting part is, it seems to work in cases where the primary key is a
serial.
Thanks,
Dave Armstrong
Kris Jurka wrote:
>
>
>
> On Tue, 21 Oct 2008, Marcel Petavy wrote:
>
>> Bug reference: 4488
>>
On Friday 26 December 2008 01:12:26 Tom Lane wrote:
> More generally, there are a *whole lot* of ridiculous inefficiencies
> in our information_schema views; I'm surprised there haven't been
> more complaints about them. Sometime someone ought to go through
> the whole set and see what other refac
Tom Lane wrote:
> [ reincluding the mailing list ]
>
> Michael Milligan writes:
> > Okay, it reproduces and surprise surprise nLocks does overflow...
>
> > ERROR: lock AccessShareLock on object 16385/16467/0 is already held
> > lock(0x87408a028) id(16385,16467,0,0,0,1) grantMask(a) waitMask(0)
Alvaro Herrera writes:
> Tom Lane wrote:
>> Michael Milligan writes:
>>> Okay, it reproduces and surprise surprise nLocks does overflow...
>>
>> Hah. Okay, that shows that we'd never have reproduced it with a small
>> test case.
> This hasn't been fixed yet, has it?
Well, it has been addressed
Tom Lane wrote:
> 2008-09-15 21:56 tgl
>
> * src/include/storage/: lock.h (REL8_1_STABLE), lock.h
> (REL8_3_STABLE), lock.h (REL8_0_STABLE), lock.h (REL8_2_STABLE),
> lock.h: Widen the nLocks counts in local lock tables from int to
> int64.
Doh, I didn't see it because I
Namely it does not disable the rule... Enabling inside of the
transaction seems to work though
Tried both CVS and 8.3.5...
create table trule (a int);
insert into trule (a) values (1);
create rule trule_rule as on update to trule do instead nothing;
update trule set a = 2;
UPDATE 0
begin;
ALTER
On Mon, Dec 29, 2008 at 15:07, Alex Hunsaker wrote:
> Namely it does not disable the rule...
> Enabling inside of the transaction seems to work though
Hrm the above turned out to be false... must have gotten confused when
testing with triggers
If i turn on RELCACHE_FORCE_RELEASE or CLOBBER_CACH
"Alex Hunsaker" writes:
> Namely it does not disable the rule... Enabling inside of the
> transaction seems to work though
Fixed, thanks ...
Index: relcache.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v
retriev
