Re: Something for the TODO list: deprecating abstime and friends

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mark Dilger <hornschnorter(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Something for the TODO list: deprecating abstime and friends
Date: 2017-07-19 18:36:21
Message-ID: 8467.1500489381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alternatively, we could turn the origin point for abstime into
>> pg_control field, and regard changing it as a reason for a database
>> not being pg_upgrade'able unless it lacks any abstime columns.

> I would be OK with that, too, but is there any danger that we're going
> to grow pg_control to a size where reads and writes can no longer be
> assumed atomic, if we keep adding things?

Hm. Currently sizeof(struct ControlFileData) = 296, at least on my
machine. Letting it grow past 512 would be problematic. It's hard
to see getting to that any time soon, though; we don't add fields
there often.

Note that I'm not seriously pushing for this solution. I'm just trying
to make sure that we've considered all the reasonable options.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-07-19 18:53:42 Re: Pluggable storage
Previous Message Michael Paquier 2017-07-19 18:31:06 Re: Using non-sequential timelines in order to help with possible collisions