Thanks so much.
I understand now.
Best Regards,
Zhenghua Lyu
On Mon, Jun 10, 2019 at 3:22 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 12:42 PM Etsuro Fujita
> wrote:
>
>> Hi,
>>
>> On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh
>> wrote:
>> > On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu
On Mon, Jun 10, 2019 at 12:42 PM Etsuro Fujita
wrote:
> Hi,
>
> On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh
> wrote:
> > On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu wrote:
> >> 2. Is the case above a bug or a feature?
> >>
> > IMHO, it looks like an expected behaviour of a correct transactio
Hi,
On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh wrote:
> On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu wrote:
>> 2. Is the case above a bug or a feature?
>>
> IMHO, it looks like an expected behaviour of a correct transaction management
> implementation.
This is documented behavior; see the C
Hello,
On Mon, Jun 10, 2019 at 11:31 AM Zhenghua Lyu wrote:
>
> 1. why after emitting `lockrows` plannode, the result can no longer be
> assumed sorted?
>
The plan corresponding to your select query is as following:
QUERY PLAN
---
Limit
-> LockRows
Hi,
I am reading the code that generating plan for `rowmarks` of Postgres
9.4 (
https://github.com/postgres/postgres/blob/REL9_4_STABLE/src/backend/optimizer/plan/planner.c#L2070
)
After emitting the `LockRows` plannode, the results cannot be considered
in order, and there are comments ther
