Re: tracking commit timestamps

On 11/05/2014 05:43 PM, Andres Freund wrote:
> On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
> Imo that's essentially a different feature. What you essentially would
> need here is a 'commit sequence number' - but no timestamps. And
> probably to be useful that number has to be 8 bytes in itself.

I think this gets to the heart of some of the differing views people
have expressed on this patch

Is this patch supposed to:

A) Add commit timestamp tracking but nothing more

B) Add infrastructure to store commit timestamps and provide a facility
for storing additional bits of data extensions might want to be
associated with the commit

C). Add commit timestamps and node identifiers to commits

If the answer is (A) then I can see why some people are objecting to
adding extradata. If the answer is (B) then it's fair to ask how well
does this patch handle various types of things people might want to
attach to the commit record (such as the LSN). I think the problem is
that once you start providing a facility extensions can use to store
data along with the commit record then being restricted to 4 or 8 bytes
is very limiting. It also doesn't allow you to load two extensions at
once on a system. You wouldn't be able to have both the
'steve_commit_order' extension and BDR installed at the same time. I
don't think this patch does a very good job at (B) but It wasn't
intended to.

If what we are really doing is C, and just calling the space 'extradata'
until we get the logical identifier stuff in and then we are going to
rename extradata to nodeid then we should say so. If we are really
concerned about the pg_upgrade impact of expanding the record later then
maybe we should add 4 bytes of padding to the CommitTimeStampEntry now
and but leave the manipulating the node id until later.

Steve

> Greetings,
>
> Andres Freund
>