Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

2015-07-18 Thread Michael Paquier
On Fri, Jul 17, 2015 at 11:37 PM, Tom Lane wrote: Geoff Winkless writes: While doing some testing of 9.5a one of my colleagues (not on list) found a reproducible server segfault. Hm, looks like commit 1345cc67bbb014209714af32b5681b1e11eaf964 is to

Re: [HACKERS] BRIN index and aborted transaction

2015-07-18 Thread Alvaro Herrera
Tatsuo Ishii wrote: When a transaction aborts, it seems a BRIN index leaves summary data which is not valid any more. Is this an expected behavior? I guess the answer is yes, because it does not affect correctness of a query result, but I would like to make sure. You're right, that is not

[HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

2015-07-18 Thread Alvaro Herrera
Heikki Linnakangas wrote: On 07/17/2015 05:40 PM, Michael Paquier wrote: On Fri, Jul 17, 2015 at 11:16 PM, Kevin Grittner wrote: Heikki Linnakangas wrote: This fixes bug #13126, reported by Kirill Simonov. It looks like you missed something with

Re: [HACKERS] pgbench stats per script other stuff

2015-07-18 Thread Fabien COELHO
Oops, as usual I forgot something... This v2 removes old stats code that was put in comment and simplify the logic when counting lag times, as they are now taken into account at the end of the transaction instead of at the beginning. This patch adds per-script statistics other

Re: [HACKERS] BRIN index and aborted transaction

2015-07-18 Thread Tatsuo Ishii
Alvaro, Thank you for the explanation. It's really helpfull. Second question is when the wrong summary data is gone? It seems vacuum does not help. Do I have to recreate the index (or reindex)? Yeah, that's a bit of an open problem: we don't have any mechanism to mark a block range as

Re: [HACKERS] [PERFORM] intel s3500 -- hot stuff

2015-07-18 Thread Julien Rouhaud
On 18/07/2015 12:03, Julien Rouhaud wrote: On 10/12/2014 17:52, Jeff Janes wrote: On Tue, Dec 9, 2014 at 12:43 PM, Bruce Momjian wrote: On Mon, Dec 8, 2014 at 03:40:43PM -0600, Merlin Moncure wrote: Did not see consistent measurable gains

Re: [HACKERS] WAL test/verification tool

2015-07-18 Thread Michael Paquier
On Sat, Jul 18, 2015 at 8:28 AM, Alvaro Herrera wrote: Thomas Munro wrote: I have heard rumours of a tool that could verify or compare the effects of applying WAL records for testing/development purposes, but I've been unable to track it down or find out if it was

Re: [HACKERS] pg_resetsysid

2015-07-18 Thread Petr Jelinek
On 2015-07-18 02:29, Peter Eisentraut wrote: On 6/14/15 11:29 AM, Petr Jelinek wrote: 0002 - Adds pg_resetsysid utility which changes the system id to newly generated one. 0003 - Adds -s option to pg_resetxlog to change the system id to the one specified - this is separate from the other one

[HACKERS] pg_uuid_t support in contrib/btree_gist

2015-07-18 Thread Jarred Ward
I'd like to add uuid support to contrib/btree_gist. Proposal: * Add `contrib/btree_gist/btree_uuid.c' with implementation based on gbtree_ninfo type description * Modify `contrib/btree_gist/btree_utils_num.c' to support pg_uuid_t * Modify `contrib/btree_gist/btree_gist.h' to add gbt_t_uuid type

Re: [HACKERS] object_classes array is broken, again

2015-07-18 Thread Alvaro Herrera
Robert Haas wrote: The transforms patch seems to have forgotten to add TransformRelationId to object_classes[], much like the RLS patch forgot to add PolicyRelationId in the same place. Fixing this is easy, but ISTM that we need to insert some sort of a guard to prevent people from

Re: [HACKERS] pg_uuid_t support in contrib/btree_gist

2015-07-18 Thread Tom Lane
Jarred Ward writes: pg_uuid_t is an opaque type in `src/include/utils/uuid.h'. To put this type in a struct for both a new uuidKEY and the gbtree_ninfo type description support we need the implementation of the struct that is currently hidden in

Re: [HACKERS] pg_resetsysid

2015-07-18 Thread Peter Eisentraut
On 7/18/15 9:42 AM, Petr Jelinek wrote: Well, last time I submitted this I did it exactly as you propose but there was long discussion about this changing the target audience of pg_resetxlog and that it would be better as separate binary from pg_resetxlog. In my reading of the thread, I did