| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | yi huang <yi(dot)codeplayer(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: PostgreSQL12 crash bug report |
| Date: | 2019-08-26 05:36:52 |
| Message-ID: | 20190826053652.a5a6bdsgtus7xcez@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2019-08-24 15:54:01 -0700, Andres Freund wrote:
> Working on that.
Think it's going to look not too invasive. Needs a good bit more
cleanup, but I'm getting there.
One thing I'm struggling with is understanding and testing nested EPQ
states:
/*
* Each EState must have its own es_epqScanDone state, but if we have
* nested EPQ checks they should share es_epqTupleSlot arrays. This
* allows sub-rechecks to inherit the values being examined by an outer
* recheck.
*/
At the moment I don't understand what the point here is. When/why do we
want to inherit values from the parent epqstate? I know how to construct
queries with nested EPQ, but I don't see why we'd ever want to inherit
the values from the outer check? Nor how we're doing so -
EvalPlanQualFetchRowMarks() unconditionally clears out the old tuple,
and nodeLockRows.c unconditionally fetches the source tuples too?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2019-08-26 05:52:48 | BUG #15978: PostgreSQL Importing issue for view in .Net Framework |
| Previous Message | Michael Paquier | 2019-08-26 02:17:23 | Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE' |