On Fri, Jul 17, 2015 at 11:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Geoff Winkless pgsqlad...@geoff.dj 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
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
Heikki Linnakangas wrote:
On 07/17/2015 05:40 PM, Michael Paquier wrote:
On Fri, Jul 17, 2015 at 11:16 PM, Kevin Grittner kgri...@ymail.com wrote:
Heikki Linnakangas heikki.linnakan...@iki.fi wrote:
This fixes bug #13126, reported by Kirill Simonov.
It looks like you missed something with
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
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
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 br...@momjian.us
mailto:br...@momjian.us wrote:
On Mon, Dec 8, 2014 at 03:40:43PM -0600, Merlin Moncure wrote:
Did not see consistent measurable gains
On Sat, Jul 18, 2015 at 8:28 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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
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
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
Jarred Ward jar...@webriots.com 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
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
12 matches
Mail list logo
