pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Mario De Frutos Dieguez <mariodefrutos@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Fwd: Problem with a "complex" upsert
Date: Tue, 10 Jul 2018 16:59:33 -0400
Message-ID: <30415.1531256373@sss.pgh.pa.us> (raw)
In-Reply-To: <8da3739d-da24-1125-cab6-b68d6ec1bc6a@lab.ntt.co.jp>
References: <CAFYwGJ0xfzy8jaK80hVN2eUWr6huce0RU8AgU04MGD00igqkTg@mail.gmail.com>
	<CAFYwGJ3Cpb2T+177rEopU7_aQE3W03UoqNZXdP5erCtSRgDGVA@mail.gmail.com>
	<18795.1529600753@sss.pgh.pa.us>
	<8da3739d-da24-1125-cab6-b68d6ec1bc6a@lab.ntt.co.jp>

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> Having worked a little bit on the ON CONFLICT code recently, I was able to
> guess at the triggering detail.  At least, I was able to reproduce the
> error and crash seen in the OP's report.  Here's a minimal example:

> create table foo (a text unique, b float);
> insert into foo values ('xyxyxy', 1);

> -- note the different order of columns in the view
> create view foo_view as select b, a from foo;

Ah-hah.

> I tried debugging why that happens and concluded that rewriteTargetView
> fails to *completely* account for the fact that the view's column's may
> have different attribute numbers than the underlying table that the DO
> UPDATE action will be applied to.  Especially, even if the view's Vars are
> replaced with those corresponding underlying base table's columns, the
> TargetEntry's into which those Vars are contained are not refreshed, that
> is, their resnos don't match varattnos.

> I created a patch that seems to fix the issue, which also adds a
> representative test in updatable_view.sql.

Hm.  I looked at this patch a bit.  While the onConflictSet change looks
reasonable, I find the exclRelTlist change fishy.  Shouldn't those resnos
correspond to the exclRelTlist's *own* vars, independently of what is or
isn't in the view_targetlist?  And why is it OK to ignore failure to find
a match?

The provided test case doesn't seem to me to prove that that code is OK.
AFAICS, exclRelTlist only gets used by EXPLAIN, and there's no EXPLAIN
output in the test case.

			regards, tom lane




view thread (30+ messages)  latest in thread

Message-ID: <30415.1531256373@sss.pgh.pa.us>
Permalink:  ../30415.1531256373@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/30415.1531256373@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: tgl@sss.pgh.pa.us, Langote_Amit_f8@lab.ntt.co.jp, mariodefrutos@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: Fwd: Problem with a "complex" upsert
  In-Reply-To: <30415.1531256373@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox