Hello,
I am in the process of migrating DB to Alma9 host. The databse
is rather large - few TBs.
I have run pg_basebackup on Alma9 host and established replication from
production to it. The idea is to quickly switch from master to this new host
during downtime.
Establishing replication we
hi
On 6/20/24 10:23, Dmitry O Litvintsev wrote:
Hello,
I am in the process of migrating DB to Alma9 host. The databse
is rather large - few TBs.
I have run pg_basebackup on Alma9 host and established replication from
production to it. The idea is to quickly switch from master to this new host
TLP:AMBER
Hello all,
I upgraded version of Postgres from 13.5 to newest 16.2. But Python was not
upgraded.
I create procedure pyver():
CREATE OR REPLACE FUNCTION pyver ()
RETURNS TEXT
AS $$
import sys
pyversion = sys.version
return pyversion
$$ LANGUAGE 'plpython3u';
On the Po
> I am in the process of migrating DB to Alma9 host. The databse
> is rather large - few TBs.
>
> I have run pg_basebackup on Alma9 host and established replication from
> production to it. The idea is to quickly switch from master to this new host
> during downtime.
>
> Establishing replication
Dmitry O Litvintsev wrote:
> WARNING: database "xxx" has a collation version mismatch
> DETAIL: The database was created using collation version 2.17, but the
> operating system provides version 2.34.
> HINT: Rebuild all objects in this database that use the default collation
> and run
On Thu, Jun 20, 2024 at 3:23 AM Dmitry O Litvintsev
wrote:
> Hello,
>
> I am in the process of migrating DB to Alma9 host. The databse
> is rather large - few TBs.
>
> I have run pg_basebackup on Alma9 host and established replication from
> production to it. The idea is to quickly switch from ma
Am Wed, Jun 19, 2024 at 02:32:07PM -0700 schrieb Rich Shepard:
> Yes, I see how this works if the transaction is committed. But before I
> commit the transaction I run a select statement to ensure the rows added are
> correct. Can I rollback a commited transaction? I've assumed not, so I won't
> c
On Thu, 20 Jun 2024, Karsten Hilbert wrote:
Shot in the dark: are you be any chance using tab-completion
when running the SELECT before the COMMIT ?
Karsten,
Nope. I prepare DDL, DML, and DQL scripts in emacs, then run them from the
psql prompt using \i .
Regards,
Rich
On Wed, 19 Jun 2024, Ron Johnson wrote:
In addition, manually run the "BEGIN;" before the "\i insert-blarge.sql"
command.
That way, insert-blarge.sql just inserts. My reasoning: since you control
the ROLLBACK, you should also control the BEGIN.
Ron,
Hadn't thought of doing that, but now will
> On Jun 20, 2024, at 7:05 AM, Rich Shepard wrote:
>
> On Thu, 20 Jun 2024, Karsten Hilbert wrote:
>
>> Shot in the dark: are you be any chance using tab-completion
>> when running the SELECT before the COMMIT ?
>
> Karsten,
>
> Nope. I prepare DDL, DML, and DQL scripts in emacs, then run
On Thu, 20 Jun 2024, Rob Sargent wrote:
Is psql running in emacs (which is my preferred sql shell. M-x sql-postgres)?
Rob,
Not when I'm entering new data or updating existing tables. Otherwise, yes.
Regards,
Rich
On 6/20/24 07:47, Rich Shepard wrote:
On Thu, 20 Jun 2024, Rob Sargent wrote:
Is psql running in emacs (which is my preferred sql shell. M-x
sql-postgres)?
Rob,
Not when I'm entering new data or updating existing tables. Otherwise, yes.
From one of my previous posts(modified):
At this poi
On 6/19/24 22:05, Šika Michal wrote:
TLP:AMBER
Hello all,
I upgraded version of Postgres from 13.5 to newest 16.2. But Python was
not upgraded.
I create procedure pyver():
CREATE OR REPLACE FUNCTION pyver ()
RETURNS TEXT
AS $$
import sys
pyversion = sys.version
return p
On Thu, 20 Jun 2024, Adrian Klaver wrote:
From one of my previous posts(modified):
At this point I think you need to create a simple test case where:
1) You have script with
BEGIN;
COMMIT; --optional
2) In psql do \i
3) Do what you did before to 'recover' from the error.
Shows us the conte
Hi everyone,
we can see in our database, that the DB is 200GB of size, with 99% bloat. After
vacuum full the DB decreases to 2GB.
DB total size: 200GB
DB bloat: 198 GB
DB non-bloat: 2GB
We further see, that during bulk updates (i.e. a long running transaction), the
DB is still growing, i.e. the
On 6/20/24 09:46, Shenavai, Manuel wrote:
Hi everyone,
we can see in our database, that the DB is 200GB of size, with 99%
bloat. After vacuum full the DB decreases to 2GB.
DB total size: 200GB
DB bloat: 198 GB >
DB non-bloat: 2GB
We further see, that during bulk updates (i.e. a long running
On Thu, Jun 20, 2024 at 12:47 PM Shenavai, Manuel
wrote:
> Hi everyone,
>
>
>
> we can see in our database, that the DB is 200GB of size, with 99% bloat.
> After vacuum full the DB decreases to 2GB.
>
> DB total size: 200GB
>
> DB bloat: 198 GB
>
> DB non-bloat: 2GB
>
>
>
> We further see, that d
Στις 20/6/24 19:46, ο/η Shenavai, Manuel έγραψε:
Hi everyone,
we can see in our database, that the DB is 200GB of size, with 99%
bloat. After vacuum full the DB decreases to 2GB.
DB total size: 200GB
DB bloat: 198 GB
DB non-bloat: 2GB
We further see, that during bulk updates (i.e. a long
18 matches
Mail list logo
