9.2RC1 wraps this Thursday ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: 9.2RC1 wraps this Thursday ...
Date: 2012-08-21 14:47:41
Message-ID: 945.1345560461@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

... or at least, that's what the schedule says. I don't think we can
honestly produce a "release candidate" when there are still open issues
listed as blockers at
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items
We need to either get something done about those, conclude that they're
not blockers, or postpone RC1.

The items currently listed as blockers are:

* GiST indexes vs fuzzy comparisons used by geometric types
** Alexander proposed a patch that would support the current behavior, but should we change the behavior instead?

I put this in the blocker list because I was hoping to get some
conversation going about the whole issue of fuzzy comparisons in the
geometric stuff. However, the time for making any basic semantic
revisions in 9.2 is long past. We could perhaps look at applying
Alexander's more restricted patch, but maybe even that is too
destabilizing at this point. I'm inclined to move the whole thing onto
the "long term issues" list. Comments?

* Should we fix tuple limit handling, or redefine 9.x behavior as correct?
** The consensus seems to be to change the documentation to match the current behavior.

At this point this is just a pre-existing documentation bug. Somebody
ought to do something about it at some point, but it hardly seems like
a release blocker.

* keepalives

I don't know who put this item in, or what it refers to, since it has
no supporting link. Unless somebody steps forward with an explanation
of what the blocker issue is here, this entry is going to disappear.

* pg_ctl crashes on Win32 when neither PGDATA nor -D specified

I'm not sure that this qualifies as a release blocker either --- isn't
it a plain-vanilla pre-existing bug? And what does the proposed patch
have to do with the stated problem? (Even if you define the problem
as "make sure we're restricted" rather than the stated symptom, the
patch looks rather fragile and Rube Goldbergian ... isn't there a way
to actually test if we're in a restricted process?)

* Checkpointer process split broke fsync'ing
** bug is fixed, but now we had better recheck earlier performance claims

Is anyone actually going to do any performance testing on this?

* View options are problematic for pg_dump

I had hoped those who created this problem were going to fix it, but
given the lack of response I guess I'll have to.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit kapila 2012-08-21 14:57:25 Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Previous Message Robert Haas 2012-08-21 14:46:20 Re: [PATCH]Tablesample Submission