On 14/02/2022 11:36, Heikki Linnakangas wrote:
On 27/01/2022 08:34, Michael Paquier wrote:
On Tue, Jan 25, 2022 at 12:12:40PM +0200, Heikki Linnakangas wrote:
In last round of review, I spotted one bug: I had mixed up the meaning of
EndOfLogTLI. It is the TLI in the *filename* of the WAL segmen
On 27/01/2022 08:34, Michael Paquier wrote:
On Tue, Jan 25, 2022 at 12:12:40PM +0200, Heikki Linnakangas wrote:
In last round of review, I spotted one bug: I had mixed up the meaning of
EndOfLogTLI. It is the TLI in the *filename* of the WAL segment that we read
the last record from, which can b
On Tue, Jan 25, 2022 at 12:12:40PM +0200, Heikki Linnakangas wrote:
> In last round of review, I spotted one bug: I had mixed up the meaning of
> EndOfLogTLI. It is the TLI in the *filename* of the WAL segment that we read
> the last record from, which can be different from the TLI that the last
>
On Wed, Nov 24, 2021 at 12:16 PM Heikki Linnakangas wrote:
> And here's another rebase, now that Robert got rid of ReadRecPtr and
> EndRecPtr.
In general, I think 0001 is a good idea, but the comment that says
"Set the XLP_FIRST_IS_OVERWRITE_CONTRECORD flag on the page header"
seems to me to be t
On 17/09/2021 06:10, Kyotaro Horiguchi wrote:
recoveryStopReason is always acquired but it is used only after
archive recovery. I'm not sure about reason for the variable to
live in that wide context. Couldn't we remove the variable then
call getRecoveryStopReason() directly at the
> On 5 Oct 2021, at 03:09, Jaime Casanova wrote:
> Are we waiting a rebased version? Currently this does not apply to head.
> I'll mark this as WoA and move it to necxt CF.
This patch still doesn't apply, exacerbated by the recent ThisTimelineID
changes in xlog.c. I'm marking this Returned with
On Thu, Sep 16, 2021 at 4:24 AM Heikki Linnakangas wrote:
> Here is another rebase.
Like probably everyone else who has an opinion on the topic, I like
the idea of splitting xlog.c. I don't have a fully formed opinion on
the changes yet, but it seems to be a surprisingly equal split, which
seems
On Fri, Sep 17, 2021 at 12:10:17PM +0900, Kyotaro Horiguchi wrote:
> Hello.
>
> At Thu, 16 Sep 2021 11:23:46 +0300, Heikki Linnakangas
> wrote in
> > Here is another rebase.
>
> I have several comments on this.
>
Hi Heikki,
Are we waiting a rebased version? Currently this does not apply to
Hello.
At Thu, 16 Sep 2021 11:23:46 +0300, Heikki Linnakangas wrote
in
> Here is another rebase.
I have several comments on this.
0001:
I understand this is almost simple relocation of code fragments. But
it seems introducing some behavioral changes.
PublishStartProcessInformation() w
After applying 0001 and 0002 I got a bunch of compile problems:
In file included from /pgsql/source/master/src/include/postgres.h:46,
from /pgsql/source/master/src/backend/access/transam/xlog.c:39:
/pgsql/source/master/src/backend/access/transam/xlog.c: In function
'StartupXLOG':
Hi,
I think it'd make sense to apply the first few patches now, they seem
uncontroversial and simple enough.
On 2021-07-31 00:33:34 +0300, Heikki Linnakangas wrote:
> From 0cfb852e320bd8fe83c588d25306d5b4c57b9da6 Mon Sep 17 00:00:00 2001
> From: Heikki Linnakangas
> Date: Mon, 21 Jun 2021 22:14
On Tue, Jun 22, 2021 at 2:37 AM Heikki Linnakangas wrote:
>
> On 17/06/2021 02:00, Andres Freund wrote:
> > On 2021-06-16 16:30:45 +0300, Heikki Linnakangas wrote:
> >> That's a fairly clean split. StartupXLOG() stays in xlog.c, but much of
> >> the
> >> code from it has been moved to new functi
Hi,
On 2021-06-16 16:30:45 +0300, Heikki Linnakangas wrote:
> xlog.c is very large. We've split off some functions from it over the years,
> but it's still large and it keeps growing.
>
> Attached is a proposal to split functions related to WAL replay, standby
> mode, fetching files from archive,
13 matches
Mail list logo
