Re: replication primary writting infinite number of WAL files

On 11/24/23 14:01, Les wrote:
>
> A single sequence for all id columns across all tables?
>
> How is the sequence value landing in the id column?
>
> In most cases it is by using "nextval(seq_name)" in the SQL statement.
> But sometimes the sequence value is taken first, and then multiple
> inserts are sent with fixed increasing values. (Sometimes records
> reference each other, such records are inserted within a short
> transaction with deferred foreign key constraints.)

Leaving the reasoning behind this alone, the important part is that in
order for the id values to jump like they did there was intensive
processing of queries going on.

That would be one thing you should track down, what kicked that off and why?

> It is the main app that is using the database, using jdbc. Multiple
> instances were running when the sequence jumped.

Multiple instances of the app or something else?

What where the instances doing?

> When the dev db starts up (from the cloned data directory), it still has
> the old repmgr conf. That config is deleted, and repmgr is disabled
> right after the startup, but there is the possibility that the dev db
> has connected the primary when it was cloned (7 days ago), because at
> the beginning of startup, it is the exact clone of the standby from a
> previous point of time.

Hmm, that does not look good.

At this point I would create a new post/thread where you organize the
bits an pieces that you have posted over the course of this thread into
a something more coherent. In particular a time line of the whole
cloning/replication process.

>
>    Laszlo

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com