CommitFest wrap-up

On 12/13/2010 12:37 PM, Robert Haas wrote:

- SQL/MED - core functionality - Seems clear to move this to the next
CF and keep working on it.

[...]

- SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in
marking this Returned with Feedback for now in anticipation of a new
version before CF 2011-01.
- SQL/MED - postgresql_fdw - Hasn't received as much review, I think,
so should probably be moved to next CF as-is.

Don't we need the core patch before the FDW patches? I hope that the
core patch is completed and committed ASAP so we have a chance to get
the FDW patches in.

cheers

andrew

On Mon, Dec 13, 2010 at 12:55 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 12/13/2010 12:37 PM, Robert Haas wrote:

- SQL/MED - core functionality - Seems clear to move this to the next
CF and keep working on it.

[...]

- SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in
marking this Returned with Feedback for now in anticipation of a new
version before CF 2011-01.
- SQL/MED - postgresql_fdw - Hasn't received as much review, I think,
so should probably be moved to next CF as-is.

Don't we need the core patch before the FDW patches? I hope that the core
patch is completed and committed ASAP so we have a chance to get the FDW
patches in.

The core patch will certainly need to be committed first. But I doubt
that's going to happen in the next few days. If we get it in before
the next CF starts, I think we'll be doing very well.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Dec 13, 2010 at 12:37:52PM -0500, Robert Haas wrote:

We're now just a day or two from the end of this CommitFest and there
are still a LOT of open patches - to be specific, 23.Here's a brief
synopsis of where we are with the others, all IMO of course.

[snip]

- Writeable CTEs - I think we need Tom to pick this one up.

What is it about this that's so complex? It's not like it could
impinge on previous functionality, at least at the SQL level.

- Tab completion in psql for triggers on views - Added to CF late,
suggest we bump it to the next CF where it will have a leg up by
virtue of already being marked Ready for Committer.

People are, by the way, allowed to commit patches outside of CFs. I
had submitted it imagining that its triviality would allow this, which
is why it got into the CF late in the first place.

[etc., etc., etc.]

All in all it's disappointing to have so many major patches
outstanding at this point in the CommitFest, but I think we're just
going to have to make the best of it.

I'm thinking that given all these givens, we should make the best of
it with more CF in March. We don't want a repeat of the "last-minute
giant change" anti-pattern, and even if we're releasing 9.1 in July,
three months plus is plenty of time to shake things out.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Mon, Dec 13, 2010 at 2:19 PM, David Fetter <david@fetter.org> wrote:

On Mon, Dec 13, 2010 at 12:37:52PM -0500, Robert Haas wrote:

We're now just a day or two from the end of this CommitFest and there
are still a LOT of open patches - to be specific, 23.Here's a brief
synopsis of where we are with the others, all IMO of course.

[snip]

- Writeable CTEs - I think we need Tom to pick this one up.

What is it about this that's so complex?  It's not like it could
impinge on previous functionality, at least at the SQL level.

I didn't say it was complex, although it is. I said I think we need
Tom to pick it up. That's partly because he's likely to have
overpoweringly strong opinions on how it should work, which may make
it unproductive for someone else to spend time on it. Also, it is
complex, and regardless of what effects it has on anything else, it
does need to work. Tom is good at that.

- Tab completion in psql for triggers on views - Added to CF late,
suggest we bump it to the next CF where it will have a leg up by
virtue of already being marked Ready for Committer.

People are, by the way, allowed to commit patches outside of CFs.  I
had submitted it imagining that its triviality would allow this, which
is why it got into the CF late in the first place.

You can insist all you like that your favorite patches are trivial,
but that doesn't make it so. I am well aware that patches can be
committed between CommitFests. For example:

git log --author=Haas --since=2010-10-16 --before=2010-11-14

All in all it's disappointing to have so many major patches
outstanding at this point in the CommitFest, but I think we're just
going to have to make the best of it.

I'm thinking that given all these givens, we should make the best of
it with more CF in March.  We don't want a repeat of the "last-minute
giant change" anti-pattern, and even if we're releasing 9.1 in July,
three months plus is plenty of time to shake things out.

-1. That's as likely to make the back-up of big patches worse as it
is to make it better. Maybe more likely.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

We're now just a day or two from the end of this CommitFest and there
are still a LOT of open patches - to be specific, 23.Here's a brief
synopsis of where we are with the others, all IMO of course.

Thanks for doing this!

- Extensions - Still under active discussion, suggested we move to
next CF.

Well, it might be confusing to follow those threads at about any
distance but in fact, the only active one left is about some details
concerning the ALTER EXTENSION UPGRADE command, which is *not* to be in
this commit fest but (hopefully) the next.

I think the main extension patch is about as ready as it can be now,
I've only been fixing nitpicks and interfacing for awhile (all along
this commit fest) and the underlying code has been very stable.

As we want to avoid pushing "big" patches into the last commit fest, I'd
very like it if we could have a last round of review-then-commit on this
patch. Of course it's still possible to work on it in between two commit
fests, but that's not a good idea: this is a very restrained time when
the more involved people here can work on their own ideas.

So, who's in to finish up and commit this patch in this round? :)
I certainly am ready to support last minute changes, given some are
required. And if they are too big for the schedule, better shake the
patch out now rather than let it bitrot another month.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote:

So, who's in to finish up and commit this patch in this round? :)
I certainly am ready to support last minute changes, given some are
required. And if they are too big for the schedule, better shake the
patch out now rather than let it bitrot another month.

I'll try to do another review this week.

David

"David E. Wheeler" <david@kineticode.com> writes:

On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote:

So, who's in to finish up and commit this patch in this round? :)

I'll try to do another review this week.

Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On 12/13/10 9:37 AM, Robert Haas wrote:

- synchronous replication - and...
- synchronous replication, transaction-controlled - If we want to get
this feature into 9.1, we had better get a move on. But I don't
currently have it in my time budget to deal with this.

I thought we'd covered most of the major issues here. What's holding
these up?

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

Robert Haas wrote:

- instrument checkpoint sync calls - I plan to commit this in the next
48 hours. (Hopefully Greg Smith will do the cleanup I suggested, if
not I'll do it.)

Yes, doing that tonight so you can have a simple (hopefully) bit of work
to commit tomorrow.

- MERGE command - Returned with Feedback? Not sure where we stand with this.

That's waiting for me to do another round of review. I'm getting to
that soon I hope, maybe tomorrow.

- SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in
marking this Returned with Feedback for now in anticipation of a new
version before CF 2011-01.
- SQL/MED - postgresql_fdw - Hasn't received as much review, I think,
so should probably be moved to next CF as-is.

I was thinking of just moving both of those into the next CF without
adding any clear resolution code--then they can get worked on as
feasible after the core goes in.

All in all it's disappointing to have so many major patches
outstanding at this point in the CommitFest, but I think we're just
going to have to make the best of it.

I've done a pretty lame job of pushings thing forward here, but I don't
think things have progressed that badly. The community produced several
large and/or multi-part patches that the CF could have choked on, and
instead they've been broken into digestible chunks and kept chewing
through them. I'm just glad that's happening in this CF, rather than a
pile like this showing up for the last one.

Thanks for the wrap-up summary, I was going to do something like that
myself tonight but you beat me to it.

--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

On Mon, Dec 13, 2010 at 4:52 PM, Josh Berkus <josh@agliodbs.com> wrote:

On 12/13/10 9:37 AM, Robert Haas wrote:

- synchronous replication - and...
- synchronous replication, transaction-controlled - If we want to get
this feature into 9.1, we had better get a move on.  But I don't
currently have it in my time budget to deal with this.

I thought we'd covered most of the major issues here.  What's holding
these up?

I don't know where you got that idea. We have two competing patches
neither of which has been updated in several months. And neither of
which has gotten a whole lot of review, either. We spent a lot of
time arguing about basic design and then everyone got tired and went
on doing other things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Dec13, 2010, at 18:37 , Robert Haas wrote:

We're now just a day or two from the end of this CommitFest and there
are still a LOT of open patches - to be specific, 23.Here's a brief
synopsis of where we are with the others, all IMO of course.

Thanks for putting this together!

- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That sucks,
because I think this is a really important change.

I can try to find some time to update the patch if it suffers from bit-rot. Would that help?

best regards,
Florian Pflug

On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug <fgp@phlo.org> wrote:

- serializable lock consistency - I am fairly certain this needs
rebasing.  I don't have time to deal with it right away.  That sucks,
because I think this is a really important change.

I can try to find some time to update the patch if it suffers from bit-rot. Would that help?

Yes!

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Dec 13, 2010 at 12:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:

- fix for seg picksplit function - I don't have confidence this change
is for the best and can't take responsibility for it. It needs review
by a committer who understands this stuff better than me and can
determine whether or not the change is really an improvement.

Still outstanding.

- unlogged tables - This is not going to get fully resolved in the
next two days.  I'll move it to the next CF and keep plugging away at
it.

Moved.

- instrument checkpoint sync calls - I plan to commit this in the next
48 hours.  (Hopefully Greg Smith will do the cleanup I suggested, if
not I'll do it.)

Committed.

- explain analyze getrusage tracking - It seems clear to mark this as
Returned with Feedback.

Marked return with Feedback.

- synchronous replication - and...
- synchronous replication, transaction-controlled - If we want to get
this feature into 9.1, we had better get a move on.  But I don't
currently have it in my time budget to deal with this.

Neither patch applies, and Simon's was also labelled WIP. Marked both
Returned with Feedback.

- serializable lock consistency - I am fairly certain this needs
rebasing.  I don't have time to deal with it right away.  That sucks,
because I think this is a really important change.
- MERGE command - Returned with Feedback?  Not sure where we stand with this.

Still outstanding.

- Add primary key using an existing index - Returned with Feedback
unless a committer is available immediately to pick this up and finish
it off.

Returned with Feedback. Looks like author is planning to rework this one.

- SQL/MED - core functionality - Seems clear to move this to the next
CF and keep working on it.

Moved.

- Idle in transaction cancellation V3 - I think this is waiting on
further review.  Can anyone work on this one RSN?

Reviewed, but no doubt there's more work left to be done here than is
going to happen in this CF.

- Writeable CTEs - I think we need Tom to pick this one up.
- Per-column collation - Bump to next CF, unless Peter is planning to
commit imminently.

Both still outstanding. I suppose these will have to be moved to the
next CommitFest.

- Tab completion in psql for triggers on views - Added to CF late,
suggest we bump it to the next CF where it will have a leg up by
virtue of already being marked Ready for Committer.

Partially committed. I'll see if I can find time to commit the rest;
otherwise, I'll move it along to the next CF.

- SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in
marking this Returned with Feedback for now in anticipation of a new
version before CF 2011-01.
- SQL/MED - postgresql_fdw - Hasn't received as much review, I think,
so should probably be moved to next CF as-is.

Per recommendation from Greg Smith, moved to next CF.

- Label switcher function (trusted procedure) - I plan to commit this
with whatever changes are needed within the next 48 hours.

Committed.

- Extensions - Still under active discussion, suggested we move to next CF.
- Fix snapshot taking inconsistencies - Ready for committer. Can any
committer pick this up?
- Crash dump handler for Windows.  Magnus?
- Directory archive format for pg_dump.  Heikki?

These are all still outstanding.

- WIP patch for parallel dump.  Returned with Feedback?

Returned with Feedback, with some reluctance, but nothing else seems reasonable.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Dec14, 2010, at 15:01 , Robert Haas wrote:

On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug <fgp@phlo.org> wrote:

- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That sucks,
because I think this is a really important change.

I can try to find some time to update the patch if it suffers from bit-rot. Would that help?

Yes!

I've rebased the patch to the current HEAD, and re-run my FK concurrency test suite,
available from https://github.com/fgp/fk_concurrency, to verify that things still work.

I've also asserts to the callers of heap_{update,delete,lock_tuple} to verify (and document)
that update_xmax may only be InvalidTransactionId if a lockcheck_snapshot is passed to
heap_{update,delete,lock_tuple}.

Finally, I've improved the explanation in src/backend/executor/README of how row locks and
REPEATABLE READ transactions interact, and tried to state the guarantees provided by
FOR SHARE and FOR UPDATE locks more precisely.

I've published my work to https://github.com/fgp/postgres/tree/serializable_lock_consistency,
and attached an updated patch. I'd be happy to give write access to that GIT repository
to anyone who wants to help getting this committed.

best regards,
Florian Pflug

On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug <fgp@phlo.org> wrote:

On Dec14, 2010, at 15:01 , Robert Haas wrote:

On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug <fgp@phlo.org> wrote:

- serializable lock consistency - I am fairly certain this needs
rebasing.  I don't have time to deal with it right away.  That sucks,
because I think this is a really important change.

I can try to find some time to update the patch if it suffers from bit-rot. Would that help?

Yes!

I've rebased the patch to the current HEAD, and re-run my FK concurrency test suite,
available from https://github.com/fgp/fk_concurrency, to verify that things still work.

Thanks, but, EWRONGTHREAD.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Dec15, 2010, at 16:45 , Robert Haas wrote:

On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug <fgp@phlo.org> wrote:

On Dec14, 2010, at 15:01 , Robert Haas wrote:

On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug <fgp@phlo.org> wrote:

- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That sucks,
because I think this is a really important change.

I can try to find some time to update the patch if it suffers from bit-rot. Would that help?

Yes!

I've rebased the patch to the current HEAD, and re-run my FK concurrency test suite,
available from https://github.com/fgp/fk_concurrency, to verify that things still work.

Thanks, but, EWRONGTHREAD.

Sorry for that. I wasn't sure whether to post this here or into the original thread,
and it seems I ended up on the losing side of that 50-50 chance ;-)

Want me to repost there, or just remember to use the correct thread next time?

best regards,
Florian Pflug

On Wed, Dec 15, 2010 at 10:57 AM, Florian Pflug <fgp@phlo.org> wrote:

On Dec15, 2010, at 16:45 , Robert Haas wrote:

On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug <fgp@phlo.org> wrote:

On Dec14, 2010, at 15:01 , Robert Haas wrote:

On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug <fgp@phlo.org> wrote:

- serializable lock consistency - I am fairly certain this needs
rebasing.  I don't have time to deal with it right away.  That sucks,
because I think this is a really important change.

I can try to find some time to update the patch if it suffers from bit-rot. Would that help?

Yes!

I've rebased the patch to the current HEAD, and re-run my FK concurrency test suite,
available from https://github.com/fgp/fk_concurrency, to verify that things still work.

Thanks, but, EWRONGTHREAD.

Sorry for that. I wasn't sure whether to post this here or into the original thread,
and it seems I ended up on the losing side of that 50-50 chance ;-)

Want me to repost there, or just remember to use the correct thread next time?

Nah, don't bother reposting. It'd be helpful if you could add a link
to that message on the CF app though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Dec15, 2010, at 17:17 , Robert Haas wrote:

Nah, don't bother reposting. It'd be helpful if you could add a link
to that message on the CF app though.

Already done. Seems we've hit a race condition there - you must have overlooked
the signalling the semaphore on my rooftop did to warn you...

best regards,
Florian Pflug

Robert Haas <robertmhaas@gmail.com> writes:

On Mon, Dec 13, 2010 at 12:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:

- fix for seg picksplit function - I don't have confidence this change
is for the best and can't take responsibility for it. It needs review
by a committer who understands this stuff better than me and can
determine whether or not the change is really an improvement.

Still outstanding.

I will take a look at that one --- it is a bug fix at bottom, so we
can't just drop it for lack of reviewers.

- Writeable CTEs - I think we need Tom to pick this one up.
- Fix snapshot taking inconsistencies - Ready for committer. Can any
committer pick this up?

Will take a look at these two also.

regards, tom lane