Skip site navigation (1) Skip section navigation (2)

Re: cache problem (v2)

From: De Leeuw Guy <G(dot)De_Leeuw(at)eurofer(dot)be>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-admin(at)postgresql(dot)org
Subject: Re: cache problem (v2)
Date: 2007-07-17 20:21:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
> Is that BEGIN;?  If not, this is _not_ one transaction.  It's two.
> You're not actually _calling_ the trigger, right?  It just happens
> automatically?  Also, I don't have the slightest clue how this code=3
> (does not exist) works.  AFAICT code=1.  So code=3 is never true, no?
Yes it's a case study but my trigger consider  this possibility.
>> Now I have a flat file :
>> 1,150
>> 2,450
>> COPY .... path_to_this_flat_file
>> code=3,qte=450
>> Why ?
> Because it's all one transaction, and because there's more than one
> state your variables could resolve to, only one of them actually
> applies is my _guess_.  It's hard for me to say with any more detail
> without the code and the schema.  Anyway, you have two transactions
> in your first example, it appears.  The COPY statement is only one.
Ok, but strange for me ... the transaction is a guarantee of visibility
inter process but in the same also ?
If yes it' is possible to change that ? I see on the documentation (yes,
yes I read them :-) ) that the UNCOMMITED_READ are equal to COMMITED
READ in postgres
>> Another error also is "duplicate key"
> This is a different problem.  Where is it coming from?  Anyway, you
> have some sort of collision there, as the result I assume of your
> modifications of the data.  Does it only happen with the COPY case? 
> If so, that's another clue that the trigger function is not doing
> what you think it is.
Yes I agree, originally same problem
>> I read the documentation from postgres not all. But sufficiently to
>> start a test  of a trigger.
> But apparently not a successful one ;-)  I'm just saying, it seems to
> me that you have a deep misunderstanding of the way transaction scope
> works.  I think you need to have another look at that.  I also think
> you need to look a little harder at how COPY works as compared to
Yes for me in the same transaction I see my update but is not the case.
But I agree I take more time to understand the transactional part :-)



In response to

pgsql-admin by date

Next:From: Jim C. NasbyDate: 2007-07-17 20:42:04
Subject: Re: plpgsql debugger
Previous:From: km4hrDate: 2007-07-17 19:33:06
Subject: What user privileges do I need to CREATE FUNCTION's?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group