On 04/28/2014 10:32 PM, Tom Lane wrote:
Robert Haas writes:
I have to admit it's been a few years since I've had to play with
WAL_DEBUG, so I don't really remember what I was trying to do. But I
don't see any real argument that three slash-separated numbers will be
more useful to somebody who
On 10 April 2014 14:21, I wrote
>
> I shall perform some more test, for that I need to do some more hack in
> the code and I will post them soon..
>
> Test Scenario:
> Create table t1 (a int, b int);
> Create table t2 (a int, b int);
>
> Random record inserted in t1 and t2, as
On Monday, 28 April 2014 10:56 PM, Tom Lane wrote:
Greg Stark writes:
>So they pretty much would have to make concat() treat NULL as empty.
could it be problematic if I update pg_operator catalogue entry for ||,
call to concat() function instead of texcat(), in my production environment ?
rebased
2014-04-29 7:43 GMT+04:00 Michael Paquier :
> On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
> wrote:
> > 2014-04-29 5:52 GMT+04:00 Peter Eisentraut :
> >
> >> Please fix this compiler warning. I think it came from this patch.
> >> print.c: In function 'print_aligned_vertical':
> >>
On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
wrote:
> 2014-04-29 5:52 GMT+04:00 Peter Eisentraut :
>
>> Please fix this compiler warning. I think it came from this patch.
>> print.c: In function 'print_aligned_vertical':
>> print.c:1354:10: error: pointer targets in passing argument 1 of
>>
Please fix this compiler warning. I think it came from this patch.
print.c: In function ‘print_aligned_vertical’:
print.c:1354:10: error: pointer targets in passing argument 1 of
‘strlen_max_width’ differ in signedness [-Werror=pointer-sign]
encoding);
^
print.c:126:12: note
On 4/28/14, 8:04 AM, Robert Haas wrote:
On Mon, Apr 21, 2014 at 6:38 PM, Jim Nasby wrote:
I feel that if there is no memory pressure, frankly it doesnt matter much
about what gets out and what not. The case I am specifically targeting is
when the clocksweep gets to move about a lot i.e. high me
>> Yeah. I'm still not exactly convinced that custom-scan will ever allow
>> independent development of new plan types (which, with all due respect to
>> Robert, is what it was being sold as last year in Ottawa). But I'm not
>> opposed in principle to committing it, if we can find a way to have a
On 2014-04-28 13:20:47 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
> >> As far as pg_xlogdump goes, I agree that symbolic fork names are probably
> >> nice, but I think the case for printing db/ts/rel OIDs as a pathname is a
> >> whole lot we
On 28/04/14 15:36, Robert Haas wrote:
On Tue, Apr 22, 2014 at 9:55 AM, Petr Jelinek wrote:
But if I do first receive after detach like in this sequence:
P1 -> set_sender
P1 -> attach
P2 -> set_receiver
P2 -> attach
P1 -> send
P1 -> send
P1 -> detach
P2 -> receive
I get SHM_MQ_DETACHED on the
On 28/04/14 16:27, Robert Haas wrote:
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer wrote:
On 04/17/2014 08:35 AM, Craig Ringer wrote:
I've just noticed that the bgworker control interfaces do not honour
bgw.bgw_restart_time = BGW_NEVER_RESTART if you exit with status zero.
This means that it'
Robert Haas writes:
> I have to admit it's been a few years since I've had to play with
> WAL_DEBUG, so I don't really remember what I was trying to do. But I
> don't see any real argument that three slash-separated numbers will be
> more useful to somebody who has to dig through this than a path
On Mon, Apr 28, 2014 at 2:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane wrote:
>>> It's more verbose, it's not actually any more information, and in many
>>> cases it's actively misleading, because what's printed is NOT the real
>>> file name --- it om
On 2014-04-28 14:44:16 -0400, Robert Haas wrote:
> > BTW, for the same reasons I'm less than impressed with the uses of
> > relpath in error messages in, eg, reorderbuffer.c:
> >
> > relation = RelationIdGetRelation(reloid);
> >
> > if (relation == NULL)
> >
Robert Haas writes:
> On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane wrote:
>> It's more verbose, it's not actually any more information, and in many
>> cases it's actively misleading, because what's printed is NOT the real
>> file name --- it omits segment numbers for instance. As a particularly
>>
On Fri, Apr 25, 2014 at 10:45 AM, Peter Geoghegan wrote:
> I've now done a non-limited comparative benchmark of master against
> the patch (once again, with usage_count starting at 6, and
> BM_MAX_USAGE_COUNT at 30) with a Gaussian distribution. Once again,
> the distribution threshold used was co
On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
>>> As far as pg_xlogdump goes, I agree that symbolic fork names are probably
>>> nice, but I think the case for printing db/ts/rel OIDs as a pathname is a
>>> whole lot we
On Mon, Apr 28, 2014 at 6:02 AM, Robert Haas wrote:
> Also true. But the problem is that it is very rarely, if ever, the
> case that all pages are *equally* hot. On a pgbench workload, for
> example, I'm very confident that while there's not really any cold
> data, the btree roots and visibility
On Mon, Apr 28, 2014 at 11:05 AM, Tom Lane wrote:
> Andres Freund writes:
> > I don't think this is about the truncation thing, but about the
> > deadlock.c/proc.c logic around DS_BLOCKED_BY_AUTOVACUUM. I.e. that a
> > autovacuum is cancelled if user code tries to acquire a conflicting
> > lock.
On 2014-04-28 14:05:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think this is about the truncation thing, but about the
> > deadlock.c/proc.c logic around DS_BLOCKED_BY_AUTOVACUUM. I.e. that a
> > autovacuum is cancelled if user code tries to acquire a conflicting
> > lock.
>
>
Andres Freund writes:
> I don't think this is about the truncation thing, but about the
> deadlock.c/proc.c logic around DS_BLOCKED_BY_AUTOVACUUM. I.e. that a
> autovacuum is cancelled if user code tries to acquire a conflicting
> lock.
It's a bit of a stretch to claim that a manual VACUUM should
On Mon, Apr 28, 2014 at 10:58 AM, Tom Lane wrote:
> Claudio Freire writes:
> > On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
> > wrote:
> >> Tom Lane wrote:
> >>> Abhijit Menon-Sen writes:
> In the past, we've had situations where "everything is hung" turned
> out
> to be because
On 2014-04-28 13:58:10 -0400, Tom Lane wrote:
> Claudio Freire writes:
> > On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
> > wrote:
> >> Tom Lane wrote:
> >>> Abhijit Menon-Sen writes:
> In the past, we've had situations where "everything is hung" turned out
> to be because of a scr
On Mon, Apr 28, 2014 at 6:54 AM, Tom Lane wrote:
> Abhijit Menon-Sen writes:
> > In the past, we've had situations where "everything is hung" turned out
> > to be because of a script that ran manual VACUUM that was holding some
> > lock. It's admittedly not a huge problem, but it might be useful
Claudio Freire writes:
> On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Abhijit Menon-Sen writes:
In the past, we've had situations where "everything is hung" turned out
to be because of a script that ran manual VACUUM that was holding some
lock.
On 2014-04-28 09:54:49 -0400, Tom Lane wrote:
> Abhijit Menon-Sen writes:
> > In the past, we've had situations where "everything is hung" turned out
> > to be because of a script that ran manual VACUUM that was holding some
> > lock. It's admittedly not a huge problem, but it might be useful if a
On Mon, Apr 28, 2014 at 12:52 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Abhijit Menon-Sen writes:
>> > In the past, we've had situations where "everything is hung" turned out
>> > to be because of a script that ran manual VACUUM that was holding some
>> > lock. It's admittedly not a huge pro
Greg Stark writes:
> The missing bit of context is that concat() is there because early on
> in Postgres's life there was an effort to have a full suite of Oracle
> compatibility functions. If someone suggested it now they would be
> pushed towards making it an extension or pointed at EDB. But thi
Robert Haas writes:
> On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
>> As far as pg_xlogdump goes, I agree that symbolic fork names are probably
>> nice, but I think the case for printing db/ts/rel OIDs as a pathname is a
>> whole lot weaker --- to my taste, that's actually an anti-feature.
The missing bit of context is that concat() is there because early on
in Postgres's life there was an effort to have a full suite of Oracle
compatibility functions. If someone suggested it now they would be
pushed towards making it an extension or pointed at EDB. But things
like concat are the remn
All,
Unfortunately, Rackspace has had to post-pone this pending
finalization of the switch configuration.
We'll send out an update when we have a (new) finalized downtime
window.
Thanks,
Stephen
* Stephen Frost (sfr...@snowman.net) wrote:
> Greetings,
>
> As
On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> ... which might or might not be the same one that libpgcommon was compiled
>>> with, no? I don't think you're really protecting yourself against version
>>> skew that way.
>
>> The CATALOG_VERSION d
Alvaro Herrera writes:
> Tom Lane wrote:
>> ... which might or might not be the same one that libpgcommon was compiled
>> with, no? I don't think you're really protecting yourself against version
>> skew that way.
> The CATALOG_VERSION dependency in that code is a mistake which I didn't
> notice
Tom Lane wrote:
> Abhijit Menon-Sen writes:
> > In the past, we've had situations where "everything is hung" turned out
> > to be because of a script that ran manual VACUUM that was holding some
> > lock. It's admittedly not a huge problem, but it might be useful if a
> > manual VACUUM could be ca
On 28 April 2014 15:01, Robert Haas wrote:
> Interesting. This can pretty obviously produce a big win if things
> break our way. But it'll take some effort do determine whether the
> range of possible values for the join column is narrow enough to make
> the inferred BETWEEN clause selective en
Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 04/28/2014 04:51 PM, Tom Lane wrote:
> >> I'm not even worried about which headers this program uses. What I'm
> >> worried about is that you've got CATALOG_VERSION_NO compiled into a
> >> non-server executable. Is that really such a great idea
On Mon, Apr 28, 2014 at 11:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane wrote:
>>> ... and not, in particular, parse analysis or rewrite time?
>
>> I think breaking those out would be a good idea. Especially rewrite time.
>
> Rewrite time seems gener
Tom Lane wrote:
> What might be less breakable is to identify exactly which declarations
> pg_controldata needs out of this file and push just those into some new
> header.
Yeah, I also thought about that but didn't get around to trying.
> However, pg_controldata is just the tip of the iceberg -
On 2014-04-28 10:57:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-28 10:03:58 -0400, Tom Lane wrote:
> >> What I find much more worrisome about Andres' proposals is that he
> >> seems to be thinking that there are *no* other changes to the buffer
> >> headers on the horizon.
>
Robert Haas writes:
> On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane wrote:
>> ... and not, in particular, parse analysis or rewrite time?
> I think breaking those out would be a good idea. Especially rewrite time.
Rewrite time seems generally negligible in comparison to the other two
components, a
Heikki Linnakangas writes:
> On 04/28/2014 04:51 PM, Tom Lane wrote:
>> I'm not even worried about which headers this program uses. What I'm
>> worried about is that you've got CATALOG_VERSION_NO compiled into a
>> non-server executable. Is that really such a great idea? Wouldn't it be
>> bette
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm. It would certainly be better if pg_controldata could use
>> postgres_fe.h not postgres.h, but I'm confused about how the new header
>> added by this patch helps that? None of the declarations you removed from
>> xlog.h look like they'd be more prob
Andres Freund writes:
> On 2014-04-28 10:03:58 -0400, Tom Lane wrote:
>> What I find much more worrisome about Andres' proposals is that he
>> seems to be thinking that there are *no* other changes to the buffer
>> headers on the horizon.
> Err. I am not thinking that at all. I am pretty sure I n
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> pg_controldata includes postgres.h not postgres_fe.h, so utils/palloc.h
> >> must be able to compile in a "#define FRONTEND" context.
>
> > Hmm, I had this patch in an abandoned branch from long ago, which I
> > think helped remove
Alvaro Herrera writes:
> Tom Lane wrote:
>> pg_controldata includes postgres.h not postgres_fe.h, so utils/palloc.h
>> must be able to compile in a "#define FRONTEND" context.
> Hmm, I had this patch in an abandoned branch from long ago, which I
> think helped remove postgres.h from pg_controldat
On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
wrote:
> The patch attached improves docs in fdwhandler.sgml a little bit.
When you submit a patch, it's helpful to describe what the patch
actually does, rather than just saying it makes things better. For
example, I think that this patch could be
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer wrote:
> On 04/17/2014 08:35 AM, Craig Ringer wrote:
>> On 04/17/2014 04:47 AM, Petr Jelinek wrote:
>>>
>>> Well the logging is just too spammy in general when it comes to dynamic
>>> bgworkers but that's easy to fix in the future, no need to make
>>>
Andres Freund writes:
> On 2014-04-27 18:44:16 -0400, Tom Lane wrote:
>> They don't get nearly as upset as they do if the database loses their
>> data. Yes, in an ideal world, we could fix this and not suffer any
>> performance loss anywhere. But no such option is on the table, and
>> waiting is
On 2014-04-28 10:03:58 -0400, Tom Lane wrote:
> What I find much more worrisome about Andres' proposals is that he
> seems to be thinking that there are *no* other changes to the buffer
> headers on the horizon.
Err. I am not thinking that at all. I am pretty sure I never made that
argument. The r
On Wed, Apr 23, 2014 at 3:46 AM, Etsuro Fujita
wrote:
> (2014/04/15 15:27), Etsuro Fujita wrote:
>> (2014/04/14 23:53), Robert Haas wrote:
>>>
>>> On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita
>>> wrote:
Attached is an updated version of the patch.
>
>
>>> I think the other changes des
On 04/28/2014 04:51 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/28/2014 03:29 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
to physical files.
Isn't pg_rewind s
Robert Haas writes:
> I think the fact that making 20k connections might crash your computer
> is an artifact of other problems that we really ought to also fix
> (like per-backend memory utilization, and lock contention on various
> global data structures) rather than baking it into more places.
On Tue, Apr 22, 2014 at 11:44 AM, Simon Riggs wrote:
> I was recently nudged to describe an optimisation of merge
> joins/sorts. Rather than decribe that, I've looked at the general
> case:
>
> There are some additional implications we may make when joining
> tables... a particularly interesting o
Abhijit Menon-Sen writes:
> In the past, we've had situations where "everything is hung" turned out
> to be because of a script that ran manual VACUUM that was holding some
> lock. It's admittedly not a huge problem, but it might be useful if a
> manual VACUUM could be cancelled the way autovacuum
Heikki Linnakangas writes:
> On 04/28/2014 03:29 PM, Christoph Berg wrote:
>> Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
>>> I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
>>> to physical files.
>> Isn't pg_rewind so low-level server-close that i
Tom Lane wrote:
> Can't completely get rid of #ifndef FRONTEND in palloc.h :-(
>
> pg_controldata includes postgres.h not postgres_fe.h, so utils/palloc.h
> must be able to compile in a "#define FRONTEND" context.
Hmm, I had this patch in an abandoned branch from long ago, which I
think helped re
amul sul writes:
> concat function and operator || have different behaviour, if any input is
> NULL.
The behavior of || is specified by the SQL standard, and it says (SQL99
6.27 general rule 2a):
a) If either S1 or S2 is the null value, then the result of the
is the
On Tue, Apr 22, 2014 at 9:55 AM, Petr Jelinek wrote:
> I was playing with shm_mq and found a little odd behavior with detaching
> after sending messages.
>
> Following sequence behaves as expected (receiver gets 2 messages):
> P1 -> set_sender
> P1 -> attach
> P2 -> set_receiver
> P2 -> attach
> P
On Mon, Apr 21, 2014 at 6:38 PM, Jim Nasby wrote:
>> I feel that if there is no memory pressure, frankly it doesnt matter much
>> about what gets out and what not. The case I am specifically targeting is
>> when the clocksweep gets to move about a lot i.e. high memory pressure
>> workloads. Of cou
On Fri, Apr 18, 2014 at 11:46 AM, Greg Stark wrote:
> On Fri, Apr 18, 2014 at 4:14 PM, Robert Haas wrote:
>> I am a bit confused by this remark. In *any* circumstance when you
>> evict you're incurring precisely one page fault I/O when the page is
>> read back in. That doesn't mean that the ch
On 04/28/2014 03:29 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
Comments? If there's anyone who has a really good use-case for using
relpath() from outside the backend, better speak up.
I'm using it in the pg_rewind tool. It needs to know how to m
Hi ALL,
I need little help to understand, text concatenation.
concat function and operator || have different behaviour, if any input is NULL.
test=# select 'abc' || NULL;
?column?
--
(1 row)
test=# select concat('abc', NULL);
concat
abc
(1 row)
It has simple reason, conc
On Mon, Apr 28, 2014 at 7:37 AM, Andres Freund wrote:
>> Well, often that's still good enough.
>
> That may be true for 2-4k max_connections, but >65k? That won't even
> *run*, not to speak of doing something, in most environments because of
> the number of processes required.
>
> Even making only
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
> >Comments? If there's anyone who has a really good use-case for using
> >relpath() from outside the backend, better speak up.
>
> I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
> to physical files.
>
On Fri, Apr 25, 2014 at 8:58 PM, Josh Berkus wrote:
> Well, I've already had collisions with UUID-OSSP, in production, with
> only around 20 billion values. So clearly there aren't 122bits of true
> randomness in OSSP. I can't speak for other implementations because I
> haven't tried them.
Inte
On 2014-04-28 13:32:45 +0300, Heikki Linnakangas wrote:
> On 04/28/2014 12:39 PM, Andres Freund wrote:
> >On 2014-04-28 10:48:30 +0300, Heikki Linnakangas wrote:
> >>On 04/26/2014 09:27 PM, Andres Freund wrote:
> >>>I don't think we need to decide this without benchmarks proving the
> >>>benefits.
On Sun, Apr 27, 2014 at 1:07 PM, Tom Lane wrote:
> ... and not, in particular, parse analysis or rewrite time?
I think breaking those out would be a good idea. Especially rewrite time.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgs
On 04/28/2014 12:39 PM, Andres Freund wrote:
On 2014-04-28 10:48:30 +0300, Heikki Linnakangas wrote:
On 04/26/2014 09:27 PM, Andres Freund wrote:
I don't think we need to decide this without benchmarks proving the
benefits. I basically want to know whether somebody has an actual
usecase - even
Hi.
In the past, we've had situations where "everything is hung" turned out
to be because of a script that ran manual VACUUM that was holding some
lock. It's admittedly not a huge problem, but it might be useful if a
manual VACUUM could be cancelled the way autovacuum can be.
One way to do this w
On 2014-04-28 10:48:30 +0300, Heikki Linnakangas wrote:
> On 04/26/2014 09:27 PM, Andres Freund wrote:
> >I don't think we need to decide this without benchmarks proving the
> >benefits. I basically want to know whether somebody has an actual
> >usecase - even if I really, really, can't think of on
On 2014-04-27 18:44:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> Just for some clarity, that also happens with expressions like:
> >> WHERE
> >> ROW(ev_class, rulename, ev_action) >= ROW('pg_rewrite'::regclass,
> >> '_RETURN', NULL)
> >> ORDER BY ROW(ev_class, rulename, ev_action);
>
>
On 04/27/2014 11:33 PM, Tom Lane wrote:
I wrote:
On closer inspection, the issue here is really that putting relpath.h/.c
in common/ was completely misguided from the get-go. It's unnecessary:
there's nothing outside the backend that uses it, except for
contrib/pg_xlogdump which could very easi
On 04/26/2014 09:27 PM, Andres Freund wrote:
I don't think we need to decide this without benchmarks proving the
benefits. I basically want to know whether somebody has an actual
usecase - even if I really, really, can't think of one - of setting
max_connections even remotely that high. If there'
73 matches
Mail list logo
