Re: [HACKERS] Restore-reliability mode

2015-07-27 Thread Alvaro Herrera
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 wrote: > > > > - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local > > > > pin > > > > count falls to zero. Und

Re: [HACKERS] Restore-reliability mode

2015-07-26 Thread Noah Misch
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 wrote: > > > - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local > > > pin > > > count falls to zero. Under CLOBBER_FREED_MEMORY, wipe

Re: [HACKERS] Restore-reliability mode

2015-07-23 Thread Alvaro Herrera
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 al

Re: [HACKERS] Restore-reliability mode

2015-07-23 Thread Alvaro Herrera
Peter Geoghegan wrote: > On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch 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 pat

Re: [HACKERS] Restore-reliability mode

2015-06-10 Thread Andres Freund
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 restructur

Re: [HACKERS] Restore-reliability mode

2015-06-09 Thread Noah Misch
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 ha

Re: [HACKERS] Restore-reliability mode

2015-06-08 Thread Bruce Momjian
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 > >

Re: [HACKERS] Restore-reliability mode

2015-06-08 Thread Andres Freund
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

Re: [HACKERS] Restore-reliability mode

2015-06-08 Thread Bruce Momjian
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

Re: [HACKERS] Restore-reliability mode

2015-06-07 Thread Peter Geoghegan
On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch 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? --

Re: [HACKERS] Restore-reliability mode

2015-06-06 Thread Michael Paquier
On Sun, Jun 7, 2015 at 4:58 AM, Noah Misch 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

Re: [HACKERS] Restore-reliability mode

2015-06-06 Thread Noah Misch
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

Re: [HACKERS] Restore-reliability mode

2015-06-05 Thread Simon Riggs
On 3 June 2015 at 14:50, 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: > > Well, I think we stop what we are doing, focus on restructuring, > > testing, and reviewing areas that historically h

Re: [HACKERS] Restore-reliability mode

2015-06-03 Thread Joshua D. Drake
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 av

Re: [HACKERS] Restore-reliability mode

2015-06-03 Thread Andres Freund
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 f

Re: [HACKERS] Restore-reliability mode

2015-06-03 Thread Geoff Winkless
On 3 June 2015 at 14:50, Noah Misch 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

[HACKERS] Restore-reliability mode

2015-06-03 Thread Noah Misch
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