Hello,
About patch eols:
postgresql patch -p1 ../pgbench-measurements-v2.patch
patching file contrib/pgbench/pgbench.c
patching file doc/src/sgml/pgbench.sgml
it can depends on o.s. I did tests on Fedora 14. and for patching without
warning I had to use dos2unix tool.
Hmmm. I
On Thu, Sep 12, 2013 at 11:27 PM, Kevin Grittner kgri...@ymail.com wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
[...]
The patch adds an identical
From: Jeff Janes jeff.ja...@gmail.com
--
I've implemented the Min to Max change and did some more testing. Now I
have a different but related problem (which I also saw before, but less
often than the select() one). The 5 second clock doesn't get
On Wed, Sep 11, 2013 at 2:35 PM, Andrew Dunstan and...@dunslane.net wrote:
I vote against this. If we remove V2 support from libpq, then we'll
have no easy way to test that the backend's support still works. And
we've got too many people using V2 to think that it's OK not to have
an easy way
Benedikt Grundmann bgrundm...@janestreet.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
Attached is a patch for a bit of infrastructure I believe to be
necessary for correct behavior of REFRESH MATERIALIZED VIEW
CONCURRENTLY as well as incremental maintenance of matviews.
[...]
The
On Tue, Sep 10, 2013 at 11:45 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Fair enough, I think. So the action item for KaiGai is to think of
how the planner integration might work.
Do you think the idea I mentioned at the upthread is worth to investigate
for more detailed consideration? Or,
On Wed, Sep 11, 2013 at 3:40 PM, Josh Berkus j...@agliodbs.com wrote:
I think that most of the arguments in this thread drastically
overestimate the precision and the effect of effective_cache_size. The
planner logic behind it basically only uses it to calculate things
within a single index
Marti Raudsepp ma...@juffo.org a écrit :
On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp ma...@juffo.org
wrote:
While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
% make DESTDIR=/tmp/foo install
/usr/bin/install: will not overwrite just-created
Hi Kevin,
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
The new operator is logically similar to IS NOT DISTINCT FROM for a
record, although its implementation is very different. For one
thing, it doesn't replace the operation with column level operators
in the parser. For another
On Fri, Sep 13, 2013 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Sep 11, 2013 at 3:40 PM, Josh Berkus j...@agliodbs.com wrote:
I think that most of the arguments in this thread drastically
overestimate the precision and the effect of effective_cache_size. The
planner logic
On Thu, Sep 12, 2013 at 11:33 AM, Magnus Hagander mag...@hagander.net wrote:
Well, undocumented and OpenSSL tend to go hand in hand a lot. Or,
well, it might be documented, but not in a useful way. I wouldn't
count on it.
The OpenSSL code is some of the worst-formatted spaghetti code I've
ever
On Wed, Sep 11, 2013 at 8:47 PM, Peter Geoghegan p...@heroku.com wrote:
In practice the vast majority of insertions don't involve TOASTing.
That's not an excuse for allowing the worst case to be really bad in
terms of its impact on query response time, but it may well justify
having whatever
On Fri, Sep 13, 2013 at 11:07 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-13 10:50:06 -0500, Merlin Moncure wrote:
The stock documentation advice I probably needs to be revised to so
that's the lesser of 2GB and 25%.
I think that would be a pretty bad idea. There are lots of
On 2013-09-13 10:50:06 -0500, Merlin Moncure wrote:
The stock documentation advice I probably needs to be revised to so
that's the lesser of 2GB and 25%.
I think that would be a pretty bad idea. There are lots of workloads
where people have postgres happily chugging along with s_b lots bigger
Heikki, all,
* Stephen Frost (sfr...@snowman.net) wrote:
Very curious. Out of time right now to look into it, but will probably
be back at it later tonight.
Alright, I was back at this a bit today and decided to go with a hunch-
and it looks like I might have been right to try.
Leaving the
On Thu, Sep 12, 2013 at 5:29 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Is the following known behaviour, or should I put some time in writing a
self contained test case?
We have a function that takes a value and returns a ROW type. With the
function implemented in language SQL, when
On 2013-09-13 11:27:03 -0500, Merlin Moncure wrote:
On Fri, Sep 13, 2013 at 11:07 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-09-13 10:50:06 -0500, Merlin Moncure wrote:
The stock documentation advice I probably needs to be revised to so
that's the lesser of 2GB and 25%.
I
On 2013-09-13 12:40:11 -0400, Stephen Frost wrote:
Heikki, all,
* Stephen Frost (sfr...@snowman.net) wrote:
Very curious. Out of time right now to look into it, but will probably
be back at it later tonight.
Alright, I was back at this a bit today and decided to go with a hunch-
and
Andres,
On Friday, September 13, 2013, Andres Freund wrote:
It'd be interesting to replace the origin callbacks with one immediately
doing an abort() or similar to see whether they maybe are called after
they shouldn't be and from where.
Good thought. Got sucked into a meeting but once I'm
On 2013-09-13 13:15:34 -0400, Stephen Frost wrote:
Andres,
On Friday, September 13, 2013, Andres Freund wrote:
It'd be interesting to replace the origin callbacks with one immediately
doing an abort() or similar to see whether they maybe are called after
they shouldn't be and from
On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain
ced...@2ndquadrant.com wrote:
Marti Raudsepp ma...@juffo.org a écrit :
Did we ever do anything about this? It looks like the thread got
distracted with VPATH builds and now I'm seeing this problem in 9.3.0.
Andrew is about to commit (well...I
* Stephen Frost (sfr...@snowman.net) wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
Hm. close_SSL() first does pqsecure_destroy() which will unset the
callbacks, and the count and then goes on to do X509_free() and
ENGINE_finish(), ENGINE_free() if either is used.
It's not
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-09-13 13:15:34 -0400, Stephen Frost wrote:
Good thought. Got sucked into a meeting but once I'm out I'll try having
the lock/unlock routines abort if they're called while ssl_open_connections
is zero, which should not be happening, but
On 2013-09-13 14:33:25 -0400, Stephen Frost wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
Hm. close_SSL() first does pqsecure_destroy() which will unset the
callbacks, and the count and then goes on to do X509_free() and
On 2013-09-13 13:59:54 -0400, Stephen Frost wrote:
Unfortunately, while I can still easily get the deadlock to happen when
the hooks are reset, the hooks don't appear to ever get called when
ssl_open_connections is set to zero. You have a good point about the
additional SSL calls after the
On 13.09.2013 22:26, Heikki Linnakangas wrote:
I'm afraid the move_locks.diff patch you posted earlier is also
broken; close_SSL() is called in error scenarios from
pqsecure_open_client(), while already holding the mutex. So it will
deadlock with itself if the connection cannot be established.
* Peter Geoghegan (p...@heroku.com) wrote:
I would suggest letting those other individuals speak for themselves
too. Particularly if you're going to name someone who is on vacation
like that.
It was my first concern regarding this patch.
Thanks,
Stephen
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Umm, with that patch, pqsecure_destroy() is never called. The if
(conn-ssl) test that's now at the end of the close_SSL function is
never true, because conn-ssl is set to NULL earlier.
Yeah, got ahead of myself, as Andres pointed out.
I'm
On Fri, Sep 13, 2013 at 9:23 AM, Robert Haas robertmh...@gmail.com wrote:
Andres is being very polite here, but the reality is that this
approach has zero chance of being accepted.
I quite like Andres, but I have yet to see him behave as you describe
in a situation where someone proposed what
On 13.09.2013 22:03, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
It seems slightly cleaner to just move the pqsecure_destroy(); to the
end of that function, based on a boolean. But if you think otherwise, I
won't protest...
Hmm, agreed; I had originally been concerned
On 09/13/2013 09:27 AM, Merlin Moncure wrote:
I happen to be one of those couple people. Load goes from 0.1 to
500 without warning then back to 0.1 equally without warning.
Unfortunately the server is in a different jurisdiction such that it
makes deep forensic analysis impossible. I think
* Andres Freund (and...@2ndquadrant.com) wrote:
It seems slightly cleaner to just move the pqsecure_destroy(); to the
end of that function, based on a boolean. But if you think otherwise, I
won't protest...
Hmm, agreed; I had originally been concerned that the SIGPIPE madness
needed to be
On 2013-09-13 15:03:31 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
It seems slightly cleaner to just move the pqsecure_destroy(); to the
end of that function, based on a boolean. But if you think otherwise, I
won't protest...
Hmm, agreed; I had originally
On Fri, Sep 13, 2013 at 12:14 PM, Stephen Frost sfr...@snowman.net wrote:
It was my first concern regarding this patch.
It was my first concern too.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2013-09-13 11:59:54 -0700, Peter Geoghegan wrote:
On Fri, Sep 13, 2013 at 9:23 AM, Robert Haas robertmh...@gmail.com wrote:
Andres is being very polite here, but the reality is that this
approach has zero chance of being accepted.
I quite like Andres, but I have yet to see him behave as
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Actually, I think there's a pre-existing bug there in git master. If
the SSL_set_app_data or SSL_set_fd call in pqsecure_open_client
fails for some reason, it will call close_SSL() with conn-ssl
already set, and the mutex held. close_SSL()
* Andres Freund (and...@2ndquadrant.com) wrote:
That patch looks wrong to me. Note that the if (conn-ssl) branch resets
conn-ssl to NULL.
huh, it figures one would overlook the simplest things. Of course it's
not locking up now- we never remove the hooks (as my original patch was
doing :).
On Fri, Sep 13, 2013 at 2:36 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/13/2013 09:27 AM, Merlin Moncure wrote:
I happen to be one of those couple people. Load goes from 0.1 to
500 without warning then back to 0.1 equally without warning.
Unfortunately the server is in a different
On 09/13/2013 12:55 PM, Merlin Moncure wrote:
what are the specific symptoms of your problem? anything interesting
in pg_locks? is $client willing to experiment with custom patches?
3 servers: 1 master, two replicas.
32-core Xeon, hyperthreaded to 64 cores
512GB RAM each
s_b set to 8GB
On 09/13/2013 01:25 PM, Andres Freund wrote:
Josh Berkus j...@agliodbs.com schrieb:
What's notable is that sometimes it's just *one* of the replicas which
goes into paralysis. If the master gets this issue though, the
replicas
experience it soon afterwards. Increasing wal_buffers from
Josh Berkus j...@agliodbs.com schrieb:
What's notable is that sometimes it's just *one* of the replicas which
goes into paralysis. If the master gets this issue though, the
replicas
experience it soon afterwards. Increasing wal_buffers from 16GB to
64GB
seems to make this issue happen less
Hi,
Please find attached to this email three patches covering the missing PL
support for Event Triggers: pltcl, plperl and plpython.
Due to “platform” problems here tonight and the CF deadline, the
plpython patch is known not to pass regression tests on my machine. The
code is fully rebased and
On Fri, Sep 13, 2013 at 3:20 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/13/2013 12:55 PM, Merlin Moncure wrote:
what are the specific symptoms of your problem? anything interesting
in pg_locks? is $client willing to experiment with custom patches?
3 servers: 1 master, two replicas.
Andres Freund and...@2ndquadrant.com wrote:
Absolutely not claiming the contrary. I think it sucks that we
couldn't fully figure out what's happening in detail. I'd love to
get my hand on a setup where it can be reliably reproduced.
I have seen two completely different causes for symptoms
On Fri, Sep 13, 2013 at 4:04 PM, Kevin Grittner kgri...@ymail.com wrote:
Andres Freund and...@2ndquadrant.com wrote:
Absolutely not claiming the contrary. I think it sucks that we
couldn't fully figure out what's happening in detail. I'd love to
get my hand on a setup where it can be reliably
On 09/13/2013 01:58 PM, Merlin Moncure wrote:
ok, points similar:
*) master/slave config (two slaves for me)
*) 'big' server 256GB mem, 32 core
*) 80% approx. (perhaps more)
*) some spacial searching (but not very much)
*) OLTP
*) presentation of load, although in my case it did resolve
On Fri, Sep 13, 2013 at 4:15 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/13/2013 01:58 PM, Merlin Moncure wrote:
ok, points similar:
*) master/slave config (two slaves for me)
*) 'big' server 256GB mem, 32 core
*) 80% approx. (perhaps more)
*) some spacial searching (but not very much)
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
The new operator is logically similar to IS NOT DISTINCT FROM for a
record, although its implementation is very different. For one
thing, it doesn't replace the operation with column level
On Fri, Sep 13, 2013 at 12:23 PM, Andres Freund and...@2ndquadrant.com wrote:
The reason I wasn't saying this will never get accepted are twofold:
a) I don't want to stiffle alternative ideas to the promises idea,
just because I think it's the way to go. That might stop a better idea
from
Hi,
Attached is a patch for optionally printing more information on STRICT
failures in PL/PgSQL:
set plpgsql.print_strict_params to true;
create or replace function footest() returns void as $$
declare
x record;
p1 int := 2;
p3 text := 'foo';
begin
-- too many rows
select * from foo
On 2013-09-13 14:04:55 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Absolutely not claiming the contrary. I think it sucks that we
couldn't fully figure out what's happening in detail. I'd love to
get my hand on a setup where it can be reliably reproduced.
I
On 2013-09-13 14:36:27 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
The new operator is logically similar to IS NOT DISTINCT FROM for a
record, although its implementation is very different. For one
thing, it
Peter Geoghegan p...@heroku.com wrote:
we exclusive lock a heap buffer (exactly one heap buffer) while
holding shared locks on btree index buffers. Is that really so
different to holding an exclusive lock on a btree buffer while
holding a shared lock on a heap buffer? Because that's what
Andres Freund and...@2ndquadrant.com wrote:
I am not actually that concerned with MVCs using this, you're quite
capable of analyzing the dangers. What I am wary of is exposing an
operator that's basically broken from the get go to SQL.
Now, the obvious issue there is that matviews use SQL to
On 2013-09-13 15:13:20 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
I am not actually that concerned with MVCs using this, you're quite
capable of analyzing the dangers. What I am wary of is exposing an
operator that's basically broken from the get go to SQL.
Marko Tiikkaja wrote:
set plpgsql.print_strict_params to true;
Hmm, shouldn't this be a compile option? See the comp_option
production in pl_gram.y for existing examples.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
On 2013-09-14 00:39, Alvaro Herrera wrote:
set plpgsql.print_strict_params to true;
Hmm, shouldn't this be a compile option? See the comp_option
production in pl_gram.y for existing examples.
I thought about that, but it seemed more like a runtime option to me.
Any particular reason you
The attached patch adds the MAP_HUGETLB flag to mmap() for shared memory
on systems that support it. It's based on Christian Kruse's patch from
last year, incorporating suggestions from Andres Freund.
On a system with 4GB shared_buffers, doing pgbench runs long enough for
each backend to touch
On Thu, Sep 12, 2013 at 10:03 PM, wangs...@highgo.com.cn wrote:
Second, I tested the check and the foreign key constraint as your test
above.
And no error found, as fellow:
You're missing the point. Peter wasn't worried that your patch throws
an error; he's concerned about the fact that it
Marko Tiikkaja wrote:
On 2013-09-14 00:39, Alvaro Herrera wrote:
set plpgsql.print_strict_params to true;
Hmm, shouldn't this be a compile option? See the comp_option
production in pl_gram.y for existing examples.
I thought about that, but it seemed more like a runtime option to
me. Any
On Fri, 2013-09-13 at 14:56 +0530, Atri Sharma wrote:
This is our complete patch for implementation of WITHIN GROUP.
Please fix compiler warnings:
inversedistribution.c: In function ‘mode_final’:
inversedistribution.c:276:11: warning: ‘mode_val’ may be used uninitialized in
this function
On 2013-09-14 03:33, Alvaro Herrera wrote:
Marko Tiikkaja wrote:
I thought about that, but it seemed more like a runtime option to
me. Any particular reason you think it would be better as a compile
time option?
Seems like something that would be useful to change per function, rather
than
Andres Freund and...@2ndquadrant.com wrote:
Not one that's dependendant on padding bytes, null bitmaps that
can or cannot be present and such.
Can you provide an example of where that's an issue with this
patch?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On 23/08/2013 10:36, I wrote:
On 8/23/13 8:38 AM, Pavel Stehule wrote:
do you prepare patch ?
I should have the time to produce one for the September commitfest, but
if you (or anyone else) want to work on this, I won't object.
My opinion at this very moment is that we should leave the the
Hi,
After my previous suggestion for adding a STRICT keyword got shot
down[1], I've been thinking about an idea Andrew Gierth tossed out:
adding a new strict mode into PL/PgSQL. In this mode, any query which
processes more than one row will raise an exception. This is a bit
similar to
On 14/09/2013 06:28, I wrote:
2) Checking row_count for a statement is ugly and cumbersome, so
often it just isn't checked. I often use RETURNING TRUE INTO STRICT _OK
for DML, but that a) requires an extra variable, and b) isn't possible
if 0 rows affected is not an error in the application
A few thoughts about this.
On 14 September 2013 at 05:28 Marko Tiikkaja ma...@joh.to wrote:
Hi,
After my previous suggestion for adding a STRICT keyword got shot
down[1], I've been thinking about an idea Andrew Gierth tossed out:
adding a new strict mode into PL/PgSQL. In this mode, any
67 matches
Mail list logo
