Re: setLastTid() and currtid()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "Inoue, Hiroshi" <h-inoue(at)dream(dot)email(dot)ne(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, pgsql-odbc(at)postgresql(dot)org
Subject: Re: setLastTid() and currtid()
Date: 2019-04-11 18:06:13
Message-ID: 23188.1555005973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-odbc

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-11 13:27:03 -0400, Tom Lane wrote:
>> I think removing it after feature freeze is not something to do,
>> but +1 for nuking it as soon as the v13 branch opens. Unless
>> there's some important reason we need it to be gone in v12?

> No, I don't think there really is. They're bogus and possibly a bit
> dangerous, but that's not really new.

> I was mostly just reminded of this when Heikki asked me to improve the
> documentation for heap_get_latest_tid/table_get_latest_tid() - and I was
> briefly wondering whether we could just nuke the whole functionality.
> But it's still used in nodeTidscan.c:

Yeah, if we could simplify the tableam API, that would be sufficient
reason to remove the stuff in v12, IMO. But if it is outside of that
API, I'd counsel waiting till v13.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2019-04-11 18:15:41 Re: Enable data checksums by default
Previous Message Bruce Momjian 2019-04-11 18:05:41 Re: Retronym: s/magnetic disk/main data/

Browse pgsql-odbc by date

  From Date Subject
Next Message Cevin A Moses 2019-04-11 21:27:02 64 Bit versus 32 Bit
Previous Message Andres Freund 2019-04-11 18:05:25 Re: setLastTid() and currtid()