Ron Johnson writes:
> If there's an encoding mismatch between the server and client, does
> "something" (like a PQ driver) convert text in the data stream from the
> source encoding to the target encoding?
The server does that itself.
regards, tom lane
On Fri, Dec 19, 2025 at 1:52 PM Tom Lane wrote:
> Igor Korot writes:
> > But what is the purpose of setting client encoding on the server? It is
> for
> > the client
>
> No, it's to tell the server what encoding to transmit to the client
> (as well as what encoding strings coming from the client
Igor Korot writes:
> But what is the purpose of setting client encoding on the server? It is for
> the client
No, it's to tell the server what encoding to transmit to the client
(as well as what encoding strings coming from the client are in).
regards, tom lane
-- Forwarded message -
From: Igor Korot
Date: Fri, Dec 19, 2025 at 9:17 AM
Subject: Re: PQexecPrepared() question
To: Laurenz Albe
Hi, Lauren’s,
On Thu, Dec 18, 2025 at 11:43 PM Laurenz Albe
wrote:
> On Thu, 2025-12-18 at 07:20 -0800, Igor Korot wrote:
> > Imagine following s
On Fri, 2025-12-19 at 09:49 -0500, Greg Sabino Mullane wrote:
> If this is still an issue after you check David's theory about premature
> analyzing,
> another approach is to pre-populate and pre-analyze future tables. Something
> like this:
>
> * disable autovac on the future table
> * detach t
## Andrus ([email protected]):
> This fails since tabletorecover contains lot foreign key references.
Check pg_restore options "--section=pre-data" and "--section=data" -
pre-data is the schema without indexes, contraints, etc. (those
would be in section post-data).
Regards,
Christoph
--
Spare
On 12/19/25 08:12, Adrian Klaver wrote:
On 12/19/25 04:41, Andrus wrote:
Hi!
Large database backup is created using
pg_dump -b -f backup.backup -F c
How to restore single table in schema firma2 from it in Windows?
Created database recovery and tried
pg_restore --schema-only --n firma2 -d re
On 19/12/2025 12:41, Andrus wrote:
Hi!
Large database backup is created using
pg_dump -b -f backup.backup -F c
How to restore single table in schema firma2 from it in Windows?
Created database recovery and tried
pg_restore --schema-only --n firma2 -d recovery backup.backup
pg_restore -n fir
On 12/19/25 04:41, Andrus wrote:
Hi!
Large database backup is created using
pg_dump -b -f backup.backup -F c
How to restore single table in schema firma2 from it in Windows?
Created database recovery and tried
pg_restore --schema-only --n firma2 -d recovery backup.backup
pg_restore -n firma2
Hi!
Large database backup is created using
pg_dump -b -f backup.backup -F c
How to restore single table in schema firma2 from it in Windows?
Created database recovery and tried
pg_restore --schema-only --n firma2 -d recovery backup.backup
pg_restore -n firma2 -t tabletorecover -d recovery bac
If this is still an issue after you check David's theory about premature
analyzing, another approach is to pre-populate and pre-analyze future
tables. Something like this:
* disable autovac on the future table
* detach the table from the main partition
* insert a few hundred thousand rows into it,
On Fri, 2025-12-19 at 14:25 +0100, Colin 't Hart wrote:
> What's the behaviour when pg_resetwal is used to change the WAL segment size?
>
> This note is worrying to me:
> --
> While pg_resetwal will set the WAL starting address beyond the latest
> existing WAL segment file, some segment size chan
What's the behaviour when pg_resetwal is used to change the WAL segment
size?
This note is worrying to me:
--
While pg_resetwal will set the WAL starting address beyond the latest
existing WAL segment file, some segment size changes can cause previous WAL
file names to be reused. It is recommended
On Fri, 2025-12-19 at 09:26 +0100, Andrew wrote:
> As an oracle dba new to Postgres, I’m used to the concept of context switches
> and latch issues
> with regards to transaction log switches. Does Postgres have a similar
> mechanism with latching
> etc when it switches to a new wal segment that i
As an oracle dba new to Postgres, I’m used to the concept of context switches
and latch issues with regards to transaction log switches. Does Postgres have a
similar mechanism with latching etc when it switches to a new wal segment that
is alleviated when increasing the size of the wal segments?
15 matches
Mail list logo
