Re: Remaining beta blockers

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

In response to

Responses

Browse pgsql-hackers by date

  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