Hi,
the current tcl version is 8.6, and configure should recognize it. The
attached patch has been in the Debian/Ubuntu packages for a while, so
it's tested.
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
diff --git a/config/tcl.m4 b/config/tcl.m4
new file mode 100644
index e886057..a9fe7ba
Hi,
to support ppc64le, config.guess needs to be updated. The attached
patch is what was reported to work for Ubuntu.
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
diff --git a/config/config.guess b/config/config.guess
new file mode 100755
index 2055429..b79252d
*** a/config/config.guess
On 9 May 2014 02:40, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 8 May 2014 20:40, Robert Haas robertmh...@gmail.com wrote:
For my money, we'd be better off
getting some kind of basic custom scan node functionality committed
first, even if the
Hello,
Done. Attached is the updated version of the patch.
I was trying to check WAL reduction using this patch on latest available git
version of Postgres using JDBC runner with tpcc benchmark.
patching_problems.txt
http://postgresql.1045698.n5.nabble.com/file/n5803482/patching_problems.txt
On Sat, May 10, 2014 at 2:43 AM, Michael Paquier
michael.paqu...@gmail.comwrote:
On Fri, May 9, 2014 at 10:49 PM, Fujii Masao masao.fu...@gmail.com
wrote:
On Fri, May 9, 2014 at 10:03 PM, Andres Freund and...@2ndquadrant.com
wrote:
You plan to commit it?
Yes unless many people object
Christoph Berg c...@df7cb.de writes:
the current tcl version is 8.6, and configure should recognize it. The
attached patch has been in the Debian/Ubuntu packages for a while, so
it's tested.
While that patch looks harmless enough, I'm curious why you'd need it
--- isn't tcl installed as plain
Christoph Berg c...@df7cb.de writes:
to support ppc64le, config.guess needs to be updated. The attached
patch is what was reported to work for Ubuntu.
Our normal procedure is
o update config.guess and config.sub at the start of beta
(from
Sameer Thakur samthaku...@gmail.com writes:
I was trying to check WAL reduction using this patch on latest available git
version of Postgres using JDBC runner with tpcc benchmark.
patching_problems.txt
http://postgresql.1045698.n5.nabble.com/file/n5803482/patching_problems.txt
I did
From: Amit Kapila amit.kapil...@gmail.com
I think it's bit late for this patch for 9.4, you might want to move it to
next CF.
Thanks, I've moved it. It's a regret that this very small patch wasn't put
in 9.4.
Regards
MauMau
--
Sent via pgsql-hackers mailing list
On Fri, 2014-05-09 at 17:16 -0400, Stephen Frost wrote:
Guillaume,
* Guillaume Lelarge (guilla...@lelarge.info) wrote:
Should information_schema tables be moved and not pg_catalog ones? it
doesn't seem consistent to me.
The catalog tables are moved by changing the database's tablespace,
On 2014-05-10 00:59:59 -0400, Noah Misch wrote:
On Fri, May 09, 2014 at 04:58:54PM +0200, Andres Freund wrote:
On 2014-05-09 10:49:09 -0400, Robert Haas wrote:
Patch 03: Add valgrind suppression for writing out padding bytes. That's
better than zeroing the data from the get go because
Re: Tom Lane 2014-05-10 27409.1399729...@sss.pgh.pa.us
Christoph Berg c...@df7cb.de writes:
the current tcl version is 8.6, and configure should recognize it. The
attached patch has been in the Debian/Ubuntu packages for a while, so
it's tested.
While that patch looks harmless enough,
Re: Tom Lane 2014-05-10 27476.1399729...@sss.pgh.pa.us
Christoph Berg c...@df7cb.de writes:
to support ppc64le, config.guess needs to be updated. The attached
patch is what was reported to work for Ubuntu.
Our normal procedure is
o update config.guess and config.sub at the start
On 9.5.2014 00:47, Tomas Vondra wrote:
On 8.5.2014 23:48, Andrew Dunstan wrote:
On 05/08/2014 05:21 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I really don't get what your objection to the setup is. And no, I
don't want them to run concurrently, I'd rather spread out the
cycles.
I
Hackers,
GIN hangs on lossy bitmap scan. Here is test case:
create extension btree_gin;
create table test as (select random() v from generate_series(1,100));
create index test_idx on test using gin(v);
set work_mem = '16MB';
select count(*) from test where v 0.9;
count
───
99916
(1
* Simon Riggs (si...@2ndquadrant.com) wrote:
What I have said is that authors of CustomJoins or CustomScans should
declare in advance via system catalogs which operators their new code
works with so that Postgres knows when it is appropriate to call them.
I guess I just took that as given,
* Guillaume Lelarge (guilla...@lelarge.info) wrote:
Thanks for the explanation. I should have RTFM before complaining. Sorry
for the noise :)
No prob. If people don't feel that makes sense then we can still change
it.. I don't feel particularly strongly either way, though I seem to
recall my
On Fri, May 9, 2014 at 10:44 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Wouldn't a better name be recovery_min_apply_delay?
+1
Works for me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Sat, May 10, 2014 at 8:33 PM, Sameer Thakur samthaku...@gmail.com wrote:
Hello,
Done. Attached is the updated version of the patch.
I was trying to check WAL reduction using this patch on latest available git
version of Postgres using JDBC runner with tpcc benchmark.
patching_problems.txt
On 05/10/2014 10:41 PM, Alexander Korotkov wrote:
Hackers,
GIN hangs on lossy bitmap scan. Here is test case:
create extension btree_gin;
create table test as (select random() v from generate_series(1,100));
create index test_idx on test using gin(v);
set work_mem = '16MB';
select count(*)
On 05/09/2014 11:44 PM, Tom Lane wrote:
Greg Stark st...@mit.edu writes:
Well the question seems to me to be that if we're always doing recheck
then what advantage is there to not hashing everything?
Right now, there's not much. But it seems likely to me that there will be
more JSON
On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
The main difference between the two opclasses from a user's standpoint
is not whether they hash or not. The big difference is that one
indexes complete paths from the root, and the other indexes just the
leaf level. For example, if you have
On Sat, May 10, 2014 at 9:51 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Fri, May 9, 2014 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
On Fri, May 9, 2014 at 8:42 PM, Tom Lane t...@sss.pgh.pa.us
+1
but bit confused with json instead of jsonb
On Sun, May 11, 2014 at 1:00 AM, Andrew Dunstan and...@dunslane.net wrote:
On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
The main difference between the two opclasses from a user's standpoint is
not whether they hash or not. The big
On 2014-05-11 06:02:23 +0900, Fujii Masao wrote:
On Sat, May 10, 2014 at 9:51 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Fri, May 9, 2014 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[ shrug... ] proactive would have been doing this a month ago.
If we're going to
Andres Freund and...@2ndquadrant.com writes:
I don't even understand why it's questionable whether this should be
fixed.
Sigh. We have some debate isomorphic to this one every year, it seems
like. The argument why it shouldn't be fixed now is: ITS. TOO. LATE.
Which part of that isn't clear to
On Sat, May 10, 2014 at 1:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
For example, if you have an object like '{foo: {bar: 123 } }', one will
index foo, foo-bar, and foo-bar-123 while the other will index
foo, bar and 123.
That isn't quite right, if we're talking about the user's
Andrew Dunstan and...@dunslane.net writes:
On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
Whether the opclasses use hashing to shorten the key is an orthogonal
property, and IMHO not as important. To reflect that, I suggest that
we name the opclasses:
json_path_ops
json_value_ops
On Sat, May 10, 2014 at 5:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 9, 2014 at 10:44 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Wouldn't a better name be recovery_min_apply_delay?
+1
Works for me.
Done!!
--
Fabrízio de Royes Mello
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
On Sat, May 10, 2014 at 5:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 9, 2014 at 10:44 PM, FabrÃzio de Royes Mello
fabriziome...@gmail.com wrote:
Wouldn't a better name be recovery_min_apply_delay?
+1
On Sat, May 10, 2014 at 6:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
I don't even understand why it's questionable whether this should be
fixed.
Sigh. We have some debate isomorphic to this one every year, it seems
like. The argument why it
On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote:
On Sat, May 10, 2014 at 6:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
I don't even understand why it's questionable whether this should be
fixed.
Sigh. We have some debate
On Sun, May 11, 2014 at 12:27 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote:
On Sat, May 10, 2014 at 6:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
I don't even understand why it's
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote:
Sorry but I don't understand why it's too late. The 9.4 branch not been
created yet.
The problem is that once the beta is in progress (starting tomorrow),
the projects tries to avoid
On Sat, May 10, 2014 at 7:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote:
On Sat, May 10, 2014 at 6:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
I don't even understand why it's
On 2014-05-11 00:31:09 +0200, Magnus Hagander wrote:
On Sun, May 11, 2014 at 12:27 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-10 19:19:22 -0300, Fabrízio de Royes Mello wrote:
On Sat, May 10, 2014 at 6:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund
On Sun, May 11, 2014 at 7:39 AM, Andres Freund and...@2ndquadrant.com wrote:
(makes me really wish betas were properly tagged with git as well...)
They are tags for betas, here is for example the update of CATVERSION for 9.3:
$ git log -p REL9_3_BETA1..REL9_3_0 src/include/catalog/catversion.h |
On Sat, May 10, 2014 at 12:30 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, May 9, 2014 at 7:01 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, May 9, 2014 at 1:06 PM, Amit Kapila amit.kapil...@gmail.com wrote:
There is no harm in forbidding data_directory, but similarly we can
Magnus Hagander mag...@hagander.net writes:
On Sun, May 11, 2014 at 12:27 AM, Andres Freund and...@2ndquadrant.comwrote:
The problem is that once the beta is in progress (starting tomorrow),
the projects tries to avoid changes which require a dump and restore (or
pg_upgrade). Since the patch
On 2014-05-10 19:08:48 -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, May 11, 2014 at 12:27 AM, Andres Freund
and...@2ndquadrant.comwrote:
The problem is that once the beta is in progress (starting tomorrow),
the projects tries to avoid changes which require a
On Sat, May 10, 2014 at 9:45 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Last night I sent a patch [1] to add more tests and change the operator
name. Maybe we can merge the test cases... ;-)
Sure, I noticed that. But I think that they are more complicated than
necessary. I am as
On Sun, May 11, 2014 at 8:17 AM, Andres Freund and...@2ndquadrant.com wrote:
Anyway. I accept it's too late for beta1 now. Let's commit it if there's
another catversion bump.
+1. Let's rely on the experience of senior committers here.
--
Michael
--
Sent via pgsql-hackers mailing list
On Sat, May 10, 2014 at 2:52 PM, Peter Geoghegan p...@heroku.com wrote:
I've added a wildcard to the rhs jsonb here, which of course won't
work, the proximate cause being that that simply isn't valid jsonb.
It's also something inherently impossible to support with the current
jsonb_hash_op's
Peter Geoghegan p...@heroku.com writes:
Now, I'm not all that worried about this, because this is surely an
odd-ball use case, particularly for jsonb_hash_ops where no keys are
separately indexed (separately from *primitive* elements/values).
However, it is worth noting in the documentation in
On Sat, May 10, 2014 at 5:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure whether we have consensus to rename jsonb_hash_ops to
jsonb_path_ops, but since time is so short I went ahead and made a draft
patch to do so (attached). Probably the most interesting part of this is
the new text
Peter Geoghegan p...@heroku.com writes:
On Sat, May 10, 2014 at 5:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
+ especially if
+ there are a very large number of rows containing any single one of the
+ three keys
I suggest that you phrase this as three index items.
Good idea ---
On Sun, May 11, 2014 at 4:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
ISTM that data_directory is in different situation from the other. That is,
setting data_directory in postgresql.auto.conf is problematic whether its
setting value is valid or invalid. Imagine the case where
On Thu, Mar 13, 2014 at 3:49 AM, Rukh Meski rukh.me...@yahoo.ca wrote:
Oops. Of course shouldn't try and change how INSERT works. Latest version
attached.
I had given a brief look into this patch and found that the
implementation for Update .. ORDER BY is not appropriate for
inheritance
48 matches
Mail list logo
