Re: SQL/MED - file_fdw - Mailing list pgsql-hackers

From Shigeru HANADA
Subject Re: SQL/MED - file_fdw
Date
Msg-id 20101217114931.393D.6989961C@metrosystems.co.jp
Whole thread Raw
In response to Re: SQL/MED - file_fdw  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: SQL/MED - file_fdw  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
List pgsql-hackers
On Thu, 16 Dec 2010 19:35:56 +0900
Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote:
> On Thu, Dec 16, 2010 at 18:45, Shigeru HANADA <hanada@metrosystems.co.jp> wrote:
> > "COPY FROM" is a command which INSERT data from a file essentially,
> > so it requires RowExclusiveLock on the target table.  On the other
> > hand, file_fdw is a feature which reads data from a file through a
> > table, so it requires AccessShareLock on the source table.
>
> Ah, I found my bug in BeginCopy(), but it's in the usage of
> ExecCheckRTPerms() rather than RowExclusiveLock, right?
> The target relation should have been opened and locked by the caller.

The target foreign tables are locked in InitForeignScan() via
ExecOpenScanRelation(), so COPY routines don't need to lock it again.

> I think we can move the check to DoCopy() as like as checking for
> superuser(). In my understanding, we don't have to check permissions
> in each FDW  because it was done in parse and analyze phases.

In addition, ISTM that the check for read-only transaction should be
moved to DoCopy() because file_fdw scan can be used in read-only
transacntion.

> Could you fix it? Or, shall I do?

I've just moved permission check and read-only check from BeginCopy()
to DoCopy().  Please see attached patch.

Regards,
--
Shigeru Hanada

Attachment

pgsql-hackers by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: plperlu problem with utf8
Next
From: "David E. Wheeler"
Date:
Subject: Re: plperlu problem with utf8