pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedRestore-reliability mode
79+ messages / 25 participants
[nested] [flat]
Commits from this thread:
2020-07-18 1e0dfd166b Add Valgrind buffer access instrumentation.
* Restore-reliability mode
@ 2015-06-03 13:50 Noah Misch <noah@leadboat.com>
0 siblings, 4 replies; 79+ messages in thread
From: Noah Misch @ 2015-06-03 13:50 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Subject changed from "Re: [CORE] postpone next week's release".
On Sat, May 30, 2015 at 10:48:45PM -0400, Bruce Momjian wrote:
> Well, I think we stop what we are doing, focus on restructuring,
> testing, and reviewing areas that historically have had problems, and
> when we are done, we can look to go to 9.5 beta. What we don't want to
> do is to push out more code and get back into a
> wack-a-bug-as-they-are-found mode, which obviously did not serve us well
> for multi-xact, and which is what releasing a beta will do, and of
> course, more commit-fests, and more features.
>
> If we have to totally stop feature development until we are all happy
> with the code we have, so be it. If people feel they have to get into
> cleanup mode or they will never get to add a feature to Postgres again,
> so be it. If people say, heh, I am not going to do anything and just
> come back when cleanup is done (by someone else), then we will end up
> with a smaller but more dedicated development team, and I am fine with
> that too. I am suggesting that until everyone is happy with the code we
> have, we should not move forward.
I like the essence of this proposal. Two suggestions. We can't achieve or
even robustly measure "everyone is happy with the code," so let's pick
concrete exit criteria. Given criteria framed like "Files A,B,C and patches
X,Y,Z have a sign-off from a committer other than their original committer."
anyone can monitor progress and find specific ways to contribute. Second, I
would define the subject matter as "bug fixes, testing and review", not
"restructuring, testing and review." Different code structures are clearest
to different hackers. Restructuring, on average, adds bugs even more quickly
than feature development adds them.
Thanks,
nm
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-03 14:07 Geoff Winkless <pgsqladmin@geoff.dj>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 0 replies; 79+ messages in thread
From: Geoff Winkless @ 2015-06-03 14:07 UTC (permalink / raw)
To: pgsql-hackers
On 3 June 2015 at 14:50, Noah Misch <noah@leadboat.com> wrote:
> I
>
> would define the subject matter as "bug fixes, testing and review", not
> "restructuring, testing and review." Different code structures are
> clearest
> to different hackers. Restructuring, on average, adds bugs even more
> quickly
> than feature development adds them.
>
+1 to this. Rewriting or restructuring code because you don't trust it
(even though you have no reported real-world bugs) is a terrible idea.
Stopping all feature development to do it is even worse.
I know you're not talking about rewriting, but I think
http://www.joelonsoftware.com/articles/fog0000000069.html is always worth a
re-read, if only because it's funny :)
I would always 100% support a decision to push back new releases because of
bugfixes for *known* issues, but if you think you *might *be able to find
bugs in code you don't like, you should do that on your own time. Iff you
find actual bugs, *then *you talk about halting new releases.
Geoff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-03 14:18 Andres Freund <andres@anarazel.de>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 2 replies; 79+ messages in thread
From: Andres Freund @ 2015-06-03 14:18 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 2015-06-03 09:50:49 -0400, Noah Misch wrote:
> Second, I would define the subject matter as "bug fixes, testing and
> review", not "restructuring, testing and review." Different code
> structures are clearest to different hackers. Restructuring, on
> average, adds bugs even more quickly than feature development adds
> them.
I can't agree with this. While I agree with not doing large
restructuring for 9.5, I think we can't affort not to refactor for
clarity, even if that introduces bugs. Noticeable parts of our code have
to frequently be modified for new features and are badly structured at
the same time. While restructuring will may temporarily increase the
number of bugs in the short term, it'll decrease the number of bugs long
term while increasing the number of potential contributors and new
features. That's obviously not to say we should just refactor for the
sake of it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-03 14:51 Joshua D. Drake <jd@commandprompt.com>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 79+ messages in thread
From: Joshua D. Drake @ 2015-06-03 14:51 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; Noah Misch <noah@leadboat.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 06/03/2015 07:18 AM, Andres Freund wrote:
>
> On 2015-06-03 09:50:49 -0400, Noah Misch wrote:
>> Second, I would define the subject matter as "bug fixes, testing and
>> review", not "restructuring, testing and review." Different code
>> structures are clearest to different hackers. Restructuring, on
>> average, adds bugs even more quickly than feature development adds
>> them.
>
> I can't agree with this. While I agree with not doing large
> restructuring for 9.5, I think we can't affort not to refactor for
> clarity, even if that introduces bugs. Noticeable parts of our code have
> to frequently be modified for new features and are badly structured at
> the same time. While restructuring will may temporarily increase the
> number of bugs in the short term, it'll decrease the number of bugs long
> term while increasing the number of potential contributors and new
> features. That's obviously not to say we should just refactor for the
> sake of it.
>
Our project has been continuing to increase momentum over the last few
years and our adoption has increased at an amazing rate. It is important
to remember that we have users. These users have needs that must be met
else those users will move on to a different technology.
I agree that we need to postpone this release. I also agree that there
is likely re-factoring to be done. I have also never met a programmer
who doesn't think something needs to be re-factored. The majority of
programmers I know all suffer from NIH and want to change how things are
implemented.
If we are going to re-factor, it should not be considered global and
should be attacked with specific goals in mind. If those goals are not
specifically defined and agreed on, we will get very pretty code with
very little use for our users. Then our users will leave because they
are busy waiting on us to re-factor.
In short, we must balance this effort with the needs of the code versus
the needs of our users.
Sincerely,
JD
--
The most kicking donkey PostgreSQL Infrastructure company in existence.
The oldest, the most experienced, the consulting company to the stars.
Command Prompt, Inc. http://www.commandprompt.com/ +1 -503-667-4564 -
24x7 - 365 - Proactive and Managed Professional Services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-03 17:21 Josh Berkus <josh@agliodbs.com>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 3 replies; 79+ messages in thread
From: Josh Berkus @ 2015-06-03 17:21 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; +Cc: Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 06/03/2015 06:50 AM, Noah Misch wrote:
> Subject changed from "Re: [CORE] postpone next week's release".
>
> On Sat, May 30, 2015 at 10:48:45PM -0400, Bruce Momjian wrote:
>> If we have to totally stop feature development until we are all happy
>> with the code we have, so be it. If people feel they have to get into
>> cleanup mode or they will never get to add a feature to Postgres again,
>> so be it. If people say, heh, I am not going to do anything and just
>> come back when cleanup is done (by someone else), then we will end up
>> with a smaller but more dedicated development team, and I am fine with
>> that too. I am suggesting that until everyone is happy with the code we
>> have, we should not move forward.
>
> I like the essence of this proposal. Two suggestions. We can't achieve or
> even robustly measure "everyone is happy with the code," so let's pick
> concrete exit criteria. Given criteria framed like "Files A,B,C and patches
> X,Y,Z have a sign-off from a committer other than their original committer."
> anyone can monitor progress and find specific ways to contribute. Second, I
> would define the subject matter as "bug fixes, testing and review", not
> "restructuring, testing and review." Different code structures are clearest
> to different hackers. Restructuring, on average, adds bugs even more quickly
> than feature development adds them.
So, historically, this is what the period between feature freeze and
beta1 was for; the "consolidation" phase was supposed to deal with this.
The problem over the last few years, by my observation, has been that
consolidation has been left to just a few people (usually just Bruce &
Tom or Tom & Robert) and our code base is now much to large for that.
The way other projects deal with this is having continuous testing as
stuff comes in, and *more* testing that just our regression tests (e.g.
acceptance tests, integration tests, performance tests, etc.). So our
other issue has been that our code complexity has been growing faster
than our test suite. Part of that is that this community has never
placed much value in automated testing or testers, so people who are
interested in it find other projects to contribute to.
I would argue that if we delay 9.5 in order to do a 100% manual review
of code, without adding any new automated tests or other non-manual
tools for improving stability, then it's a waste of time; we might as
well just release the beta, and our users will find more issues than we
will. I am concerned that if we declare a cleanup period, especially in
the middle of the summer, all that will happen is that the project will
go to sleep for an extra three months.
I will also point out that there is a major adoption cost to delaying
9.5. Right now users are excited about UPSERT, big data, and extra
JSON features. If they have to wait another 7 months, they'll be a lot
less excited, and we'll lose more potential users to the new databases
and the MySQL forks. It could also delay the BDR project (Simon/Craig
can speak to this) which would suck.
Reliability of having a release every year is important as well as
database reliability ... and for a lot of the new webdev generation,
PostgreSQL is already the most reliable piece of software infrastructure
they use. So if we're going to have a cleanup delay, then let's please
make it an *intensive* cleanup delay, with specific goals, milestones,
and a schedule. Otherwise, don't bother.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-03 17:25 Andres Freund <andres@anarazel.de>
parent: Josh Berkus <josh@agliodbs.com>
2 siblings, 0 replies; 79+ messages in thread
From: Andres Freund @ 2015-06-03 17:25 UTC (permalink / raw)
To: Josh Berkus <josh@agliodbs.com>; +Cc: Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 2015-06-03 10:21:28 -0700, Josh Berkus wrote:
> So, historically, this is what the period between feature freeze and
> beta1 was for; the "consolidation" phase was supposed to deal with this.
> The problem over the last few years, by my observation, has been that
> consolidation has been left to just a few people (usually just Bruce &
> Tom or Tom & Robert) and our code base is now much to large for that.
>
> The way other projects deal with this is having continuous testing as
> stuff comes in, and *more* testing that just our regression tests (e.g.
> acceptance tests, integration tests, performance tests, etc.). So our
> other issue has been that our code complexity has been growing faster
> than our test suite. Part of that is that this community has never
> placed much value in automated testing or testers, so people who are
> interested in it find other projects to contribute to.
>
> I would argue that if we delay 9.5 in order to do a 100% manual review
> of code, without adding any new automated tests or other non-manual
> tools for improving stability, then it's a waste of time; we might as
> well just release the beta, and our users will find more issues than we
> will. I am concerned that if we declare a cleanup period, especially in
> the middle of the summer, all that will happen is that the project will
> go to sleep for an extra three months.
>
> I will also point out that there is a major adoption cost to delaying
> 9.5. Right now users are excited about UPSERT, big data, and extra
> JSON features. If they have to wait another 7 months, they'll be a lot
> less excited, and we'll lose more potential users to the new databases
> and the MySQL forks. It could also delay the BDR project (Simon/Craig
> can speak to this) which would suck.
>
> Reliability of having a release every year is important as well as
> database reliability ... and for a lot of the new webdev generation,
> PostgreSQL is already the most reliable piece of software infrastructure
> they use. So if we're going to have a cleanup delay, then let's please
> make it an *intensive* cleanup delay, with specific goals, milestones,
> and a schedule. Otherwise, don't bother.
+very many
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-04 14:43 Stephen Frost <sfrost@snowman.net>
parent: Josh Berkus <josh@agliodbs.com>
2 siblings, 1 reply; 79+ messages in thread
From: Stephen Frost @ 2015-06-04 14:43 UTC (permalink / raw)
To: Josh Berkus <josh@agliodbs.com>; +Cc: Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Josh,
* Josh Berkus (josh@agliodbs.com) wrote:
> I would argue that if we delay 9.5 in order to do a 100% manual review
> of code, without adding any new automated tests or other non-manual
> tools for improving stability, then it's a waste of time; we might as
> well just release the beta, and our users will find more issues than we
> will. I am concerned that if we declare a cleanup period, especially in
> the middle of the summer, all that will happen is that the project will
> go to sleep for an extra three months.
This is the exact same concern that I have. A delay just to have a
delay is not useful. I completely agree that we need more automated
testing, etc, though getting all of that set up and running could be
done at any time too- there's no reason to wait, nor do I believe
delaying 9.5 would make such automated testing appear.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-04 23:53 Craig Ringer <craig@2ndquadrant.com>
parent: Stephen Frost <sfrost@snowman.net>
0 siblings, 1 reply; 79+ messages in thread
From: Craig Ringer @ 2015-06-04 23:53 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 4 June 2015 at 22:43, Stephen Frost <sfrost@snowman.net> wrote:
> Josh,
>
> * Josh Berkus (josh@agliodbs.com) wrote:
> > I would argue that if we delay 9.5 in order to do a 100% manual review
> > of code, without adding any new automated tests or other non-manual
> > tools for improving stability, then it's a waste of time; we might as
> > well just release the beta, and our users will find more issues than we
> > will. I am concerned that if we declare a cleanup period, especially in
> > the middle of the summer, all that will happen is that the project will
> > go to sleep for an extra three months.
>
> This is the exact same concern that I have. A delay just to have a
> delay is not useful. I completely agree that we need more automated
> testing, etc, though getting all of that set up and running could be
> done at any time too- there's no reason to wait, nor do I believe
> delaying 9.5 would make such automated testing appear.
>
>
In terms of specific testing improvements, things I think we need to have
covered and runnable on the buildfarm are:
* pg_dump and pg_restore testing (because it's scary we don't do this)
* WAL archiving based warm standby testing with promotion
* Two node streaming replication with promotion, both with a slot and with
archive fallback
* Three node cascading streaming replication with middle node promotion
then tail end node promotion
* Logical decoding streaming testing, comparing to expected decoded output
* DDL deparse test coverage for all operations
* pg_basebackup + start up from backup
* hard-kill the postmaster, start up from crashed datadir
* pg_start_backup, rsync, pg_stop_backup, start up in hot standby
* disk exhaustion tests both for pg_xlog and for the main datadir, showing
we can recover OK when disk is filled then space is freed
* Tests of crash recovery during various DDL operations
Obviously some of these overlap, so one test can cover more than one item.
Implementing these requires stepping outside the comfortable zone of
pg_regress and the isolationtester and having something that can manage
multiple data directories. It's also hard to be sure you're testing the
same thing each time - for example, when using streaming replication with
archive fallback, it might be tricky to ensure that your replica falls
behind and falls back to WAL archive each time. There's always SIGSTOP I
guess.
While these are multi-node tests, at least in PostgreSQL we can just run on
different ports, so there's no need to muck about with containers or VMs.
I already run some of these tests using Ansible for BDR, but I don't
imagine that'd be acceptable in core. It's Python, and it's not especially
well suited to use as a regression testing framework, it's just what I had
to hand and already needed for other automation tasks.
Is pg_tap a reasonable starting point for this sort of testing?
Am I missing obvious and important tests?
How would a test that would've caught the multixact issues look?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 04:28 Michael Paquier <michael.paquier@gmail.com>
parent: Craig Ringer <craig@2ndquadrant.com>
0 siblings, 2 replies; 79+ messages in thread
From: Michael Paquier @ 2015-06-05 04:28 UTC (permalink / raw)
To: Craig Ringer <craig@2ndquadrant.com>; +Cc: Stephen Frost <sfrost@snowman.net>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 8:53 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>
>
> On 4 June 2015 at 22:43, Stephen Frost <sfrost@snowman.net> wrote:
>>
>> Josh,
>>
>> * Josh Berkus (josh@agliodbs.com) wrote:
>> > I would argue that if we delay 9.5 in order to do a 100% manual review
>> > of code, without adding any new automated tests or other non-manual
>> > tools for improving stability, then it's a waste of time; we might as
>> > well just release the beta, and our users will find more issues than we
>> > will. I am concerned that if we declare a cleanup period, especially in
>> > the middle of the summer, all that will happen is that the project will
>> > go to sleep for an extra three months.
>>
>> This is the exact same concern that I have. A delay just to have a
>> delay is not useful. I completely agree that we need more automated
>> testing, etc, though getting all of that set up and running could be
>> done at any time too- there's no reason to wait, nor do I believe
>> delaying 9.5 would make such automated testing appear.
>>
>
> In terms of specific testing improvements, things I think we need to have
> covered and runnable on the buildfarm are:
>
> * pg_dump and pg_restore testing (because it's scary we don't do this)
We do test it in some way with pg_upgrade using set of objects that
are not removed by the regression test suite. Extension dumps are
uncovered yet though.
> * WAL archiving based warm standby testing with promotion
> * Two node streaming replication with promotion, both with a slot and with
> archive fallback
> * Three node cascading streaming replication with middle node promotion then
> tail end node promotion
> * Logical decoding streaming testing, comparing to expected decoded output
> * hard-kill the postmaster, start up from crashed datadir
> * pg_basebackup + start up from backup
> * pg_start_backup, rsync, pg_stop_backup, start up in hot standby
> * Tests of crash recovery during various DDL operations
Well, steps in this direction are the point of this patch, the
replication test suite:
https://commitfest.postgresql.org/5/197/
And this one, addition of Windows support for TAP tests:
https://commitfest.postgresql.org/5/207/
> * DDL deparse test coverage for all operations
What do you have in mind except what is already in objectaddress.sql
and src/test/modules/test_dll_deparse/?
> * disk exhaustion tests both for pg_xlog and for the main datadir, showing
> we can recover OK when disk is filled then space is freed
This may be tricky. How would you emulate that?
> Is pg_tap a reasonable starting point for this sort of testing?
IMO, using the TAP machinery would be a good base for that. What lacks
is a basic set of perl routines that one can easily use to set of test
scenarios.
> How would a test that would've caught the multixact issues look?
I have not followed closely those discussions, not sure about that.
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 06:50 Simon Riggs <simon@2ndQuadrant.com>
parent: Josh Berkus <josh@agliodbs.com>
2 siblings, 2 replies; 79+ messages in thread
From: Simon Riggs @ 2015-06-05 06:50 UTC (permalink / raw)
To: Josh Berkus <josh@agliodbs.com>; +Cc: Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 3 June 2015 at 18:21, Josh Berkus <josh@agliodbs.com> wrote:
> I would argue that if we delay 9.5 in order to do a 100% manual review
> of code, without adding any new automated tests or other non-manual
> tools for improving stability, then it's a waste of time; we might as
> well just release the beta, and our users will find more issues than we
> will. I am concerned that if we declare a cleanup period, especially in
> the middle of the summer, all that will happen is that the project will
> go to sleep for an extra three months.
>
Agreed. Cleanup can occur while we release code for public testing.
Many eyeballs of Beta beats anything we can throw at it thru manual
inspection. The whole problem of bugs is that they are mostly found by
people trying to use the software.
> I will also point out that there is a major adoption cost to delaying
> 9.5. Right now users are excited about UPSERT, big data, and extra
> JSON features. If they have to wait another 7 months, they'll be a lot
> less excited, and we'll lose more potential users to the new databases
> and the MySQL forks.
>
> Reliability of having a release every year is important as well as
> database reliability ... and for a lot of the new webdev generation,
> PostgreSQL is already the most reliable piece of software infrastructure
> they use. So if we're going to have a cleanup delay, then let's please
> make it an *intensive* cleanup delay, with specific goals, milestones,
> and a schedule. Otherwise, don't bother.
>
We've decided previously that having a fixed annual schedule was a good
thing for the project. Getting the features that work into the hands of the
people that want them is very important.
Discussing halting the development schedule publicly is very damaging.
If there are features in doubt, lets do more work on them or just pull them
now and return to the schedule. I don't really care which ones get canned
as long as we return to the schedule.
Whatever we do must be exact and measurable. If its not, it means we
haven't assembled enough evidence for action that is sufficiently directed
to achieve the desired goal.
On 3 June 2015 at 18:21, Josh Berkus <josh@agliodbs.com> wrote:
> It could also delay the BDR project (Simon/Craig
>
can speak to this) which would suck.
>
Nothing being discussed here can/will slow down the BDR project since it is
already a different thread of development. More so, 2ndQuadrant has zero
income tied to the release of 9.5 or the commit of any feature, so as far
as that company is concerned, the release could wait for 10 years.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-05 07:25 Simon Riggs <simon@2ndQuadrant.com>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 1 reply; 79+ messages in thread
From: Simon Riggs @ 2015-06-05 07:25 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 3 June 2015 at 14:50, Noah Misch <noah@leadboat.com> wrote:
> Subject changed from "Re: [CORE] postpone next week's release".
>
> On Sat, May 30, 2015 at 10:48:45PM -0400, Bruce Momjian wrote:
> > Well, I think we stop what we are doing, focus on restructuring,
> > testing, and reviewing areas that historically have had problems, and
> > when we are done, we can look to go to 9.5 beta. What we don't want to
> > do is to push out more code and get back into a
> > wack-a-bug-as-they-are-found mode, which obviously did not serve us well
> > for multi-xact, and which is what releasing a beta will do, and of
> > course, more commit-fests, and more features.
> >
> > If we have to totally stop feature development until we are all happy
> > with the code we have, so be it. If people feel they have to get into
> > cleanup mode or they will never get to add a feature to Postgres again,
> > so be it. If people say, heh, I am not going to do anything and just
> > come back when cleanup is done (by someone else), then we will end up
> > with a smaller but more dedicated development team, and I am fine with
> > that too. I am suggesting that until everyone is happy with the code we
> > have, we should not move forward.
>
> I like the essence of this proposal. Two suggestions. We can't achieve or
> even robustly measure "everyone is happy with the code," so let's pick
> concrete exit criteria. Given criteria framed like "Files A,B,C and
> patches
> X,Y,Z have a sign-off from a committer other than their original
> committer."
> anyone can monitor progress and find specific ways to contribute.
I don't like the proposal, nor do I like the follow on comments made.
This whole idea of "feature development" vs reliability is bogus. It
implies people that work on features don't care about reliability. Given
the fact that many of the features are actually about increasing database
reliability in the event of crashes and corruptions it just makes no sense.
How will we participate in cleanup efforts? How do we know when something
has been "cleaned up", how will we measure our success or failure? I think
we should be clear that wasting N months on cleanup can *fail* to achieve a
useful objective. Without a clear plan it almost certainly will do so. The
flip side is that wasting N months will cause great amusement and dancing
amongst those people who wish to pull ahead of our open source project and
we should take care not to hand them a victory from an overreaction.
Lastly, the idea that we allow developers to drift away and we're OK with
that is just plain mad. I've spent a decade trying to grow the pool of
skilled developers who can assist the project. Acting against that, in deed
or just word, is highly counter productive for the project.
Let's just take a breath and think about this.
It is normal for us to spend a month or so consolidating our work. It is
also normal for people that see major problems to call them out,
effectively using the "Stop The Line" technique.
https://leanbuilds.wordpress.com/tag/stop-the-line/
So lets do our normal things, not do a "total stop" for an indefinite
period. If someone has specific things that in their opinion need to be
addressed, list them and we can talk about doing them, together. I thought
that was what the Open Items list was for. Let's use it.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 14:00 Robert Haas <robertmhaas@gmail.com>
parent: Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 4 replies; 79+ messages in thread
From: Robert Haas @ 2015-06-05 14:00 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Agreed. Cleanup can occur while we release code for public testing.
The code is available for public testing right now. Stamping it a
beta implies that we think it's something fairly stable that we'd be
pretty happy to release if things go well, which is a higher bar to
clear.
I can't help noticing for all the drumbeat of "let's release 9.5 beta
now", activity to clean up the items on this list seems quite
sluggish:
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
I've seen Tom and a few other people doing some work that I would
describe as useful pre-beta stabilization, but I think there is a good
bit more that could be done, and that list is a good starting point.
I hope to have time to do some myself, but right now I am busy trying
to stabilize 9.3, along with Alvaro, Noah, Andres, and Thomas Munro,
and PGCon is coming up in just over a week. I think we could afford
to give ourselves at least until a few weeks following PGCon to tidy
up.
I do agree that an indefinite development freeze with unclear
parameters for resuming development and unclear goals is a bad plan.
But I think giving ourselves a little more time to, say, turn the
buildfarm consistently green, and, say, fix the known but
currently-unfixed multixact bugs, and, say, fix the known bugs in 9.5
features is a good plan, and I hope you and others will support it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 14:23 Tom Lane <tgl@sss.pgh.pa.us>
parent: Robert Haas <robertmhaas@gmail.com>
3 siblings, 2 replies; 79+ messages in thread
From: Tom Lane @ 2015-06-05 14:23 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jun 5, 2015 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Agreed. Cleanup can occur while we release code for public testing.
> The code is available for public testing right now.
Only to people who have the time and ability to pull the code from git
and build from source. I don't know exactly what fraction of interested
testers that excludes, but I bet it's significant. The point of producing
packages would be to remove that barrier to testing.
> Stamping it a
> beta implies that we think it's something fairly stable that we'd be
> pretty happy to release if things go well, which is a higher bar to
> clear.
So let's call it an alpha, or some other way of setting expectations
appropriately. But I think it's silly to maintain that the code is not in
a state where end-user testing is useful. They just have to understand
that they can't trust it with production data.
> I can't help noticing for all the drumbeat of "let's release 9.5 beta
> now", activity to clean up the items on this list seems quite
> sluggish:
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
While we need to work on those items, I do not agree that getting that
list to empty has to happen before we release a test version. I think
serializing effort in that way is simply bad project management. And
it's not how we've operated in the past either: getting the open items
list to empty has always been understood as a prerequisite to RC versions,
not to betas.
To get to specifics instead of generalities: exactly which of the current
open items do you think is so bad that it precludes user testing? I do
not see a beta-blocker in the lot.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:05 Bruce Momjian <bruce@momjian.us>
parent: Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 2 replies; 79+ messages in thread
From: Bruce Momjian @ 2015-06-05 15:05 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 07:50:31AM +0100, Simon Riggs wrote:
> On 3 June 2015 at 18:21, Josh Berkus <josh@agliodbs.com> wrote:
>
>
> I would argue that if we delay 9.5 in order to do a 100% manual review
> of code, without adding any new automated tests or other non-manual
> tools for improving stability, then it's a waste of time; we might as
> well just release the beta, and our users will find more issues than we
> will. I am concerned that if we declare a cleanup period, especially in
> the middle of the summer, all that will happen is that the project will
> go to sleep for an extra three months.
>
>
> Agreed. Cleanup can occur while we release code for public testing.
>
> Many eyeballs of Beta beats anything we can throw at it thru manual inspection.
> The whole problem of bugs is that they are mostly found by people trying to use
> the software.
Please address some of the specific issues I mentioned. The problem
with the multi-xact case is that we just kept fixing bugs as people
found them, and did not do a holistic review of the code. I am saying
let's not _keep_ doing that and let's make sure we don't have any
systematic problems in our code where we just keep fixing things without
doing a thorough analysis.
To release 9.5 beta would be to get back into that cycle, and I am not
sure we are ready for that. I think the fact we have multiple people
all reviewing the multi-xact code now (and not dealing with 9.5) is a
good sign. If we were focused on 9.5 beta, I doubt this would have
happened.
I am saying let's make sure we are not deficient in other areas, then
let's move forward again. I would love to think we can do multiple
things at once, but for multi-xact, serious review didn't happen for 18
months, so if slowing release development is what is required, I support
it.
> We've decided previously that having a fixed annual schedule was a good thing
> for the project. Getting the features that work into the hands of the people
> that want them is very important.
Yes, but let's not be a slave to the schedule if our reliability is
suffering, which it clearly has in the past 18 months.
> Discussing halting the development schedule publicly is very damaging.
Agreed.
> If there are features in doubt, lets do more work on them or just pull them now
> and return to the schedule. I don't really care which ones get canned as long
> as we return to the schedule.
Again, please address my concerns above. This is not about 9.5
features, but rather our overall focus on schedule vs. reliability, and
your arguments are reinforcing my idea that we do not have the proper
balance here.
> Whatever we do must be exact and measurable. If its not, it means we haven't
> assembled enough evidence for action that is sufficiently directed to achieve
> the desired goal.
Sure. I think everyone agrees the multi-xact work is all good, so I am
asking what else needs this kind of research. If there is nothing else,
we can move forward again --- I am just saying we need to ask the
reliability question _first_.
Let me restate something that has appeared in many replies to my ideas
--- I am not asking for infinite or unbounded review, but I am asking
that we make sure reliability gets the proper focus in relation to our
time pressures. Our balance was so off a month ago that I feel only a
full stop on time pressure would allow us to refocus because people are
not good at focusing on multiple things. It is sometimes necessary to
stop everything to get people's attention, and to help them remember
that without reliability, a database is useless.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:05 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Michael Paquier <michael.paquier@gmail.com>
1 sibling, 1 reply; 79+ messages in thread
From: Alvaro Herrera @ 2015-06-05 15:05 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Craig Ringer <craig@2ndquadrant.com>; Stephen Frost <sfrost@snowman.net>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Michael Paquier wrote:
> On Fri, Jun 5, 2015 at 8:53 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> > In terms of specific testing improvements, things I think we need to have
> > covered and runnable on the buildfarm are:
> >
> > * pg_dump and pg_restore testing (because it's scary we don't do this)
>
> We do test it in some way with pg_upgrade using set of objects that
> are not removed by the regression test suite. Extension dumps are
> uncovered yet though.
We could put more emphasis on having objects of all kinds remain in the
regression database, so that the pg_upgrade test covers more of this.
What happened with the extension tests patches you submitted? They
seemed valuable to me, but I lost track.
> > * DDL deparse test coverage for all operations
>
> What do you have in mind except what is already in objectaddress.sql
> and src/test/modules/test_dll_deparse/?
The current SQL scripts in that test do not cover all possible object
types, so there's a lot of the decoding capabilities that are currently
not exercised. So one way to attack this would be to add more object
types to those files. However, a completely different way is to have
the test process serial_schedule from src/test/regress and run
everything in there under deparse. That would be even more useful,
because whenever some future DDL is added, we will automatically get
coverage.
> > How would a test that would've caught the multixact issues look?
>
> I have not followed closely those discussions, not sure about that.
One issue with these bugs is that unless you use things such as
pg_burn_multixact, producing large enough numbers of multixacts takes a
long time. I've wondered if we could somehow make those easier to
reproduce by lowering the range, and thus doing thousands of
wraparounds, freezing and truncations in reasonable time. (For example,
change the typedefs to uint16 rather than uint32). But then the issue
becomes that the test code is not exactly equivalent to the production
code, which could cause its own bugs.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:18 Simon Riggs <simon@2ndQuadrant.com>
parent: Robert Haas <robertmhaas@gmail.com>
3 siblings, 2 replies; 79+ messages in thread
From: Simon Riggs @ 2015-06-05 15:18 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 5, 2015 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > Agreed. Cleanup can occur while we release code for public testing.
>
> The code is available for public testing right now.
People test when they get the signal from us, not before. While what you
say is literally correct, that is not the point.
> Stamping it a
> beta implies that we think it's something fairly stable that we'd be
> pretty happy to release if things go well, which is a higher bar to
> clear.
>
We don't have a clear definition of what Beta means. For me, Beta has
always meant "trial software, please test".
I don't think anybody will say anything bad about us if we release a beta
and then later pull some of the features because we are not confident with
them when AFTER testing the feature is shown to be below our normal
standard; that will bring us credit, I feel. It is extremely common in
software development to defer some of the features if their goals aren't
met, or to change APIs and interfaces based upon user feedback.
Making decisions on what will definitely be in a release BEFORE testing and
feedback seems foolhardy and certainly not scientific.
None of this means I disagree with assessments of the current state of the
software, I'm saying that we should simply follow the normal process and
stick to the schedule we have previously agreed, for all of the reasons
cited when we agreed it.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:20 Robert Haas <robertmhaas@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 79+ messages in thread
From: Robert Haas @ 2015-06-05 15:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 10:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jun 5, 2015 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Agreed. Cleanup can occur while we release code for public testing.
>
>> The code is available for public testing right now.
>
> Only to people who have the time and ability to pull the code from git
> and build from source. I don't know exactly what fraction of interested
> testers that excludes, but I bet it's significant. The point of producing
> packages would be to remove that barrier to testing.
Sure, I agree with that.
>> Stamping it a
>> beta implies that we think it's something fairly stable that we'd be
>> pretty happy to release if things go well, which is a higher bar to
>> clear.
>
> So let's call it an alpha, or some other way of setting expectations
> appropriately. But I think it's silly to maintain that the code is not in
> a state where end-user testing is useful. They just have to understand
> that they can't trust it with production data.
I don't maintain that end-user testing is unuseful at this point. I
do maintain that it would be better to (1) finish fixing the known
multixact bugs and (2) clean up some of the open items before we make
a big push in that direction. For example, consider this item from
the open items list:
http://www.postgresql.org/message-id/CAHGQGwEqWD=yNQE+ZojbpoxyWT3xLK52-V_q9S+XOfCKJd5egA@mail.gmail....
Now this is a fundamental definitional issue about how RLS is supposed
to work. I'm not going to deny that we COULD ship a release without
deciding what the behavior should be there, but I don't think it's a
good idea. I am fine with the possibility that one of our new
features may, say, dump core someplace due to a NULL pointer deference
we haven't found yet. Such bugs can always exist, but they are easily
fixed once found. But if we're not clear on how a feature is supposed
to behave, which seems to be the case here, I favor trying to resolve
that issue before shipping anything. Otherwise, we're saying "test
this, even though the final version will likely work differently".
That's not really helpful for us and will discourage testers from
doing anything at all.
Going through the open items, the other ones that seem to involve
definitional changes are:
1. FPW compression leaks information - The usefulness of the GUC may
depend on its PGC_*-ness. We should decide what we want to do before
asking people to test it.
2. custom-join has no way to construct Plan nodes of child Path nodes
- The entire feature is a C API, and the API needs to be changed. We
should finalize the API before asking people to test whether they can
use it for interesting things.
3. recovery_target_action = pause & hot_standby = off - Rumor has it
we replaced one surprising behavior with a different but
equally-surprising behavior. We should decide what the right thing is
and make sure the code is doing that before calling it a release.
4. Arguable RLS security bug, EvalPlanQual() paranoia - This seems
like another question of what the expectations around RLS actually
are.
I would also argue that we really ought to make a decision about
"basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe"
before we get too close to final release. Maybe it's not a
beta-blocker, exactly, but it doesn't seem like the sort of change
that should be rushed in too close to the end, because it looks sorta
complicated and scary. (Those are the technical terms.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:23 Simon Riggs <simon@2ndQuadrant.com>
parent: Robert Haas <robertmhaas@gmail.com>
3 siblings, 0 replies; 79+ messages in thread
From: Simon Riggs @ 2015-06-05 15:23 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com> wrote:
> I do agree that an indefinite development freeze with unclear
> parameters for resuming development and unclear goals is a bad plan.
> But I think giving ourselves a little more time to, say, turn the
> buildfarm consistently green, and, say, fix the known but
> currently-unfixed multixact bugs, and, say, fix the known bugs in 9.5
> features is a good plan, and I hope you and others will support it.
>
Yes, its a good plan and I support that. That's just normal process.
If you mean we should allow that to stall the release of Beta then I
disagree. The presence of bugs clearly has nothing to do with the discovery
of new ones and we should be looking to discover as many as possible as
quickly as possible.
I can understand the argument to avoid releasing Beta because of Dev
Meeting, so we should aim for June 25th Beta 1.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:36 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 79+ messages in thread
From: Andres Freund @ 2015-06-05 15:36 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 2015-06-05 11:05:14 -0400, Bruce Momjian wrote:
> To release 9.5 beta would be to get back into that cycle, and I am not
> sure we are ready for that. I think the fact we have multiple people
> all reviewing the multi-xact code now (and not dealing with 9.5) is a
> good sign. If we were focused on 9.5 beta, I doubt this would have
> happened.
At least form me that I'm working on multixacts right now has nothing to
do with to beta or not to beta.
And I don't understand why releasing an alpha or beta would detract from
that right now. We need more people doing crazy shit with our codebase,
not fewer.
None of the master-only issues is a blocker for an alpha, so besides
some release work within the next two weeks I don't see what'd detract
us that much?
> I am saying let's make sure we are not deficient in other areas, then
> let's move forward again.
I don't think we actually can do that. The problem of the multixact
stuff is precisely that it looked so innocent that a bunch of
experienced people just didn't see the problem. Omniscience is easy in
hindsight.
> I would love to think we can do multiple things at once, but for
> multi-xact, serious review didn't happen for 18 months, so if slowing
> release development is what is required, I support it.
FWIW, I can stomach a week or four of doing bugfix only stuff. After
that I'm simply not going to be efficient at that anymore. And I
seriously doubt that I'm the only one like that. Doing the same thing
for weeks makes you miss obvious stuff.
I don't think anything as localized as 'do nothing but bugfixes for a
while and then carry on' actually will solve the problem. We need to
find and reallocate resources to put more emphasis on review, robustness
and refactoring in the long term, not do panick-y stuff short term. This
isn't a problem that can be solved by focusing on bugfixing for a week
or four.
That means we have to convince employers to actually *pay* us (people
experienced with the codebase) to do work on these kind of things
instead of much-easier-to-market new features. A lot of
review/robustness work has been essentially done in our spare time,
after long days. Which means the employers need to get more people.
> Sure. I think everyone agrees the multi-xact work is all good, so I am
> asking what else needs this kind of research. If there is nothing else,
> we can move forward again --- I am just saying we need to ask the
> reliability question _first_.
I'm starting to get grumpy here. You've called for review in lots of
emails now. Let's get going then?
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: Robert Haas <robertmhaas@gmail.com>
1 sibling, 1 reply; 79+ messages in thread
From: Tom Lane @ 2015-06-05 15:39 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Robert Haas <robertmhaas@gmail.com> writes:
> I don't maintain that end-user testing is unuseful at this point. I
> do maintain that it would be better to (1) finish fixing the known
> multixact bugs and (2) clean up some of the open items before we make
> a big push in that direction. For example, consider this item from
> the open items list:
> http://www.postgresql.org/message-id/CAHGQGwEqWD=yNQE+ZojbpoxyWT3xLK52-V_q9S+XOfCKJd5egA@mail.gmail....
> Now this is a fundamental definitional issue about how RLS is supposed
> to work. I'm not going to deny that we COULD ship a release without
> deciding what the behavior should be there, but I don't think it's a
> good idea. I am fine with the possibility that one of our new
> features may, say, dump core someplace due to a NULL pointer deference
> we haven't found yet. Such bugs can always exist, but they are easily
> fixed once found. But if we're not clear on how a feature is supposed
> to behave, which seems to be the case here, I favor trying to resolve
> that issue before shipping anything. Otherwise, we're saying "test
> this, even though the final version will likely work differently".
> That's not really helpful for us and will discourage testers from
> doing anything at all.
The other side of that coin is that we might get useful comments from
testers on how the feature ought to work. I don't agree with the notion
that all feature details must be graven on stone tablets before we start
trying to get feedback from people outside the core development community.
The same point applies to the FDW C API questions, or to RLS, or to the
"expanded objects" work that I did. (I'd really love it if the PostGIS
folk would try to use that sometime before it's too late to adjust the
definition...) Now, you could argue that people likely to have useful
input on those issues are fully capable of working with git tip, and you'd
probably be right, but would they do so? As Simon says nearby, publishing
an alpha/beta/whatever is our signal to the wider community that it's time
for them to start paying attention. I do not think they will look at 9.5
until we do that; and I think it'll be our loss if they don't start
looking at these things soon.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:51 Andres Freund <andres@anarazel.de>
parent: Robert Haas <robertmhaas@gmail.com>
1 sibling, 1 reply; 79+ messages in thread
From: Andres Freund @ 2015-06-05 15:51 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 2015-06-05 11:20:52 -0400, Robert Haas wrote:
> I don't maintain that end-user testing is unuseful at this point.
Unless I misunderstand you, and you're not saying that user level
testing wouldn't be helpful right now, I'm utterly baffled. There's
loads of user-exposed features that desperately need exposure.
Looking at https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL I
don't see a single item that correlates with the ones on the open items
list list. Sure, it's incomplete. But that's a lot of stuff to test
already. And the authors of those features can work on fixing the issues
coming up. Lots of those features have barely got any testing at this
point.
> do maintain that it would be better to (1) finish fixing the known
> multixact bugs and (2) clean up some of the open items before we make
> a big push in that direction.
There's maybe 3-4 people that can actually do something about the
existing issues on that list. The community is far bigger than
that. Right now everyone is sitting on the sidelines and twiddling their
thumbs or developing new stuff. At least that's my impression.
> 2. custom-join has no way to construct Plan nodes of child Path nodes
> - The entire feature is a C API, and the API needs to be changed. We
> should finalize the API before asking people to test whether they can
> use it for interesting things.
I think any real world exposure of that API will result in much larger
changes than that.
> 3. recovery_target_action = pause & hot_standby = off - Rumor has it
> we replaced one surprising behavior with a different but
> equally-surprising behavior. We should decide what the right thing is
> and make sure the code is doing that before calling it a release.
Fujii pushed the bugfix, restoring the old behaviour afaics. It's imo
still crazy, but at this point it doesn't look like a 9.5 discussion.
> 4. Arguable RLS security bug, EvalPlanQual() paranoia - This seems
> like another question of what the expectations around RLS actually
> are.
In the end that's minor from the end user's perspective.
> I would also argue that we really ought to make a decision about
> "basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe"
> before we get too close to final release. Maybe it's not a
> beta-blocker, exactly, but it doesn't seem like the sort of change
> that should be rushed in too close to the end, because it looks sorta
> complicated and scary. (Those are the technical terms.)
Yea, I'd really like to get that in at some point. I'll work on it as
soon I've finished the multixact truncation thingy.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:52 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 79+ messages in thread
From: Bruce Momjian @ 2015-06-05 15:52 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 05:36:41PM +0200, Andres Freund wrote:
> I don't think anything as localized as 'do nothing but bugfixes for a
> while and then carry on' actually will solve the problem. We need to
> find and reallocate resources to put more emphasis on review, robustness
> and refactoring in the long term, not do panick-y stuff short term. This
> isn't a problem that can be solved by focusing on bugfixing for a week
> or four.
Fine. We just need that refocus, and people usually can't refocus while
they are worried about other pressures, e.g. time --- its like trying to
adjust the GPS while driving --- not easy.
> That means we have to convince employers to actually *pay* us (people
> experienced with the codebase) to do work on these kind of things
> instead of much-easier-to-market new features. A lot of
> review/robustness work has been essentially done in our spare time,
> after long days. Which means the employers need to get more people.
Agreed --- that is a serious long-term need.
> > Sure. I think everyone agrees the multi-xact work is all good, so I am
> > asking what else needs this kind of research. If there is nothing else,
> > we can move forward again --- I am just saying we need to ask the
> > reliability question _first_.
>
> I'm starting to get grumpy here. You've called for review in lots of
> emails now. Let's get going then?
I really don't know. If people say we don't have anything like
multi-xact that we have avoided, then I have no further concerns. I am
asking that such decisions be made independent of external time
pressures.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:54 Simon Riggs <simon@2ndQuadrant.com>
parent: Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 79+ messages in thread
From: Simon Riggs @ 2015-06-05 15:54 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 5 June 2015 at 16:05, Bruce Momjian <bruce@momjian.us> wrote:
>
> Please address some of the specific issues I mentioned.
I can discuss them but not because I am involved directly. I take
responsibility as a committer and have an interest from that perspective.
In my role at 2ndQuadrant, I approved all of the time Alvaro and Andres
spent on submitting, reviewing and fixing bugs - at this point that has
cost something close to fifty thousand dollars just on this feature and
subsequent actions. (I believe the feature was originally funded, but we
never saw a penny of that, though others did.)
> The problem
> with the multi-xact case is that we just kept fixing bugs as people
> found them, and did not do a holistic review of the code.
I observed much discussion and review. The bugs we've had have all been
fairly straightforwardly fixed. There haven't been any design-level
oversights or head-palm moments. It's complex software that had complex
behaviour that caused problems. The problem has been that anything on-disk
causes more problems when errors occur. We should review carefully anything
that alters the way on-disk structures work, like the WAL changes, UPSERTs
new mechanism etc..
From my side, it is only recently I got some clear answers to my questions
about how it worked. I think it is very important that major features have
extensive README type documentation with them so the underlying principles
used in the development are clear. I would define the measure of a good
feature as whether another committer can read the code comments and get a
good feel. A bad feature is one where committers walk away from it, saying
I don't really get it and I can't read an explanation of why it does that.
Tom's most significant contribution is his long descriptive comments on
what the problem is that need to be solved, the options and the method
chosen. Clarity of thought is what solves bugs.
Overall, I don't see the need to stop the normal release process and do a
holistic review. But I do think we should check each feature to see whether
it is fully documented or whether we are simply trusting one of us to be
around to fix it.
I am just saying we need to ask the
> reliability question _first_.
>
Agreed
> Let me restate something that has appeared in many replies to my ideas
> --- I am not asking for infinite or unbounded review, but I am asking
> that we make sure reliability gets the proper focus in relation to our
> time pressures. Our balance was so off a month ago that I feel only a
> full stop on time pressure would allow us to refocus because people are
> not good at focusing on multiple things. It is sometimes necessary to
> stop everything to get people's attention, and to help them remember
> that without reliability, a database is useless.
>
Here, I think we are talking about different types of reliability.
PostgreSQL software is well ahead of most industry measures of quality;
these recent bugs have done nothing to damage that, other than a few people
woke up and said "Wow! Postgres had a bug??!?!?". The presence of bugs is
common and if we have grown unused to them, we should be wary of that,
though not tolerant.
PostgreSQL is now reliable in the sense that we have many features that
ensure availability even in the face of software problems and bug induced
corruption. Those have helped us get out of the current situations, giving
users a workaround while bugs are fixed. So the impact of database software
bugs is not what it once was.
Reliable delivery of new versions of software is important too. New
versions often contain new features that fix real world problems, just as
much as bug fixes do, hence why I don't wish to divert from the normal
process and schedule.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 15:55 Jim Nasby <Jim.Nasby@BlueTreble.com>
parent: Michael Paquier <michael.paquier@gmail.com>
1 sibling, 0 replies; 79+ messages in thread
From: Jim Nasby @ 2015-06-05 15:55 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; Craig Ringer <craig@2ndquadrant.com>; +Cc: Stephen Frost <sfrost@snowman.net>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 6/4/15 11:28 PM, Michael Paquier wrote:
<list of things to test>
* More configuration variations; ./configure, initdb options, and *.conf
* More edge-case testing. (ie: what happens to each varlena as it
approaches 1GB? 1B tables test. Etc.)
* More race-condition testing, like the tool Peter used heavily during
ON CONFLICT development (written by Jeff Janes?)
* More non-SQL testing. For example, the logic in HeapTupleSatisfies* is
quite complicated yet there's no tests dedicated to ensuring the logic
is correct because it'd be extremely difficult (if not impossible) to
construct those tests at a SQL level. Testing them with direct test
calls to HeapTupleSatisfies* wouldn't be difficult, but we have no
machinery to do C level testing.
>> Is pg_tap a reasonable starting point for this sort of testing?
> IMO, using the TAP machinery would be a good base for that. What lacks
> is a basic set of perl routines that one can easily use to set of test
> scenarios.
I think Stephen was referring specifically to pgTap (http://pgtap.org/).
Isn't our TAP framework just different output from pg_regress? Is there
documentation on our TAP stuff?
>> >How would a test that would've caught the multixact issues look?
> I have not followed closely those discussions, not sure about that.
I've thought about this and unfortunately I think this may be a scenario
that's just too complex to completely protect against with a test. What
might help though is having better testing of edge cases (such as MXID
wrap) and then combining that with other forms of testing, such as
pg_upgrade and streaming rep. testing. Test things like "What happens if
we pg_upgrade a cluster that's in danger of wraparound?"
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 16:06 Jim Nasby <Jim.Nasby@BlueTreble.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 79+ messages in thread
From: Jim Nasby @ 2015-06-05 16:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 6/5/15 10:39 AM, Tom Lane wrote:
> The other side of that coin is that we might get useful comments from
> testers on how the feature ought to work. I don't agree with the notion
> that all feature details must be graven on stone tablets before we start
> trying to get feedback from people outside the core development community.
+1
> The same point applies to the FDW C API questions, or to RLS, or to the
> "expanded objects" work that I did. (I'd really love it if the PostGIS
> folk would try to use that sometime before it's too late to adjust the
> definition...) Now, you could argue that people likely to have useful
> input on those issues are fully capable of working with git tip, and you'd
> probably be right, but would they do so? As Simon says nearby, publishing
> an alpha/beta/whatever is our signal to the wider community that it's time
> for them to start paying attention. I do not think they will look at 9.5
> until we do that; and I think it'll be our loss if they don't start
> looking at these things soon.
+1, but I also think we should have a better mechanism for soliciting
user input on these things while design discussions are happening. ISTM
that there's a lot of hand-waving that happens around use cases that
could probably be clarified with end user input.
FWIW, I don't think the blocker here is git or building from source. If
someone has that amount of time to invest it's not much different than
grabbing a tarball.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 16:20 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 1 reply; 79+ messages in thread
From: Alvaro Herrera @ 2015-06-05 16:20 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Simon Riggs wrote:
> On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com> wrote:
> > Stamping it a beta implies that we think it's something fairly
> > stable that we'd be pretty happy to release if things go well, which
> > is a higher bar to clear.
>
> We don't have a clear definition of what Beta means. For me, Beta has
> always meant "trial software, please test".
I think that definition *is* the problem, actually. To me, "beta" means
"trial software, please test, but final product will be very similar to
what you see here". What we need to convey at this point is what you
said, but I think a better word for that is "alpha". There may be more
mobility in there than in a beta, in users's perception, which is the
right impression we want to convey.
Another point is that historically, once we've released a beta, we're
pretty reluctant to bump catversion. We're not ready for that at this
stage, which is one criteria that suggests to me that we're not ready
for beta.
So I think the right thing to do at this point is to get an alpha out,
shortly after releasing upcoming minors.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 16:56 Robert Haas <robertmhaas@gmail.com>
parent: Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 1 reply; 79+ messages in thread
From: Robert Haas @ 2015-06-05 16:56 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 11:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> We don't have a clear definition of what Beta means. For me, Beta has always
> meant "trial software, please test".
>
> I don't think anybody will say anything bad about us if we release a beta
> and then later pull some of the features because we are not confident with
> them when AFTER testing the feature is shown to be below our normal
> standard; that will bring us credit, I feel. It is extremely common in
> software development to defer some of the features if their goals aren't
> met, or to change APIs and interfaces based upon user feedback.
Yeah, but we usually haven't. Tom, for example, has previously not
wanted to even bump catversion after beta1, which rules out a huge
variety of possible fixes and interface changes. If we want to make a
policy decision to change our approach, we should be up-front about
that.
> None of this means I disagree with assessments of the current state of the
> software, I'm saying that we should simply follow the normal process and
> stick to the schedule we have previously agreed, for all of the reasons
> cited when we agreed it.
Well, to my way of looking at it, our feature freeze was later this
year than it has been in the past, so our beta will be later, too. If
we want to stick with the schedule, we have to do that throughout.
Our typical schedule has been a two-month final CommitFest starting on
January 15th. This year we had a three month final CommitFest
starting on February 15th. So we finished the last CommitFest two
months later than has been typical.
Typically our beta has been in early May, 1-2 months after the end of
the last CommitFest. If you add the same two months to that, you get
early July, which sounds reasonable, rather than early June, which
sounds rushed, especially since we have an urgent need to get minor
releases out the door to fix critical stability bugs right now, and
then we have PGCon, during which nobody's going to be looking at
anything.
It sounds to me like the original plan was to put out a beta in early
June, which would have been fine if we'd stuck to the traditional
2-month final CommitFest. But we didn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 18:39 Josh Berkus <josh@agliodbs.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 79+ messages in thread
From: Josh Berkus @ 2015-06-05 18:39 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 06/05/2015 07:23 AM, Tom Lane wrote:
> So let's call it an alpha, or some other way of setting expectations
> appropriately. But I think it's silly to maintain that the code is not in
> a state where end-user testing is useful. They just have to understand
> that they can't trust it with production data.
Yes ... that seems like a good compromise.
Frankly, I'm testing 9.5 already; having alpha packages would make that
testing easier for me, and maybe possible for others.
We'd need to take into account that our packagers are a bit overworked
this month due to update releases ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 18:57 Peter Geoghegan <pg@heroku.com>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 79+ messages in thread
From: Peter Geoghegan @ 2015-06-05 18:57 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 8:51 AM, Andres Freund <andres@anarazel.de> wrote:
>> 4. Arguable RLS security bug, EvalPlanQual() paranoia - This seems
>> like another question of what the expectations around RLS actually
>> are.
>
> In the end that's minor from the end user's perspective.
I think that depends on what we ultimately decide to do about it,
which is something that I have yet to form an opinion on (although I
know we need to document the issue, at the very least). For example,
one idea that Stephen and I discussed privately was making security
barrier quals referencing other relations lock the referenced rows.
This was an informal throwing around of ideas, but it's possible that
something like that could end up happening.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-05 21:08 Peter Geoghegan <pg@heroku.com>
parent: Robert Haas <robertmhaas@gmail.com>
3 siblings, 0 replies; 79+ messages in thread
From: Peter Geoghegan @ 2015-06-05 21:08 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 7:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I do agree that an indefinite development freeze with unclear
> parameters for resuming development and unclear goals is a bad plan.
> But I think giving ourselves a little more time to, say, turn the
> buildfarm consistently green, and, say, fix the known but
> currently-unfixed multixact bugs, and, say, fix the known bugs in 9.5
> features is a good plan, and I hope you and others will support it.
FWIW, I have 3 pending bug fixes for UPSERT. While those are pretty
benign issues, I'd be annoyed if they didn't get into the first 9.5
beta (or alpha, even).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 03:07 Bruce Momjian <bruce@momjian.us>
parent: Simon Riggs <simon@2ndQuadrant.com>
0 siblings, 1 reply; 79+ messages in thread
From: Bruce Momjian @ 2015-06-06 03:07 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 5, 2015 at 04:54:56PM +0100, Simon Riggs wrote:
> On 5 June 2015 at 16:05, Bruce Momjian <bruce@momjian.us> wrote:
>
>
> Please address some of the specific issues I mentioned.
>
>
> I can discuss them but not because I am involved directly. I take
> responsibility as a committer and have an interest from that perspective.
>
> In my role at 2ndQuadrant, I approved all of the time Alvaro and Andres spent
> on submitting, reviewing and fixing bugs - at this point that has cost
> something close to fifty thousand dollars just on this feature and subsequent
> actions. (I believe the feature was originally funded, but we never saw a penny
> of that, though others did.)
Yes, the burden has fallen heavily on Alvaro. I personally am concerned
that many people were focusing on 9.5 rather than helping him. I think
that was a mistake on our part and we need to take reliability problems
more seriously.
What has also concerned me is that there are so many 9.3/9.4 bugs in
this area that few of us can even understand what was fixed when, and we
are then having problems figuring out what bugs were present when
analyzing bug reports. pg_upgrade has made this worse by allowing
multi-xact bugs to propagate across major versions, and pg_upgrade had
some multi-xact bugs of its own in early 9.3 releases. :-(
> The problem
> with the multi-xact case is that we just kept fixing bugs as people
> found them, and did not do a holistic review of the code.
>
>
> I observed much discussion and review. The bugs we've had have all been fairly
> straightforwardly fixed. There haven't been any design-level oversights or
> head-palm moments. It's complex software that had complex behaviour that caused
> problems. The problem has been that anything on-disk causes more problems when
> errors occur. We should review carefully anything that alters the way on-disk
> structures work, like the WAL changes, UPSERTs new mechanism etc..
Agreed. However, I think a thorough review early on could have caught
many of these bugs before they were reported by users. As proof, even
in the past few weeks, review is finding bugs before they are found by
users.
> From my side, it is only recently I got some clear answers to my questions
> about how it worked. I think it is very important that major features have
> extensive README type documentation with them so the underlying principles used
> in the development are clear. I would define the measure of a good feature as
> whether another committer can read the code comments and get a good feel. A bad
> feature is one where committers walk away from it, saying I don't really get it
> and I can't read an explanation of why it does that. Tom's most significant
> contribution is his long descriptive comments on what the problem is that need
> to be solved, the options and the method chosen. Clarity of thought is what
> solves bugs.
Yes, I think we should have done that early-on for multi-xact, and I am
hopeful we will learn to do that more often when complex features are
implemented, or when we identify areas that are more complex than we
thought.
> Overall, I don't see the need to stop the normal release process and do a
> holistic review. But I do think we should check each feature to see whether it
> is fully documented or whether we are simply trusting one of us to be around to
> fix it.
Agreed. We just need to be honest that we are doing what we need for
reliability and not allow schedule and feature pressure to cause us to
skimp in this area.
> I am just saying we need to ask the
> reliability question _first_.
>
>
> Agreed
>
>
> Let me restate something that has appeared in many replies to my ideas
> --- I am not asking for infinite or unbounded review, but I am asking
> that we make sure reliability gets the proper focus in relation to our
> time pressures. Our balance was so off a month ago that I feel only a
> full stop on time pressure would allow us to refocus because people are
> not good at focusing on multiple things. It is sometimes necessary to
> stop everything to get people's attention, and to help them remember
> that without reliability, a database is useless.
>
>
> Here, I think we are talking about different types of reliability. PostgreSQL
> software is well ahead of most industry measures of quality; these recent bugs
> have done nothing to damage that, other than a few people woke up and said
> "Wow! Postgres had a bug??!?!?". The presence of bugs is common and if we have
> grown unused to them, we should be wary of that, though not tolerant.
In going over the 9.5 commits, I was struck by a high volume of cleanups
and fixes, which is good.
> PostgreSQL is now reliable in the sense that we have many features that ensure
> availability even in the face of software problems and bug induced corruption.
> Those have helped us get out of the current situations, giving users a
> workaround while bugs are fixed. So the impact of database software bugs is not
> what it once was.
Uh, yes, we have avoided the worst of the impact from these bugs. In my
understanding, each bug has X% chance of being serious, and you might go
for a long time before a serious bug is created, but the more bugs we
have, the more likely that one will serious. The _volume_ of multi-xact
bugs should have triggered a review much sooner.
People think I want to stop feature development to review. What I am
saying is that we need to stop development so we can be honest about
whether we need review, and where. It is hard to be honest when time
and feature pressure are on you. It shouldn't take long to make that
decision as a group.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 05:43 Michael Paquier <michael.paquier@gmail.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 0 replies; 79+ messages in thread
From: Michael Paquier @ 2015-06-06 05:43 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Craig Ringer <craig@2ndquadrant.com>; Stephen Frost <sfrost@snowman.net>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sat, Jun 6, 2015 at 12:05 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
> What happened with the extension tests patches you submitted? They
> seemed valuable to me, but I lost track.
Those ones are registered in the queue of 9.6:
https://commitfest.postgresql.org/5/187/
And this is the latest patch:
http://www.postgresql.org/message-id/CAB7nPqSQr1UjZ1h8=be1wBq3mMdmM38nrjBKvBJuM--tTTY=EA@mail.gmail....
This patch extends prove_check by giving the possibility for a given
utility using t/ to add extra modules in t/extra that will be
installed and usable for its regression tests. This becomes more
interesting considering as well that pg_upgrade could be switched to
use the TAP infrastructure, where we could have modules dedicated to
only the tests of pg_upgrade (supporting TAP tests on Windows is a
necessary condition though before switching pg_upgrade).
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 09:07 Simon Riggs <simon@2ndQuadrant.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 2 replies; 79+ messages in thread
From: Simon Riggs @ 2015-06-06 09:07 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 5 June 2015 at 17:20, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Simon Riggs wrote:
> > On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com> wrote:
>
> > > Stamping it a beta implies that we think it's something fairly
> > > stable that we'd be pretty happy to release if things go well, which
> > > is a higher bar to clear.
> >
> > We don't have a clear definition of what Beta means. For me, Beta has
> > always meant "trial software, please test".
>
> I think that definition *is* the problem, actually. To me, "beta" means
> "trial software, please test, but final product will be very similar to
> what you see here". What we need to convey at this point is what you
> said, but I think a better word for that is "alpha". There may be more
> mobility in there than in a beta, in users's perception, which is the
> right impression we want to convey.
>
> Another point is that historically, once we've released a beta, we're
> pretty reluctant to bump catversion. We're not ready for that at this
> stage, which is one criteria that suggests to me that we're not ready
> for beta.
>
> So I think the right thing to do at this point is to get an alpha out,
> shortly after releasing upcoming minors.
>
OK, I can get behind that.
My only additional point is that it is a good idea to release an Alpha
every time, not just this release.
And if its called Alpha, lets release it immediately. We can allow Alpha1,
Alpha2 as needed, plus we allow catversion and file format changes between
Alpha versions.
Proposed definitions
Alpha: This is trial software please actively test and report bugs. Your
feedback is sought on usability and performance, which may result in
changes to the features included here. Not all known issues have been
resolved but work continues on resolving them. Multiple Alpha versions may
be released before we move to Beta. We reserve the right to change internal
API definitions, file formats and increment the catalog version between
Alpha versions and Beta, so we do not guarantee and easy upgrade path from
this version to later versions of this release.
Beta: This is trial software please actively test and report bugs and
performance issues. Multiple Beta versions may be released before we move
to Release Candidate. We will attempt to maintain APIs, file formats and
catversions.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 10:13 Gavin Flower <GavinFlower@archidevsys.co.nz>
parent: Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 0 replies; 79+ messages in thread
From: Gavin Flower @ 2015-06-06 10:13 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 06/06/15 21:07, Simon Riggs wrote:
> On 5 June 2015 at 17:20, Alvaro Herrera <alvherre@2ndquadrant.com
> <mailto:alvherre@2ndquadrant.com>> wrote:
>
> Simon Riggs wrote:
> > On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
> > > Stamping it a beta implies that we think it's something fairly
> > > stable that we'd be pretty happy to release if things go well,
> which
> > > is a higher bar to clear.
> >
> > We don't have a clear definition of what Beta means. For me,
> Beta has
> > always meant "trial software, please test".
>
> I think that definition *is* the problem, actually. To me, "beta"
> means
> "trial software, please test, but final product will be very
> similar to
> what you see here". What we need to convey at this point is what you
> said, but I think a better word for that is "alpha". There may be more
> mobility in there than in a beta, in users's perception, which is the
> right impression we want to convey.
>
> Another point is that historically, once we've released a beta, we're
> pretty reluctant to bump catversion. We're not ready for that at this
> stage, which is one criteria that suggests to me that we're not ready
> for beta.
>
> So I think the right thing to do at this point is to get an alpha out,
> shortly after releasing upcoming minors.
>
>
> OK, I can get behind that.
>
> My only additional point is that it is a good idea to release an Alpha
> every time, not just this release.
>
> And if its called Alpha, lets release it immediately. We can allow
> Alpha1, Alpha2 as needed, plus we allow catversion and file format
> changes between Alpha versions.
>
> Proposed definitions
>
> Alpha: This is trial software please actively test and report bugs.
> Your feedback is sought on usability and performance, which may result
> in changes to the features included here. Not all known issues have
> been resolved but work continues on resolving them. Multiple Alpha
> versions may be released before we move to Beta. We reserve the right
> to change internal API definitions, file formats and increment the
> catalog version between Alpha versions and Beta, so we do not
> guarantee and easy upgrade path from this version to later versions of
> this release.
>
> Beta: This is trial software please actively test and report bugs and
> performance issues. Multiple Beta versions may be released before we
> move to Release Candidate. We will attempt to maintain APIs, file
> formats and catversions.
>
> --
> Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/;
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
As a 'user' I am very happy with the idea of having Alpha's, gives me a
feeling that there will be less chance of problems being released in the
final version.
Because not only does it give more chances to test, but might encourage
more people to get involved in contributing, either ideas for minor
tweaks or simple patches etc. (as being not quite finished, and an
expectation that minor functional changes have a possibility of being
accepted for the version, if there is sufficient merit).
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 10:15 Magnus Hagander <magnus@hagander.net>
parent: Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 1 reply; 79+ messages in thread
From: Magnus Hagander @ 2015-06-06 10:15 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sat, Jun 6, 2015 at 11:07 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 5 June 2015 at 17:20, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
>> Simon Riggs wrote:
>> > On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> > > Stamping it a beta implies that we think it's something fairly
>> > > stable that we'd be pretty happy to release if things go well, which
>> > > is a higher bar to clear.
>> >
>> > We don't have a clear definition of what Beta means. For me, Beta has
>> > always meant "trial software, please test".
>>
>> I think that definition *is* the problem, actually. To me, "beta" means
>> "trial software, please test, but final product will be very similar to
>> what you see here". What we need to convey at this point is what you
>> said, but I think a better word for that is "alpha". There may be more
>> mobility in there than in a beta, in users's perception, which is the
>> right impression we want to convey.
>>
>> Another point is that historically, once we've released a beta, we're
>> pretty reluctant to bump catversion. We're not ready for that at this
>> stage, which is one criteria that suggests to me that we're not ready
>> for beta.
>>
>> So I think the right thing to do at this point is to get an alpha out,
>> shortly after releasing upcoming minors.
>>
>
> OK, I can get behind that.
>
> My only additional point is that it is a good idea to release an Alpha
> every time, not just this release.
>
> And if its called Alpha, lets release it immediately. We can allow Alpha1,
> Alpha2 as needed, plus we allow catversion and file format changes between
> Alpha versions.
>
If I'm not mistaken, we (Simon and me) actually discussed something else
along this line a while ago that might be worth considering. That is, maybe
we should consider time-based alpha releases. That is, we can just decide
"we wrap an alpha every other Monday until we think we are good to go with
beta". The reason for that is to get much quicker iteration on bugfixes,
which would encourage people to use and test these versions. Report a bug
and if it was easy enough to fix, you have a wrapped release with the fix
in 2 weeks top.
This would require that we can (at least mostly) automate the wrapping of
an alpha release, but I'm pretty sure we can solve that problem. We can
also, I think, get a way with doing the release notes for an alpha just as
a wiki page and a lot less formal than others, meaning we don't need to
hold up any process for that.
Package availability would depend on platform. For those platforms where
package building is more or less entirely automatic already, this could
probably also be easily automated. And for those that take a lot more work,
such as the Windows installers, we could just go with wrapping every other
or every third alpha. As this is not a production release, I don't see why
we'd need to hold some back to cover for the rest.
>
> Proposed definitions
>
> Alpha: This is trial software please actively test and report bugs. Your
> feedback is sought on usability and performance, which may result in
> changes to the features included here. Not all known issues have been
> resolved but work continues on resolving them. Multiple Alpha versions may
> be released before we move to Beta. We reserve the right to change internal
> API definitions, file formats and increment the catalog version between
> Alpha versions and Beta, so we do not guarantee and easy upgrade path from
> this version to later versions of this release.
>
> Beta: This is trial software please actively test and report bugs and
> performance issues. Multiple Beta versions may be released before we move
> to Release Candidate. We will attempt to maintain APIs, file formats and
> catversions.
>
>
These sound like good definitions. Might add to the beta one something like
"whilst we will try to avoid it, pg_upgrade may be required between betas
and from beta to rc versions".
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 10:27 Devrim GÜNDÜZ <devrim@gunduz.org>
parent: Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 79+ messages in thread
From: Devrim GÜNDÜZ @ 2015-06-06 10:27 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Alvaro Herrera <alvherre@2ndquadrant.com>; Robert Haas <robertmhaas@gmail.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Hi,
On Sat, 2015-06-06 at 12:15 +0200, Magnus Hagander wrote:
> If I'm not mistaken, we (Simon and me) actually discussed something
> else along this line a while ago that might be worth considering. That
> is, maybe we should consider time-based alpha releases. That is, we
> can just decide "we wrap an alpha every other Monday until we think we
> are good to go with beta". The reason for that is to get much quicker
> iteration on bugfixes, which would encourage people to use and test
> these versions. Report a bug and if it was easy enough to fix, you
> have a wrapped release with the fix in 2 weeks top.
+1.
> Package availability would depend on platform. For those platforms
> where package building is more or less entirely automatic already,
> this could probably also be easily automated.
When we used to release more alphas years ago, I was releasing Alpha
RPMs for many platforms. I'll do it again if we keep doing it.
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 10:47 Geoff Winkless <pgsqladmin@geoff.dj>
parent: Devrim GÜNDÜZ <devrim@gunduz.org>
0 siblings, 2 replies; 79+ messages in thread
From: Geoff Winkless @ 2015-06-06 10:47 UTC (permalink / raw)
To: pgsql-hackers
>
>
>
To play devil's advocate for a moment, is there anyone who would genuinely
be prepared to download and install an alpha release who would not already
have downloaded one of the nightlies? I only ask because I assume that
releasing
an alpha is not zero-developer-cost and I don't believe
that
there's a large
number of people who *would *be happy to install something that's described
as being buggy and subject to change but are put off by having to type
"configure" and "make".
Further, it seems to me that the number of people who won't roll their own
who are useful as bug-finders is even smaller.
I get the feeling that the argument appears to be "Bruce doesn't want to
release a beta, Simon wants to release something. Let's release an alpha
because it's sort-of half way in between" as a consensus compromise (I'm
not deliberately picking on specific people, I'm aware you're not the only
two involved and arguing for either side, but you do seem to be fairly
polar opposite sides of the argument :) ); I don't really believe that
releasing an alpha moves anything further forward from a testing point of
view, and I'm fairly sure that it will have just as dele
terious effect on bugfixing as would a beta
, with the added disadvantage of the extra developer cost.
Geoff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 12:41 Sehrope Sarkuni <sehrope@jackdb.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
1 sibling, 1 reply; 79+ messages in thread
From: Sehrope Sarkuni @ 2015-06-06 12:41 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Sat, Jun 6, 2015 at 6:47 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> To play devil's advocate for a moment, is there anyone who would genuinely be prepared to download
> and install an alpha release who would not already have downloaded one of the nightlies? I only ask
> because I assume that releasing an alpha is not zero-developer-cost and I don't believe that
> there's a large number of people who would be happy to install something that's described as being
> buggy and subject to change but are put off by having to type "configure" and "make".
I fit into that category and I would guess there would be others as
well. Having system packages available via an "apt-get install ..."
lowers the bar significantly to try things out.
As an example, I installed the 9.4 beta as soon as it was available to
run a smoke test and try out some of the new jsonb features. I'll be
doing the same with a 9.5 alpha/beta (or whatever it's called), for
both similar testing and to try out UPSERT.
It's much easier to work into dev/test setups if there are system
packages as it's just a config change to an existing script. Building
from source would require a whole new workflow that I don't have time
to incorporate.
> Further, it seems to me that the number of people who won't roll their own who are useful as bug-finders is even smaller.
That's probably true but they definitely won't find any bugs if they
don't test at all.
If it's possible to have automated packaging, even for just a subset
of platforms, I think that'd be useful.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 14:33 Robert Haas <robertmhaas@gmail.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
1 sibling, 1 reply; 79+ messages in thread
From: Robert Haas @ 2015-06-06 14:33 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Sat, Jun 6, 2015 at 6:47 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> To play devil's advocate for a moment, is there anyone who would genuinely
> be prepared to download and install an alpha release who would not already
> have downloaded one of the nightlies? I only ask because I assume that
> releasing
> an alpha is not zero-developer-cost and I don't believe
> that
> there's a large
> number of people who would be happy to install something that's described as
> being buggy and subject to change but are put off by having to type
> "configure" and "make".
This is pretty much why Peter Eisentraut gave up on doing alphas after
the 9.1 cycle.
Admittedly, what is being proposed here is somewhat different.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 14:35 Geoff Winkless <pgsqladmin@geoff.dj>
parent: Sehrope Sarkuni <sehrope@jackdb.com>
0 siblings, 2 replies; 79+ messages in thread
From: Geoff Winkless @ 2015-06-06 14:35 UTC (permalink / raw)
To: pgsql-hackers
On 6 June 2015 at 13:41, Sehrope Sarkuni <sehrope@jackdb.com> wrote:
> On Sat, Jun 6, 2015 at 6:47 AM, Geoff Winkless <pgsqladmin@geoff.dj>
> wrote:
> > To play devil's advocate for a moment, is there anyone who would
> genuinely be prepared to download
> > and install an alpha release who would not already have downloaded one
> of the nightlies? I only ask
> > because I assume that releasing an alpha is not zero-developer-cost and
> I don't believe that
> > there's a large number of people who would be happy to install something
> that's described as being
> > buggy and subject to change but are put off by having to type
> "configure" and "make".
>
> I fit into that category and I would guess there would be others as
> well. Having system packages available via an "apt-get install ..."
> lowers the bar significantly to try things out.
But it also lowers the bar to the extent that you get the people who won't
read the todo list and end up complaining about the things that everyone
already knows about.
> It's much easier to work into dev/test setups if there are system
> packages as it's just a config change to an existing script. Building
> from source would require a whole new workflow that I don't have time
> to incorporate.
>
Really? You genuinely don't have time to paste, say:
mkdir -p ~/src/pgdevel
cd ~/src/pgdevel
wget https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2
tar xjf postgresql-snapshot.tar.bz2
mkdir bld
cd bld
../postgresql-9.5devel/configure $(pg_config --configure | sed -e
's/\(pg\|postgresql[-\/]\)\(doc-\)\?9\.[0-9]*\(dev\)\?/\1\29.5dev/g')
make wor
ld
make check
make world-install
and yet you think you have enough time to provide more than a "looks like
it's working" report to the developers?
(NB the sed for the pg_config line will probably need work, it looks like
it should work on the two types of system I have here but I have to admit I
changed the config line manually when I built it)
> > Further, it seems to me that the number of people who won't roll their
> own who are useful as bug-finders is even smaller.
>
> That's probably true but they definitely won't find any bugs if they
> don't test at all.
>
> If it's possible to have automated packaging, even for just a subset
> of platforms, I think that'd be useful.
>
Well yes, automated packaging of the nightly build, that doesn't involve
the developers having to stop what they're doing to write official alpha
release docs or any of the other stuff that goes along with doing a
release, would be zero-impact on development (assuming the developers
didn't have to build or maintain the auto-packager) and therefore any
return (however small) would make it worthwhile.
Fancy building (and maintaining) the auto-packaging system, and managing a
mailing list for its users?
Geoff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 15:58 Sehrope Sarkuni <sehrope@jackdb.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
1 sibling, 0 replies; 79+ messages in thread
From: Sehrope Sarkuni @ 2015-06-06 15:58 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Sat, Jun 6, 2015 at 10:35 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> Really? You genuinely don't have time to paste, say:
>
> mkdir -p ~/src/pgdevel
> cd ~/src/pgdevel
> wget https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2
> tar xjf postgresql-snapshot.tar.bz2
> mkdir bld
> cd bld
> ../postgresql-9.5devel/configure $(pg_config --configure | sed -e 's/\(pg\|postgresql[-> \/]\)\(doc-\)\?9\.[0-9]*\(dev\)\?/\1\29.5dev/g')
> make world
> make check
> make world-install
>
> and yet you think you have enough time to provide more than a "looks like it's working" report to the developers?
Adding steps to an existing process to fetch and build from source is
significantly more complicated then flipping a version number. And I'm
not trying to run PG's built in tests on my machine. I want to run the
tests for my applications, and ideally, my applications themselves.
If doing so leads me to find that something doesn't work then of
course I would research and report the cause. At that point it's
something that I know will directly effect me if it's not fixed!
> Well yes, automated packaging of the nightly build, that doesn't involve the developers having to stop what they're doing to write official alpha release docs or any of the other stuff that goes along with doing a release, would be zero-impact on development (assuming the developers didn't have to build or maintain the auto-packager) and therefore any return (however small) would make it worthwhile.
> Fancy building (and maintaining) the auto-packaging system, and managing a mailing list for its users?
I don't have much experience in setting things like this up so I'm not
one to estimate the work load involved. If it existed though, I'd use
it.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 16:33 Kevin Grittner <kgrittn@ymail.com>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 79+ messages in thread
From: Kevin Grittner @ 2015-06-06 16:33 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; Simon Riggs <simon@2ndquadrant.com>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Robert Haas <robertmhaas@gmail.com> wrote:
> Tom, for example, has previously not wanted to even bump
> catversion after beta1, which rules out a huge variety of
> possible fixes and interface changes. If we want to make a
> policy decision to change our approach, we should be up-front
> about that.
What?!? There have been catversion bumps between the REL?_?_BETA1
tag and the REL?_?_0 tag for 8.2, 8.3, 9.0, 9.1, 9.3, and 9.4.
(That is, it has happend on 6 of the last 8 releases.) I don't
think we're talking about any policy change here. We try to avoid
a catversion bump after beta if we can; we're not that reluctant to
do so if needed.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 16:55 Joshua D. Drake <jd@commandprompt.com>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 79+ messages in thread
From: Joshua D. Drake @ 2015-06-06 16:55 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; Simon Riggs <simon@2ndQuadrant.com>; +Cc: Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 06/05/2015 08:07 PM, Bruce Momjian wrote:
>> From my side, it is only recently I got some clear answers to my questions
>> about how it worked. I think it is very important that major features have
>> extensive README type documentation with them so the underlying principles used
>> in the development are clear. I would define the measure of a good feature as
>> whether another committer can read the code comments and get a good feel. A bad
>> feature is one where committers walk away from it, saying I don't really get it
>> and I can't read an explanation of why it does that. Tom's most significant
>> contribution is his long descriptive comments on what the problem is that need
>> to be solved, the options and the method chosen. Clarity of thought is what
>> solves bugs.
>
> Yes, I think we should have done that early-on for multi-xact, and I am
> hopeful we will learn to do that more often when complex features are
> implemented, or when we identify areas that are more complex than we
> thought.
>
I see this idea of the README as very useful. There are far more people
like me in this community than Simon or Alvaro. I can test, I can break
things, I can script up a harness but I need to be understand HOW and
the README would help allow for that.
>
> People think I want to stop feature development to review. What I am
> saying is that we need to stop development so we can be honest about
> whether we need review, and where. It is hard to be honest when time
> and feature pressure are on you. It shouldn't take long to make that
> decision as a group.
>
Right. This is all about taking a step back, a deep breath, an objective
look and then digging in with a more productive and reliable manner.
Sincerely,
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-06 17:02 Joshua D. Drake <jd@commandprompt.com>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 0 replies; 79+ messages in thread
From: Joshua D. Drake @ 2015-06-06 17:02 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On 06/06/2015 07:33 AM, Robert Haas wrote:
>
> On Sat, Jun 6, 2015 at 6:47 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
>> To play devil's advocate for a moment, is there anyone who would genuinely
>> be prepared to download and install an alpha release who would not already
>> have downloaded one of the nightlies? I only ask because I assume that
>> releasing
>> an alpha is not zero-developer-cost and I don't believe
>> that
>> there's a large
>> number of people who would be happy to install something that's described as
>> being buggy and subject to change but are put off by having to type
>> "configure" and "make".
Yes, me and everyone like me in feature set.
Compiling takes time, time that does not need to be spent. If I can push
an alpha into a container and start testing, I will do so. If I have to:
git pull; configure --prefix; make -j8 install
Then I will likely move on to other things because my time (nor is any
other's on this list) is not free.
If you add into this a test harness that I can execute from the alpha
release (or another package) that allows me to instant report via
buildfarm or just email a tarball to -hackers that is even better.
I know that I am not taking everything into account here but remember
that most of our users are not -hackers. They are practitioners and a
lot of them would love to help but just can't because a lot of the
infrastructure has never been built and -hackers think like -hackers.
Sincerely,
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-06 19:58 Noah Misch <noah@leadboat.com>
parent: Simon Riggs <simon@2ndQuadrant.com>
0 siblings, 4 replies; 79+ messages in thread
From: Noah Misch @ 2015-06-06 19:58 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Fri, Jun 05, 2015 at 08:25:34AM +0100, Simon Riggs wrote:
> This whole idea of "feature development" vs reliability is bogus. It
> implies people that work on features don't care about reliability. Given
> the fact that many of the features are actually about increasing database
> reliability in the event of crashes and corruptions it just makes no sense.
I'm contrasting work that helps to keep our existing promises ("reliability")
with work that makes new promises ("features"). In software development, we
invariably hazard old promises to make new promises; our success hinges on
electing neither too little nor too much risk. Two years ago, PostgreSQL's
track record had placed it in a good position to invest in new, high-risk,
high-reward promises. We did that, and we emerged solvent yet carrying an
elevated debt service ratio. It's time to reduce risk somewhat.
You write about a different sense of "reliability." (Had I anticipated this
misunderstanding, I might have written "Restore-probity mode.") None of this
was about classifying people, most of whom allocate substantial time to each
kind of work.
> How will we participate in cleanup efforts? How do we know when something
> has been "cleaned up", how will we measure our success or failure? I think
> we should be clear that wasting N months on cleanup can *fail* to achieve a
> useful objective. Without a clear plan it almost certainly will do so. The
> flip side is that wasting N months will cause great amusement and dancing
> amongst those people who wish to pull ahead of our open source project and
> we should take care not to hand them a victory from an overreaction.
I agree with all that. We should likewise take care not to become insolvent
from an underreaction.
> So lets do our normal things, not do a "total stop" for an indefinite
> period. If someone has specific things that in their opinion need to be
> addressed, list them and we can talk about doing them, together.
I recommend these four exit criteria:
1. Non-author committer review of foreign keys locks/multixact durability.
Done when that committer certifies, as if he were committing the patch
himself today, that the code will not eat data.
2. Non-author committer review of row-level security. Done when that
committer certifies that the code keeps its promises and that the
documentation bounds those promises accurately.
3. Second committer review of the src/backend/access changes for INSERT ... ON
CONFLICT DO NOTHING/UPDATE. (Bugs affecting folks who don't use the new
syntax are most likely to fall in that portion.) Unlike the previous two
criteria, a review without certification is sufficient.
4. Non-author committer certifying that the 9.5 WAL format changes will not
eat your data. The patch lists Andres and Alvaro as reviewers; if they
already reviewed it enough to make that certification, this one is easy.
That ties up four people. For everyone else:
- Fix bugs those reviews find. This will start slow but will grow to keep
everyone busy. Committers won't certify code, and thus we can't declare
victory, until these bugs are fixed. The rest of this list, in contrast,
calls out topics to sample from, not topics to exhaust.
- Turn current buildfarm members green.
- Write, review and commit more automated test machinery to PostgreSQL. Test
whatever excites you. If you need ideas, Craig posted some good ones
upthread. Here are a few more:
- Add a debug mode that calls sched_yield() in SpinLockRelease(); see
6322.1406219591@sss.pgh.pa.us.
- Improve TAP suite (src/test/perl/TestLib.pm) logging. Currently, these
suites redirect much output to /dev/null. Instead, log that output and
teach the buildfarm to capture the log.
- Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local pin
count falls to zero. Under CLOBBER_FREED_MEMORY, wipe a shared buffer
when its global pin count falls to zero.
- With assertions enabled, or perhaps in a new debug mode, have
pg_do_encoding_conversion() and pg_server_to_any() check the data for a
no-op conversion instead of assuming the data is valid.
- Add buildfarm members. This entails reporting any bugs that prevent an
initial passing run. Once you have a passing run, schedule regular runs.
Examples of useful additions:
- "./configure ac_cv_func_getopt_long=no, ac_cv_func_snprintf=no ..." to
enable all the replacement code regardless of the current platform's need
for it. This helps distinguish "Windows bug" from "replacement code bug."
- --disable-integer-datetimes, --disable-float8-byval, disable-float4-byval,
--disable-spinlocks, --disable-atomics, disable-thread-safety,
--disable-largefile, #define RANDOMIZE_ALLOCATED_MEMORY
- Any OS or CPU architecture other than x86 GNU/Linux, even ones already
represented.
- Write, review and commit fixes for the bugs that come to light by way of
these new automated tests.
- Anything else targeted to make PostgreSQL keep the promises it has already
made to our users.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-06 20:29 Michael Paquier <michael.paquier@gmail.com>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 0 replies; 79+ messages in thread
From: Michael Paquier @ 2015-06-06 20:29 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sun, Jun 7, 2015 at 4:58 AM, Noah Misch <noah@leadboat.com> wrote:
> - Write, review and commit more automated test machinery to PostgreSQL. Test
> whatever excites you. If you need ideas, Craig posted some good ones
> upthread. Here are a few more:
> - Improve TAP suite (src/test/perl/TestLib.pm) logging. Currently, these
> suites redirect much output to /dev/null. Instead, log that output and
> teach the buildfarm to capture the log.
We can capture the logs and redirect them by replacing
system_or_bail() with more calls to IPC::run. That would be a patch
simple enough. pg_rewind's tests should be switched to use that as
well.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-07 02:07 Robert Haas <robertmhaas@gmail.com>
parent: Kevin Grittner <kgrittn@ymail.com>
0 siblings, 1 reply; 79+ messages in thread
From: Robert Haas @ 2015-06-07 02:07 UTC (permalink / raw)
To: Kevin Grittner <kgrittn@ymail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sat, Jun 6, 2015 at 12:33 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> Tom, for example, has previously not wanted to even bump
>> catversion after beta1, which rules out a huge variety of
>> possible fixes and interface changes. If we want to make a
>> policy decision to change our approach, we should be up-front
>> about that.
>
> What?!? There have been catversion bumps between the REL?_?_BETA1
> tag and the REL?_?_0 tag for 8.2, 8.3, 9.0, 9.1, 9.3, and 9.4.
> (That is, it has happend on 6 of the last 8 releases.) I don't
> think we're talking about any policy change here. We try to avoid
> a catversion bump after beta if we can; we're not that reluctant to
> do so if needed.
Perhaps we're honoring this more in the breech than in the observance,
but I'm not making up what Tom has said about this:
http://www.postgresql.org/message-id/27310.1251410965@sss.pgh.pa.us
http://www.postgresql.org/message-id/19174.1299782543@sss.pgh.pa.us
http://www.postgresql.org/message-id/3413.1301154369@sss.pgh.pa.us
http://www.postgresql.org/message-id/3261.1401915832@sss.pgh.pa.us
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-07 02:14 Peter Geoghegan <pg@heroku.com>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 79+ messages in thread
From: Peter Geoghegan @ 2015-06-07 02:14 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Kevin Grittner <kgrittn@ymail.com>; Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sat, Jun 6, 2015 at 7:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Perhaps we're honoring this more in the breech than in the observance,
> but I'm not making up what Tom has said about this:
>
> http://www.postgresql.org/message-id/27310.1251410965@sss.pgh.pa.us
> http://www.postgresql.org/message-id/19174.1299782543@sss.pgh.pa.us
> http://www.postgresql.org/message-id/3413.1301154369@sss.pgh.pa.us
> http://www.postgresql.org/message-id/3261.1401915832@sss.pgh.pa.us
Of course, not doing a catversion bump after beta1 doesn't necessarily
have much value in and of itself. *Promising* to not do a catversion
bump, and then usually keeping that promise definitely has a certain
value, but clearly we are incapable of that.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-07 02:58 Joshua D. Drake <jd@commandprompt.com>
parent: Peter Geoghegan <pg@heroku.com>
0 siblings, 1 reply; 79+ messages in thread
From: Joshua D. Drake @ 2015-06-07 02:58 UTC (permalink / raw)
To: Peter Geoghegan <pg@heroku.com>; Robert Haas <robertmhaas@gmail.com>; +Cc: Kevin Grittner <kgrittn@ymail.com>; Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 06/06/2015 07:14 PM, Peter Geoghegan wrote:
>
> On Sat, Jun 6, 2015 at 7:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Perhaps we're honoring this more in the breech than in the observance,
>> but I'm not making up what Tom has said about this:
>>
>> http://www.postgresql.org/message-id/27310.1251410965@sss.pgh.pa.us
>> http://www.postgresql.org/message-id/19174.1299782543@sss.pgh.pa.us
>> http://www.postgresql.org/message-id/3413.1301154369@sss.pgh.pa.us
>> http://www.postgresql.org/message-id/3261.1401915832@sss.pgh.pa.us
>
> Of course, not doing a catversion bump after beta1 doesn't necessarily
> have much value in and of itself. *Promising* to not do a catversion
> bump, and then usually keeping that promise definitely has a certain
> value, but clearly we are incapable of that.
>
It seems to me that a cat bump during Alpha or Beta should be absolutely
fine and reservedly fine respectively. Where we should absolutely not
cat bump unless there is absolutely no other choice is during and RC.
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-07 03:07 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Joshua D. Drake <jd@commandprompt.com>
0 siblings, 0 replies; 79+ messages in thread
From: Alvaro Herrera @ 2015-06-07 03:07 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Simon Riggs <simon@2ndQuadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Joshua D. Drake wrote:
>
> On 06/05/2015 08:07 PM, Bruce Momjian wrote:
>
> >> From my side, it is only recently I got some clear answers to my questions
> >>about how it worked. I think it is very important that major features have
> >>extensive README type documentation with them so the underlying principles used
> >>in the development are clear. I would define the measure of a good feature as
> >>whether another committer can read the code comments and get a good feel. A bad
> >>feature is one where committers walk away from it, saying I don't really get it
> >>and I can't read an explanation of why it does that. Tom's most significant
> >>contribution is his long descriptive comments on what the problem is that need
> >>to be solved, the options and the method chosen. Clarity of thought is what
> >>solves bugs.
> >
> >Yes, I think we should have done that early-on for multi-xact, and I am
> >hopeful we will learn to do that more often when complex features are
> >implemented, or when we identify areas that are more complex than we
> >thought.
>
> I see this idea of the README as very useful. There are far more people like
> me in this community than Simon or Alvaro. I can test, I can break things, I
> can script up a harness but I need to be understand HOW and the README would
> help allow for that.
There is a src/backend/access/README.tuplock that attempts to describe
multixacts. Is that not sufficient?
Now that I think about it, this file hasn't been updated with the latest
changes, so it's probably a bit outdated now.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-07 14:10 Kevin Grittner <kgrittn@ymail.com>
parent: Joshua D. Drake <jd@commandprompt.com>
0 siblings, 0 replies; 79+ messages in thread
From: Kevin Grittner @ 2015-06-07 14:10 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; Peter Geoghegan <pg@heroku.com>; Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Josh Berkus <josh@agliodbs.com>; Noah Misch <noah@leadboat.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Joshua D. Drake <jd@commandprompt.com> wrote:
> On 06/06/2015 07:14 PM, Peter Geoghegan wrote:
>> On Sat, Jun 6, 2015 at 7:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Perhaps we're honoring this more in the breech than in the
>>> observance, but I'm not making up what Tom has said about this:
>>>
>>> http://www.postgresql.org/message-id/27310.1251410965@sss.pgh.pa.us
That's 9.0 release discussion:
| I think that the traditional criterion is that we don't release beta1
| as long as there are any known issues that might force an initdb.
| We were successful in avoiding a post-beta initdb this time, although
| IIRC the majority of release cycles have had one --- so maybe you
| could argue that that's not so important. It would certainly be
| less important if we had working pg_migrator functionality to ease
| the pain of going from beta to final.
>>> http://www.postgresql.org/message-id/19174.1299782543@sss.pgh.pa.us
That's 9.1 release discussion:
| Historically we've declared it beta once we think we are done with
| initdb-forcing problems.
| In any case, the existence of pg_upgrade means that "might we need
| another initdb?" is not as strong a consideration as it once was, so
| I'm not sure if we should still use that as a criterion. I don't know
| quite what "ready for beta" should mean otherwise, though.
>>> http://www.postgresql.org/message-id/3413.1301154369@sss.pgh.pa.us
Also 9.1, it is listed as one criterion:
| * No open issues that are expected to result in a catversion bump.
| (With pg_upgrade, this is not as critical as it used to be, but
| I still think catalog stability is a good indicator of a release's
| maturity)
>>> http://www.postgresql.org/message-id/3261.1401915832@sss.pgh.pa.us
Here we jump to 9.4 discussion:
| > Agreed. Additionally I also agree with Stefan that the price of a initdb
| > during beta isn't that high these days.
|
| Yeah, if nothing else it gives testers another opportunity to exercise
| pg_upgrade ;-). The policy about post-beta1 initdb is "avoid if
| practical", not "avoid at all costs".
So I think these examples show that the policy has shifted from a
pretty strong requirement to "it's probably nice if" status, with
some benefits seen in pg_upgrade testing to actually having a bump.
>> Of course, not doing a catversion bump after beta1 doesn't necessarily
>> have much value in and of itself. *Promising* to not do a catversion
>> bump, and then usually keeping that promise definitely has a certain
>> value, but clearly we are incapable of that.
As someone who was able to bring up a new production application on
8.2 because it was all redundant data and not yet mission-critical,
I appreciate that in very rate circumstances that combination could
have benefit. But really, how often are people in that position?
> It seems to me that a cat bump during Alpha or Beta should be absolutely
> fine and reservedly fine respectively. Where we should absolutely not
> cat bump unless there is absolutely no other choice is during and RC.
+1 on all of that. And for a while now we've been talking about an
alpha test release, right?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-07 20:01 Jeff Janes <jeff.janes@gmail.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
1 sibling, 1 reply; 79+ messages in thread
From: Jeff Janes @ 2015-06-07 20:01 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Sat, Jun 6, 2015 at 7:35 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> On 6 June 2015 at 13:41, Sehrope Sarkuni <sehrope@jackdb.com> wrote:
>
>>
>>
> It's much easier to work into dev/test setups if there are system
>> packages as it's just a config change to an existing script. Building
>> from source would require a whole new workflow that I don't have time
>> to incorporate.
>>
>
> Really? You genuinely don't have time to paste, say:
>
> mkdir -p ~/src/pgdevel
> cd ~/src/pgdevel
> wget
> https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2
> tar xjf postgresql-snapshot.tar.bz2
> mkdir bld
>
> cd bld
> ../postgresql-9.5devel/configure $(pg_config --configure | sed -e
> 's/\(pg\|postgresql[-\/]\)\(doc-\)\?9\.[0-9]*\(dev\)\?/\1\29.5dev/g')
> make wor
> ld
> make check
> make world-install
>
I think this is rather uncharitable. You don't include yum, zypper, or
apt-get anywhere in there, and I vaguely recall it took me quite a bit of
time to install all the prereqs in order to get it to compile several years
ago when I first started trying to compile it. And then even more time get
it to compile with several of the config flags I wanted. And then even
more time to get the docs to compile.
And now after I got all of that, when I try your code, it still doesn't
work. $(pg_config ....) seems to not quote things the way that configure
wants them quoted, or something. And the package from which I was using
pg_config uses more config options than I was set up for when compiling
myself, so I either have to manually remove the flags, or find more
dependencies (pam, xslt, ossp-uuid, tcl, tcl-dev, and counting). This is
not very fun, and I didn't even need to get bureaucratic approval to do any
of this stuff, like a lot of people do.
And then when I try to install it, it tries to overwrite some of the files
which were initially installed by the package manager in /usr/lib. That
doesn't seem good.
And how do I, as a hypothetical package manager user, start this puppy up?
Where is pg_ctlcluster? How does one do pg_upgrade between a
package-controlled data directory and this new binary?
And then when I find a bug, how do I know it is a bug and not me doing
something wrong in the build process, and getting the wrong .so to load
with the wrong binary or something like that?
> and yet you think you have enough time to provide more than a "looks like
> it's working" report to the developers?
>
If it isn't working, reports of it isn't working with error messages are
pretty helpful and don't take a whole lot of time. If it is working,
reports of that probably aren't terribly helpful without putting a lot more
work into it. But people might be willing to put a lot of work into, say,
performance regression testing it that is their area of expertise, if they
don' t also have to put a lot of work into getting the software to compile
in the first place, which is not their area.
Now I don't see a lot of evidence of beta testing from the public (i.e.
unfamiliar names) on -hackers and -bugs lists. But a lot of hackers report
things that "a client" or "someone on IRC" reported to them, so I'm willing
to believe that a lot of useful beta testing does go on, even though I
don't directly see it, and if there were alpha releases, why wouldn't it
extend to that?
>
> (NB the sed for the pg_config line will probably need work, it looks like
> it should work on the two types of system I have here but I have to admit I
> changed the config line manually when I built it)
>
Right, and are the people who use apt-get to install everything likely to
know how to do that work?
Cheers,
Jeff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-08 04:10 Peter Geoghegan <pg@heroku.com>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 1 reply; 79+ messages in thread
From: Peter Geoghegan @ 2015-06-08 04:10 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch <noah@leadboat.com> wrote:
> - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local pin
> count falls to zero. Under CLOBBER_FREED_MEMORY, wipe a shared buffer
> when its global pin count falls to zero.
Did a patch for this ever materialize?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 12:59 David Gould <daveg@sonic.net>
parent: Jeff Janes <jeff.janes@gmail.com>
0 siblings, 2 replies; 79+ messages in thread
From: David Gould @ 2015-06-08 12:59 UTC (permalink / raw)
To: Jeff Janes <jeff.janes@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
I think Alphas are valuable and useful and even more so if they have release
notes. For example, some of my clients are capable of fetching sources and
building from scratch and filing bug reports and are often interested in
particular new features. They even have staging infrastructure that could
test new postgres releases with real applications. But they don't do it.
They also don't follow -hackers, they don't track git, and they don't have
any easy way to tell if if the new feature they are interested in is
actually complete and ready to test at any particular time. A lot of
features are developed in multiple commits over a period of time and they
see no point in testing until at least most of the feature is complete and
expected to work. But it is not obvious from outside when that happens for
any given feature. For my clients the value of Alpha releases would
mainly be the release notes, or some other mark in the sand that says "As of
Alpha-3 feature X is included and expected to mostly work."
-dg
--
David Gould daveg@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 13:21 Geoff Winkless <pgsqladmin@geoff.dj>
parent: David Gould <daveg@sonic.net>
1 sibling, 2 replies; 79+ messages in thread
From: Geoff Winkless @ 2015-06-08 13:21 UTC (permalink / raw)
To: pgsql-hackers
Among several others, On 8 June 2015 at 13:59, David Gould <daveg@sonic.net>
wrote:
> I think Alphas are valuable and useful and even more so if they have
> release
> notes. For example, some of my clients are capable of fetching sources and
> building from scratch and filing bug reports and are often interested in
> particular new features. They even have staging infrastructure that could
> test new postgres releases with real applications. But they don't do it.
> They also don't follow -hackers, they don't track git, and they don't have
> any easy way to tell if if the new feature they are interested in is
> actually complete and ready to test at any particular time. A lot of
> features are developed in multiple commits over a period of time and they
> see no point in testing until at least most of the feature is complete and
> expected to work. But it is not obvious from outside when that happens for
> any given feature. For my clients the value of Alpha releases would
> mainly be the release notes, or some other mark in the sand that says "As
> of
> Alpha-3 feature X is included and expected to mostly work."
>
Wow! I never knew there were all these people out there who would be
rushing to help test if only the PG developers released alpha versions.
It's funny how they never used to do it when those alphas were done.
I say again: in my experience you don't get useful test reports from people
who aren't able or prepared to compile software; what you do get is lots of
unrelated and/or unhelpful noise in the mailing list. That may be harsh or
unfair or whatever, it's just my experience.
I guess the only thing we can do is see who's right. I'm simply trying to
point out that it's not the zero-cost exercise that everyone appears to
think that it is.
Geoff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 15:01 Robert Haas <robertmhaas@gmail.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
1 sibling, 2 replies; 79+ messages in thread
From: Robert Haas @ 2015-06-08 15:01 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Mon, Jun 8, 2015 at 9:21 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> Wow! I never knew there were all these people out there who would be rushing
> to help test if only the PG developers released alpha versions. It's funny
> how they never used to do it when those alphas were done.
That's probably overplaying your hand a little bit (and it sounds a
bit catty, too). Some testing got done and it had some value. It
just wasn't enough to make Peter feel like it was worthwhile. That
doesn't mean that no testing got done and that it had no value, or
that the same thing would happen this time. I'm as skeptical about
this whole rush-out-an-alpha business as anyone, but I think that
skepticism has to yield to contrary evidence, and people saying "I
would test if..." is legitimate contrary evidence.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 15:06 Joshua D. Drake <jd@commandprompt.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
1 sibling, 0 replies; 79+ messages in thread
From: Joshua D. Drake @ 2015-06-08 15:06 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On 06/08/2015 06:21 AM, Geoff Winkless wrote:
>
> Wow! I never knew there were all these people out there who would be
> rushing to help test if only the PG developers released alpha versions.
> It's funny how they never used to do it when those alphas were done.
The type of responses you are providing on this thread are not warranted.
JD
--
The most kicking donkey PostgreSQL Infrastructure company in existence.
The oldest, the most experienced, the consulting company to the stars.
Command Prompt, Inc. http://www.commandprompt.com/ +1 -503-667-4564 -
24x7 - 365 - Proactive and Managed Professional Services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 15:22 Geoff Winkless <pgsqladmin@geoff.dj>
parent: Robert Haas <robertmhaas@gmail.com>
1 sibling, 1 reply; 79+ messages in thread
From: Geoff Winkless @ 2015-06-08 15:22 UTC (permalink / raw)
To: pgsql-hackers
On 8 June 2015 at 16:01, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jun 8, 2015 at 9:21 AM, Geoff Winkless <pgsqladmin@geoff.dj>
> wrote:
> > Wow! I never knew there were all these people out there who would be
> rushing
> > to help test if only the PG developers released alpha versions. It's
> funny
> > how they never used to do it when those alphas were done.
>
> That's probably overplaying your hand a little bit (and it sounds a
> bit catty, too).
I agree. The responses I had written yesterday but didn't send were much
worse.
Mainly because I think it's quite an attitude to take that open-source
developers should put extra time into building RPMs of development versions
rather than testers waiting 5 minutes while their machines compile.
Ohmygosh, you have to rpm install a bunch of -devel stuff? What a massive
hardship.
On 8 June 2015 at 16:06, Joshua D. Drake <jd@commandprompt.com> wrote:
>
> The type of responses you are providing on this thread are not warranted.
>
I got people appearing completely insulted at my remarks and telling me
that if only they could run the alpha they would provide testing, so I
pointed out how easy it is to install the nightly from source and then they
tell me that actually compiling is far too difficult and complicated, and
that there are loads of clients who would run these nightlies if they had
RPMS...
If I truly believed that such an RPM would produce useful testing, I would
spend some of my own time building a setup to produce those RPMs myself and
post here publicising them, at which point we would have a huge number of
useful and productive test reports. Any one of the people telling me that
I'm wrong could easily do the same, but so far none has.
I'm not harping on because I want to make people feel bad, I'm harping on
because I don't want to see beta (and final) releases pushed back further
because of a bad compromise, and I believe that that will happen. I
apologise that I've clearly upset some people but they all have a very easy
route to prove me wrong, and I'll be happy to admit my error.
Geoff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 15:22 Petr Jelinek <petr.jelinek@2ndquadrant.com>
parent: Robert Haas <robertmhaas@gmail.com>
1 sibling, 0 replies; 79+ messages in thread
From: Petr Jelinek @ 2015-06-08 15:22 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On Mon, Jun 8, 2015 at 5:01 , Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jun 8, 2015 at 9:21 AM, Geoff Winkless <pgsqladmin@geoff.dj>
> wrote:
>> Wow! I never knew there were all these people out there who would
>> be rushing
>> to help test if only the PG developers released alpha versions.
>> It's funny
>> how they never used to do it when those alphas were done.
>
> That's probably overplaying your hand a little bit (and it sounds a
> bit catty, too). Some testing got done and it had some value. It
> just wasn't enough to make Peter feel like it was worthwhile. That
> doesn't mean that no testing got done and that it had no value, or
> that the same thing would happen this time. I'm as skeptical about
> this whole rush-out-an-alpha business as anyone, but I think that
> skepticism has to yield to contrary evidence, and people saying "I
> would test if..." is legitimate contrary evidence.
Agreed.
To get back to the point, I think the problem with original alphas was
that they were after CF snapshots, not something that represented the
final release.
I do think that proper alpha/beta release is signal for several
companies (I do know some that do testing once beta gets out) to do
testing as it does indeed say that we are releasing something that is
close in functionality to the final release.
Also the packages are really important, there are enough companies that
don't install development packages to servers at all so it's not just
compile and run for them, they have to move it over to other machines,
etc. We should be lowering the barrier to user based testing as much as
possible and doing alpha with packages is exactly how we do that.
IMHO the only real discussion here is if current 9.5 is ready for user
testing and FWIW I thin it is.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 16:03 Claudio Freire <klaussfreire@gmail.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
0 siblings, 3 replies; 79+ messages in thread
From: Claudio Freire @ 2015-06-08 16:03 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Mon, Jun 8, 2015 at 12:22 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> On 8 June 2015 at 16:01, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Mon, Jun 8, 2015 at 9:21 AM, Geoff Winkless <pgsqladmin@geoff.dj>
>> wrote:
>> > Wow! I never knew there were all these people out there who would be
>> > rushing
>> > to help test if only the PG developers released alpha versions. It's
>> > funny
>> > how they never used to do it when those alphas were done.
>>
>> That's probably overplaying your hand a little bit (and it sounds a
>> bit catty, too).
>
>
> I agree. The responses I had written yesterday but didn't send were much
> worse.
>
> Mainly because I think it's quite an attitude to take that open-source
> developers should put extra time into building RPMs of development versions
> rather than testers waiting 5 minutes while their machines compile.
> Ohmygosh, you have to rpm install a bunch of -devel stuff? What a massive
> hardship.
It's not about the 5 minutes of compile time, it's about the signalling.
Just *when* is git ready for testing? You don't know from the outside.
I do lurk here a lot and still am unsure quite often.
Even simply releasing an alpha *tarball* would be useful enough. What
is needed is the signal to test, rather than a fully-built package.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 16:14 Geoff Winkless <pgsqladmin@geoff.dj>
parent: Claudio Freire <klaussfreire@gmail.com>
2 siblings, 1 reply; 79+ messages in thread
From: Geoff Winkless @ 2015-06-08 16:14 UTC (permalink / raw)
To: pgsql-hackers
On 8 June 2015 at 17:03, Claudio Freire <klaussfreire@gmail.com> wrote:
> It's not about the 5 minutes of compile time, it's about the signalling.
>
> Just *when* is git ready for testing? You don't know from the outside.
>
> I do lurk here a lot and still am unsure quite often.
>
> Even simply releasing an alpha *tarball* would be useful enough. What
> is needed is the signal to test, rather than a fully-built package.
>
I can see that, and can absolutely get behind the idea of a nightly being
flagged as an alpha, since it should involve next to no developer time.
I may be overestimating the amount of time that goes towards producing a
release; the fact that the full-on alpha releases were stopped did imply to
me that it's not insignificant.
Geoff
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 16:16 David G. Johnston <david.g.johnston@gmail.com>
parent: Claudio Freire <klaussfreire@gmail.com>
2 siblings, 2 replies; 79+ messages in thread
From: David G. Johnston @ 2015-06-08 16:16 UTC (permalink / raw)
To: Claudio Freire <klaussfreire@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On Mon, Jun 8, 2015 at 12:03 PM, Claudio Freire <klaussfreire@gmail.com>
wrote:
> Just *when* is git ready for testing? You don't know from the outside.
>
> I do lurk here a lot and still am unsure quite often.
>
> Even simply releasing an alpha *tarball* would be useful enough. What
> is needed is the signal to test, rather than a fully-built package.
>
>
IIUC the master branch is always ready for testing.
I do not think the project cares whether everyone is testing the exact
same codebase; as long as test findings include the relevant commit hash
the results will be informative.
David J.
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 16:32 David G. Johnston <david.g.johnston@gmail.com>
parent: Geoff Winkless <pgsqladmin@geoff.dj>
0 siblings, 2 replies; 79+ messages in thread
From: David G. Johnston @ 2015-06-08 16:32 UTC (permalink / raw)
To: Geoff Winkless <pgsqladmin@geoff.dj>; +Cc: pgsql-hackers
On Mon, Jun 8, 2015 at 12:14 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> On 8 June 2015 at 17:03, Claudio Freire <klaussfreire@gmail.com> wrote:
>
>> It's not about the 5 minutes of compile time, it's about the signalling.
>>
>> Just *when* is git ready for testing? You don't know from the outside.
>>
>> I do lurk here a lot and still am unsure quite often.
>>
>> Even simply releasing an alpha *tarball* would be useful enough. What
>> is needed is the signal to test, rather than a fully-built package.
>>
>
> I can see that, and can absolutely get behind the idea of a nightly being
> flagged as an alpha, since it should involve next to no developer time.
>
>
Nightly where? This is an international community.
The tip of the master branch is the current "alpha" - so the question is
whether a tar bundle should be provided instead of asking people to simply
keep their Git clone up-to-date. These both have the flaw of excluding
people who would test the application if it could simply be installed like
any other package on their system. But I'm not seeing where there would be
a huge group of people who would test an automatically generated source
tar-ball but would not be willing to use Git. Or are we talking about a
non-source tar-ball?
Maybe packagers could be convinced to bundle up the master branch on a
monthly basis and simply call it Master-SNAPSHOT. No alpha, no beta, no
version number. I've never packaged before so I don't know but while the
project should encourage this as things currently standard the core project
is doing its job by ensuring that the tip of master is always in a usable
state.
Or, whenever a new patch release goes out packagers can also bundle up the
current master at the same time.
David J.
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 16:39 Andres Freund <andres@anarazel.de>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 79+ messages in thread
From: Andres Freund @ 2015-06-08 16:39 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Claudio Freire <klaussfreire@gmail.com>; Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On 2015-06-08 12:16:34 -0400, David G. Johnston wrote:
> IIUC the master branch is always ready for testing.
I don't really think so. For one we often find bugs ourselves quite
quickly.
But more importantly, I'd much rather have users use their precious (and
thus limited!) time to test when the set of features (not every detail
of a feature) is mostly set in stone. There's not much point in doing
in-depth testing before that. Similarly it's not particularly worthwhile
to test while the buildfarm still shows failures on common platforms.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 17:00 Stephen Frost <sfrost@snowman.net>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 79+ messages in thread
From: Stephen Frost @ 2015-06-08 17:00 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Claudio Freire <klaussfreire@gmail.com>; Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
David,
* David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Mon, Jun 8, 2015 at 12:03 PM, Claudio Freire <klaussfreire@gmail.com>
> wrote:
> > Just *when* is git ready for testing? You don't know from the outside.
> >
> > I do lurk here a lot and still am unsure quite often.
> >
> > Even simply releasing an alpha *tarball* would be useful enough. What
> > is needed is the signal to test, rather than a fully-built package.
> >
> >
> IIUC the master branch is always ready for testing.
>
> I do not think the project cares whether everyone is testing the exact
> same codebase; as long as test findings include the relevant commit hash
> the results will be informative.
For my 2c, I do believe it's useful for projects which are based on PG
or which work with PG to have a 'alpha1' tag to refer to. Asking users
to test with git hash XYZABC isn't great. Getting more users of
applications which use PG to do testing is, in my view at least, a great
way to improve our test coverage and I do think having an alpha will
help with that.
That said, I'm not pushing to have one released this week or before
PGCon or any such- let's get the back-branch releases dealt with and
then we can get an alpha out.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 17:01 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 1 reply; 79+ messages in thread
From: Alvaro Herrera @ 2015-06-08 17:01 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
David G. Johnston wrote:
> On Mon, Jun 8, 2015 at 12:14 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> > I can see that, and can absolutely get behind the idea of a nightly being
> > flagged as an alpha, since it should involve next to no developer time.
> >
> Nightly where? This is an international community.
A "nightly" refers to our development snapshots, which are uploaded to
the ftp servers every "night" (according to some timezone). You can
find them in pub/snapshot/ for each branch.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 17:03 Bruce Momjian <bruce@momjian.us>
parent: David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 79+ messages in thread
From: Bruce Momjian @ 2015-06-08 17:03 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On Mon, Jun 8, 2015 at 12:32:45PM -0400, David G. Johnston wrote:
> On Mon, Jun 8, 2015 at 12:14 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
>
> On 8 June 2015 at 17:03, Claudio Freire <klaussfreire@gmail.com> wrote:
>
> It's not about the 5 minutes of compile time, it's about the
> signalling.
>
> Just *when* is git ready for testing? You don't know from the outside.
>
> I do lurk here a lot and still am unsure quite often.
>
> Even simply releasing an alpha *tarball* would be useful enough. What
> is needed is the signal to test, rather than a fully-built package.
>
>
> I can see that, and can absolutely get behind the idea of a nightly being
> flagged as an alpha, since it should involve next to no developer time.
>
>
>
> Nightly where? This is an international community.
The daily snapshot tarballs are built in a way to minimize the number of
development tools required:
http://www.postgresql.org/ftp/snapshot/dev/
These would be easier to use than pulling from git.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 17:07 Magnus Hagander <magnus@hagander.net>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 0 replies; 79+ messages in thread
From: Magnus Hagander @ 2015-06-08 17:07 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On Mon, Jun 8, 2015 at 7:01 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:
> David G. Johnston wrote:
> > On Mon, Jun 8, 2015 at 12:14 PM, Geoff Winkless <pgsqladmin@geoff.dj>
> wrote:
>
> > > I can see that, and can absolutely get behind the idea of a nightly
> being
> > > flagged as an alpha, since it should involve next to no developer time.
> > >
> > Nightly where? This is an international community.
>
> A "nightly" refers to our development snapshots, which are uploaded to
> the ftp servers every "night" (according to some timezone). You can
> find them in pub/snapshot/ for each branch.
>
Snapshots are actually not nightly anymore, and haven't been for some time.
They are currently run every 4 hours, and are uploaded to the ftp server
once a buildfarm run (on debian x64) finishes.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-08 17:44 Bruce Momjian <bruce@momjian.us>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 1 reply; 79+ messages in thread
From: Bruce Momjian @ 2015-06-08 17:44 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Sat, Jun 6, 2015 at 03:58:05PM -0400, Noah Misch wrote:
> On Fri, Jun 05, 2015 at 08:25:34AM +0100, Simon Riggs wrote:
> > This whole idea of "feature development" vs reliability is bogus. It
> > implies people that work on features don't care about reliability. Given
> > the fact that many of the features are actually about increasing database
> > reliability in the event of crashes and corruptions it just makes no sense.
>
> I'm contrasting work that helps to keep our existing promises ("reliability")
> with work that makes new promises ("features"). In software development, we
> invariably hazard old promises to make new promises; our success hinges on
> electing neither too little nor too much risk. Two years ago, PostgreSQL's
> track record had placed it in a good position to invest in new, high-risk,
> high-reward promises. We did that, and we emerged solvent yet carrying an
> elevated debt service ratio. It's time to reduce risk somewhat.
>
> You write about a different sense of "reliability." (Had I anticipated this
> misunderstanding, I might have written "Restore-probity mode.") None of this
> was about classifying people, most of whom allocate substantial time to each
> kind of work.
>
> > How will we participate in cleanup efforts? How do we know when something
> > has been "cleaned up", how will we measure our success or failure? I think
> > we should be clear that wasting N months on cleanup can *fail* to achieve a
> > useful objective. Without a clear plan it almost certainly will do so. The
> > flip side is that wasting N months will cause great amusement and dancing
> > amongst those people who wish to pull ahead of our open source project and
> > we should take care not to hand them a victory from an overreaction.
>
> I agree with all that. We should likewise take care not to become insolvent
> from an underreaction.
I understand the overreaction/underreaction debate. Here were my goals
in this discussion:
1. stop worry about the 9.5 timeline so we could honestly assess our
software - *done*
2. seriously address multi-xact issues without 9.5/commit-fest pressure -
*in process*
3. identify any other areas in need of serious work
While I like the list you provided, I don't think we can be effective in
an environment where we assume every big new features will have problems
like multi-xact. For example, we have not seen destabilization from any
major 9.4 features, that I can remember anyway.
Unless there is consensus about new areas for #3, I am thinking we will
continue looking at multi-xact until we are happy, then move ahead with
9.5 items in the way we have before.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-08 17:48 Andres Freund <andres@anarazel.de>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 79+ messages in thread
From: Andres Freund @ 2015-06-08 17:48 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Noah Misch <noah@leadboat.com>; Simon Riggs <simon@2ndQuadrant.com>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 2015-06-08 13:44:05 -0400, Bruce Momjian wrote:
> I understand the overreaction/underreaction debate. Here were my goals
> in this discussion:
>
> 1. stop worry about the 9.5 timeline so we could honestly assess our
> software - *done*
> 2. seriously address multi-xact issues without 9.5/commit-fest pressure -
> *in process*
> 3. identify any other areas in need of serious work
>
> While I like the list you provided, I don't think we can be effective in
> an environment where we assume every big new features will have problems
> like multi-xact. For example, we have not seen destabilization from any
> major 9.4 features, that I can remember anyway.
>
> Unless there is consensus about new areas for #3, I am thinking we will
> continue looking at multi-xact until we are happy, then move ahead with
> 9.5 items in the way we have before.
I think one important part is that we (continue to?) regularly tell our
employers that work on pre-commit, post-commit review, and refactoring
are critical for their long term business prospects. My impression so
far is that that the employer side hasn't widely realized that fact, and
that many contributors do the review etc. part in their spare time.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-08 17:51 Bruce Momjian <bruce@momjian.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 79+ messages in thread
From: Bruce Momjian @ 2015-06-08 17:51 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Noah Misch <noah@leadboat.com>; Simon Riggs <simon@2ndQuadrant.com>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Mon, Jun 8, 2015 at 07:48:36PM +0200, Andres Freund wrote:
> On 2015-06-08 13:44:05 -0400, Bruce Momjian wrote:
> > I understand the overreaction/underreaction debate. Here were my goals
> > in this discussion:
> >
> > 1. stop worry about the 9.5 timeline so we could honestly assess our
> > software - *done*
> > 2. seriously address multi-xact issues without 9.5/commit-fest pressure -
> > *in process*
> > 3. identify any other areas in need of serious work
> >
> > While I like the list you provided, I don't think we can be effective in
> > an environment where we assume every big new features will have problems
> > like multi-xact. For example, we have not seen destabilization from any
> > major 9.4 features, that I can remember anyway.
> >
> > Unless there is consensus about new areas for #3, I am thinking we will
> > continue looking at multi-xact until we are happy, then move ahead with
> > 9.5 items in the way we have before.
>
> I think one important part is that we (continue to?) regularly tell our
> employers that work on pre-commit, post-commit review, and refactoring
> are critical for their long term business prospects. My impression so
> far is that that the employer side hasn't widely realized that fact, and
> that many contributors do the review etc. part in their spare time.
Agreed. My bet is that more employers realize it now than they did a
few months ago --- kind of hard to miss all those minor releases and
customer complaints. :-(
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 21:35 Gavin Flower <GavinFlower@archidevsys.co.nz>
parent: David Gould <daveg@sonic.net>
1 sibling, 0 replies; 79+ messages in thread
From: Gavin Flower @ 2015-06-08 21:35 UTC (permalink / raw)
To: David Gould <daveg@sonic.net>; Jeff Janes <jeff.janes@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On 09/06/15 00:59, David Gould wrote:
> I think Alphas are valuable and useful and even more so if they have release
> notes. For example, some of my clients are capable of fetching sources and
> building from scratch and filing bug reports and are often interested in
> particular new features. They even have staging infrastructure that could
> test new postgres releases with real applications. But they don't do it.
> They also don't follow -hackers, they don't track git, and they don't have
> any easy way to tell if if the new feature they are interested in is
> actually complete and ready to test at any particular time. A lot of
> features are developed in multiple commits over a period of time and they
> see no point in testing until at least most of the feature is complete and
> expected to work. But it is not obvious from outside when that happens for
> any given feature. For my clients the value of Alpha releases would
> mainly be the release notes, or some other mark in the sand that says "As of
> Alpha-3 feature X is included and expected to mostly work."
>
> -dg
>
RELEASE NOTES
I think that having:
1. release notes
2. an Alpha people can simply install without having to compile
Would encourage more people to get involved. Such people would be
unlikely to have the time and inclination to use 'nightlies', even if
compiling was not required.
I have read other posts in this thread, that support the above.
Surely, it would be good for pg to have some more people checking
quality at an earlier stage? So reducing barriers to do so is a good thing?
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: [CORE] Restore-reliability mode
@ 2015-06-08 23:02 David Gould <daveg@sonic.net>
parent: Claudio Freire <klaussfreire@gmail.com>
2 siblings, 0 replies; 79+ messages in thread
From: David Gould @ 2015-06-08 23:02 UTC (permalink / raw)
To: Claudio Freire <klaussfreire@gmail.com>; +Cc: Geoff Winkless <pgsqladmin@geoff.dj>; pgsql-hackers
On Mon, 8 Jun 2015 13:03:56 -0300
Claudio Freire <klaussfreire@gmail.com> wrote:
> > Ohmygosh, you have to rpm install a bunch of -devel stuff? What a massive
> > hardship.
>
> It's not about the 5 minutes of compile time, it's about the signalling.
>
> Just *when* is git ready for testing? You don't know from the outside.
>
> I do lurk here a lot and still am unsure quite often.
>
> Even simply releasing an alpha *tarball* would be useful enough. What
> is needed is the signal to test, rather than a fully-built package.
This. The clients I referred to earlier don't even use the rpm packages,
they build from sources. They need to know when it is worthwhile to take a
new set of sources and test. Some sort of labeling about what the contents
are would enable them to do this.
I don't think a monthly snapshot would work as well as the requirement is
knowing that "grouping sets are in" not that "it is July now".
-dg
--
David Gould daveg@sonic.net
If simplicity worked, the world would be overrun with insects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-10 05:57 Noah Misch <noah@leadboat.com>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 79+ messages in thread
From: Noah Misch @ 2015-06-10 05:57 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Wed, Jun 03, 2015 at 04:18:37PM +0200, Andres Freund wrote:
> On 2015-06-03 09:50:49 -0400, Noah Misch wrote:
> > Second, I would define the subject matter as "bug fixes, testing and
> > review", not "restructuring, testing and review." Different code
> > structures are clearest to different hackers. Restructuring, on
> > average, adds bugs even more quickly than feature development adds
> > them.
>
> I can't agree with this. While I agree with not doing large
> restructuring for 9.5, I think we can't affort not to refactor for
> clarity, even if that introduces bugs. Noticeable parts of our code have
> to frequently be modified for new features and are badly structured at
> the same time. While restructuring will may temporarily increase the
> number of bugs in the short term, it'll decrease the number of bugs long
> term while increasing the number of potential contributors and new
> features. That's obviously not to say we should just refactor for the
> sake of it.
I think I agree with everything after your first sentence. I liked your
specific proposal to split StartupXLOG(), but making broad-appeal
restructuring proposals is hard. I doubt we would get good results by casting
a wide net for restructuring ideas. Automated testing has a lower barrier to
entry and is far less liable to make things worse instead of better. I can
hope for good results from a TestSuiteFest, but not from a RestructureFest.
That said, if folks initiate compelling restructure proposals, we should be
willing to risk bugs from them like we risk bugs to acquire new features.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-06-10 08:21 Andres Freund <andres@anarazel.de>
parent: Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 79+ messages in thread
From: Andres Freund @ 2015-06-10 08:21 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On 2015-06-10 01:57:22 -0400, Noah Misch wrote:
> I think I agree with everything after your first sentence. I liked your
> specific proposal to split StartupXLOG(), but making broad-appeal
> restructuring proposals is hard. I doubt we would get good results by casting
> a wide net for restructuring ideas.
I'm not meaning that we should actively strive to find as many things to
refactor as possible (yes, over-emphasized a bit). But that we shouldn't
skip refactoring if we notice something structurally bad, just because
it's been that way and we don't want to touch something "working". That
argument has e.g. been made repeatedly for xlog.c contents.
My feeling is that we're reaching the stage where a significant number
of bugs are added because code is structured "needlessly" complicated
and/or repetitive. And better testing can only catch so much - often
enough somebody has to think of all the possible corner cases.
> Automated testing has a lower barrier to
> entry and is far less liable to make things worse instead of better. I can
> hope for good results from a TestSuiteFest, but not from a RestructureFest.
> That said, if folks initiate compelling restructure proposals, we should be
> willing to risk bugs from them like we risk bugs to acquire new
> features.
Sure, increasing testing and reviews are good independently. And
especially testing actually makes refactoring much more realistic.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-07-23 19:53 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Peter Geoghegan <pg@heroku.com>
0 siblings, 1 reply; 79+ messages in thread
From: Alvaro Herrera @ 2015-07-23 19:53 UTC (permalink / raw)
To: Peter Geoghegan <pg@heroku.com>; +Cc: Noah Misch <noah@leadboat.com>; Simon Riggs <simon@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Peter Geoghegan wrote:
> On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch <noah@leadboat.com> wrote:
> > - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local pin
> > count falls to zero. Under CLOBBER_FREED_MEMORY, wipe a shared buffer
> > when its global pin count falls to zero.
>
> Did a patch for this ever materialize?
I think the first part would be something like the attached.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
0001-add-valgrind-calls.patch (text/x-diff, 1.2K) download
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index e4b25587..83fde10 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -47,6 +47,7 @@
#include "storage/proc.h"
#include "storage/smgr.h"
#include "storage/standby.h"
+#include "utils/memdebug.h"
#include "utils/rel.h"
#include "utils/resowner_private.h"
#include "utils/timestamp.h"
@@ -1438,6 +1439,9 @@ PinBuffer(volatile BufferDesc *buf, BufferAccessStrategy strategy)
ref = NewPrivateRefCountEntry(b + 1);
LockBufHdr(buf);
+
+ VALGRIND_MAKE_MEM_DEFINED(BufHdrGetBlock(buf), BLCKSZ);
+
buf->refcount++;
if (strategy == NULL)
{
@@ -1498,6 +1502,8 @@ PinBuffer_Locked(volatile BufferDesc *buf)
*/
Assert(GetPrivateRefCountEntry(b + 1, false) == NULL);
+ VALGRIND_MAKE_MEM_DEFINED(BufHdrGetBlock(buf), BLCKSZ);
+
buf->refcount++;
UnlockBufHdr(buf);
@@ -1543,6 +1549,8 @@ UnpinBuffer(volatile BufferDesc *buf, bool fixOwner)
Assert(buf->refcount > 0);
buf->refcount--;
+ VALGRIND_MAKE_MEM_NOACCESS(BufHdrGetBlock(buf), BLCKSZ);
+
/* Support LockBufferForCleanup() */
if ((buf->flags & BM_PIN_COUNT_WAITER) &&
buf->refcount == 1)
* Re: Restore-reliability mode
@ 2015-07-23 19:57 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Noah Misch <noah@leadboat.com>
3 siblings, 0 replies; 79+ messages in thread
From: Alvaro Herrera @ 2015-07-23 19:57 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
Noah Misch wrote:
> - Add buildfarm members. This entails reporting any bugs that prevent an
> initial passing run. Once you have a passing run, schedule regular runs.
> Examples of useful additions:
> - "./configure ac_cv_func_getopt_long=no, ac_cv_func_snprintf=no ..." to
> enable all the replacement code regardless of the current platform's need
> for it. This helps distinguish "Windows bug" from "replacement code bug."
> - --disable-integer-datetimes, --disable-float8-byval, disable-float4-byval,
> --disable-spinlocks, --disable-atomics, disable-thread-safety,
> --disable-largefile, #define RANDOMIZE_ALLOCATED_MEMORY
#define RELCACHE_FORCE_RELEASE + #define CLOBBER_FREED_MEMORY
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-07-26 07:26 Noah Misch <noah@leadboat.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 79+ messages in thread
From: Noah Misch @ 2015-07-26 07:26 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Peter Geoghegan <pg@heroku.com>; Simon Riggs <simon@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers; pgsql-core <pgsql-core@postgresql.org>
On Thu, Jul 23, 2015 at 04:53:49PM -0300, Alvaro Herrera wrote:
> Peter Geoghegan wrote:
> > On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch <noah@leadboat.com> wrote:
> > > - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local pin
> > > count falls to zero. Under CLOBBER_FREED_MEMORY, wipe a shared buffer
> > > when its global pin count falls to zero.
> >
> > Did a patch for this ever materialize?
>
> I think the first part would be something like the attached.
Neat. Does it produce any new complaints during "make installcheck"?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
* Re: Restore-reliability mode
@ 2015-07-27 14:12 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Noah Misch <noah@leadboat.com>
0 siblings, 0 replies; 79+ messages in thread
From: Alvaro Herrera @ 2015-07-27 14:12 UTC (permalink / raw)
To: Noah Misch <noah@leadboat.com>; +Cc: Peter Geoghegan <pg@heroku.com>; Simon Riggs <simon@2ndquadrant.com>; Bruce Momjian <bruce@momjian.us>; Andres Freund <andres@anarazel.de>; Robert Haas <robertmhaas@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Stephen Frost <sfrost@snowman.net>; Magnus Hagander <magnus@hagander.net>; pgsql-hackers
Noah Misch wrote:
> On Thu, Jul 23, 2015 at 04:53:49PM -0300, Alvaro Herrera wrote:
> > Peter Geoghegan wrote:
> > > On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch <noah@leadboat.com> wrote:
> > > > - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local pin
> > > > count falls to zero. Under CLOBBER_FREED_MEMORY, wipe a shared buffer
> > > > when its global pin count falls to zero.
> > >
> > > Did a patch for this ever materialize?
> >
> > I think the first part would be something like the attached.
>
> Neat. Does it produce any new complaints during "make installcheck"?
I only tried a few tests, for lack of time, and it didn't produce any.
(To verify that the whole thing was working properly, I reduced the
range of memory made available during PinBuffer and that resulted in a
crash immediately). I am not really familiar with valgrind TBH and just
copied a recipe to run postmaster under it, so if someone with more
valgrind-fu could verify this, it would be great.
This part:
> > > > Under CLOBBER_FREED_MEMORY, wipe a shared buffer when its
> > > > global pin count falls to zero.
can be done without any valgrind, I think. Any takers?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 79+ messages in thread
end of thread, other threads:[~2015-07-27 14:12 UTC | newest]
Thread overview: 79+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-06-03 13:50 Restore-reliability mode Noah Misch <noah@leadboat.com>
2015-06-03 14:07 ` Geoff Winkless <pgsqladmin@geoff.dj>
2015-06-03 14:18 ` Andres Freund <andres@anarazel.de>
2015-06-03 14:51 ` Joshua D. Drake <jd@commandprompt.com>
2015-06-10 05:57 ` Noah Misch <noah@leadboat.com>
2015-06-10 08:21 ` Andres Freund <andres@anarazel.de>
2015-06-03 17:21 ` Josh Berkus <josh@agliodbs.com>
2015-06-03 17:25 ` Andres Freund <andres@anarazel.de>
2015-06-04 14:43 ` Stephen Frost <sfrost@snowman.net>
2015-06-04 23:53 ` Craig Ringer <craig@2ndquadrant.com>
2015-06-05 04:28 ` Michael Paquier <michael.paquier@gmail.com>
2015-06-05 15:05 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-06-06 05:43 ` Michael Paquier <michael.paquier@gmail.com>
2015-06-05 15:55 ` Jim Nasby <Jim.Nasby@BlueTreble.com>
2015-06-05 06:50 ` Simon Riggs <simon@2ndQuadrant.com>
2015-06-05 14:00 ` Robert Haas <robertmhaas@gmail.com>
2015-06-05 14:23 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-06-05 15:20 ` Robert Haas <robertmhaas@gmail.com>
2015-06-05 15:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-06-05 16:06 ` Jim Nasby <Jim.Nasby@BlueTreble.com>
2015-06-05 15:51 ` Andres Freund <andres@anarazel.de>
2015-06-05 18:57 ` Peter Geoghegan <pg@heroku.com>
2015-06-05 18:39 ` Josh Berkus <josh@agliodbs.com>
2015-06-05 15:18 ` Simon Riggs <simon@2ndQuadrant.com>
2015-06-05 16:20 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-06-06 09:07 ` Simon Riggs <simon@2ndQuadrant.com>
2015-06-06 10:13 ` Gavin Flower <GavinFlower@archidevsys.co.nz>
2015-06-06 10:15 ` Magnus Hagander <magnus@hagander.net>
2015-06-06 10:27 ` Devrim GÜNDÜZ <devrim@gunduz.org>
2015-06-06 10:47 ` Geoff Winkless <pgsqladmin@geoff.dj>
2015-06-06 12:41 ` Sehrope Sarkuni <sehrope@jackdb.com>
2015-06-06 14:35 ` Geoff Winkless <pgsqladmin@geoff.dj>
2015-06-06 15:58 ` Sehrope Sarkuni <sehrope@jackdb.com>
2015-06-07 20:01 ` Jeff Janes <jeff.janes@gmail.com>
2015-06-08 12:59 ` David Gould <daveg@sonic.net>
2015-06-08 13:21 ` Geoff Winkless <pgsqladmin@geoff.dj>
2015-06-08 15:01 ` Robert Haas <robertmhaas@gmail.com>
2015-06-08 15:22 ` Geoff Winkless <pgsqladmin@geoff.dj>
2015-06-08 16:03 ` Claudio Freire <klaussfreire@gmail.com>
2015-06-08 16:14 ` Geoff Winkless <pgsqladmin@geoff.dj>
2015-06-08 16:32 ` David G. Johnston <david.g.johnston@gmail.com>
2015-06-08 17:01 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-06-08 17:07 ` Magnus Hagander <magnus@hagander.net>
2015-06-08 17:03 ` Bruce Momjian <bruce@momjian.us>
2015-06-08 16:16 ` David G. Johnston <david.g.johnston@gmail.com>
2015-06-08 16:39 ` Andres Freund <andres@anarazel.de>
2015-06-08 17:00 ` Stephen Frost <sfrost@snowman.net>
2015-06-08 23:02 ` David Gould <daveg@sonic.net>
2015-06-08 15:22 ` Petr Jelinek <petr.jelinek@2ndquadrant.com>
2015-06-08 15:06 ` Joshua D. Drake <jd@commandprompt.com>
2015-06-08 21:35 ` Gavin Flower <GavinFlower@archidevsys.co.nz>
2015-06-06 14:33 ` Robert Haas <robertmhaas@gmail.com>
2015-06-06 17:02 ` Joshua D. Drake <jd@commandprompt.com>
2015-06-05 16:56 ` Robert Haas <robertmhaas@gmail.com>
2015-06-06 16:33 ` Kevin Grittner <kgrittn@ymail.com>
2015-06-07 02:07 ` Robert Haas <robertmhaas@gmail.com>
2015-06-07 02:14 ` Peter Geoghegan <pg@heroku.com>
2015-06-07 02:58 ` Joshua D. Drake <jd@commandprompt.com>
2015-06-07 14:10 ` Kevin Grittner <kgrittn@ymail.com>
2015-06-05 15:23 ` Simon Riggs <simon@2ndQuadrant.com>
2015-06-05 21:08 ` Peter Geoghegan <pg@heroku.com>
2015-06-05 15:05 ` Bruce Momjian <bruce@momjian.us>
2015-06-05 15:36 ` Andres Freund <andres@anarazel.de>
2015-06-05 15:52 ` Bruce Momjian <bruce@momjian.us>
2015-06-05 15:54 ` Simon Riggs <simon@2ndQuadrant.com>
2015-06-06 03:07 ` Bruce Momjian <bruce@momjian.us>
2015-06-06 16:55 ` Joshua D. Drake <jd@commandprompt.com>
2015-06-07 03:07 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-06-05 07:25 ` Simon Riggs <simon@2ndQuadrant.com>
2015-06-06 19:58 ` Noah Misch <noah@leadboat.com>
2015-06-06 20:29 ` Michael Paquier <michael.paquier@gmail.com>
2015-06-08 04:10 ` Peter Geoghegan <pg@heroku.com>
2015-07-23 19:53 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-07-26 07:26 ` Noah Misch <noah@leadboat.com>
2015-07-27 14:12 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-06-08 17:44 ` Bruce Momjian <bruce@momjian.us>
2015-06-08 17:48 ` Andres Freund <andres@anarazel.de>
2015-06-08 17:51 ` Bruce Momjian <bruce@momjian.us>
2015-07-23 19:57 ` Alvaro Herrera <alvherre@2ndquadrant.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox