Kris Kiger <[EMAIL PROTECTED]> writes:
> Interesting. That makes sense, though. So, is there a good way to lock
> a set of rows using SELECT FOR UPDATE in plpgsql? I assume using
> PERFORM would yield the same problem, because it immediately discards
> the results.
I think PERFORM would work
Interesting. That makes sense, though. So, is there a good way to lock
a set of rows using SELECT FOR UPDATE in plpgsql? I assume using
PERFORM would yield the same problem, because it immediately discards
the results.
Thanks!
Kris
Tom Lane wrote:
Kris Kiger <[EMAIL PROTECTED]> writes:
In
Kris Kiger <[EMAIL PROTECTED]> writes:
> In your second paragraph, I think that you are saying that SELECT FOR
> UPDATE only locks one row, even though the select itself may return
> many. Am I mis-interpreting you?
No, I'm saying that plpgsql's SELECT INTO operation only reads one row.
The fac
In your second paragraph, I think that you are saying that SELECT FOR
UPDATE only locks one row, even though the select itself may return
many. Am I mis-interpreting you? Also, what do you mean by seizing on
a non-active row?
Your assumption about pkey_id is right, I meant for that to mean p
Kris Kiger <[EMAIL PROTECTED]> writes:
> Hmm.. I was trying simplify my function to get the point across with
> minimal confusion. If you don't think there is enough detail, let me
> know what is lacking and I will add the appropriate detail. The
> function is executed BEFORE insert on table1.
Hmm.. I was trying simplify my function to get the point across with
minimal confusion. If you don't think there is enough detail, let me
know what is lacking and I will add the appropriate detail. The
function is executed BEFORE insert on table1. Thanks again for the help all
Kris
Tom Lane
Kris Kiger <[EMAIL PROTECTED]> writes:
> Here is my problem. I have a function that is triggered on insert. For
> simplicity's sake, lets say the function looks like this:
> CREATE OR REPLACE FUNCTION dostuff_on_insert() RETURNS TRIGGER AS '
> DECLARE lockrows RECORD;
> BEGIN
> select into
I guess first we should understand why the insert B waits at all,the
insert A did not commit ,right ,then how did it found any pkey_id =
NEW.pkey_id? That means you have already had those while starting your
experiment.
So ,insert B wait for those "old" rows not for your insert (i mean an
INSER
transaction_isolation
---
read committed
Running Postgres 7.4 btw
Kris
Tsirkin Evgeny wrote:
What transaction level are you using?
Evgeny.
Kris Kiger wrote:
Here is my problem. I have a function that is triggered on insert.
For simplicity's sake, lets say the function looks
What transaction level are you using?
Evgeny.
Kris Kiger wrote:
Here is my problem. I have a function that is triggered on insert. For
simplicity's sake, lets say the function looks like this:
CREATE OR REPLACE FUNCTION dostuff_on_insert() RETURNS TRIGGER AS '
DECLARE lockrows RECORD;
BEGIN
Here is my problem. I have a function that is triggered on insert. For
simplicity's sake, lets say the function looks like this:
CREATE OR REPLACE FUNCTION dostuff_on_insert() RETURNS TRIGGER AS '
DECLARE lockrows RECORD;
BEGIN
select into lockrows * from table1 where pkey_id = NEW.pkey_id f
11 matches
Mail list logo
