From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Remaining beta blockers |
Date: | 2013-04-27 18:06:02 |
Message-ID: | 29994.1367085962@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Sat, Apr 27, 2013 at 10:59:32AM -0400, Tom Lane wrote:
>> As far as #1 goes, I think we have little choice at this point but to
>> remove the unlogged-matviews feature for 9.3.
> This perspective is all wrong. I hate to be blunt, but that thread ended with
> your technical objections to the committed implementation breaking apart and
> sinking. There was no consensus to change it on policy/UI grounds, either.
[ shrug... ] You and Kevin essentially repeated your claims that the
current implementation is OK; nobody else weighed in. I see absolutely
no reason to change my opinion on this. Keeping relisscannable state in
the form of is-the-file-of-nonzero-size is something we WILL regret, and
Pollyanna-ish refusal to believe that is not an adequate reason for
painting ourselves into a corner, especially not for a second-order
feature like unlogged matviews.
The way forward to unlogged matviews that behave the way Kevin wants
is to improve crash recovery so that we can update catalog state after
completing recovery, which is something there are other reasons to want
anyway. But it's far too late to do that in this cycle. In the
meantime I remain convinced that we're better off dropping the feature
until we have an implementation that's not going to bite us in the rear
in the future.
I also note that there are acknowledged-even-by-you bugs in the current
implementation, which no patch has emerged for, so *something's* got to
be done. I'm done waiting for something to happen, and am going to go
fix it in the way I think best.
>> 2. The checksum algorithm business. Again, we don't get to tinker with
>> that anymore once we're in beta.
> Since pg_upgrade isn't in a position to migrate beta clusters to a new
> checksum algorithm, I share the desire to settle this sooner rather than
> later. However, if finalizing it before beta singularly entails slipping beta
> by more than a week or two, I think we should cut the beta without doing so.
> Then mention in its release notes that "initdb --data-checksums" beta clusters
> may require dump/reload to upgrade to a release or later beta.
Meh. If we want to reserve the right to do that, we'd better do
something about putting a checksum algorithm ID in pg_control after all.
Otherwise we'll be faced with not detecting the algorithm change, or
else changing pg_control format post-beta1, which would break beta
clusters for everybody not just those who'd experimented with checksums.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-04-27 18:24:17 | Re: pg_ctl non-idempotent behavior change |
Previous Message | Noah Misch | 2013-04-27 17:23:47 | Re: Remaining beta blockers |