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.
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.
Could you fix it? Or, shall I do?
> Using COPY routines from file_fdw might need another kind of
> modularization, such as split file operation from COPY module and use
> it from both of COPY and file_fdw. But it would require more code work,
> and possibly performance tests.
My plan was that the 'rel' argument for BeginCopyFrom() is a "template"
for the CSV file. So, we need only AccessShareLock (or, NoLock?) for
the relation. TupleDesc might be enough for the purpose, but I've not
changed the type because of DEFAULT columns.
OTOH, CopyFrom(cstate, rel) will require an additional 'rel' argument,
that means the "target" to be inserted, though it's always same with
the above "template" in COPY FROM. RowExclusiveLock is required only
for the target relation.
--
Itagaki Takahiro
