Re: [HACKERS] Potential GIN vacuum bug

2015-08-16 Thread Heikki Linnakangas
On 08/16/2015 12:58 AM, Jeff Janes wrote: When ginbulkdelete gets called for the first time in a VACUUM(i.e. stats == NULL), one of the first things it does is call ginInsertCleanup to get rid of the pending list. It does this in lieu of vacuuming the pending list. This is important because if

Re: [HACKERS] Error message with plpgsql CONTINUE

2015-08-16 Thread Pavel Stehule
2015-08-17 6:19 GMT+02:00 Jim Nasby : > Calling CONTINUE with a label that's not a loop produces an error message > with no context info [1]. This is because of > > rc = exec_stmt_block(&estate, func->action); > if (rc != PLPGSQL_RC_RETURN) > { > estate.err_

Re: [HACKERS] Configure checks and optimizations/crc32 tests

2015-08-16 Thread Heikki Linnakangas
On 08/14/2015 07:42 PM, Andres Freund wrote: Going over my vpaths I noticed another problem with the test. With gcc I get slice-by-8 instead of the runtime variant: checking for builtin __atomic int64 atomic operations... yes checking for __get_cpuid... yes checking for __cpuid... no checking fo

[HACKERS] Memory allocation in spi_printtup()

2015-08-16 Thread Neil Conway
spi_printtup() has the following code (spi.c:1798): if (tuptable->free == 0) { tuptable->free = 256; tuptable->alloced += tuptable->free; tuptable->vals = (HeapTuple *) repalloc(tuptable->vals, tuptable->alloced * sizeof(HeapTuple

[HACKERS] Error message with plpgsql CONTINUE

2015-08-16 Thread Jim Nasby
Calling CONTINUE with a label that's not a loop produces an error message with no context info [1]. This is because of rc = exec_stmt_block(&estate, func->action); if (rc != PLPGSQL_RC_RETURN) { estate.err_stmt = NULL; estate.err_text = NUL

Re: [HACKERS] TAP tests are badly named

2015-08-16 Thread Michael Paquier
On Mon, Aug 17, 2015 at 7:15 AM, Noah Misch wrote: > On Sun, Aug 16, 2015 at 05:08:56PM -0400, Andrew Dunstan wrote: >> On 08/16/2015 02:23 PM, Noah Misch wrote: >> >>-sub tapcheck >> >>+sub tap_check >> >> { >> >>- InstallTemp(); >> >>+ die "Tap tests not enabled in configuration" >> >>+

Re: [HACKERS] TAP tests are badly named

2015-08-16 Thread Noah Misch
On Sun, Aug 16, 2015 at 05:08:56PM -0400, Andrew Dunstan wrote: > On 08/16/2015 02:23 PM, Noah Misch wrote: > >>-sub tapcheck > >>+sub tap_check > >> { > >>- InstallTemp(); > >>+ die "Tap tests not enabled in configuration" > >>+ unless $config->{tap_tests}; > >I endorse Heikki's argument

Re: [HACKERS] TAP tests are badly named

2015-08-16 Thread Andrew Dunstan
On 08/16/2015 02:23 PM, Noah Misch wrote: -sub tapcheck +sub tap_check { - InstallTemp(); + die "Tap tests not enabled in configuration" + unless $config->{tap_tests}; I endorse Heikki's argument for having omitted the configuration flag: http://www.postgresql.org/message

Re: [HACKERS] TAP tests are badly named

2015-08-16 Thread Noah Misch
On Fri, Aug 14, 2015 at 09:31:43AM -0400, Andrew Dunstan wrote: > On 08/14/2015 09:27 AM, Andrew Dunstan wrote: > >The code > >is rearranged a little, and an incorrect piece of code setting > >$ENV{PERL5LIB} is fixed (in the case where it was previously empty it > >would have added a spurious ";" a

Re: [HACKERS] Raising our compiler requirements for 9.6

2015-08-16 Thread Tom Lane
Andres Freund writes: > On 2015-08-15 23:50:09 -0400, Noah Misch wrote: >> Solaris Studio 12.3 (newest version as of Oct 2014) still does that >> when optimization is disabled, and I place sufficient value on keeping >> inlining enabled for such a new compiler. > Ah, that's cool. I was wondering

Re: [HACKERS] Test code is worth the space

2015-08-16 Thread Greg Stark
On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch wrote: > When I've just spent awhile implementing a behavior change, the test diffs are > a comforting sight. They confirm that the test suite exercises the topic I > just changed. Furthermore, most tests today do not qualify under this > stringent met

Re: [HACKERS] Management of simple_eval_estate for plpgsql DO blocks

2015-08-16 Thread Simon Riggs
On 14 August 2015 at 17:42, Tom Lane wrote: > The simplest fix for this would be to give up on the idea that DO blocks > use private simple_eval_estates, and make them use the shared one. > However, that would result in intra-transaction memory bloat for > transactions executing large numbers of

Re: [HACKERS] Raising our compiler requirements for 9.6

2015-08-16 Thread Noah Misch
On Fri, Aug 14, 2015 at 08:40:13PM +0200, Andres Freund wrote: > > > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote: > > > > > + * lockdefs.h > > > > > + * Frontend exposed parts of postgres' low level lock mechanism > I actually think the split came out to work far better than I'd > anti