Skip site navigation (1) Skip section navigation (2)

Re: pg_lzcompress patch for 8.3, 8.2 branch

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pg_lzcompress patch for 8.3, 8.2 branch
Date: 2008-05-29 13:01:58
Message-ID: 483EA946.80008@sun.com (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> I attached backported pg_lzcompress patch which is already in head for version 
>> 8.2 and 8.3.
> 
>> Version 8.1 and prior contains more changes in decompress code and they does not 
>> contain any check. Shell I backported it as well or it will be better to keep it 
>> untouched?
> 
> AFAICS the only nontrivial patch in pg_lzcompress.c between 7.4 and 8.2
> is my cleanup patch here:
> http://archives.postgresql.org/pgsql-committers/2006-10/msg00076.php
> That's been in the tree long enough that I wouldn't have any hesitation
> about back-porting it, so that all the supported versions would have
> the same lzcompress code.

OK I will backport your and my patch together back to the 7.4.

> About the only reason I can see not to do it
> is that conceivably some third-party code somewhere might be calling
> pglz_compress directly; in which case an API change in a minor release
> would be a problem for them.

Hmm, It brings me idea that we should have some stable API definition for C 
function. For example API for datatype  helps to upgrade user datatypes
without any changes (no recompilation). The same model uses e.g. Solaris for 
driver. Binary drivers are compatible and drivers from S8 should work on S10.

> On the other hand, I remain unconvinced that this problem is severe
> enough to justify much backporting work.  AFAIK we've only seen one
> occurence of a problem to date.

I know about two occurrence. One was reported on -bug 
(http://archives.postgresql.org/pgsql-bugs/2008-04/msg00206.php)
and second was reported from our customer.

The main problem is that you are not able to fix corrupted data. When database 
raise error on damaged data you are able to catch this error and remove affected 
row. If database crashes than only gdb guru is able to mine ctid of affected row 
or any other row specification from core dump.

		Zdenek
	

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2008-05-29 13:51:18
Subject: Re: pg_lzcompress patch for 8.3, 8.2 branch
Previous:From: Guillaume SmetDate: 2008-05-29 08:41:48
Subject: Re: Upcoming back-branch update releases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group