Příspěvky

1

Server / Re:Upgrade PostGIS extension z dev verze

« kdy: 01. 04. 2025, 23:33:24 »

Nn, zavolal jsem ten "select postgis_extensions_upgrade();" a ten to zvedl rovnou na tu posledni dostupnou verzi, ktera v dane image byla k dispozici. V tomhle pripade na 3.5.0.

2

Server / Re:Upgrade PostGIS extension z dev verze

« kdy: 01. 04. 2025, 13:41:15 »

Tak kdybyste nahodou nekdy nekdo resil, tak nakonec podle vseho zafungovalo nasledujici:

cd /usr/share/postgres/13/extension
ln -s postgis--TEMPLATED--TO--ANY.sql postgis--3.2.0dev--ANY.sql

Pripadne totez provest pro soubory dalsich extensions. Standardni update pres zavolani "select postgis_extensions_upgrade();" uz pak projde bez problemu a ZATIM jsem nenarazil na zadne chyby.
Tak snad jsme z toho vybruslili a pro priste budu rozhodne opatrnejsi

3

Server / Re:Upgrade PostGIS extension z dev verze

« kdy: 16. 03. 2025, 00:37:52 »

Kolegove, diky za napad!. Souhlasim s tim, ze by to nejspise mohlo byt elegantni reseni, kterym bych se vyhnul potrebe exportu/importu, bohuzel v mem prostredi nemam k dispozici moznost si postavit repliku (korporat, takze oddeleni kompetenci, security pravidla atd.).

4

Server / Upgrade PostGIS extension z dev verze

« kdy: 10. 03. 2025, 10:33:45 »

Ahoj!
Na serveru se mi do Docker image nejakou nestastnou shodou okolnosti dostala extension PostGIS ve verzi 3.2.0.dev, nad kterou se nasledne postavila kupa uzivatelskych objektu.
Pri patchovani jsem narazil na to, ze dostupna verze extension uz je novejsi (3.5.0), bohuzel se mi nedari prijit na zadny zpusob, jak stavajici extension updatovat. Vzdy skoncim na informaci, ze z dane verze neni k dispozici zadna cesta pro update na novou verzi. Rad bych se vyhnul odstavce spojene s exportem/importem dat (instance neni uplne mala a zabere to cas) a tak bych se jeste rad zkusil zeptat zkusenejsich. Existuje nejaka moznost, jak provest update extension nebo me dump zkratka nemine?
Diky moc za pripadne napady!

5

Server / Re:Postgres instance v recovery, přitom otevřená korektně

« kdy: 22. 09. 2023, 12:47:35 »

Diky, dava to smysl. Jen to hledani je trosku metoda pokus/omyl
Zapnuti pg_checksums uz je v procesu, v neprodukci uz mame nasazeno, pro produkci hledame vhodne okno.
Ono to pri vetsim objemu dat docela trva

6

Server / Re:Postgres instance v recovery, přitom otevřená korektně

« kdy: 21. 09. 2023, 22:47:39 »

Diky, zkousel jsem taky, nicmene bez efektu.
Nakonec, pro me naprosto nepochopitelne, se problem prestal objevovat po provedeni vacuum full.
Problem se tim sice "vyresil", bohuzel se mi nepovedlo jednoznacne urcit, co bylo pricinou

7

Server / Re:Postgres instance v recovery, přitom otevřená korektně

« kdy: 10. 09. 2023, 21:56:38 »

Tak nakonec to bude asi slozitejsi. Narovnani parametru problem nevyresilo. Zjistil jsem ale, ze jsem problem schopen jednoznacne reprodukovat. Staci jeden konkretni jednoduchy select a skoncim v logu s nasledujicim:

00000 LOG:  server process (PID 24537) was terminated by signal 11: Segmentation fault
00000 DETAIL:  Failed process was running: select * from XXX  where id ='YYY';
00000 LOG:  terminating any other active server processes
57P02 WARNING:  terminating connection because of crash of another server process
57P02 DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
57P02 HINT:  In a moment you should be able to reconnect to the database and repeat your command.

Dohledal jsem zatim, ze k tomu byl nejaky bug, ale v mnou pouzivane verzi db (13.10) by jiz mel byt vyresen.
Snazim se patrat dal a zjistit, co konkretne by tenhle problem mohlo zpusobovat.

8

Server / Re:Postgres instance v recovery, přitom otevřená korektně

« kdy: 08. 09. 2023, 22:10:50 »

Diky za tip! Nakonec to vypada, ze to bude opravdu nejspis neco na urovni OS. Po odeslani prispevku jsem zjistil, ze problem se zacal vyskytovat az po preclusterovani na druhy node a po kontrole jsem narazil na to, ze nektere soft limit parametry se na nodech lisi.
V logu (pro me prekvapive) nic dalsiho neni. Pouze chybovy kod 57P03, ale zadna do kontextu uvadejici zprava predtim. Nicmene predpokladam, ze to klidne muze byt zpusobeno custom konfiguraci logovani.
Planoval jsem nastavit uroven na debug, abych zjistil vice, ale nejprve otestuji narovnani parametru OS.

9

Server / Postgres instance v recovery, přitom otevřená korektně

« kdy: 08. 09. 2023, 18:30:59 »

Ahoj všem!

Narazil jsem na takový problém, se kterým si zatím nevím rady a napadlo mě zkusit se zeptat zde, zda už jste třeba někdo neřešil ...
Mám korektně nastartovanou instanci Postgresu ve verzi 13.
Vše se tváří ok, dokud nespustím jeden relativně náročný dotaz. Po nějaké době vykonávání dotazu začnou do logu padat hlášky, že instance je v recovery režimu. Kontrola přes pg_controldata ale vrací, že instance je In production.
Tak jsem z toho nějaký zmatený a nedaří se mi zatím přijít na to, co je příčinou.
Napadlo mě třeba poškození nějakých bloků, ale říkám si, že to by se asi v logu projevilo jinak.
Nepotkal jste se s tím už někdo někdy?
Díky za každý případný nápad!

10

Server / Postgres: pg_checksum v kontejneru

« kdy: 16. 02. 2023, 10:34:27 »

Ahoj!

Rad bych poprosil zkusenejsi kolegy o radu. Potreboval bych aktivovat pg_checksum na instancich, ktere bezi v dockeru a ktere maji datovy fs pripojeny zvenku.
Narazim na problem, ze binarka, ktera toto aktivuje, musi bezet (celkem pochopitelne) nad zastavenou instanci.
Jenze kdyz nebezi instance, nebezi kontejner.
Jako reseni me napada nainstalovat binarky primo na server a aktivovat to primo nad fs pro jednotlive instance.
Nejsem si ale jisty, zda ta aktivace neni nejak spojena primo s binarkami, ze kterych se to spousti a zda pak po spusteni kontejneru nemuzu narazit na nejake neplechy?
Podle dokumentace by se neco melo propisovat jen do pg_control, ktery je soucasti daneho fs, takze fungovat by to snad mohlo. Ale prece jen bych se rad zeptal, zda jste nekdo uz neco podobneho neresil?
Diky moc za pripadne zkusenosti!

11

Server / Re:Postgres - identifikace šifrování ransomwarem?

« kdy: 08. 12. 2022, 15:47:21 »

Diky za info i opravu. Cilem neni ani tak snaha overit, zda to Postgres rozdycha, jako spise proverit, zda existuje moznost detekovat takovou podezrelou aktivitu uz nejak z databaze.
Pripadne potvrdit, ze to z db urovne smysluplne nejde a musi se jit na uroven operacniho systemu.

12

Server / Postgres - identifikace šifrování ransomwarem?

« kdy: 08. 12. 2022, 12:49:44 »

Ahoj,

snazim se vyresit, zda jde v pripade teoretickeho pruniku do site poznat v db, ze se pripadny ransomware snazi sifrovat datove soubory primo na fs?

Co jsem zatim zkousel, tak editace samotneho souboru Postgresu nijak nevadi. Kdyz do nej neco pripojim, nevadi mu to vubec a vse funguje bez problemu dal a pokud ho komplet zevnitr smazu nebo prepisu, tak jen vraci prazdne vysledky a dokonce nehaze chybu ani pri insertu, ackoliv nasledny select insertovany radek neobsahuje.

V logu se rovnez zadna chyba neobjevi.

Narazil jsem na to, ze od verze 14 je k dispozici pg_checksums a predpokladal jsem, ze po jeho zapnuti tohle nejak osetri. V zakladu se tak ale nestale, vse puvodne popsane funguje stejnym zpusobem dal.

Rad bych se tedy zeptal zkusenejsich, prosim. Jakym zpusobem vyvolavat kontrolu (nejlepe prubezne), zda jsou datove soubory konzistentni a idealne to zaznamenavat do logu?

Diky moc za pripadne rady ci nakopnuti spravnym smerem!

13

Server / Re:PostgreSQL: objem a obsah WAL logů zpětně

« kdy: 29. 09. 2022, 15:07:50 »

Diky, koukal jsem ted na ten pgbadger a uz jsem taky zjistil, ze to parsuje klasicky log a netyka se to WAL logu.
Moje chyba, spatne jsem to pochopil.
Jinak napad s nastavenim logu a naslednou obnovou je fajn, ale nejspis to v tomto konkretnim pripade nebude mozne.

14

Server / Re:PostgreSQL: objem a obsah WAL logů zpětně

« kdy: 29. 09. 2022, 14:03:18 »

V Postgresu samotném nikde nevidíte historická data. Pro provoz se doporučuje používat aplikace jako je Munin, Zabix, pgwatch2, ... které si metriky z Postgresu sbírají a drží historii. Postgres sám to nedělá. Pokud jste žádný takový tool neměli, tak nic nenajdete.

Diky moc za potvrzeni, alespon vim, ze se s tim nema smysl dal trapit A nadhodim ke zvazeni, zda neco zminovaneho do budoucna nenasadit.

pg_xlogdump/pg_waldump?

Diky za napad. Tohle jsem zkousel jako prvni, ale vytahnul jsem z toho jen info, ktere mi bohuzel prilis nepomohlo. Potreboval bych vedet, ktera aplikace do toho "busila", resp. ktery uzivatel atd. Ale to jsem z toho nevycetl.

pgbadger by vam to z logu vytahl, ale pokud WALy nelogujete, tak...

WAL logy archivujeme, takze k dispozici je mam. Zkusim se na tuhle variantu podivat, diky!

15

Server / PostgreSQL: objem a obsah WAL logů zpětně

« kdy: 29. 09. 2022, 09:49:16 »

Ahoj,
rad bych se tu na zkusenejsi a znalejsi obratil s prosbou o radu.
Resim situaci, kdy se mi zblaznila nejaka Postgre instance a za vikend vygenerovala nestandardne velke mnozstvi wal logu, coz nekolikrat vedlo k ucpani archivniho file systemu, jelikoz se fs zaplnil drive nez doslo ke spusteni naplanovane zalohy archivnich logu.
Dle uzivatelu nemela nad db probihat zadna nestandardni aktivita a ja se ted zpetne snazim zjistit, co se tam vlastne stalo.

Na Oracle mam k dispozici view, pres ktera jsem schopny zjistit objem vygenerovanych logu zpetne a nejak to porovnat s beznym vikendem, pripadne v EE mam k dispozici ASH pro analyzu probehle aktivity. Na Postgre se mi zatim nic podobneho najit nepodarilo. Existuje zde ve standardu neco, cim bych se toho dopatral?
Pripadne existuje nejaka moznost vycist to z tech archivovanych wal logu?
Auditovani tam bohuzel nemam zapnuto, takze ze standardniho logu to nevyctu.
Diky moc za pripadne napady ci nasmerovani!