From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Remaining beta blockers |
Date: | 2013-04-30 01:44:11 |
Message-ID: | 20130430014411.GF4361@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Kevin Grittner (kgrittn(at)ymail(dot)com) wrote:
> If they modified the heap files that way while the server was
> running, the results would be somewhat unpredictable. If they did
> it while the server was stopped, starting the server and attempting
> to access the matview would generate:
Right, the point being that they could (ab)use it as a flag to trigger
something to happen. I'd also be worried about failure cases where
files appear to be zero-length.
> > Or we end up wanting to have that file be non-zero and considered
> > 'empty' later, but we don't want pg_upgrade running around
> > touching all of the existing files out there?
>
> I didn't follow this one; could you restate it, please?
Down the road we decide that we shouldn't have any zero-length files
(perhaps due to checksums..?), yet we have to special case around these
mat views and figure out a way to deal with them during pg_upgrade.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-04-30 02:01:30 | Re: pg_ctl non-idempotent behavior change |
Previous Message | Robert Haas | 2013-04-30 01:38:29 | Re: The missing pg_get_*def functions |