Re: [HACKERS] pg_resetsysid

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 di

Re: [HACKERS] pg_uuid_t support in contrib/btree_gist

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 `src/backend/utils/adt/uuid.c'. Yeah, I'd j

Re: [HACKERS] object_classes array is broken, again

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 con

[HACKERS] pg_uuid_t support in contrib/btree_gist

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] BRIN index and aborted transaction

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 a

Re: [HACKERS] pg_resetsysid

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 as

Re: [HACKERS] WAL test/verification tool

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 publicly >> released.

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

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 the addition of > >>AT_

Re: [HACKERS] pgbench stats per script & other stuff

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 improvement

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

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 > 2

Re: [HACKERS] BRIN index and aborted transaction

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 no

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

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 > blame: memory management for the pl