On Mon, Nov 14, 2022 at 2:55 AM Adrian Klaver
wrote:
> On 11/13/22 13:07, Tom Lane wrote:
> > Adrian Klaver writes:
> >> INSERT INTO books VALUES (12, 0, CURRENT_TIMESTAMP)
> >> ON CONFLICT (id)
> >> WHERE updated IS NULL OR updated + INTERVAL '2min' < CURRENT_TIMESTAMP
> >> DO UPDATE
> >> SET
Le lun. 14 nov. 2022 à 13:10, Julien Rouhaud a écrit :
> yes exactly. but it's likely that people will have some form of automation
>> to run the reindex if there's any discrepancy between the recorded
>> collation version and recorded version,
>
>
sorry I meant "and the current version"
>
Le lun. 14 nov. 2022 à 05:58, Karsten Hilbert a
écrit :
> Am Sun, Nov 13, 2022 at 12:46:53PM -0800 schrieb Christophe Pettus:
>
> > > On Nov 13, 2022, at 12:45, Karsten Hilbert
> wrote:
> > > REINDEX DATABASE db_in_question;
> > > ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
Am Sun, Nov 13, 2022 at 12:46:53PM -0800 schrieb Christophe Pettus:
> > On Nov 13, 2022, at 12:45, Karsten Hilbert wrote:
> > REINDEX DATABASE db_in_question;
> > ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
> > ALTER COLLATION every_collation_from_pg_collation REFRESH
On Sun, Nov 13, 2022 at 1:07 PM Tom Lane wrote:
> A WHERE placed there is an index_predicate attachment to the ON CONFLICT
> clause. It doesn't have any run-time effect other than to allow partial
> indexes to be chosen as arbiter indexes. TFM explains
>
> index_predicate
>
> Used
On 11/13/22 13:07, Tom Lane wrote:
Adrian Klaver writes:
INSERT INTO books VALUES (12, 0, CURRENT_TIMESTAMP)
ON CONFLICT (id)
WHERE updated IS NULL OR updated + INTERVAL '2min' < CURRENT_TIMESTAMP
DO UPDATE
SET version = books.version + 1, updated = CURRENT_TIMESTAMP;
I have not used WHERE
Adrian Klaver writes:
> INSERT INTO books VALUES (12, 0, CURRENT_TIMESTAMP)
> ON CONFLICT (id)
> WHERE updated IS NULL OR updated + INTERVAL '2min' < CURRENT_TIMESTAMP
> DO UPDATE
> SET version = books.version + 1, updated = CURRENT_TIMESTAMP;
> I have not used WHERE with ON CONFLICT myself so
Note that WAL replication replicates *the whole instance* not just specific
databases. You need logical replication for that.
Also, I just learned that 9.4 *does* have WAL replication slots (which makes
replication *much* easier). v9.6 is where replication is "like rolling off
a log"
> On Nov 13, 2022, at 12:45, Karsten Hilbert wrote:
> REINDEX DATABASE db_in_question;
> ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
> ALTER COLLATION every_collation_from_pg_collation REFRESH VERSION;
I may be totally off-base here, but shouldn't the REINDEX be
Dear all,
just to confirm my understanding:
Is it correct to say that the following sequence will "fix"
all current collation version issues in a given database ?
REINDEX DATABASE db_in_question;
ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
ALTER COLLATION
In process of answering an SO question I ran across the below.
The original question example:
CREATE TABLE books (
id int4 NOT NULL,
version int8 NOT NULL,
updated timestamp NULL,
CONSTRAINT books_pkey PRIMARY KEY (id)
);
INSERT INTO books VALUES (12, 0,
On Sun, 2022-11-13 at 14:50 +, Alexis Zapata wrote:
> I found that xmin does not change when running the vacuum.
Which xmin?
Yours,
Laurenz Albe
On 11/12/22 22:07, Tom Lane wrote:
Ron writes:
On 11/11/22 23:09, Adrian Klaver wrote:
2) For your explanation above, pg_dump from 9.4(5432) to pg_restore
12(5433) the issue would be ...\9.4\bin\pg_dump.exe of 9.4 and pg_restore
of said dump file to version 12. When moving up in version you
On 11/12/22 18:18, Brad White wrote:
> How where the restored copies made on the original cluster?
I guess I'm not understanding the confusion here. They were restored
with the same script but to a different DB name and with the 9.4
executables.
In fact, that was why the
Hi All
I set up Postgres 11 stream replication env.Use keepalived to control
VIP and a script to check Postgres status.
Usually. I could check the stream replication status by this view
"pg_stat_replcation" on primary server.
Check this view "pg_stat_wal_receiver" on standby
Hi Laurenz ,
I found that xmin does not change when running the vacuum.
De: Laurenz Albe
Enviado: sábado, 12 de noviembre de 2022 9:05 a. m.
Para: Alexis Zapata ; pgsql-general@lists.postgresql.org
Asunto: Re: Table : Bloat grow high
On Fri, 2022-11-11 at
16 matches
Mail list logo
