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
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 |