Removing log_cnt from pg_sequence_read_tuple()

Hi all,
(Nathan in CC regarding c8b06bb969bf)

While rebasing my patch set for sequence AMs, I've looked at what has
been done with c8b06bb969bf and pg_sequence_read_tuple() because I can
reuse it in the sequence AM patch to grab the last value of a sequence
and if it has been called (the patch set implemented the same thing,
with a different function name), and got surprised that the function
also returns log_cnt, which is for the in-core sequence metadata an
internal counter to decide when a sequence should be WAL-logged.

Why do we need this field at all in this function? pg_dump only cares
about the last value and is_called to be able to rebuilt its sequence
DDLs, and log_cnt is reset each time we restore or do a crash
recovery, bumping at the next sequence value based on an internal of
32.

I am also a bit dubious about the value it adds for debugging. The
thing is that depending on the way sequences are computed, we may not
care about WAL at all, and log_cnt is something related to the way
in-core sequences are computed and how its data is persistent. So
this makes the whole concept of sequence metadata a bit fuzzier
because we mix data necessary for the sequence command and more
things. There is no need for it in pg_dump or pg_upgrade, either.

last_value and is_called are different and required all the time,
of course, because these define how the sequence DDLs should be
created.

It seems to me that we'd live better without it, at least it matters
for the sequence AM patch, because some of its callbacks are also
shaped around the fact that WAL may not be required for sequence value
computations. Providing a function that should be rather generic does
not fit well in this context, still I agree that it comes down to how
the callbacks are defined, of course. My point is that the use of WAL
is something that should be optional, but log_cnt in this function
makes it a mandatory concept that all sequence AMs would need to deal
with.

Comments?
--
Michael