Обсуждение: COPY FROM appears broken in PostgreSQL 15

Поиск
Список
Период
Сортировка

COPY FROM appears broken in PostgreSQL 15

От
richard coleman
Дата:
Did something happen to the COPY FROM command in PostgreSQL 15?

I used to run scripts to process and load data from files into various PostgreSQL tables. A series of:

copy {schema.table} from '/{path}/{file}' delimiter '|' null '' ;

in PostgreSQL 15 it fails with this message:

ERROR:  could not open file "/{path}/{file}" for reading: Permission denied
HINT:  COPY FROM instructs the PostgreSQL server process to read a file. You may want a client-side facility such as psql's \copy.

I have checked and the postgres user can read/write to the file just fine.

In PostgreSQL < 15 it works just fine.
The official PostgreSQL docs, up to and including 16, don't mention a problem with this command.

Did something happen?

Thanks, 
rik.

Re: COPY FROM appears broken in PostgreSQL 15

От
Tom Lane
Дата:
richard coleman <rcoleman.ascentgl@gmail.com> writes:
> Did something happen to the COPY FROM command in PostgreSQL 15?

It seems quite unlikely that you'd be the first to notice such
a fundamental problem.

> ERROR:  could not open file "/{path}/{file}" for reading: Permission denied
> HINT:  COPY FROM instructs the PostgreSQL server process to read a file.
> You may want a client-side facility such as psql's \copy.

> I have checked and the postgres user can read/write to the file just fine.

Check that again.  Check lookup permission on all the directories in
the path, too.

            regards, tom lane



Re: COPY FROM appears broken in PostgreSQL 15

От
Tom Lane
Дата:
I wrote:
> richard coleman <rcoleman.ascentgl@gmail.com> writes:
>> I have checked and the postgres user can read/write to the file just fine.

> Check that again.  Check lookup permission on all the directories in
> the path, too.

BTW, if you're on a selinux-enabled system (most Red-Hat-based
distros), you need to check file contexts too.  Under selinux,
it's not uncommon for a daemon process to have fewer privileges
than the "same" user running an interactive session.

            regards, tom lane