On Mon, May 19, 2014 at 5:47 PM, Dilip kumar dilip.ku...@huawei.com 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);
On Mon, May 19, 2014 at 10:05 AM, Fabrízio de Royes Mello
fabri...@timbira.com.br wrote:
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 Mon, May 19, 2014 at 6:35 AM, Fabrízio de Royes Mello
fabri...@timbira.com.br wrote:
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
Re: Tom Lane 2014-05-18 26862.1400449...@sss.pgh.pa.us
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 19 May 2014 12:15 David Rowley Wrote,
I think you are right here, it would be correct to remove that join, but I
also think that the query in question could be quite easily be written as:
select t1.a from t1 left join t2 on t1.a=t2.b;
Where the join WILL be removed. The distinct clause here
On 05/18/2014 06:30 AM, Jeff Janes wrote:
On Saturday, May 17, 2014, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/17/2014 12:28 AM, Jeff Janes wrote:
More fun with my torn page injection test program on 9.4.
24171 2014-05-16 14:00:44.934 PDT:WARNING: 01000: page verification
pg_isready has --username:
-U, --username=USERNAME user name to connect as
so is replying when given a non-existent user not a bug?
pg_isready --username= -p 6544
/tmp:6544 - accepting connections
There is no user . (PG envvars are removed)
Thanks,
Erik Rijkers
--
Sent
On 05/19/2014 02:36 AM, Euler Taveira wrote:
Hi,
Here are some more trivial fixes in pg_recvlogical message style.
Thanks, applied.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 05/19/2014 01:37 PM, Erik Rijkers wrote:
pg_isready has --username:
-U, --username=USERNAME user name to connect as
so is replying when given a non-existent user not a bug?
pg_isready --username= -p 6544
/tmp:6544 - accepting connections
There is no user . (PG envvars are
Re: To Tom Lane 2014-05-19 20140519091808.ga7...@msgid.df7cb.de
Re: Tom Lane 2014-05-18 26862.1400449...@sss.pgh.pa.us
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
On 2014-05-19 13:53:18 +0200, Christoph Berg wrote:
I've done some more digging. The problem exists also on plain 32bit
kernels, not only 64bit running a 32bit userland. (Tested on Debian
Wheezy's 3.2.57 kernel.)
Too bad.
Debian/Ubuntu have been using hardened PostgreSQL builds for years
Hi,
On 2014-05-19 13:53:18 +0200, Christoph Berg wrote:
* PostgreSQL allocates lots of heap using brk() instead of mmap()
It doesn't really do that, btw. It's the libc's mmap that makes those
decisions, not postgres.
Greetings,
Andres Freund
--
Andres Freund
Andres Freund and...@2ndquadrant.com writes:
Isn't the far more obvious thing ot just not build postgres with -pie on
32bit? It's hardly a security benefit if it allows plain user to crash
the server.
Yeah, that's what I was doing when I was at Red Hat --- PIE mode would
be nice, but not when
On 2014-05-19 09:53:11 -0400, Tom Lane wrote:
I think throwing an error out of a SIGBUS handler is right out. There
would be no way to know exactly what code we were interrupting. It's
the same reason we don't let, eg, the SIGALRM handler throw a timeout
error directly (in most places
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.
Sorry, let me address some items I skipped on your list:
IIUC: Logical decoding allows for streaming of
Re: Andres Freund 2014-05-19 20140519141221.gc5...@alap3.anarazel.de
On 2014-05-19 09:53:11 -0400, Tom Lane wrote:
I think throwing an error out of a SIGBUS handler is right out. There
would be no way to know exactly what code we were interrupting. It's
the same reason we don't let, eg,
Hi,
On 2014-05-18 14:49:10 -0400, Tom Lane wrote:
AFAICT, the inner invocation's Relation should always have zero reference
count by the time we get back to the outer invocation. Therefore it
should be possible for RelationCacheInsert to just delete the
about-to-be-unreachable Relation
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-18 14:49:10 -0400, Tom Lane wrote:
if (RelationHasReferenceCountZero(oldrel))
RelationDestroyRelation(oldrel, false);
else
elog(WARNING, leaking still-referenced duplicate relation);
If that happens we'd essentially have a too
On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian br...@momjian.us wrote:
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.
Sorry, let me address some items I
On Mon, May 19, 2014 at 12:36 AM, Bruce Momjian br...@momjian.us wrote:
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
On 2014-05-19 11:25:04 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-18 14:49:10 -0400, Tom Lane wrote:
if (RelationHasReferenceCountZero(oldrel))
RelationDestroyRelation(oldrel, false);
else
elog(WARNING, leaking still-referenced duplicate
Re: To Tom Lane 2014-05-19 20140519144717.gg7...@msgid.df7cb.de
Disabling -pie for all 32bit archs seems to be the way to go for us
now.
FTR, I've just had a look at armhf (arm-linux-gnueabihf), the address
layout looks exactly the same there, and 9.3 crashes easily, so it's
really a problem of
Christoph Berg c...@df7cb.de writes:
FTR, I've just had a look at armhf (arm-linux-gnueabihf), the address
layout looks exactly the same there, and 9.3 crashes easily, so it's
really a problem of all Linux 32bit archs. I'm puzzled the regression
tests passed there [1], but anyway, we'll
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-19 11:25:04 -0400, Tom Lane wrote:
No, we'd have two independent entries, each with its own correct refcount.
When the refcount on the no-longer-linked-in-the-hashtable entry goes to
zero, it'd be leaked, same as it's always been. (The
On 5/18/14, 3:52 AM, Pavel Stehule wrote:
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
On 5/18/14, 12:28 AM, Tom Lane wrote:
So, having seen that proof-of-concept, I'm wondering if we shouldn't make
an effort to support contrib/uuid-ossp with a choice of UUID libraries
underneath it. There is a non-OSSP set of UUID library functions
available on Linux (libuuid from
On 18.5.2014 20:49, Tom Lane wrote:
With both of these things fixed, I'm not seeing any significant memory
bloat during the first parallel group of the regression tests. I don't
think I'll have the patience to let it run much further than that
(the uuid and enum tests are still running after
On 17.5.2014 22:35, Tomas Vondra wrote:
On 17.5.2014 19:58, Andrew Dunstan wrote:
On 05/15/2014 07:47 PM, Tomas Vondra wrote:
On 15.5.2014 22:07, Andrew Dunstan wrote:
Yes, I've seen that. Frankly, a test that takes something like 500
hours is a bit crazy.
Maybe. It certainly is not a test
On Mon, May 19, 2014 at 3:32 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/18/2014 06:30 AM, Jeff Janes wrote:
On Saturday, May 17, 2014, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
The seems to have fixed it.
Okay, thanks, committed.
Your torn-page generator
Tomas Vondra t...@fuzzy.cz writes:
On 18.5.2014 20:49, Tom Lane wrote:
With both of these things fixed, I'm not seeing any significant memory
bloat during the first parallel group of the regression tests. I don't
think I'll have the patience to let it run much further than that
(the uuid and
Attached patch makes minor adjustment to a comment that is no longer
accurate (as of commit ff7bbb01).
--
Peter Geoghegan
*** a/src/backend/utils/adt/jsonb_util.c
--- b/src/backend/utils/adt/jsonb_util.c
*** convertJsonbScalar(StringInfo buffer, JE
*** 1462,1468
/*
*
Peter Geoghegan p...@heroku.com writes:
Attached patch makes minor adjustment to a comment that is no longer
accurate (as of commit ff7bbb01).
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 05/19/2014 03:40 PM, Tomas Vondra wrote:
On 17.5.2014 22:35, Tomas Vondra wrote:
On 17.5.2014 19:58, Andrew Dunstan wrote:
On 05/15/2014 07:47 PM, Tomas Vondra wrote:
On 15.5.2014 22:07, Andrew Dunstan wrote:
Yes, I've seen that. Frankly, a test that takes something like 500
hours is a
On 19.5.2014 23:04, Andrew Dunstan wrote:
On 05/19/2014 03:40 PM, Tomas Vondra wrote:
On 17.5.2014 22:35, Tomas Vondra wrote:
On 17.5.2014 19:58, Andrew Dunstan wrote:
On 05/15/2014 07:47 PM, Tomas Vondra wrote:
On 15.5.2014 22:07, Andrew Dunstan wrote:
Yes, I've seen that. Frankly, a test
On 19.5.2014 22:11, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 18.5.2014 20:49, Tom Lane wrote:
With both of these things fixed, I'm not seeing any significant memory
bloat during the first parallel group of the regression tests. I don't
think I'll have the patience to let it run
On 2014-05-19 23:40:32 +0200, Tomas Vondra wrote:
On 19.5.2014 22:11, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I intentionally didn't do that, first because I have only a limited
amount of confidence in the patch, and second because I don't think
it matters for anything except
Hello
As a simple example for people wondering what the point of this
feature is, I created a table work (id, data, status)
and then create 10,000 items with status 'NEW' and then started
a number of worker threads that did the following pair of
transactions, with and without SKIP LOCKED DATA on
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-19 23:40:32 +0200, Tomas Vondra wrote:
I was however wondering if this might be related to OOM errors a few
local users reported to us. IIRC they've been using temporary tables
quite heavily - not sure if that could be related.
I've
On 05/19/2014 05:37 PM, Tomas Vondra wrote:
IMHO the problem is that d6a97674 was the last revision in the
REL9_3_STABLE branch when the test started (00:14), but at 06:06
777d07d7 got committed. So the check at the end failed, because the
tested revision was suddenly ~2 days over the limit.
Hi!
I found that sometimes larger maintenance_work_mem leads to larger GIN
index. That is quite strange. ISTM that it's related to posting lists
compression but I can't figure out how exactly it is.
See example on delicious bookmarks dataset.
http://mira.sai.msu.ru/~megera/tmp/js.copy.gz
set
Andrew Dunstan and...@dunslane.net writes:
Well, the original code was put in for a reason, presumably that we were
getting some stale data and wanted to exclude it. So I'm unwilling to
throw it out altogether. If someone can propose a reasonable sanity
check then I'm prepared to implement
On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, the original code was put in for a reason, presumably that we were
getting some stale data and wanted to exclude it. So I'm unwilling to throw
it out altogether. If someone can propose a reasonable sanity check
42 matches
Mail list logo
