Re: [Bug] Inconsistent result for inheritance and FOR UPDATE.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Bug] Inconsistent result for inheritance and FOR UPDATE.
Date: 2014-12-12 02:19:52
Message-ID: 23107.1418350792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> (2014/12/12 10:37), Tom Lane wrote:
>> Yeah, this is clearly a thinko: really, nothing in the planner should
>> be using get_parse_rowmark(). I looked around for other errors of the
>> same type and found that postgresGetForeignPlan() is also using
>> get_parse_rowmark(). While that's harmless at the moment because we
>> don't support foreign tables as children, it's still wrong. Will
>> fix that too.

> I don't think we need to fix that too. In order to support that, I'm
> proposing to modify postgresGetForeignPlan() in the following way [1]
> (see fdw-inh-5.patch).

My goodness, that's ugly. And it's still wrong, because this is planner
code so it shouldn't be using get_parse_rowmark at all. The whole point
here is that the rowmark info has been transformed into something
appropriate for the planner to use. While that transformation is
relatively trivial today, it might not always be so.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-12-12 02:29:38 Re: Review of Refactoring code for sync node detection
Previous Message Etsuro Fujita 2014-12-12 02:05:45 Re: [Bug] Inconsistent result for inheritance and FOR UPDATE.