# Patchen einer Source Code Installation
**URL:** https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965
**Category:** Installation
**Created:** [4. Juni 2020 um 10:16 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965 "2020-06-04T10:16:11Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@gertE](https://www.pg-forum.de/u/gertE)
#### Post date: [4. Juni 2020 um 10:16 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/1 "2020-06-04T10:16:11Z")
Ich habe eine kompilierte 12.3 Installation (wegen Verwendung von GSSAPI) auf einem CentOS 7 System, die soweit funktioniert. Aber wie kann ich hier Patches einspielen, der sonst für Upgrades zuständige Package Manager weiß ja leider nichts davon.
lG
gert
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [4. Juni 2020 um 12:59 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/2 "2020-06-04T12:59:02Z")
Ich habe das noch nie gemacht, aber ich würde davon ausgehen, dass Du ein `git pull` machen musst, in dem Verzeichnis in dem Du den Quellcode ausgecheckt hast. (RELEASE\_12 Branch) und dann einfach neu bauen.
Zudem gibt es ja für jedes Release (auch die Minors) eine entsprechendes tar.gz mit den dazu gehörigen Source. [https://www.postgresql.org/ftp/source/](https://www.postgresql.org/ftp/source/)
Wenn also dann die 12.4 erscheint, sollte das entsprechende Archiv dort auch verfügbar sein.
---
### Author:  [@gertE](https://www.pg-forum.de/u/gertE)
#### Post date: [4. Juni 2020 um 13:20 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/3 "2020-06-04T13:20:30Z")
Stimmt soweit (funktioniert auch), mit einem pg\_upgrade kann man auch die Datenbank “migrieren”.
/var/lib/pgsql/12.1/bin/pg\_upgrade --old-bindir=/var/lib/pgsql/12.0/bin --new-bindir=/var/lib/pgsql/12.1/bin/ --old-datadir=/var/lib/pgsql/data\_old/ --new-datadir=/var/lib/pgsql/dataNew/ --check --verbose
Bei sehr vielen Clustern auf einer Installation empfiehlt sich dann dringend ein Script zu bauen.
Jetzt wäre es noch interessant, wann es ausreicht, die Datenbank einfach mit den neuen Binaries zu starten und wann ein Upgrade der DB erforderlich ist. Das kann nämlich bei größeren Datenbanken schnell sehr aufwendig werden.
Bei Major Release Wechsel wird es sich wahrschlich nicht vermeiden lassen.
lG
gert
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [4. Juni 2020 um 13:30 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/4 "2020-06-04T13:30:55Z")
pg\_upgrade ist nur notwendig wenn man von einer Major Version zur nächsten migriert. Bei Minor Upgrades ist das nicht notwendig. Einfach binaries installieren, neu starten, fertig.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [4. Juni 2020 um 14:00 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/5 "2020-06-04T14:00:46Z")
> [@gertE](#):
>
> Jetzt wäre es noch interessant, wann es ausreicht, die Datenbank einfach mit den neuen Binaries zu starten und wann ein Upgrade der DB erforderlich ist.
bei minor-Updates reicht immer ein Neustart nach dem Einspielen der binaries. Es _kann_ erforderlich sein, Indexe neu zu bauen. Das passiert selten, und wenn, steht es in den release-notes.
---
### Author:  [@gertE](https://www.pg-forum.de/u/gertE)
#### Post date: [9. Juni 2020 um 14:00 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/6 "2020-06-09T14:00:26Z")
Bei einem Major Version upgrade mit pg\_upgrade werden die Konfig Dateien postgresql.conf und pg\_hba.conf ja nicht mitgenommen, daher habe ich sie jetzt immer manuell kopiert.
Gibt es da eine bessere Vorgangsweise, da dadurch neue Einstellungen etwa in der postgresql.conf die mit einer neuen Version kommen würden ja überschrieben werden?
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [9. Juni 2020 um 14:14 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/7 "2020-06-09T14:14:02Z")
Ich mache grundsätzlich nur eine einzige Änderung in postgresql.conf: nämlich ein include auf eine “custom.conf” in der alle meine Änderungen drin stehen. Nach einem Upgrade muss man nur die custom.conf kopieren und das entsprechende include wieder einfügen.
Wenn man sich das Kopieren auch noch sparen will, kann man z.B. die custom.conf z.B. in ein Verzeichnis außerhalb des Data Directory legen (aber um das einfügen des include kommt man nicht herum)
---
### Author:  [@gertE](https://www.pg-forum.de/u/gertE)
#### Post date: [9. Juni 2020 um 14:31 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/8 "2020-06-09T14:31:44Z")
Genial: Besten Dank für die Anregung!
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [9. Juni 2020 um 14:55 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/9 "2020-06-09T14:55:09Z")
ACK, ist auch unsere Empfehlung. Wenn Du z.B. die Config von 10 nach 11 oder von 11 nach 12 kopierst wirst Du a) Konflikte haben weil Parameter entfallen sind und b) du siehst neue Parameter nicht. Das ist als eine recht schlechte Idee.
---
### Author:  [@Xandrian](https://www.pg-forum.de/u/Xandrian)
#### Post date: [9. Juni 2020 um 15:13 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/10 "2020-06-09T15:13:32Z")
Off-Topic: Nicht nur für PostgreSQL eine Empfehlung sondern grundsätzlich. Spart man sich viel Ärger bei Updates von Programmen.
---
### Author:  [@system](https://www.pg-forum.de/u/system)
#### Post date: [21. Februar 2021 um 06:48 UTC](https://www.pg-forum.de/t/patchen-einer-source-code-installation/11965/11 "2021-02-21T06:48:17Z")