Hi.
We're now at the nearly done stage of the first 9.5 CF.
Twenty-four patches have been committed so far, and five more are ready
for committer (and of those, four are small). Thirty patches are still
marked needs review, and twenty-one are waiting on author.
I'll go through the patches and
On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I had another look at this and it appears you were right the first time,
we
need to ensure there's no NULLs on both sides of the join condition.
Ugh. I'm back to being
Hello, Let me apologize for continuing the discussion even though
the deadline is approaching.
At Fri, 11 Jul 2014 09:49:55 +0900, Michael Paquier michael.paqu...@gmail.com
wrote in cab7npqtjezoz-fotibsejyg0eabngx2plqywodchyfxzfqy...@mail.gmail.com
Updated patches attached.
On Thu, Jul 10,
Kaigai-san,
The v3 patch had conflict in src/backend/tcop/utility.c for newly
added IMPORT FOREIGN SCHEMA statement, but it was trivial.
2014-07-08 20:55 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
* System catalog name was changed to pg_custom_plan_provider;
that reflects role of the
Hi.
Do we have any consensus on this patch?
I took a quick look at it because no review was posted. The patch itself
does what it claims to, but from the discussion it doesn't seem like we
want the feature; or perhaps we only don't want it in its present form.
So which is more appropriate,
At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
Hm. Not sure what you're ACKing here ;).
The idea of giving the unallocated memory a NULL key.
Ok. A new version of the patches implementing that are attached.
Including a couple of small fixups and docs. The latter aren't
Fujita-san,
2014-07-11 18:22 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
I think the following comment for store_returning_result() in
postgres_fdw.c is not right.
/* PGresult must be released before leaving this function. */
I think PGresult should not be released before
Thank you for reviewing, the revised patch will come later.
At Mon, 14 Jul 2014 11:01:52 +0530, Amit Kapila amit.kapil...@gmail.com wrote
in caa4ek1+6b6wjwf51ozmrl+mkfh8xup9j-pehqvor8se7swy...@mail.gmail.com
On Fri, Jun 13, 2014 at 1:11 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp
On Mon, Jul 14, 2014 at 7:31 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
Fujita-san,
2014-07-11 18:22 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
I think the following comment for store_returning_result() in
postgres_fdw.c is not right.
/* PGresult must be released
Abhijit Menon-Sen a...@2ndquadrant.com writes:
Do we have any consensus on this patch?
I took a quick look at it because no review was posted. The patch itself
does what it claims to, but from the discussion it doesn't seem like we
want the feature; or perhaps we only don't want it in its
On Fri, Jul 11, 2014 at 7:21 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jul 11, 2014 at 5:45 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
blocks for a bitmap heap scan when both the numbers of exact/lossy
At 2014-07-14 07:55:34 -0400, t...@sss.pgh.pa.us wrote:
I'd vote for rejecting and annotating the TODO item with a link to
this thread.
I've marked the patch as rejected and edited the TODO list to remove the
easy. There was already a link to this thread there.
Thank you.
-- Abhijit
--
On Mon, Jul 14, 2014 at 3:21 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
Hi.
We're now at the nearly done stage of the first 9.5 CF.
Twenty-four patches have been committed so far, and five more are ready
for committer (and of those, four are small). Thirty patches are still
marked
David Rowley dgrowle...@gmail.com writes:
On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ugh. I'm back to being discouraged about the usefulness of the
optimization.
Are you worried about the planning overhead of the not null checks, or is
it more that you think there's
On Mon, Jul 14, 2014 at 4:02 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
At Mon, 14 Jul 2014 11:01:52 +0530, Amit Kapila amit.kapil...@gmail.com
wrote in caa4ek1+6b6wjwf51ozmrl+mkfh8xup9j-pehqvor8se7swy...@mail.gmail.com
On Fri, Jun 13, 2014 at 1:11 PM, Kyotaro HORIGUCHI
On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin
christoph.r.mar...@gmail.com wrote:
I noticed a minor inconsistency with the search_path separator used in the
default configuration.
The schemas of any search_path set using `SET search_path TO...` are
separated by , (comma, space), while
On Fri, Jul 11, 2014 at 2:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This example in the regression database is a simplified version of a bug
I was shown off-list:
regression=# select (
select q from
( select 1,2,3 where f10
union all
select 4,5,6.0 where f1=0
) q
)
from int4_tbl;
True. Both variants are legal, and most people won't ever notice. I
stumbled across this while writing a test case for a transaction helper
that sets/restores search_path before committing. The test was to simply
compare the string values of `SHOW search_path;` before `BEGIN
TRANSACTION;` and
On Sun, Jul 13, 2014 at 2:23 PM, Andres Freund and...@2ndquadrant.com wrote:
The actual if (lock != NULL) bit costs significant amounts of cycles?
I'd have assumed that branch prediction takes care of that. Or is it
actually the icache not keeping up? Did you measure icache vs. dcache
misses?
On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
Uh, why does this need to be in ALTER TABLE? Can't this be part of
table creation done by pg_dump?
Uh, I think you need to read the thread. We have to
On 2014-07-14 11:24:26 -0400, Robert Haas wrote:
On Sun, Jul 13, 2014 at 2:23 PM, Andres Freund and...@2ndquadrant.com wrote:
The actual if (lock != NULL) bit costs significant amounts of cycles?
I'd have assumed that branch prediction takes care of that. Or is it
actually the icache not
On 07/06/2014 10:11 AM, Andres Freund wrote:
Hi Steve,
Right. I thought about this for a while, and I think we should change
two things. For one, don't request replies here. It's simply not needed,
as this isn't dealing with timeouts. For another don't just check -flush
sentPtr but also
On Mon, Jul 14, 2014 at 12:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
Uh, why does this need to be in ALTER TABLE? Can't this be part of
table
On Thu, Jun 12, 2014 at 2:09 PM, Peter Geoghegan p...@heroku.com wrote:
Right. It was a little bit incautious of me to say that we had the
full benefit of 8 bytes of storage with en_US.UTF-8, since that is
only true of lower case characters (I think that FreeBSD can play
tricks with this.
On 07/13/2014 10:35 PM, Magnus Hagander wrote:
On Sun, Jul 13, 2014 at 10:32 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
On 07/12/2014 03:08 PM, Magnus Hagander wrote:
As an administrator, I find that you fairly often want to know what
your current connections are actually using
On Mon, Jul 14, 2014 at 2:53 PM, Peter Geoghegan p...@heroku.com wrote:
My concern is that it won't be worth it to do the extra work,
particularly given that I already have 8 bytes to work with. Supposing
I only had 4 bytes to work with (as researchers writing [2] may have
only had in 1994),
On Mon, Jul 14, 2014 at 6:20 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
Hm. Not sure what you're ACKing here ;).
The idea of giving the unallocated memory a NULL key.
Ok. A new version of the patches implementing that are
On Mon, Jul 14, 2014 at 11:03 AM, Claudio Freire klaussfre...@gmail.com wrote:
Are those numbers measured on MAC's strxfrm?
That was the one with suboptimal entropy on the first 8 bytes.
No, they're from a Linux system which uses glibc 2.19. The
optimization will simply be not used on
Re: Fabrízio de Royes Mello 2014-07-12
cafcns+qf5fukkp9vdjwokiabn_rrm4+hjqxeevpd_7-to0l...@mail.gmail.com
... that being the non-WAL-logging with wal_level=minimal, or more?
This is the first of additional goals, but we have others. Please see [1].
Oh I wasn't aware of the wiki page, I had
On Mon, Jul 14, 2014 at 11:26:19AM -0400, Robert Haas wrote:
On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian br...@momjian.us wrote:
On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
Uh, why does this need to be in ALTER TABLE? Can't this be part of
table creation done by
Re: Noah Misch 2014-07-12 20140712170151.ga1985...@tornado.leadboat.com
Thanks. Preliminary questions:
+#ifdef HAVE_UNIX_SOCKETS
+/* make_temp_sockdir() is invoked at most twice from pg_upgrade.c via
get_sock_dir() */
+#define MAX_TEMPDIRS 2
+static int n_tempdirs = 0; /* actual
Re: Andres Freund 2014-07-12 20140712135128.gd3...@awork2.anarazel.de
I'm also not really happy with the fact that we only complete a single
search_path item. But it's not easy to do better and when looking around
other places (e.g. DROP TABLE) don't support it either.
The difference is that
On 2014-07-11 09:55:34 -0400, Bruce Momjian wrote:
On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
Uh, why does this need to be in ALTER TABLE? Can't this be part of
table creation done by pg_dump?
Uh, I think you need to read the thread. We have to delay the toast
populate_record_worker in jsonfuncs.c says this:
if (get_call_result_type(fcinfo, NULL, tupdesc) != TYPEFUNC_COMPOSITE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg(function returning record called in context
On Wed, Jul 9, 2014 at 5:16 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
The way it works now, each opclass needs to have three support
procedures; I've called them getOpers, maybeUpdateValues, and compare.
(I realize these names are pretty bad, and will be changing them.)
getOpers is
On 07/14/2014 03:44 PM, Robert Haas wrote:
populate_record_worker in jsonfuncs.c says this:
if (get_call_result_type(fcinfo, NULL, tupdesc) != TYPEFUNC_COMPOSITE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
On Mon, Jul 14, 2014 at 4:39 PM, Andrew Dunstan and...@dunslane.net wrote:
Is there any reasonable alternative? That is, if you have a function
returning SETOF record, and the details of the record type aren't
specified, is there anything you can do other than error out like
this?
Not that
Robert Haas wrote:
On Mon, Jul 14, 2014 at 6:20 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
Hm. Not sure what you're ACKing here ;).
The idea of giving the unallocated memory a NULL key.
Ok. A new version of the
Is there an easy way to get a list of held lwlocks out of gdb attached to a
core dump (or for that matter attached to a live process)?
I can try manually walking the internal data structure, but I am hoping for
something analogous to the way you get memory contexts:
(gdb) p
On 07/14/2014 04:46 PM, Robert Haas wrote:
On Mon, Jul 14, 2014 at 4:39 PM, Andrew Dunstan and...@dunslane.net wrote:
Is there any reasonable alternative? That is, if you have a function
returning SETOF record, and the details of the record type aren't
specified, is there anything you can do
Jaime Casanova wrote:
Attached is a patch moving the reloptions of views into its own structure.
i also created a view_reloptions() function in order to not use
heap_reloptions() for views, but maybe that was too much?
No, that was part of what I was thinking too -- I have pushed this now.
Fabrízio de Royes Mello wrote:
On Fri, May 16, 2014 at 2:03 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Hi all,
Are there some reason to don't show the tablespace size in the \db+
psql command?
The attached patch show tablespace size in \db+ psql command.
Thanks,
On Sat, Jul 12, 2014 at 8:49 AM, Magnus Hagander mag...@hagander.net wrote:
It's today really hard to figure out if your SSL connection is
actually *using* SSL compression. This got extra hard when we the
default value started getting influenced by environment variables at
least on many
On Sun, Jul 13, 2014 at 2:27 AM, Mitsumasa KONDO
kondo.mitsum...@gmail.com wrote:
I still agree with Fabien-san. I cannot understand why our logical proposal
isn't accepted...
Well, I think the feedback has been pretty clear, honestly. Here's
what I'm unhappy about: I can't understand what
(2014/07/14 19:46), Fujii Masao wrote:
On Mon, Jul 14, 2014 at 7:31 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
Fujita-san,
2014-07-11 18:22 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
I think the following comment for store_returning_result() in
postgres_fdw.c is not right.
On Mon, Jul 14, 2014 at 3:31 PM, Christoph Berg c...@df7cb.de wrote:
Oh I wasn't aware of the wiki page, I had just read the old thread.
Thanks for the pointer.
:-)
Thanks again for your review!
diff --git a/doc/src/sgml/ref/alter_table.sgml
b/doc/src/sgml/ref/alter_table.sgml
(2014/07/14 21:01), Fujii Masao wrote:
On Fri, Jul 11, 2014 at 7:21 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jul 11, 2014 at 5:45 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
blocks for a bitmap heap scan
At 2014-07-14 16:48:09 -0400, alvhe...@2ndquadrant.com wrote:
The attachments are there on the archives, and also on my mbox -- and
unlike Robert, I was not copied. I think this is a problem on
Abhijit's end.
Yes, it is. I apologise for the noise.
-- Abhijit
--
Sent via pgsql-hackers
On 12 July 2014 23:25, Emre Hasegeli Wrote,
I have one last comment, after clarifying this I can move it to
ready for committer.
1. In networkjoinsel, For avoiding the case of huge statistics, only
some of the values from mcv and histograms are used (calculated using
SQRT).
-- But in my
49 matches
Mail list logo
