From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, S Arvind <arvindwill(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Best suiting OS |
Date: | 2009-10-02 21:58:15 |
Message-ID: | m21vll1mrs.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> It's worth your time to learn how to do this on whatever system you
> prefer to use. Then, if you're ever in a situation where you really
> need patch XYZ right now, you can easily add that patch to the package
> sources and rebuild a custom version that will play nicely within the
> distro's package system --- right up to being automatically replaced
> when the next regular release does come out.
I recently had to do just that (local fix a contrib module failure,
pg_freespacemap). It looks like this when you're using debian:
$ apt-get source postgresql-8.3
$ cd postgresql-8.3-8.3.7
$ cp /path/to/patch.diff debian/patches/13-pg_fsm.diff --- pick yourself next available id
$ $EDITOR debian/changelog
$ debuild
Now you have a new .deb you want to distribute for upgrades (targeting
preprod first, of course). The changelog editing is best done knowing
what is a NMU and how to represent it there, and how version sorting
works; that's the key to automatic overwrite at next official minor
upgrade, and it allows to put the version under your name, so that you
can GnuPG sign the packages at the end of the debuild process.
http://www.debian.org/doc/developers-reference/pkgs.html#nmu
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-02 22:01:05 | Re: Speed while runnning large transactions. |
Previous Message | Tom Lane | 2009-10-02 21:38:35 | Re: Best suiting OS |