WG: [Extern] Re: question on plain pg_dump file usage

Von: Ron Johnson Gesendet: Dienstag, 17. September 2024 14:44 An: PG-General Mailing List Betreff: [Extern] Re: question on plain pg_dump file usage On Tue, Sep 17, 2024 at 8:22 AM Zwettler Markus (OIZ) mailto:markus.zwett...@zuerich.ch>> wrote: I have to do an out-of-place Postgres mig

WG: question on plain pg_dump file usage

Von: Zwettler Markus (OIZ) Gesendet: Dienstag, 17. September 2024 14:22 An: PG-General Mailing List Betreff: question on plain pg_dump file usage I have to do an out-of-place Postgres migration from PG12 to PG16 using: pg_dump -F p -f dump.sql ... sed -i "s/old_name/new_name/g&quo

AW: Re: PostgreSQL container crash trouble.

Hi Laurenz, You said use your backup. Wouldn't it be enough to start instance crash recovery just before the corrupted wal in that case? recovery_target_lsn = <> recovery_target_inclusive = off No need for a backup. Correct? Cheers, Markus > -Ursprüngliche Nachri

Advice on binary installation

install all global needed extensions or software with every project to get a homogenous binary installation. Software installation is done with yum using PGDG downstream channels. Any recommendations? Thanks, Markus

AW: [Extern] Re: Advice on binary installation

> -Ursprüngliche Nachricht- > Von: Paul Förster > Gesendet: Dienstag, 13. April 2021 15:02 > An: Zwettler Markus (OIZ) > Cc: pgsql-gene...@postgresql.org > Betreff: [Extern] Re: Advice on binary installation > > Hi Markus, > > On 13. Apr, 2021, at 14:43,

autovacuum on pg_catalog tables

: "pg_largeobject_metadata" is a system catalog (How) Is it possible to change such table attributes on pg_catalog tables? Thanks, Markus

AW: [Extern] Re: autovacuum on pg_catalog tables

Thanks for the info. I have a lot of LO manipulation and want a more aggressive autovacuum on some pg_catalog tables therefore. I do not see any reason why this should not work or be at risk? Markus Von: Vijaykumar Jain Gesendet: Freitag, 4. Juni 2021 17:37 An: Zwettler Markus (OIZ) Cc

AW: AW: [Extern] Re: autovacuum on pg_catalog tables

); ERROR: AccessExclusiveLock required to add toast table. Time: 1.601 ms Any idea? Thanks, Markus Von: Zwettler Markus (OIZ) Gesendet: Freitag, 4. Juni 2021 17:44 An: Vijaykumar Jain Cc: pgsql-general@lists.postgresql.org Betreff: AW: [Extern] Re: autovacuum on pg_catalog tables Thanks

change ownership of schema public?

e.g. regarding extensions? Thanks, Markus

postgres ssl client certificate authentification

TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help. pcl_l222=> Any idea? Thanks, Markus

error connecting to pgbouncer admin console

-07 16:57:00.969 CET [73046] FATAL @src/objects.c:312 in function put_in_order(): put_in_order: found existing elem $ pgbouncer --version PgBouncer 1.16.1 libevent 2.0.21-stable adns: libc-2.17 tls: OpenSSL 1.0.2k-fips 26 Jan 2017 Any idea? Thanks, Markus

AW: error connecting to pgbouncer admin console

Simply a bug. https://github.com/pgbouncer/pgbouncer/issues/568 Cheers, Markus > -Ursprüngliche Nachricht- > Von: Zwettler Markus (OIZ) > Gesendet: Dienstag, 7. Dezember 2021 17:10 > An: pgsql-general@lists.postgresql.org > Betreff: error connecting to pgbouncer admin

postgres event trigger workaround

Hi, PG event triggers are not firing on CREATE ROLE, CREATE DATABASE, CREATE TABLESPACE by definition (would be nice if they do). Is there any workaround to react with ddl_command_start behavior on such an event? Thanks, Markus

AW: [Extern] Re: postgres event trigger workaround

> > Hi, > > On Wed, Jan 12, 2022 at 11:57:45AM +0000, Zwettler Markus (OIZ) wrote: > > > > PG event triggers are not firing on CREATE ROLE, CREATE DATABASE, > > CREATE TABLESPACE by definition (would be nice if they do). > > > > Is there any workaround t

question on timezone with pgBackRest PITR

The Postgres instance is running on timezone CEST (parameter timezone = 'Europe/Zurich') which is UTC+2. The underlying Linux OS (K8s container) is running on timezone UTC. Backups are done with pgBackRest. With PITR we will have to use target timezone CEST (--target=2024-09-19 17:00:00+02") a

Re: Re: could not accept ssl connection tlsv1 alert unknown ca

> -Ursprüngliche Nachricht- > Von: Zwettler Markus (OIZ) > Gesendet: Montag, 3. Februar 2025 09:37 > An: Adrian Klaver ; Tom Lane > ; pgsql-general@lists.postgresql.org > Betreff: Re: Re: could not accept ssl connection tlsv1 alert unknown ca > > > -

Re: Re: could not accept ssl connection tlsv1 alert unknown ca

> Von: Tom Lane > Gesendet: Donnerstag, 30. Januar 2025 18:51 > An: Zwettler Markus (OIZ) > Cc: pgsql-general@lists.postgresql.org > Betreff: [Extern] Re: could not accept ssl connection tlsv1 alert unknown ca > > "Zwettler Markus (OIZ)" writes: > > How

Re: Re: could not accept ssl connection tlsv1 alert unknown ca

> -Ursprüngliche Nachricht- > Von: Adrian Klaver > Gesendet: Freitag, 31. Januar 2025 17:37 > An: Zwettler Markus (OIZ) ; Tom Lane > ; pgsql-general@lists.postgresql.org > Betreff: [Extern] Re: could not accept ssl connection tlsv1 alert unknown ca > > On 1/31/2

Re: Re: could not accept ssl connection tlsv1 alert unknown ca

> -Ursprüngliche Nachricht- > Von: Adrian Klaver > Gesendet: Freitag, 31. Januar 2025 18:07 > An: Zwettler Markus (OIZ) ; Tom Lane > ; pgsql-general@lists.postgresql.org > Betreff: [Extern] Re: could not accept ssl connection tlsv1 alert unknown ca > > On 1/31/2

could not accept ssl connection tlsv1 alert unknown ca

We wanted to use pure ssl encryption without certificate validation. We created and configured self-signed certificates at the postgres server, turned "sslmode=on" and advised our clients to use "sslmode=prefer". This worked very well. However, one client also configured some client certificate

<    1   2