Re: BUG #16951: pg_restore segfaults on custom format piped from a different version of PG

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sergey KOPOSOV <Sergey(dot)Koposov(at)ed(dot)ac(dot)uk>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16951: pg_restore segfaults on custom format piped from a different version of PG
Date: 2021-04-01 17:56:34
Message-ID: 20210401175634.GI4431@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Apr 01, 2021 at 11:39:33AM -0400, Tom Lane wrote:
> Sergey KOPOSOV <Sergey(dot)Koposov(at)ed(dot)ac(dot)uk> writes:
> > Importantly This requires running pg_restore without '-Fc' flag, i.e. to let it autodetect.
>
> > $ cat /tmp/xx1.short | ./src/bin/pg_dump/pg_restore
> > Segmentation fault (core dumped)
> > $ cat /tmp/xx1.short | ./src/bin/pg_dump/pg_restore -Fc
> > pg_restore: [archiver] unsupported version (1.14) in file header
>
> Ooooh ... the autodetect + cant-seek code path is just broken. All of the
> sanity checks on the first few fields of the file --- particularly the
> version number --- just get skipped in this scenario.
>
> I wonder why it's a good idea to read-ahead any of those fields in the
> first place. Checking the PGDMP magic string seems sufficient.
>
> Will fix, thanks for the report!

Yes, thank you both. I've run into this recently but for some reason I thought
it was fixed. It probably also explains this one from 2014.
https://www.postgresql.org/message-id/20141206061151.GA725@telsasoft.com

--
Justin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-04-01 18:13:38 Re: BUG #16951: pg_restore segfaults on custom format piped from a different version of PG
Previous Message Tom Lane 2021-04-01 15:39:33 Re: BUG #16951: pg_restore segfaults on custom format piped from a different version of PG