On Sun, 2004-06-13 at 22:46 +0200, Wouter Verhelst wrote:
> On Sun, Jun 13, 2004 at 08:33:15PM +0200, Martin Schulze wrote:
> > J.H.M. Dassen (Ray) wrote:
> > > > Can I put the package in stable-proposed-updates anyway?
> > >
> > > I don't think that's productive. It's probably a lot more productive to use
> > > your energy to bring the existence of www.backports.org (which has 7.4.2
> > > backports available for i386) to the attention of PostgreSQL upstream and
> > > the users experiencing problems with stable's 7.2.1.
> >
> > FWIW: Full ack.
> >
> > Using s-p-u for that would nullify the security update. Please don't do
> > that.
>
> Never the less, I think the original question (whether 7.2.4 should be
> accepted for woody) is a good one. If I understood Martin Pitt's
> explanation correctly, the postgresql upstream doesn't lightly perform
> third-level updates such as the one from 7.2.1 to 7.2.4.
>
> I don't know what the actual policy they apply regarding what kinds of
> bugfixes can go in such an update looks like; however, if it is (more or
> less) the same as the one Debian applies to stable updates (i.e., only
> patches to fix security holes, bugs that make the thing useless or
> mostly so, bugs that might cause data loss/corruption, or bugs that
> might break unrelated packages and/or the whole system), I don't see why
> it shouldn't be accepted.
Hi,
The policy applying to updates in the stable series of a released
PostgreSQL is very similar to Debian's own policies. PostgreSQL
development happens aggressively on the HEAD, with fixes which are
considered suficiently important patched back to older releases.
Personally I have never experienced any sort of a problem or "gotcha" in
blindly applying these revision releases, and would welcome a Debian
policy that allowed for their inclusion in a stable release series.
As an example, here are the changelogs for 7.2.3 and 7.2.4 - all of
these entries are bug fixes, some fixing potential data loss issues. The
pattern is similar for releases 7.3.2 -> 7.3.6 and for 7.4.2
7.2.3:
* Prevent possible compressed transaction log loss (Tom)
* Prevent non-superuser from increasing most recent vacuum info
(Tom)
* Handle pre-1970 date values in newer versions of glibc (Tom)
* Fix possible hang during server shutdown
* Prevent spinlock hangs on SMP PPC machines (Tomoyuki Niijima)
* Fix pg_dump to properly dump FULL JOIN USING (Tom)
7.2.4:
* Fix some additional cases of VACUUM "No one parent tuple was
found" error
* Prevent VACUUM from being called inside a function (Bruce)
* Ensure pg_clog updates are sync'd to disk before marking
checkpoint complete
* Avoid integer overflow during large hash joins
* Make GROUP commands work when pg_group.grolist is large enough
to be toasted
* Fix errors in datetime tables; some timezone names weren't being
recognized
* Fix integer overflows in circle_poly(), path_encode(), path_add
() (Neil)
* Repair long-standing logic errors in lseg_eq(), lseg_ne(),
lseg_center()
Thanks,
Andrew.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
The truth is rarely pure, and never simple. -- Oscar Wilde
-------------------------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part