Re: BUG #18926: PostgreSQL 17.5 produces malformed binary COPY output (`GPOCYP` instead of `PGCOPY`) across platform - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18926: PostgreSQL 17.5 produces malformed binary COPY output (`GPOCYP` instead of `PGCOPY`) across platform
Date
Msg-id 7389.1747227436@sss.pgh.pa.us
Whole thread Raw
In response to BUG #18926: PostgreSQL 17.5 produces malformed binary COPY output (`GPOCYP` instead of `PGCOPY`) across platform  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> I'm encountering a bug in PostgreSQL 17.5 where a `COPY ... TO STDOUT WITH
> (FORMAT binary)` operation produces malformed output: the file begins with
> `GPOCYP` instead of the expected `PGCOPY`. This behavior occurs consistently
> across environments, including:

Works as expected for me, on macOS and RHEL8:

$ psql -q -f mini_test.sql >output.bin
$ hexdump -C output.bin | head
00000000  50 47 43 4f 50 59 0a ff  0d 0a 00 00 00 00 00 00  |PGCOPY..........|
00000010  00 00 00 00 01 00 00 00  04 00 00 00 01 ff ff     |...............|
0000001f

I think your version of hexdump is regarding the input as 2-byte LSB-first
integers.  (Maybe you replaced it with some "helpful" alias?)

You might try double-checking the file with some other tool, eg od:

$ od -c output.bin | head
0000000   P   G   C   O   P   Y  \n 377  \r  \n  \0  \0  \0  \0  \0  \0
0000020  \0  \0  \0  \0 001  \0  \0  \0 004  \0  \0  \0 001 377 377
0000037

            regards, tom lane



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18928: postgres_fdw search_path not reset causing pgbouncer pool_mode=transaction using the wrong schema
Next
From: Tom Lane
Date:
Subject: Re: BUG #18928: postgres_fdw search_path not reset causing pgbouncer pool_mode=transaction using the wrong schema