From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Andres Freund <andres@anarazel.de>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>,
        David Steele <david@pgmasters.net>,
        Ildus Kurbangaliev <i.kurbangaliev@gmail.com>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] Custom compression methods
In-reply-to: <20210320153933.GT11765@telsasoft.com>
References: <20210319222242.GA23930@alvherre.pgsql>
 <CA+TgmoYQ8hn1apJXbmxutYv-sHkTOUdPxdFJUzvZ7uT4cUT+cQ@mail.gmail.com>
 <CA+TgmobGm9umTgno4O4UqSAoGhOPOAA55uiKE8N_wehnHfg4Tw@mail.gmail.com>
 <4158590.1616185209@sss.pgh.pa.us> <20210320000625.GP11765@telsasoft.com>
 <20210320074420.GR11765@telsasoft.com>
 <CAFiTN-uX=hLscjL=0raA6dYcoiZB=9YqL3DmX15CMvZiu+WB+w@mail.gmail.com>
 <20210320153933.GT11765@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Sat, 20 Mar 2021 10:39:34 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <229249.1616261775.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 20 Mar 2021 13:36:15 -0400
Message-ID: <229250.1616261775@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/229250.1616261775%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Sat, Mar 20, 2021 at 04:37:53PM +0530, Dilip Kumar wrote:
>> - And, 0008 and 0009, I think my
>> 0001-Fixup-dump-toast-compression-method.patch[1] is doing this in a
>> much simpler way, please have a look and let me know if you think that
>> has any problems and we need to do the way you are doing here?

> I tested and saw that your patch doesn't output "SET default_toast_compr=
ession"
> in non-text dumps (pg_dump -Fc).

Yeah, _doSetFixedOutputState is the wrong place: that runs on the
pg_restore side of the fence, and would not have access to the
necessary info in a separated dump/restore run.

It might be necessary to explicitly pass the state through in a TOC item,
as we do for things like the standard_conforming_strings setting.

			regards, tom lane