Обсуждение: release slippage
On Thu, Jun 9, 2011 at 10:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> It's awfully late in the release cycle, but how about we add another >> digit to the filenames used by SLRU, to up the limit? > > It's way too late for that kind of thing, unless you are saying that SSI > in and of itself is going to cause a release slip. (Which I'm getting > the uncomfortable feeling may be true anyway.) So, speaking of that, aren't we supposed to wrap beta2 any minute now? There are two open items listed on the open items page as blockers for beta2: - error in information_schema.element_types view definition (bug 5926) - more SSI loose ends We really ought to fix #1, because we've already bumped catversion since beta1 (several times, actually) and we'd probably like very much not to do it again before final. With respect to #2, it would be nice to fix that, but I'm disinclined to hold up beta2 for it. Kevin and Dan don't seem to have reached agreement on all the details of the patch, and even if they had, it's far from obvious that this will be the last SSI related change we'll need to make. I'd vote for pushing out beta2 even if we can't get that one in. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> So, speaking of that, aren't we supposed to wrap beta2 any minute now?
Yes. I'm expecting to do it this evening.
> There are two open items listed on the open items page as blockers for beta2:
> - error in information_schema.element_types view definition (bug 5926)
> - more SSI loose ends
Peter concluded that #1 was really only a documentation problem, and
fixed it in his latest commit. I'm not entirely convinced that he's
reading the spec correctly, but will defer to his judgment.
> With respect to #2, it would be nice to fix that, but I'm disinclined
> to hold up beta2 for it.
I agree. From what I can see, SSI is nowhere near RC-ready. We may as
well push out beta2 to get the fixes accumulated so far into the hands
of testers. (In particular, judging by the reports that have been
coming in, we really need to push the timezone-abbreviations Windows
crash fix...)
regards, tom lane
On Thu, Jun 9, 2011 at 16:27, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> So, speaking of that, aren't we supposed to wrap beta2 any minute now? > > Yes. I'm expecting to do it this evening. > >> There are two open items listed on the open items page as blockers for beta2: > >> - error in information_schema.element_types view definition (bug 5926) >> - more SSI loose ends > > Peter concluded that #1 was really only a documentation problem, and > fixed it in his latest commit. I'm not entirely convinced that he's > reading the spec correctly, but will defer to his judgment. > >> With respect to #2, it would be nice to fix that, but I'm disinclined >> to hold up beta2 for it. > > I agree. From what I can see, SSI is nowhere near RC-ready. We may as > well push out beta2 to get the fixes accumulated so far into the hands > of testers. (In particular, judging by the reports that have been > coming in, we really need to push the timezone-abbreviations Windows > crash fix...) Yeah, we definitely need that one out. I say let's get beta2 out, and then plan to have a beta3 as well before rc. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Robert Haas <robertmhaas@gmail.com> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > aren't we supposed to wrap beta2 any minute now? > > There are two open items listed on the open items page as blockers > for beta2: > > - error in information_schema.element_types view definition (bug > 5926) > - more SSI loose ends > > We really ought to fix #1, because we've already bumped catversion > since beta1 (several times, actually) and we'd probably like very > much not to do it again before final. > > With respect to #2, it would be nice to fix that, but I'm > disinclined to hold up beta2 for it. Kevin and Dan don't seem to > have reached agreement on all the details of the patch, and even > if they had, it's far from obvious that this will be the last SSI > related change we'll need to make. I'd vote for pushing out beta2 > even if we can't get that one in. There is this pending patch, without which there are infrequent conditions under which the users could get a LOG level message and accumulate files in pg_serial: http://archives.postgresql.org/message-id/4DEE7BE4020000250003E2BD@gw.wicourts.gov The other pending patch relates to the false positives serialization failures and funny-looking pg_lock entries from not ignoring non-MVCC snapshots in SSI. I don't think Dan had any problem with the patch I offered, but I wasn't sure what to do about two functions. He researched that and proposed a way to handle those. That looked good to me on a first pass except that there was one line he left at NULL instead of plugging in the snapshot. That looks like an easily-fixed oversight. It will take me about an hour to review his changes in detail and re-test everything, although I don't expect any other issues. It seems odd not to include a change that was requested by Tom, Robert, and Heikki (and which Dan and I both put in the hours to have a patch before beta2) in beta2. It does fix the issue which people were concerned about (the predicate locks acquired on the table heap by the transaction when doing a REINDEX within a serializable transaction is no longer occuring.) The only other pending SSI issues I know of are minor documentation tweaks. -Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> The other pending patch relates to the false positives serialization
> failures and funny-looking pg_lock entries from not ignoring
> non-MVCC snapshots in SSI. I don't think Dan had any problem with
> the patch I offered, but I wasn't sure what to do about two
> functions. He researched that and proposed a way to handle those.
> That looked good to me on a first pass except that there was one
> line he left at NULL instead of plugging in the snapshot. That looks
> like an easily-fixed oversight. It will take me about an hour to
> review his changes in detail and re-test everything, although I
> don't expect any other issues. It seems odd not to include a change
> that was requested by Tom, Robert, and Heikki (and which Dan and I
> both put in the hours to have a patch before beta2) in beta2.
Well, Heikki is lead committer for SSI; anything he's comfortable
with pushing in today, he should push. Just keep in mind that it
is too late to get a full buildfarm cycle in before beta2 wraps...
so anything that goes in today had better be low-risk.
regards, tom lane
On Thu, Jun 9, 2011 at 10:37 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > There is this pending patch, without which there are infrequent > conditions under which the users could get a LOG level message and > accumulate files in pg_serial: > > http://archives.postgresql.org/message-id/4DEE7BE4020000250003E2BD@gw.wicourts.gov That seems important to fix. > The other pending patch relates to the false positives serialization > failures and funny-looking pg_lock entries from not ignoring > non-MVCC snapshots in SSI. I don't think Dan had any problem with > the patch I offered, but I wasn't sure what to do about two > functions. He researched that and proposed a way to handle those. > That looked good to me on a first pass except that there was one > line he left at NULL instead of plugging in the snapshot. That looks > like an easily-fixed oversight. It will take me about an hour to > review his changes in detail and re-test everything, although I > don't expect any other issues. It seems odd not to include a change > that was requested by Tom, Robert, and Heikki (and which Dan and I > both put in the hours to have a patch before beta2) in beta2. It > does fix the issue which people were concerned about (the predicate > locks acquired on the table heap by the transaction when doing a > REINDEX within a serializable transaction is no longer occuring.) I didn't realize I had requested to include this, but I've concluded after looking over it that I'm not qualified to commit it. Based on a quick IM session with Heikki I am doubtful he'll be able to get to it before the wrap, but we'll see, I guess. In any case, if this misses beta2, I'm not feeling like we'd need to push beta3 just for that reason. I'm not even 100% convinced that it needs to be in 9.1. We're talking about fixing a relatively rare false positive from a system which by its design necessitates that users be prepared for the possibility of false positives. If getting this fix in is going to mean that we have to wait another month and push another beta when that otherwise wouldn't be necessary, I'd vote to ship what we have. But I doubt that's really the decision we have to make anyway. One other problem I'm realizing: didn't Peter ask Bruce to revert the change to make pg_upgrade ignore case differences in locale names, on the grounds that it was not safe? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 09.06.2011 17:46, Tom Lane wrote: > "Kevin Grittner"<Kevin.Grittner@wicourts.gov> writes: >> The other pending patch relates to the false positives serialization >> failures and funny-looking pg_lock entries from not ignoring >> non-MVCC snapshots in SSI. I don't think Dan had any problem with >> the patch I offered, but I wasn't sure what to do about two >> functions. He researched that and proposed a way to handle those. >> That looked good to me on a first pass except that there was one >> line he left at NULL instead of plugging in the snapshot. That looks >> like an easily-fixed oversight. It will take me about an hour to >> review his changes in detail and re-test everything, although I >> don't expect any other issues. It seems odd not to include a change >> that was requested by Tom, Robert, and Heikki (and which Dan and I >> both put in the hours to have a patch before beta2) in beta2. > > Well, Heikki is lead committer for SSI; anything he's comfortable > with pushing in today, he should push. Just keep in mind that it > is too late to get a full buildfarm cycle in before beta2 wraps... > so anything that goes in today had better be low-risk. I'm not planning to push anything before beta2 anymore. There is a bunch of SSI related issues pending now, some of which have patches floating around but I haven't had enough time to review them in depth. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
> One other problem I'm realizing: didn't Peter ask Bruce to revert the
> change to make pg_upgrade ignore case differences in locale names, on
> the grounds that it was not safe?
There was a hypothesis that it wasn't safe, but no very clear evidence
either way. And we did have the field report of a platform where it'd
be useful to allow a case discrepancy. I'm not uncomfortable with
leaving that as-is pending further evidence.
regards, tom lane
Robert Haas <robertmhaas@gmail.com> wrote: > Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> There is this pending patch, without which there are infrequent >> conditions under which the users could get a LOG level message >> and accumulate files in pg_serial: >> http://archives.postgresql.org/message-id/4DEE7BE4020000250003E2BD@gw.wicourts.gov > > That seems important to fix. It seems a lot more important to me than the other SSI issues. > In any case, if this misses beta2, I'm not feeling like we'd need > to push beta3 just for that reason. I'm not even 100% convinced > that it needs to be in 9.1. We're talking about fixing a > relatively rare false positive from a system which by its design > necessitates that users be prepared for the possibility of false > positives. Yeah, I was actually surprised that people felt it needed to go into 9.1, rather than being on a list of 9.2 follow-up improvements. Of course, now that it's done, I'd like to see it get into the release; but not at the cost of slipping the date.. -Kevin
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > One other problem I'm realizing: didn't Peter ask Bruce to revert the > > change to make pg_upgrade ignore case differences in locale names, on > > the grounds that it was not safe? > > There was a hypothesis that it wasn't safe, but no very clear evidence > either way. And we did have the field report of a platform where it'd > be useful to allow a case discrepancy. I'm not uncomfortable with > leaving that as-is pending further evidence. I am going to return to this issue. I thought the cause was that we allow invalid locale names in initdb, and the user actually was getting a C locale when in fact he had is locale with the wrong case. I am going to do more research on this, but obviously after beta2. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +