On Sun, Dec 28, 2014 at 10:57 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > > > On Fri, Dec 26, 2014 at 4:16 PM, Michael Paquier <michael.paqu...@gmail.com> > wrote: >> On Fri, Dec 26, 2014 at 3:24 PM, Fujii Masao <masao.fu...@gmail.com> >> wrote: >>> pglz_compress() and pglz_decompress() still use PGLZ_Header, so the >>> frontend >>> which uses those functions needs to handle PGLZ_Header. But it basically >>> should >>> be handled via the varlena macros. That is, the frontend still seems to >>> need to >>> understand the varlena datatype. I think we should avoid that. Thought? >> Hm, yes it may be wiser to remove it and make the data passed to pglz >> for varlena 8 bytes shorter.. > > OK, here is the result of this work, made of 3 patches.
Thanks for updating the patches! > The first two patches move pglz stuff to src/common and make it a frontend > utility entirely independent on varlena and its related metadata. > - Patch 1 is a simple move of pglz to src/common, with PGLZ_Header still > present. There is nothing amazing here, and that's the broken version that > has been reverted in 966115c. The patch 1 cannot be applied to the master successfully because of recent change. > - The real stuff comes with patch 2, that implements the removal of > PGLZ_Header, changing the APIs of compression and decompression to pglz to > not have anymore toast metadata, this metadata being now localized in > tuptoaster.c. Note that this patch protects the on-disk format (tested with > pg_upgrade from 9.4 to a patched HEAD server). Here is how the APIs of > compression and decompression look like with this patch, simply performing > operations from a source to a destination: > extern int32 pglz_compress(const char *source, int32 slen, char *dest, > const PGLZ_Strategy *strategy); > extern int32 pglz_decompress(const char *source, char *dest, > int32 compressed_size, int32 raw_size); > The return value of those functions is the number of bytes written in the > destination buffer, and 0 if operation failed. So it's guaranteed that 0 is never returned in success case? I'm not sure if that case can really happen, though. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
