From: Tom Lane <tgl@sss.pgh.pa.us>
To: robb@public.law
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18926: PostgreSQL 17.5 produces malformed binary COPY output
 (`GPOCYP` instead of `PGCOPY`) across platform
In-reply-to: <18926-f08e7be3ec3647f9@postgresql.org>
References: <18926-f08e7be3ec3647f9@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 14 May 2025 03:27:14 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7388.1747227436.1@sss.pgh.pa.us>
Date: Wed, 14 May 2025 08:57:16 -0400
Message-ID: <7389.1747227436@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/7389.1747227436%40sss.pgh.pa.us>
Precedence: bulk

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