On 2020/01/31 23:47, Alvaro Herrera wrote:
On 2020-Jan-31, Fujii Masao wrote:
On 2020/01/31 22:40, Alvaro Herrera wrote:
On 2020-Jan-31, Fujii Masao wrote:
You're thinking to apply this change to the back branches? Sorry
if my understanding is not right. But I don't think that back-patch
i
On 2020-Jan-31, Fujii Masao wrote:
> On 2020/01/31 22:40, Alvaro Herrera wrote:
> > On 2020-Jan-31, Fujii Masao wrote:
> >
> > > You're thinking to apply this change to the back branches? Sorry
> > > if my understanding is not right. But I don't think that back-patch
> > > is ok because it changes
On 2020/01/31 22:40, Alvaro Herrera wrote:
On 2020-Jan-31, Fujii Masao wrote:
You're thinking to apply this change to the back branches? Sorry
if my understanding is not right. But I don't think that back-patch
is ok because it changes the documented existing behavior
of pg_last_xact_replay_
On 2020-Jan-31, Fujii Masao wrote:
> You're thinking to apply this change to the back branches? Sorry
> if my understanding is not right. But I don't think that back-patch
> is ok because it changes the documented existing behavior
> of pg_last_xact_replay_timestamp(). So it looks like the behavio
On 2020/01/31 5:45, Alvaro Herrera wrote:
On 2020-Jan-30, Kyotaro Horiguchi wrote:
Agreed about backbranches. I'd like to preserve the word "transaction"
as it is more familiar to users. How about something like the follows?
"transactions are completed up to log time %s"
That's a good poi
At Thu, 30 Jan 2020 17:45:36 -0300, Alvaro Herrera
wrote in
> On 2020-Jan-30, Kyotaro Horiguchi wrote:
>
> > Agreed about backbranches. I'd like to preserve the word "transaction"
> > as it is more familiar to users. How about something like the follows?
> >
> > "transactions are completed up
On 2020-Jan-30, Kyotaro Horiguchi wrote:
> Agreed about backbranches. I'd like to preserve the word "transaction"
> as it is more familiar to users. How about something like the follows?
>
> "transactions are completed up to log time %s"
That's a good point. I used the phrase "transaction activ
At Wed, 29 Jan 2020 19:11:31 -0300, Alvaro Herrera
wrote in
> On 2020-Jan-28, Kyotaro Horiguchi wrote:
>
> > The aim of the patch seem reasonable. XLOG_END_OF_RECOVERY and
> > XLOG_XACT_PREPARE also have a timestamp but it doesn't help much. (But
> > could be included for consistency.)
>
> Hmm
On 2020-Jan-28, Kyotaro Horiguchi wrote:
> The aim of the patch seem reasonable. XLOG_END_OF_RECOVERY and
> XLOG_XACT_PREPARE also have a timestamp but it doesn't help much. (But
> could be included for consistency.)
Hmm I think I should definitely include those.
> The timestamp of a checkpoint
On 2020-Jan-29, Kyotaro Horiguchi wrote:
> But as more significant issue, nowadays PostgreSQL doesn't run a
> checkpoint if it is really inactive (that is, if no "important" WAL
> records have issued.).
Yeah, I mentioned this in message
<20200127203419.GA15216@alvherre.pgsql>. The solution for m
At Tue, 28 Jan 2020 11:18:14 -0300, Alvaro Herrera
wrote in
> > xlog.c:7329: (similar code exists at line 9332)
> > >ereport(LOG,
> > > (errmsg("redo done at %X/%X",
> > > (uint32) (ReadRecPtr >> 32), (uint32)
> > > ReadRecPtr)));
> > >
At Tue, 28 Jan 2020 11:18:50 -0300, Alvaro Herrera
wrote in
> On 2020-Jan-27, Alvaro Herrera wrote:
>
> > Actually looking again, getRecordTimestamp is looking pretty strange.
> > It looks much more natural by using nested switch/case blocks, as with
> > this diff. I think the compiler does a
On 2020-Jan-27, Alvaro Herrera wrote:
> Actually looking again, getRecordTimestamp is looking pretty strange.
> It looks much more natural by using nested switch/case blocks, as with
> this diff. I think the compiler does a better job this way too.
I hadn't noticed I forgot to attach the diff he
On 2020-Jan-28, Kyotaro Horiguchi wrote:
> At Mon, 27 Jan 2020 18:06:27 -0300, Alvaro Herrera
> wrote in
> > Actually looking again, getRecordTimestamp is looking pretty strange.
> > It looks much more natural by using nested switch/case blocks, as with
> > this diff. I think the compiler does
Hello.
At Mon, 27 Jan 2020 18:06:27 -0300, Alvaro Herrera
wrote in
> Actually looking again, getRecordTimestamp is looking pretty strange.
> It looks much more natural by using nested switch/case blocks, as with
> this diff. I think the compiler does a better job this way too.
Agreed. Anyway
Actually looking again, getRecordTimestamp is looking pretty strange.
It looks much more natural by using nested switch/case blocks, as with
this diff. I think the compiler does a better job this way too.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 2020-Jan-10, Alvaro Herrera wrote:
> A customer of ours complained that if you have an inactive primary,
> monitoring the apply lag on a standby reports monotonically increasing
> lag. The reason for this is that the apply lag is only updated on
> COMMIT records, which of course don't occur in
17 matches
Mail list logo
