Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction - Mailing list pgsql-bugs

From Amit Langote
Subject Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction
Date
Msg-id 1c23a9b1-c9c0-a11a-63fc-d821602455ba@lab.ntt.co.jp
Whole thread Raw
In response to Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction
Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction
List pgsql-bugs
Fujita-san,

On 2018/12/18 21:48, Etsuro Fujita wrote:
> FDWs would not look at heap_insert options, so another option would be to
> 1) leave that options as-is for foreign tables and 2) if the target is a
> foreign table, just skip heap_sync at the bottom of CopyFrom, or just
> return without doing anything in heap_sync.

I'd considered 2, but 1 might be better because it both fixes the problem
at hand and doesn't lead to misleadingly setting heap_insert options.

About adding guards in heap_sync itself to make sure that it becomes a
no-op for non-heap relations, I think that would make sense too.
Although, I wonder why it doesn't return without doing anything already,
given that it has this:

heap_sync(Relation rel)
{
    /* non-WAL-logged tables never need fsync */
    if (!RelationNeedsWAL(rel))
        return;

where,

#define RelationNeedsWAL(relation) \
    ((relation)->rd_rel->relpersistence == RELPERSISTENCE_PERMANENT)

Maybe, we never paid enough attention to the semantics of repersistence
property of foreign tables, though I admit that that's not something we
should set out to fix on this thread.

Thanks,
Amit



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15558: NOTIFY max channel length is undocumented
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #15558: NOTIFY max channel length is undocumented