fast promotion and log_checkpoints

Started by Fujii Masaoover 12 years ago6 messages
#1Fujii Masao
masao.fujii@gmail.com

Hi,

In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log message
of this checkpoint looks odd as follows:

LOG: checkpoint starting:

I think something like the following is better.

LOG: checkpoint starting: end-of-recovery

In 9.2 or before, "end-of-recovery" part is logged. Even if we changed the
behavior of end-of-recovery checkpoint, I think that it's more intuitive to
label it as "end-of-recovery". Thought?

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Simon Riggs
simon@2ndQuadrant.com
In reply to: Fujii Masao (#1)
Re: fast promotion and log_checkpoints

On 1 May 2013 10:05, Fujii Masao <masao.fujii@gmail.com> wrote:

In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log message
of this checkpoint looks odd as follows:

LOG: checkpoint starting:

I think something like the following is better.

LOG: checkpoint starting: end-of-recovery

In 9.2 or before, "end-of-recovery" part is logged. Even if we changed the
behavior of end-of-recovery checkpoint, I think that it's more intuitive to
label it as "end-of-recovery". Thought?

The checkpoint isn't an "end-of-recovery" checkpoint, its just the
first checkpoint after the end of recovery. I don't think it should
say "end-of-recovery".

The problem is that we've now changed the code to trigger a checkpoint
in a place that wasn't part of the original design, so the checkpoint
called at that point isn't supplied with a reason and so has nothing
to print.

It would be possible to redesign this with a special new reason, or we
could just use "time" as the reason, or we could just leave it.

Do nothing is easy, though so are the others, so we can choose
anything we want. What do we want it to say?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Heikki Linnakangas
hlinnakangas@vmware.com
In reply to: Simon Riggs (#2)
Re: fast promotion and log_checkpoints

On 19.05.2013 17:22, Simon Riggs wrote:

On 1 May 2013 10:05, Fujii Masao<masao.fujii@gmail.com> wrote:

In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log message
of this checkpoint looks odd as follows:

LOG: checkpoint starting:

I think something like the following is better.

LOG: checkpoint starting: end-of-recovery

In 9.2 or before, "end-of-recovery" part is logged. Even if we changed the
behavior of end-of-recovery checkpoint, I think that it's more intuitive to
label it as "end-of-recovery". Thought?

The checkpoint isn't an "end-of-recovery" checkpoint, its just the
first checkpoint after the end of recovery. I don't think it should
say "end-of-recovery".

Agreed.

The problem is that we've now changed the code to trigger a checkpoint
in a place that wasn't part of the original design, so the checkpoint
called at that point isn't supplied with a reason and so has nothing
to print.

It would be possible to redesign this with a special new reason, or we
could just use "time" as the reason, or we could just leave it.

Do nothing is easy, though so are the others, so we can choose
anything we want. What do we want it to say?

I'm not sure. Perhaps we should print "(no flags)", so that it wouldn't
look like there's something missing in the log message.

- Heikk

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#4Simon Riggs
simon@2ndQuadrant.com
In reply to: Heikki Linnakangas (#3)
Re: fast promotion and log_checkpoints

On 20 May 2013 20:06, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:

It would be possible to redesign this with a special new reason, or we
could just use "time" as the reason, or we could just leave it.

Do nothing is easy, though so are the others, so we can choose
anything we want. What do we want it to say?

I'm not sure. Perhaps we should print "(no flags)", so that it wouldn't look
like there's something missing in the log message.

The reason text would still be absent, so it wouldn't really help the
user interpret the log message correctly.

I suggest we use RequestCheckpoint(CHECKPOINT_CAUSE_TIME) instead,
since it is literally time for a checkpoint.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#5Fujii Masao
masao.fujii@gmail.com
In reply to: Simon Riggs (#4)
Re: fast promotion and log_checkpoints

On Tue, May 21, 2013 at 4:44 AM, Simon Riggs <simon@2ndquadrant.com> wrote:

On 20 May 2013 20:06, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:

It would be possible to redesign this with a special new reason, or we
could just use "time" as the reason, or we could just leave it.

Do nothing is easy, though so are the others, so we can choose
anything we want. What do we want it to say?

I'm not sure. Perhaps we should print "(no flags)", so that it wouldn't look
like there's something missing in the log message.

The reason text would still be absent, so it wouldn't really help the
user interpret the log message correctly.

I suggest we use RequestCheckpoint(CHECKPOINT_CAUSE_TIME) instead,
since it is literally time for a checkpoint.

Or, what about using CHECKPOINT_FORCE and just printing "force"?
Currently that checkpoint always starts because of existence of the
end-of-recovery record, but I think we should ensure that the checkpoint
always starts by using that flag.

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Simon Riggs
simon@2ndQuadrant.com
In reply to: Fujii Masao (#5)
Re: fast promotion and log_checkpoints

On 21 May 2013 15:29, Fujii Masao <masao.fujii@gmail.com> wrote:

Or, what about using CHECKPOINT_FORCE and just printing "force"?
Currently that checkpoint always starts because of existence of the
end-of-recovery record, but I think we should ensure that the checkpoint
always starts by using that flag.

This would mean we can't use the secondary checkpoint record, but we
already gave that up so should be OK.

Three people, three suggestions; so I will agree to this suggestion so
we can get on with it.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers