2013/9/14 chris travers
> **
> A few thoughts about this.
>
> > On 14 September 2013 at 05:28 Marko Tiikkaja 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
A few thoughts about this.
> On 14 September 2013 at 05:28 Marko Tiikkaja 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 quer
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
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 spe
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 DE
Andres Freund 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 Company
--
Sent via pg
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 glob
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 [-Wma
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 optio
On Thu, Sep 12, 2013 at 10:03 PM, 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 doesn't.
In PostgreS
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 mos
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 t
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-13 15:13:20 -0700, Kevin Grittner wrote:
> Andres Freund 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 obv
Andres Freund 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 refresh :(
I'm not
Peter Geoghegan 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
> _bt_check_uniq
On 2013-09-13 14:36:27 -0700, Kevin Grittner wrote:
> Andres Freund 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 re
On 2013-09-13 14:04:55 -0700, Kevin Grittner wrote:
> Andres Freund 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 tw
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 wher
On Fri, Sep 13, 2013 at 12:23 PM, Andres Freund 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 being articulated.
Andres Freund 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 operators
>> in the pars
On Fri, Sep 13, 2013 at 4:15 PM, Josh Berkus 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)
>> *) OLT
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 resol
On Fri, Sep 13, 2013 at 4:04 PM, Kevin Grittner wrote:
> Andres Freund 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
Andres Freund 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 like this,
and I suspec
On Fri, Sep 13, 2013 at 3:20 PM, Josh Berkus 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.
> 32-core Xeon,
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 c
Josh Berkus 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 frequently, bu
On 09/13/2013 01:25 PM, Andres Freund wrote:
>
>
> Josh Berkus 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
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
Load-
On Fri, Sep 13, 2013 at 2:36 PM, Josh Berkus 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 jurisdiction suc
* 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 :).
* 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_SS
On Fri, Sep 13, 2013 at 12:14 PM, Stephen Frost 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:
http://www.postgresql.org/mailpr
On 2013-09-13 11:59:54 -0700, Peter Geoghegan wrote:
> On Fri, Sep 13, 2013 at 9:23 AM, Robert Haas 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
>
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 ori
* 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 ar
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 th
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 Fri, Sep 13, 2013 at 9:23 AM, Robert Haas 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 was fundamentally a b
* 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.
* 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
signature.
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.
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 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
> > > E
* 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 happenin
* 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'
On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain
wrote:
> Marti Raudsepp 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 hope) a doc patch about that and a
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
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
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
On 2013-09-13 11:27:03 -0500, Merlin Moncure wrote:
> On Fri, Sep 13, 2013 at 11:07 AM, Andres Freund
> 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 th
On Thu, Sep 12, 2013 at 5:29 AM, Yeb Havinga 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 executing this function
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 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
On Wed, Sep 11, 2013 at 8:47 PM, Peter Geoghegan 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 ameliorating
On Fri, Sep 13, 2013 at 11:07 AM, Andres Freund 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 workloads
> where
On Thu, Sep 12, 2013 at 11:33 AM, Magnus Hagander 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 seen, and the re
On Fri, Sep 13, 2013 at 10:08 AM, Robert Haas wrote:
> On Wed, Sep 11, 2013 at 3:40 PM, Josh Berkus 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 i
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
Marti Raudsepp a écrit :
>On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp
>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
>> ‘/tmp/foo/usr/share/postgresql/extension/semver--
On Wed, Sep 11, 2013 at 3:40 PM, Josh Berkus 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 scan. That a
On Tue, Sep 10, 2013 at 11:45 PM, Kohei KaiGai 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, does it seem
Benedikt Grundmann wrote:
> Kevin Grittner 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" operator
On Wed, Sep 11, 2013 at 2:35 PM, Andrew Dunstan 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 of testing
From: "Jeff Janes"
--
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 turned off.
So afte
On Thu, Sep 12, 2013 at 11:27 PM, Kevin Grittner 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" operator (
67 matches
Mail list logo
