Re: [HACKERS] Allowing join removals for more join types

2014-05-18 Thread David Rowley
On Mon, May 19, 2014 at 5:47 PM, Dilip kumar wrote: > 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); > > > >

Re: [HACKERS] Allowing join removals for more join types

2014-05-18 Thread Dilip kumar
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,

Re: [HACKERS] 9.4 release notes

2014-05-18 Thread Bruce Momjian
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, Teod

Re: [HACKERS] 9.4 release notes

2014-05-18 Thread Bruce Momjian
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 p

Re: [HACKERS] 9.4 release notes

2014-05-18 Thread Bruce Momjian
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 l

Re: [HACKERS] 9.4 release notes

2014-05-18 Thread Bruce Momjian
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 wi

[HACKERS] Re: [GENERAL] Is it typo in pg_stat_replication column name in PG 9.4 ?

2014-05-18 Thread 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". > http://www.postgresql.org/docs/devel/static/monitoring-stats.html#PG-STAT-REPLIC

Re: [HACKERS] psql \db+ lack of size column

2014-05-18 Thread Fabrízio de Royes Mello
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 Consult

[HACKERS] cosmetic fixes

2014-05-18 Thread Euler Taveira
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:

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Andres Freund
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

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Andres Freund
On 2014-05-18 23:52:32 +0200, Andres Freund wrote: > On 2014-05-18 17:41:17 -0400, Tom Lane wrote: > > Christoph Berg 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

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Tom Lane
Andres Freund 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: >> https://bugzilla.redha

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Andres Freund
On 2014-05-18 17:41:17 -0400, Tom Lane wrote: > Christoph Berg 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 > >> u

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Tom Lane
Christoph Berg 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 depeest sta

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Christoph Berg
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 /proc/

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

2014-05-18 Thread Alvaro Herrera
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 > > compla

Re: [HACKERS] 9.4 release notes

2014-05-18 Thread Andrew Dunstan
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 allows

Re: [HACKERS] buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)

2014-05-18 Thread Tom Lane
Andres Freund 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: 1024 total in

Re: [HACKERS] Allowing join removals for more join types

2014-05-18 Thread David Rowley
On Sat, May 17, 2014 at 8:57 PM, David Rowley 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 table > that contain

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Andres Freund
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 thes

Re: [HACKERS] 9.4 beta1 crash on Debian sid/i386

2014-05-18 Thread Christoph Berg
Re: Tom Lane 2014-05-18 <9058.1400385...@sss.pgh.pa.us> > Christoph Berg 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. > > > u

[HACKERS] vacuumdb --all --analyze-in-stages - wrong order?

2014-05-18 Thread Pavel Stehule
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 has