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
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 inactive servers.
But CHECKPOINT records do oc
18 matches
Mail list logo
