Re: cache problem (v2) - Mailing list pgsql-admin

From De Leeuw Guy
Subject Re: cache problem (v2)
Date
Msg-id 469D24C6.6090903@eurofer.be
Whole thread Raw
In response to Re: cache problem (v2)  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-admin
> Is that BEGIN;?  If not, this is _not_ one transaction.  It's two.
>
Ok
> 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
> INSERT.
>
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 :-)

Regards

Guy



pgsql-admin by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: plpgsql debugger
Next
From: Peter Elmers
Date:
Subject: Re: Several postgres installation on windows possible?