From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Confusing results with lateral references |
Date: | 2015-12-04 05:28:25 |
Message-ID: | 56612479.9070503@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/12/03 21:26, Ashutosh Bapat wrote:
> Session 1
> postgres=# begin;
> BEGIN
> postgres=# update t1 set val = 2 where val2 = 1;
> UPDATE 1
>
> Session 2
> postgres=# select * from t1 left join t2 on (t1.val = t2.val) for update of
> t1;
>
> query waits
>
> Session 1
> postgres=# commit;
> COMMIT
>
>
> Session 2 query returns two rows
> select * from t1 left join t2 on (t1.val = t2.val) for update of t1;
> val | val2 | val | val2
> -----+------+-----+------
> 2 | 1 | |
> 2 | 1 | |
> (2 rows)
>
> It's confusing to see two rows from left join result when the table really
> has only a single row. Is this behaviour expected?
Maybe it is. Because the other table still has two (1, 1) rows, LockRows's
subplan would still produce two rows in result, no?
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-12-04 05:32:33 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Previous Message | amul sul | 2015-12-04 05:22:06 | Re: Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints() |