On 2014-05-18 00:36:34 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-17 19:15:15 -0400, Tom Lane wrote:
... It appears to me that
the compiler is within its rights to refuse a nonconstant expression
for an inner initializer according to C89, though I don't
On 05/18/2014 12:23 AM, Tom Lane wrote:
A larger issue is that we evidently have no buildfarm animals that are
picky about alignment, or at least none that are running a modern-enough
buildfarm script to be running the contrib/logical_decoding test.
That seems like a significant gap. I don't
Hello
I am looking on --analyze-in-stages option. If I understand well,
motivation for this option is a get some minimal statistic for databases in
minimal time. But when I tested, I found so iterations are per databases,
not per stages - some first database get a maximum statistics and second
Re: Tom Lane 2014-05-18 9058.1400385...@sss.pgh.pa.us
Christoph Berg c...@df7cb.de writes:
Re: Tom Lane 2014-05-14 1357.1400028...@sss.pgh.pa.us
It would appear that something is wrong with check_stack_depth(),
and/or getrlimit(RLIMIT_STACK) is lying to us about the available stack.
On 2014-05-18 11:08:34 +0200, Christoph Berg wrote:
Interestingly, the Debian buildd managed to run the testsuite for
i386, while I could reproduce the problem on the pgapt build machine
and on my notebook, so there must be some system difference. Possibly
the reason is these two
On Sat, May 17, 2014 at 8:57 PM, David Rowley dgrowle...@gmail.com wrote:
I'm currently in the early stages of looking into expanding join removals.
Currently left outer joins can be removed if none of the columns of the
table are required for anything and the table being joined is a base
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-17 22:55:14 +0200, Tomas Vondra wrote:
And another memory context stats for a session executing CREATE INDEX,
while having allocated The interesting thing is there are ~11k lines
that look exactly like this:
pg_namespace_oid_index:
On 05/05/2014 07:26 PM, Andrew Dunstan wrote:
On 05/05/2014 07:16 PM, Bruce Momjian wrote:
Current text is:
Add structured (non-text) data type (JSONB) for storing JSON data
(Oleg
Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, and
Andrew
Dunstan)
This
Andres Freund wrote:
On 2014-05-17 23:35:43 +0200, Christoph Berg wrote:
Fwiw, this wasn't the first time I've heard of that idea, it also
doesn't sound too far-fetched for me. I guess people usually go damn,
I can't rename active dbs, let's try something else instead of
complaining on
Re: Andres Freund 2014-05-18 20140518091445.gu23...@alap3.anarazel.de
Did you measure how large the stack actually was when you got the
SIGBUS? Should be possible to determine that by computing the offset
using some local stack variable in one of the depeest stack frames.
Looking at
Christoph Berg c...@df7cb.de writes:
Re: Andres Freund 2014-05-18 20140518091445.gu23...@alap3.anarazel.de
Did you measure how large the stack actually was when you got the
SIGBUS? Should be possible to determine that by computing the offset
using some local stack variable in one of the
On 2014-05-18 17:41:17 -0400, Tom Lane wrote:
Christoph Berg c...@df7cb.de writes:
Re: Andres Freund 2014-05-18 20140518091445.gu23...@alap3.anarazel.de
Did you measure how large the stack actually was when you got the
SIGBUS? Should be possible to determine that by computing the offset
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-18 17:41:17 -0400, Tom Lane wrote:
OK, so the problem is that getrlimit(RLIMIT_STACK) is lying to us about
the available stack depth. I'd classify that as a kernel bug. I wonder
if it's a different manifestation of this issue:
On 2014-05-18 23:52:32 +0200, Andres Freund wrote:
On 2014-05-18 17:41:17 -0400, Tom Lane wrote:
Christoph Berg c...@df7cb.de writes:
Re: Andres Freund 2014-05-18 20140518091445.gu23...@alap3.anarazel.de
Did you measure how large the stack actually was when you got the
SIGBUS? Should
On 2014-05-18 17:56:48 -0400, Tom Lane wrote:
The bad news is that the kernel guys have been ignoring the issue
for over a year. Dunno if some pressure from the Debian camp would
help raise their priority for this.
I guess we should forward the bug to the lkml/linux-mm lists. I think a
fair
Hi,
Here are some more trivial fixes in pg_recvlogical message style.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From 0bbf437b490a92afa4b14e4903188bcf795f8e47 Mon Sep 17 00:00:00 2001
From:
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.
Regards,
--
Fabrízio de Royes Mello
On 18-05-2014 05:40, Raghavendra wrote:
Hi,
PostgreSQL 9.4 document for pg_stat_replication view mentions column name
as backend_xid, whereas when a view described it shows column name as
backend_xmin.
On Fri, May 16, 2014 at 02:10:40AM +0200, Andres Freund wrote:
On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
I have completed the initial version of the 9.4 release notes. You can
view them here:
http://www.postgresql.org/docs/devel/static/release-9-4.html
I will be adding
On Fri, May 16, 2014 at 02:10:40AM +0200, Andres Freund wrote:
I am not really sure how to rewrite the notes for the logical decoding
stuff into a more appropriate format for the release notes. Currently it
seems to describe too many details and not enough overview. It's also
probably too
On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
Some errors and suggestions - my apologizes for the format as I do not have
a proper patching routine setup.
Patch Review - Top to Bottom (mostly, I think...)
I have made your suggested adjustments in the attached applied
On Sun, May 18, 2014 at 04:08:41PM -0400, Andrew Dunstan wrote:
On 05/05/2014 07:26 PM, Andrew Dunstan wrote:
On 05/05/2014 07:16 PM, Bruce Momjian wrote:
Current text is:
Add structured (non-text) data type (JSONB) for storing JSON
data (Oleg
Bartunov, Teodor Sigaev, Alexander
On 18 May 2014 16:38 David Rowley Wrote
Sound like a good idea to me..
I have one doubt regarding the implementation, consider the below query
Create table t1 (a int, b int);
Create table t2 (a int, b int);
Create unique index on t2(b);
select x.a from t1 x left join (select distinct t2.a a1,
23 matches
Mail list logo
