Re: BEFORE UPDATE trigger on postgres_fdw table not work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Shohei Mochizuki <shohei(dot)mochizuki(at)toshiba(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BEFORE UPDATE trigger on postgres_fdw table not work
Date: 2019-05-27 13:02:17
Message-ID: 65103.1558962137@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2019/05/27 10:52, Shohei Mochizuki wrote:
>> I noticed returning a modified record in a row-level BEFORE UPDATE trigger
>> on postgres_fdw foreign tables do not work. Attached patch fixes this issue.
>> This is because current fdw code adds only columns to RemoteSQL that were
>> explicitly targets of the UPDATE as follows.

> Yeah. So, the trigger execution correctly modifies the existing tuple
> fetched from the remote server, but those changes are then essentially
> discarded by postgres_fdw, that is, postgresExecForeignModify().

> ... Also, in the worst case, we'll end
> up generating new query for every row being changed, because the trigger
> may change different columns for different rows based on some condition.

Perhaps, if the table has relevant BEFORE triggers, we should just abandon
our attempts to optimize away fetching/storing all columns? It seems like
another potential hazard here is a trigger needing to read a column that
is not mentioned in the SQL query.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Guo 2019-05-27 13:39:03 Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Previous Message Tom Lane 2019-05-27 12:56:29 Re: Excessive memory usage in multi-statement queries w/ partitioning