Re: [HACKERS] Doubts about EvalPlanQual

2009-02-20 Thread Heikki Linnakangas
Jacky Leng wrote: Asserts on data-consistency checks aren't really a good idea. (IOW this is "can't happen" only as long as your database isn't corrupt...) Then why not change this to an "ereport(PANIC ...)"? If you have a corrupted database, you want to be able to read it, not panic. If

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-20 Thread Jacky Leng
> Asserts on data-consistency checks aren't really a good idea. > > (IOW this is "can't happen" only as long as your database isn't > corrupt...) > Then why not change this to an "ereport(PANIC ...)"? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Tom Lane
Jaime Casanova writes: > if it is a "can't happen" scenario then why not make it an assert? Asserts on data-consistency checks aren't really a good idea. (IOW this is "can't happen" only as long as your database isn't corrupt...) regards, tom lane -- Sent via pgsql-hac

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Jaime Casanova
On 2/19/09, Heikki Linnakangas wrote: > Tom Lane wrote: >> (I'm unconvinced that it is dead code, but even if it is it'd be folly >> to remove it.) > > Agreed, it's a useful safeguard, even it it's a "can't happen" scenario. > if it is a "can't happen" scenario then why not make it an assert? --

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Heikki Linnakangas
Tom Lane wrote: (I'm unconvinced that it is dead code, but even if it is it'd be folly to remove it.) Agreed, it's a useful safeguard, even it it's a "can't happen" scenario. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Tom Lane
Heikki Linnakangas writes: > Now that think about this more, I don't see either how that check in > EvalPlanQual could ever be true. It's there primarily to make the tuple chain chasing code the same as in other places. Whether it happens to be dead code today because of arcane details of the u

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Heikki Linnakangas
Jacky Leng wrote: Tuples with an aborted xmin can be vacuumed right away. When we're following the update chain in EvalPlanQual, it's possible that the updater has aborted, the updated dead tuple is vacuumed away, and the slot is reused for another unrelated tuple. But if the updater aborted,

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Jacky Leng
> Tuples with an aborted xmin can be vacuumed right away. When we're > following the update chain in EvalPlanQual, it's possible that the updater > has aborted, the updated dead tuple is vacuumed away, and the slot is > reused for another unrelated tuple. But if the updater aborted, how can Eva

Re: [HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Heikki Linnakangas
Jacky Leng wrote: When I read function "EvalPlanQual", I found the following code: if (heap_fetch(relation, &SnapshotDirty, &tuple, &buffer, true, NULL)) { /* * If xmin isn't what we're expecting, the slot must have been * recycled and reused for an unrelated tuple. This implies t

[HACKERS] Doubts about EvalPlanQual

2009-02-19 Thread Jacky Leng
Hi, When I read function "EvalPlanQual", I found the following code: if (heap_fetch(relation, &SnapshotDirty, &tuple, &buffer, true, NULL)) { /* * If xmin isn't what we're expecting, the slot must have been * recycled and reused for an unrelated tuple. This implies that * the l