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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: robb(at)public(dot)law
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18926: PostgreSQL 17.5 produces malformed binary COPY output (`GPOCYP` instead of `PGCOPY`) across platform
Date: 2025-05-14 12:57:16
Message-ID: 7389.1747227436@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Matheus Alcantara 2025-05-14 15:06:35 Re: BUG #18928: postgres_fdw search_path not reset causing pgbouncer pool_mode=transaction using the wrong schema
Previous Message PG Bug reporting form 2025-05-14 12:37:36 BUG #18928: postgres_fdw search_path not reset causing pgbouncer pool_mode=transaction using the wrong schema