On Tue, Oct 03, 2023 at 06:31:27AM +0200, Laurenz Albe wrote:
> On Tue, 2023-10-03 at 12:33 +1100, rob stone wrote:
>> Would running CLUSTER on the table use the new parameters for the re-
>> write?
>
> No, as far as I know.
Note that under the hoods VACUUM FULL and CLUSTER use the same code
path
On Tue, 2023-10-03 at 12:33 +1100, rob stone wrote:
> Would running CLUSTER on the table use the new parameters for the re-
> write?
No, as far as I know.
You'd need something like
-- rewrite all tuples
UPDATE tab SET id = id;
-- get rid of the bloat
VACUUM (FULL) tab;
Yours,
Laurenz Al
Hello,
On Tue, 2023-10-03 at 08:57 +0900, Michael Paquier wrote:
> On Mon, Oct 02, 2023 at 04:42:15PM +0200, Dominique Devienne wrote:
> > According to the doc, the table is NOT changed.
> > In my case, I DO want to have the bytea column rewritten
> > according to the new STORAGE and/or COMPRESSIO
Hello,
As said above, I tested pgBackRest on my bigger DB and here are the results.
Server on which this is running has the following config:
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):36
On-line CPU(s) list: 0-
On Mon, Oct 02, 2023 at 04:42:15PM +0200, Dominique Devienne wrote:
> According to the doc, the table is NOT changed.
> In my case, I DO want to have the bytea column rewritten
> according to the new STORAGE and/or COMPRESSION.
> The doc doesn't mention how to achieve that.
Yes, the compression ty
On Monday, October 2, 2023, Matthias Apitz wrote:
>
> Hello,
>
> One of our clients running our LMS on top of PostgreSQL 13.1 created a
> ticket with these messages:
>
> 2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
> 2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 wa
Pgsql RA has rep_mode=sync parameter.
https://wiki.clusterlabs.org/wiki/PgSQL_Replicated_Cluster
2023年10月2日(月) 23:48 Sergey Cherukhin :
> Hello!
>
> I use Postgresql+Pacemaker+Corosync cluster with 2 Postgresql instances in
> synchronous replication mode. When one of the nodes is down, clients h
On Mon, 02 Oct 2023 13:07:19 -0400
Tom Lane wrote:
> "Karl O. Pinc" writes:
> > What I'm looking for is some general statements about
> > parallel safety for trigger functions. I don't know
> > enough about parallelism to even know if it applies
> > to data modification statements.
>
> It do
byme@byme.email schreef op ma 02-10-2023 om 16:19 [+]:
>
>
> Is there a possibility the pg_stat_statements will be improved with
> handling IN? This problem makes it so much less useful right now.
not sure what the question is,
but if you change pg_stat_statements with another view/table,
th
On Mon, 2023-10-02 at 13:27 +0200, Matthias Apitz wrote:
> One of our clients running our LMS on top of PostgreSQL 13.1 created a
> ticket with these messages:
>
> 2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
> 2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for
"Karl O. Pinc" writes:
> What I'm looking for is some general statements about
> parallel safety for trigger functions. I don't know
> enough about parallelism to even know if it applies
> to data modification statements.
It doesn't, which is why the docs are silent on the point.
Hi,
It's not entirely clear to me what the conditions
are for function parallel safety. While the documentation
seems pretty clear in most cases, there still some
verbiage that requires knowledge of internals
in order to be useful.
What I'm looking for is some general statements about
parallel s
Hello,
I would like to ask about a problem that is bothering me for a while now. We
have implemented monitoring of our queries using pg_stat_statements. The only
problem we have with it is that expressions with
IN ('first', 'second', 'third')
get translated into a query as
IN ($1, $2, $3)
and no
On 10/2/23 00:50, Giovanni Biscontini wrote:
Hi, Yes I know I've to use the "on error" property, but the cue is to
raise an error if query has a false result: for my knowledges the only
way to do it is to "create or replace" a PL/pgSQL procedure that than
uses a "RAISE ERROR" inside, but isn't
Tom Lane schreef op ma 02-10-2023 om 10:21 [-0400]:
> Wim Bertels writes:
> > * but if you put more than 1 option, then it doesn't?:
>
> > #psql
> > postgresql://myuser@myserver/mydb?connect_timeout=10&target_session
> > _attrs=any
>
> Maybe you forgot to quote that? Ampersand is a shell metach
On 10/2/23 03:54, Sergey Cherukhin wrote:
Hello!
I use Postgresql+Pacemaker+Corosync cluster with 2 Postgresql instances in
synchronous replication mode. When one of the nodes is down, clients hang
on INSERT operations because the primary server waits until standby
confirms that it got the da
Hi. If I do either or both of the changes below:
ddevienne=> alter table dd alter column val set compression lz4;
ALTER TABLE
ddevienne=> alter table dd alter column val set storage extended;
ALTER TABLE
According to the doc, the table is NOT changed.
In my case, I DO want to have the bytea colum
Hi guys
The servers are virtual running on Nutanix
We are running Pg version 12 (12.10)
On Linux km-data1.rs.fsbtech.com 5.4.191-1.el7.elrepo.x86_64 #1 SMP Tue Apr 26
12:14:16 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
48G/16 x CPU (Master and slave)
Timeline
System had a number of issues due t
Wim Bertels writes:
> * but if you put more than 1 option, then it doesn't?:
> #psql
> postgresql://myuser@myserver/mydb?connect_timeout=10&target_session_attrs=any
Maybe you forgot to quote that? Ampersand is a shell metacharacter.
(It does seem to work for me, as long as I put quotes around
Matthias Apitz writes:
> One of our clients running our LMS on top of PostgreSQL 13.1 created a
> ticket with these messages:
> 2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
> 2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for
> ShareLock on transaction 150396
On Mon, 2023-10-02 at 14:39 +0200, Colin 't Hart wrote:
> I have a customer approaching transaction wraparound, about 3million
> transaction IDs away at the moment.
> Postgres 9.5 (yes, I know...)
>
> Somewhat mislead by the message to vacuum the database in single user
> mode, they are now in sin
Hello,
can anyone confirm this?:
* connections with at most 1 option after the ?-mark sign work:
like
#psql postgresql://myuser@myserver/mydb?connect_timeout=10
or
#psql postgresql://myuser@myserver/mydb?target_session_attrs=any
* but if you put more than 1 option, then it doesn't?:
#psql
p
Hi,
I have a customer approaching transaction wraparound, about 3million
transaction IDs away at the moment.
Postgres 9.5 (yes, I know...)
Somewhat mislead by the message to vacuum the database in single user
mode, they are now in single user mode and are running "vacuum full"
on the "worst" data
Hello,
One of our clients running our LMS on top of PostgreSQL 13.1 created a
ticket with these messages:
2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected
2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for ShareLock
on transaction 150396154; blocked by process
Am 02.10.23 um 10:54 schrieb Sergey Cherukhin:
Hello!
I use Postgresql+Pacemaker+Corosync cluster with 2 Postgresql
instances in synchronous replication mode. When one of the nodes is
down, clients hang on INSERT operations because the primary server
waits until standby confirms that it go
Hello!
I use Postgresql+Pacemaker+Corosync cluster with 2 Postgresql instances in
synchronous replication mode. When one of the nodes is down, clients hang
on INSERT operations because the primary server waits until standby
confirms that it got the data, but the standby node is down.
I need clien
Hi, Yes I know I've to use the "on error" property, but the cue is to raise
an error if query has a false result: for my knowledges the only way to do
it is to "create or replace" a PL/pgSQL procedure that than uses a "RAISE
ERROR" inside, but isn't there a more "SQL only way to do it?
thanks in ad
27 matches
Mail list logo
