From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Full support for index LP_DEAD hint bits on standby |
Date: | 2021-05-10 13:05:09 |
Message-ID: | CANtu0ohZMHaWJ3NFcggAcCw8EOiwWu_4EYpm7Sc9usGxyPyyVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Antonin.
> Sorry, I missed the fact that your example can be executed inside BEGIN - END
> block, in which case minRecoveryPoint won't advance after each command.
No, the block is not executed as a single transaction, all commands
are separated transactions (see below)
> Actually I think that a commit record should be replayed
> more often than XLOG_RUNNING_XACTS, shouldn't it?
Yes, but replaying commit records DOES NOT affect minRecoveryPoint in
almost all cases.
UpdateMinRecoveryPoint is called by XLogFlush, but xact_redo_commit
calls XLogFlush only in two cases:
* DropRelationFiles is called (some relation are dropped)
* If ForceSyncCommit was used on primary - few “heavy” commands, like
DropTableSpace, CreateTableSpace, movedb, etc.
But “regular” commit record is replayed without XLogFlush and, as
result, without UpdateMinRecoveryPoint.
So, in practice, UpdateMinRecoveryPoint is updated in an “async” way
by checkpoint job. This is why there is a sense to call it on
XLOG_RUNNING_XACTS.
Thanks,
Michail.
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-05-10 13:27:47 | Re: Enhanced error message to include hint messages for redundant options error |
Previous Message | Alexander Korotkov | 2021-05-10 13:02:27 | Re: PG 14 release notes, first draft |