Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #132353 > unrolled thread

Debian bullseye > bookworm

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-02 21:00 +0200
    Re: Debian bullseye > bookworm Tim Ritberg <tim@server.invalid> - 2023-07-02 21:26 +0200
      Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-02 21:33 +0200
        Re: Debian bullseye > bookworm Marco Moock <mo01@posteo.de> - 2023-07-02 21:41 +0200
          Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-02 21:56 +0200
          Re: Debian bullseye > bookworm Andreas Kohlbach <ank@spamfence.net> - 2023-07-02 23:32 -0400
        Re: Debian bullseye > bookworm Tim Ritberg <tim@server.invalid> - 2023-07-02 22:21 +0200
          Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-03 05:17 +0200
        Re: Debian bullseye > bookworm Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-07-03 08:38 +0200
          Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-03 08:41 +0200
          Re: Debian bullseye > bookworm Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 09:23 +0000
            Re: Debian bullseye > bookworm Tim Ritberg <tim@server.invalid> - 2023-07-03 11:54 +0200
              Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 12:10 +0200
                Re: Debian bullseye > bookworm Tim Ritberg <tim@server.invalid> - 2023-07-03 18:49 +0200
                  Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 19:00 +0200
                    Re: Debian bullseye > bookworm Tim Ritberg <tim@server.invalid> - 2023-07-03 19:09 +0200
                      Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 19:19 +0200
              Re: Debian bullseye > bookworm Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-07-03 18:53 +0200
                Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 19:13 +0200
            Re: Debian bullseye > bookworm Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-07-03 18:50 +0200
              Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 19:15 +0200
              Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-03 20:38 +0200
                Re: Debian bullseye > bookworm Tim Ritberg <tim@server.invalid> - 2023-07-03 21:12 +0200
                  Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-03 21:27 +0200
                  Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 22:42 +0200
          Re: Debian bullseye > bookworm Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 12:32 +0000
            Re: Debian bullseye > bookworm Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-07-03 18:51 +0200
              Re: Debian bullseye > bookworm Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 19:16 +0200
              Re: Debian bullseye > bookworm Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 17:46 +0000
    Re: Debian bullseye > bookworm Andreas Kohlbach <ank@spamfence.net> - 2023-07-02 23:29 -0400
      Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-03 07:12 +0200
    Re: Debian bullseye > bookworm Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-07-03 07:12 +0000
      Re: Debian bullseye > bookworm Tim Landscheidt <tim@tim-landscheidt.de> - 2023-07-03 09:30 +0000
        Re: Debian bullseye > bookworm "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-03 13:56 +0200
          Re: Debian bullseye > bookworm Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 16:32 +0200
            Re: Debian bullseye > bookworm Marcus Jodorf <m@bogomips.de> - 2023-07-04 04:40 +0200
          Re: Debian bullseye > bookworm Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-07-04 09:07 +0000
            Re: Debian bullseye > bookworm "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-04 11:55 +0200
              Re: Debian bullseye > bookworm Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-07-11 06:05 +0000
                Re: Debian bullseye > bookworm "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-11 11:29 +0200
    Re: Debian bullseye > bookworm Marcus Jodorf <m@bogomips.de> - 2023-07-04 04:36 +0200
    Re: Debian bullseye > bookworm Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-07-11 08:41 +0000
      Re: Debian bullseye > bookworm klaus reile <klaus.reile@no-more-mail-to.zr> - 2023-07-11 15:41 +0200
      Re: Debian bullseye > bookworm Friedemann Stoyan <usenet@ip6-mail.de> - 2023-07-11 16:07 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#132472

Am 03.07.23 um 18:50 schrieb Marcel Mueller:
> Am 03.07.23 um 11:23 schrieb Ulli Horlacher:
>> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>>> Am 02.07.23 um 21:33 schrieb klaus reile:
>>>>> Xubuntu 22.10 64 bit, Kernel 5.19 (native)
>>>>
>>>> Xubuntu war auch mein favorisiertes Linux.
>>>
>>> Ja, so lange bis sich der Ressourcenbedarf wegen Umstellung auf Snap
>>> verdreifacht hat. Das brauche ich wahrlich nicht.
>>
>> Mint gibts auch mit Xfce, hat aber kein Snap. Best of both worlds :-)
> 
> Weiß ich, hab ich.
> Alles, was ein Major Update brauchte, habe ich schon auf Mint 
> umgestellt. Läuft laut meiner Mutter sogar besser als das Xubuntu zuvor.

Mint ist auch meine bevorzugte Distri. Nutze ich seit Jahren und es
läuft einfach immer und auch alles.

-- 
Ut sementem feceris, ita metes (Cicero)

[toc] | [prev] | [next] | [standalone]

#132477

On Mon, 3 Jul 2023 18:50:53 +0200
Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:

> Am 03.07.23 um 11:23 schrieb Ulli Horlacher:
> > Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> >> Am 02.07.23 um 21:33 schrieb klaus reile:
> >>>> Xubuntu 22.10 64 bit, Kernel 5.19 (native)
> >>>
> >>> Xubuntu war auch mein favorisiertes Linux.
> >>
> >> Ja, so lange bis sich der Ressourcenbedarf wegen Umstellung auf
> >> Snap verdreifacht hat. Das brauche ich wahrlich nicht.
> > 
> > Mint gibts auch mit Xfce, hat aber kein Snap. Best of both
> > worlds :-)
> 
> Weiß ich, hab ich.
> Alles, was ein Major Update brauchte, habe ich schon auf Mint 
> umgestellt. Läuft laut meiner Mutter sogar besser als das Xubuntu
> zuvor.
> 
> 
> Marcel

Mint hat sich wirklich gemausert. Es ist nun das, was Ubuntu einst war.

Klaus

[toc] | [prev] | [next] | [standalone]

#132479

Am 03.07.23 um 20:38 schrieb klaus reile:
> Mint hat sich wirklich gemausert. Es ist nun das, was Ubuntu einst war.
Nö, es gibt keine halbjährlichen Upgrades für Mint.

Tim

[toc] | [prev] | [next] | [standalone]

#132481

On Mon, 3 Jul 2023 21:12:53 +0200
Tim Ritberg <tim@server.invalid> wrote:

> Am 03.07.23 um 20:38 schrieb klaus reile:
> > Mint hat sich wirklich gemausert. Es ist nun das, was Ubuntu einst
> > war.
> Nö, es gibt keine halbjährlichen Upgrades für Mint.
> 
> Tim
> 

Es gibt Leute mit verschiedenen Prioritäten. Der Eine mag dies
(Stabilität), der Andere das (immer die neueste Software). Ich habe
mich für Ersteres entschieden und nutze Debian & LMDE. Das war auch mal
anders. Früher, vor vielen Jahren ;)

Klaus

[toc] | [prev] | [next] | [standalone]

#132485

Am 03.07.23 um 21:12 schrieb Tim Ritberg:
> Am 03.07.23 um 20:38 schrieb klaus reile:
>> Mint hat sich wirklich gemausert. Es ist nun das, was Ubuntu einst war.
> Nö, es gibt keine halbjährlichen Upgrades für Mint.

Wer braucht die und warum?
Das Gute an Mint ist ja gerade die LTS-Ausrichtung.
Wärst Du bei Windows nicht noch besser aufgehoben oder bei Suse Tumbleweed?

-- 
Ut sementem feceris, ita metes (Cicero)

[toc] | [prev] | [next] | [standalone]

#132422

Marcel Mueller schrieb am 3/7/2023 08:38:

> Am 02.07.23 um 21:33 schrieb klaus reile:
>>> Xubuntu 22.10 64 bit, Kernel 5.19 (native)
>> 
>> Xubuntu war auch mein favorisiertes Linux.
>
> Ja, so lange bis sich der Ressourcenbedarf wegen Umstellung auf Snap 
> verdreifacht hat. Das brauche ich wahrlich nicht.

Man muss Snap nicht benutzen. Noch nicht, jedenfalls.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#132467

Am 03.07.23 um 14:32 schrieb Gerald E¡scher:
> Marcel Mueller schrieb am 3/7/2023 08:38:
> 
>>> Xubuntu war auch mein favorisiertes Linux.
>>
>> Ja, so lange bis sich der Ressourcenbedarf wegen Umstellung auf Snap
>> verdreifacht hat. Das brauche ich wahrlich nicht.
> 
> Man muss Snap nicht benutzen. Noch nicht, jedenfalls.

Unter Ubuntu kenne ich bei den aktuellen Versionen keinen sinnvollen Weg 
ohne Snap.


Marcel

[toc] | [prev] | [next] | [standalone]

#132473

Am 03.07.23 um 18:51 schrieb Marcel Mueller:
> Am 03.07.23 um 14:32 schrieb Gerald E¡scher:
>> Marcel Mueller schrieb am 3/7/2023 08:38:
>>
>>>> Xubuntu war auch mein favorisiertes Linux.
>>>
>>> Ja, so lange bis sich der Ressourcenbedarf wegen Umstellung auf Snap
>>> verdreifacht hat. Das brauche ich wahrlich nicht.
>>
>> Man muss Snap nicht benutzen. Noch nicht, jedenfalls.
> 
> Unter Ubuntu kenne ich bei den aktuellen Versionen keinen sinnvollen Weg 
> ohne Snap.

Flathub.

-- 
Ut sementem feceris, ita metes (Cicero)

[toc] | [prev] | [next] | [standalone]

#132475

Marcel Mueller schrieb am 3/7/2023 18:51:

> Am 03.07.23 um 14:32 schrieb Gerald E¡scher:
>> Marcel Mueller schrieb am 3/7/2023 08:38:
>> 
>>>> Xubuntu war auch mein favorisiertes Linux.
>>>
>>> Ja, so lange bis sich der Ressourcenbedarf wegen Umstellung auf Snap
>>> verdreifacht hat. Das brauche ich wahrlich nicht.
>> 
>> Man muss Snap nicht benutzen. Noch nicht, jedenfalls.
>
> Unter Ubuntu kenne ich bei den aktuellen Versionen keinen sinnvollen Weg 
> ohne Snap.

Ich bin bei 22.04 LTS und da lässt sich auch der Firefox aus dem
Repository von Mozilla verwenden. Den Rest gibt es von Ubuntu auch ohne
Snap.
Aber prinzipiell habe ich auch mit dem Snap-Firefox keine Probleme.

Zudem sieht
| $ apt search firefox-esr
| firefox-esr/jammy 102.13.0esr+build2-0ubuntu0.22.04.1 amd64
|   Safe and easy web browser from Mozilla
| [...]
danach aus, als käme Firefox ESR ohne Snap daher.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#132372

On Sun, 2 Jul 2023 21:00:57 +0200, klaus reile wrote:
>
> Kofler schreibt sinngemäss: Das beste Debian ever.
>
> Kann ich so bestätigen. Das upgrade von 11 nach 12 verlief problemlos.
> 2 kleine optische Dinge musste ich per Hand nachbessern.

Was waren die?

[Betrifft MATE]

Auf der GUI (besonders im mate-terminal) fiel mir ein neuer Font auf. Ich
habe "Use the system fixed font" abgehakt, sodass der wohl getauscht
wurde. Gewöhnungssache...

Dann werden beim Durchblättern mit ALT-TAB die Fenster selbst nicht mehr
angezeigt, nur das Rechteck in der Mitte mit deren verkleinerten
Darstellung. Auch Gewöhnungssache.

Hätte aber IMO beides nicht sein müssen. Zumal nicht gefragt wurde, ob
man das will.
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#132374

On Sun, 02 Jul 2023 23:29:49 -0400
Andreas Kohlbach <ank@spamfence.net> wrote:

> On Sun, 2 Jul 2023 21:00:57 +0200, klaus reile wrote:
> >
> > Kofler schreibt sinngemäss: Das beste Debian ever.
> >
> > Kann ich so bestätigen. Das upgrade von 11 nach 12 verlief
> > problemlos. 2 kleine optische Dinge musste ich per Hand nachbessern.
> 
> Was waren die?

Xfce: Obere Leiste Fonts für Datum sehr klein und DVD-Abspielprogramm
wollte per Hand angepasst werden (war vorher aber auch per Hand
installiert). Sonst alles gut

Klaus

> 
> [Betrifft MATE]
> 
> Auf der GUI (besonders im mate-terminal) fiel mir ein neuer Font auf.
> Ich habe "Use the system fixed font" abgehakt, sodass der wohl
> getauscht wurde. Gewöhnungssache...
> 
> Dann werden beim Durchblättern mit ALT-TAB die Fenster selbst nicht
> mehr angezeigt, nur das Rechteck in der Mitte mit deren verkleinerten
> Darstellung. Auch Gewöhnungssache.
> 
> Hätte aber IMO beides nicht sein müssen. Zumal nicht gefragt wurde, ob
> man das will.
> -- 
> Andreas

[toc] | [prev] | [next] | [standalone]

#132382

On Sun, 02 Jul 2023 21:00:57 klaus reile wrote:
> Das upgrade von 11 nach 12 verlief problemlos.

Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.

Da kann Debian nichts dafür, und Postgres auch nur sehr bedingt,
aber anstregend ist es dennoch immer wieder.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Für kleine Genies - spüren mit Stefan!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#132391

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:

>> Das upgrade von 11 nach 12 verlief problemlos.

> Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.

> Da kann Debian nichts dafür, und Postgres auch nur sehr bedingt,
> aber anstregend ist es dennoch immer wieder.

Liegt die Betonung hier auf „komplexer“, oder geht das unter
Debian nur problematisch? In Fedora funktioniert
„postgresql-setup --upgrade“ ganz passabel für „Standardin-
stallationen“.

Tim

[toc] | [prev] | [next] | [standalone]

#132417

On 2023-07-03 09:30, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:
>>> Das upgrade von 11 nach 12 verlief problemlos.
>
>> Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.
>
>> Da kann Debian nichts dafür, und Postgres auch nur sehr bedingt,
>> aber anstregend ist es dennoch immer wieder.
>
> Liegt die Betonung hier auf „komplexer“, oder geht das unter
> Debian nur problematisch?

Ich vermute, es geht darum, dass man in Postgres einen
Major-Versions-Upgrade explizit durchführen muss. Man kann nicht einfach
eine neue Version der Datenbank-Software mit den unveränderten
Datenfiles starten, man muss die vorher konvertieren (wobei das im
Normalfall nur den Catalog betrifft und die "User-Daten" unverändert
bleiben und einfach kopiert oder verlinkt werden können). Auch
Extensions müssen üblicherweise parallel upgegradet werden, was nicht
immer trivial ist.

> In Fedora funktioniert „postgresql-setup --upgrade“ ganz passabel für
> „Standardin- stallationen“.

Unter Debian macht das das Script pg_upgradecluster.

Meistens ist das meiner Erfahrung nach nicht anstrengend (dauert ein
paar Sekunden bis ein paar Minuten), aber immer ein bisschen ein
Nervenkitzel.

Patroni-Cluster o.ä. finde ich aber auch etwas anstrengend.

        hp

[toc] | [prev] | [next] | [standalone]

#132448

"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>Ich vermute, es geht darum, dass man in Postgres einen
>Major-Versions-Upgrade explizit durchführen muss. Man kann nicht einfach
>eine neue Version der Datenbank-Software mit den unveränderten
>Datenfiles starten, man muss die vorher konvertieren (wobei das im
>Normalfall nur den Catalog betrifft und die "User-Daten" unverändert
>bleiben und einfach kopiert oder verlinkt werden können). Auch
>Extensions müssen üblicherweise parallel upgegradet werden, was nicht
>immer trivial ist.
>
>Unter Debian macht das das Script pg_upgradecluster.
>
>Meistens ist das meiner Erfahrung nach nicht anstrengend (dauert ein
>paar Sekunden bis ein paar Minuten), aber immer ein bisschen ein
>Nervenkitzel.
>
>Patroni-Cluster o.ä. finde ich aber auch etwas anstrengend.

Datenbanken sind halt nichts für Weicheier ,-)

Wenn man es einfach haben möchte kann man ja MySQL oder MariaDB
nehmen.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#132501

Marc Haber <mh+usenetspam1118@zugschl.us> schrieb:

> Datenbanken sind halt nichts für Weicheier ,-)
>
> Wenn man es einfach haben möchte kann man ja MySQL oder MariaDB
> nehmen.

LOL. Made my day!


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#132518

On Mon, 03 Jul 2023 13:56:47 Peter J. Holzer wrote:
> On 2023-07-03 09:30, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:
>>>> Das upgrade von 11 nach 12 verlief problemlos.

>>> Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.

>> Liegt die Betonung hier auf „komplexer“, oder geht das unter
>> Debian nur problematisch?

> Ich vermute, es geht darum, dass man in Postgres einen
> Major-Versions-Upgrade explizit durchführen muss. Man kann nicht
> einfach eine neue Version der Datenbank-Software mit den
> unveränderten Datenfiles starten, man muss die vorher konvertieren
> (wobei das im Normalfall nur den Catalog betrifft und die
> "User-Daten" unverändert bleiben und einfach kopiert oder verlinkt
> werden können). Auch Extensions müssen üblicherweise parallel
> upgegradet werden, was nicht immer trivial ist.

Genau das. Man hat nach dem Upgrade erst einmal *zwei*
Postgres-Instanzen laufen, eine für jede Version, die Datenbank
selbst wird (UDIAGS) nicht automatisch konvertiert.

Nun habe ich da z.B. dieses - amateurhaft betriebene -
Usenet-Archiv, das den Großteil der Festplatte belegt und daher
nicht einfach so in-place konvertiert werden kann. Also vielleicht
erst einmal die alte Version weiterlaufen lassen, während ich mich
umsehe, wohin ich das Ding exportierend konvertieren und dann von
dort wieder zurückspielen kann? Klingt gut, klappt aber nur genau
bis zum ersten Aufruf eines pgperl-Skripts, das dank des Upgrades
seines Interpreters verlustig gegangen ist. Die Inbox füllt sich
rapide mit Fehlermeldungen.

Führt dazu, dass man doch kurzfristig mehr Zeit freischaufelt, als
man ursprünglich wollte (und zwischendurch noch feststellt, dass
zwar Pakete wie postgresql und postgresql-common automatisch
aktualisiert werden, aber natürlich nicht postgresql-plperl-13, für
das kein generisches Paket existiert - aber das kostet zum Glück
kaum zusätzliche Zeit).

Ist nicht das erste Mal, aber zwei Jahre reichen offenbar gut aus,
um das Problem erfolgreich zu verdrängen.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so lästig. Da lacht der Hausmann!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#132522

On 2023-07-04 09:07, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
> On Mon, 03 Jul 2023 13:56:47 Peter J. Holzer wrote:
>> On 2023-07-03 09:30, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
>>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:
>>>>> Das upgrade von 11 nach 12 verlief problemlos.
>>>> Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.
>
>>> Liegt die Betonung hier auf „komplexer“, oder geht das unter
>>> Debian nur problematisch?
>
>> Ich vermute, es geht darum, dass man in Postgres einen
>> Major-Versions-Upgrade explizit durchführen muss. Man kann nicht
>> einfach eine neue Version der Datenbank-Software mit den
>> unveränderten Datenfiles starten, man muss die vorher konvertieren
>> (wobei das im Normalfall nur den Catalog betrifft und die
>> "User-Daten" unverändert bleiben und einfach kopiert oder verlinkt
>> werden können). Auch Extensions müssen üblicherweise parallel
>> upgegradet werden, was nicht immer trivial ist.
>
> Genau das. Man hat nach dem Upgrade erst einmal *zwei*
> Postgres-Instanzen laufen, eine für jede Version, die Datenbank
> selbst wird (UDIAGS) nicht automatisch konvertiert.
>
> Nun habe ich da z.B. dieses - amateurhaft betriebene -
> Usenet-Archiv, das den Großteil der Festplatte belegt und daher
> nicht einfach so in-place konvertiert werden kann.

|      -k, --link
|          In pg_upgrade mode, use hard links instead of copying files to the
|          new cluster.  This option is merely passed on to pg_upgrade.  See
|          pg_upgrade(1) for details.

Sollte vielleicht default sein, wenn Source und Target am gleichen
Filesystem liegen (was bei Upgrades ja meistens der Fall ist).

> Führt dazu, dass man doch kurzfristig mehr Zeit freischaufelt, als
> man ursprünglich wollte (und zwischendurch noch feststellt, dass
> zwar Pakete wie postgresql und postgresql-common automatisch
> aktualisiert werden, aber natürlich nicht postgresql-plperl-13, für
> das kein generisches Paket existiert - aber das kostet zum Glück
> kaum zusätzliche Zeit).

Ist mir auch schon passiert.

> Ist nicht das erste Mal, aber zwei Jahre reichen offenbar gut aus,
> um das Problem erfolgreich zu verdrängen.

Ich habe mittlerweise genug PostgreSQL-Instanzen laufen, dass pro Jahr
zwei bis drei upgegradet werden müssen. Da vergisst man dann weniger.
Aber natürlich sind die meisten davon trivial, und die eine mit Patroni,
PgPerl/U, selbstcompilierten Perl-Modulen, Apache mit WebDAV,
hunderttausend Cronjobs und sonstigen Sonderlocken kommt nur alle 4
Jahre dran. Und da sind dann auch die Notizen vom letzten mal nur mehr
begrenzt hilfreich (zugegeben: Nur ein Teil der Komplexität hat direkt
mit PostgreSQL zu tun - das ist mehr das gesamte Drumherum.)

        hp

PS: Ich beziehe die Postgres-Pakete von PGDG, nicht von Debian/Ubuntu.
    Das entkoppelt Datenbank-Upgrade von OS-Upgrade (das war nicht die
    Motivation, ist aber ein angenehmer Nebeneffekt).

[toc] | [prev] | [next] | [standalone]

#132702

On Tue, 04 Jul 2023 11:55:25 Peter J. Holzer wrote:
> On 2023-07-04 09:07, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
>> On Mon, 03 Jul 2023 13:56:47 Peter J. Holzer wrote:
>>> On 2023-07-03 09:30, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
>>>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:
>>>>>> Das upgrade von 11 nach 12 verlief problemlos.
>>>>> Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.
>>
>> Man hat nach dem Upgrade erst einmal *zwei* Postgres-Instanzen
>> laufen, eine für jede Version, die Datenbank selbst wird (UDIAGS)
>> nicht automatisch konvertiert.

>> Nun habe ich da z.B. dieses - amateurhaft betriebene -
>> Usenet-Archiv, das den Großteil der Festplatte belegt und daher
>> nicht einfach so in-place konvertiert werden kann.
> 
> |      -k, --link
> |          In pg_upgrade mode, use hard links instead of copying files to the
> |          new cluster.  This option is merely passed on to pg_upgrade.  See
> |          pg_upgrade(1) for details.
> 
> Sollte vielleicht default sein, wenn Source und Target am gleichen
> Filesystem liegen (was bei Upgrades ja meistens der Fall ist).

Oha, danke - kannte ich noch gar nicht, und es sieht mehr als
empfehlenswert aus. Das ist der Nachteil, wenn Programme *zu*
einfach funktionieren, man dringt gar nicht erst in die Tiefe...

Die man-Page erwähnt darüberhinaus auch noch --clone, falls man ein
Sicherheitsnetz einziehen möchte.

>> Ist nicht das erste Mal, aber zwei Jahre reichen offenbar gut
>> aus, um das Problem erfolgreich zu verdrängen.

> Ich habe mittlerweise genug PostgreSQL-Instanzen laufen, dass pro
> Jahr zwei bis drei upgegradet werden müssen.

Ich habe schon noch einige weitere, aber die enthalten keine Skripts
und sind auch vom Volumen her so klein, dass das alles kein Thema
ist. Da muss ich nur daran denken, dass der Versionswechsel nach dem
Upgrade *überhaupt* noch manuell durchgeführt werden muss, das geht.

> PS: Ich beziehe die Postgres-Pakete von PGDG, nicht von
> Debian/Ubuntu.  Das entkoppelt Datenbank-Upgrade von OS-Upgrade
> (das war nicht die Motivation, ist aber ein angenehmer
> Nebeneffekt).

Hm, mal gucken. An sich halte ich meine Installationen gerne so
einfach wie möglich - hat man dann nicht erst recht die Chance, sich
irgendwelche Versionsprobleme mit Perl et al. einzufangen?

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, mit dem kompetenten Hauch der Liebe.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#132713

On 2023-07-11 06:05, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
> On Tue, 04 Jul 2023 11:55:25 Peter J. Holzer wrote:
>> On 2023-07-04 09:07, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
>>> On Mon, 03 Jul 2023 13:56:47 Peter J. Holzer wrote:
>>>> On 2023-07-03 09:30, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
>>>>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:
>>>>>>> Das upgrade von 11 nach 12 verlief problemlos.
>>>>>> Solange man halt keine komplexeren PostgreSQL-Datenbanken hat.
>>>
>>> Man hat nach dem Upgrade erst einmal *zwei* Postgres-Instanzen
>>> laufen, eine für jede Version, die Datenbank selbst wird (UDIAGS)
>>> nicht automatisch konvertiert.
>
>>> Nun habe ich da z.B. dieses - amateurhaft betriebene -
>>> Usenet-Archiv, das den Großteil der Festplatte belegt und daher
>>> nicht einfach so in-place konvertiert werden kann.
>> 
>> |      -k, --link
>> |          In pg_upgrade mode, use hard links instead of copying files to the
>> |          new cluster.  This option is merely passed on to pg_upgrade.  See
>> |          pg_upgrade(1) for details.
>> 
>> Sollte vielleicht default sein, wenn Source und Target am gleichen
>> Filesystem liegen (was bei Upgrades ja meistens der Fall ist).
>
> Oha, danke - kannte ich noch gar nicht, und es sieht mehr als
> empfehlenswert aus. Das ist der Nachteil, wenn Programme *zu*
> einfach funktionieren, man dringt gar nicht erst in die Tiefe...
>
> Die man-Page erwähnt darüberhinaus auch noch --clone, falls man ein
> Sicherheitsnetz einziehen möchte.

Dafür braucht man allerdings auch ein Filesystem, das das kann. Da ich
(eher aus Gewohnheit) Ext4 einsetze, nützt mir das nichts. Vielleicht
sollte ich doch mal den Sprung zu BtrFS oder ZFS wagen. (Postgres auf
COW-Filesystemen birgt aber auch ein paar Stolpersteine.)


>> PS: Ich beziehe die Postgres-Pakete von PGDG, nicht von
>> Debian/Ubuntu.  Das entkoppelt Datenbank-Upgrade von OS-Upgrade
>> (das war nicht die Motivation, ist aber ein angenehmer
>> Nebeneffekt).
>
> Hm, mal gucken. An sich halte ich meine Installationen gerne so
> einfach wie möglich - hat man dann nicht erst recht die Chance, sich
> irgendwelche Versionsprobleme mit Perl et al. einzufangen?

Die letzten 9 Jahre hats problemlos funktioniert ;-).

Die PGDG baut die Pakete für jede Distribution extra, also sollte es da
zu keinen Versionsproblemen kommen.

        hp

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web