| 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: | Whole Thread | Raw Message | 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
| 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 |