On Tue, Mar 27, 2012 at 01:39, Tom Lane wrote:
> Robert Haas writes:
> Thom Brown writes:
>> This is probably a dumb question but... surely there's more than 2
>> committers able to review?
>
> Able and willing might be two different things. Alvaro, Heikki, and
> Magnus have all been looking at
On Mon, Mar 26, 2012 at 9:11 PM, Robert Haas wrote:
> [ various trivial issues ]
OK, now I got that out of my system. Now on to bigger topics.
I am extremely concerned about the way in which this patch arranges to
invoke command triggers. You've got call sites spattered all over the
place, and
Hi,
now I find that params for execute statement are evaluated before
PortalRun, using another temporary estate. Is it necessary? Or can we evaluate
params during executions, that is, in ExecEvalParam function? then we can use
the same estate as one for executor, which can save time to init
I'm sorry to have coded a silly bug.
The previous patch has a bug in realloc size calculation.
And separation of the 'connname patch' was incomplete in regtest.
It is fixed in this patch.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/contrib/dblink/dblink.c b/contri
On Tue, Mar 27, 2012 at 12:57 AM, Tom Lane wrote:
> Hrm, I think we're talking at cross-purposes here.
>
> Me: "This mechanism hasn't been tested enough, and may still have nasty bugs."
>
> You: "Then let's invent some entirely new mechanism."
>
> I'm not seeing how that responds to the concern.
On Tue, Mar 20, 2012 at 1:49 PM, Dimitri Fontaine
wrote:
> Hi,
>
> I guess I sent v17 a little early considering that we now already have
> v18 including support for CREATE TABLE AS and SELECT INTO, thanks to the
> work of Andres and Tom.
>
> There was some spurious tags in the sgml files in v17 t
Robert Haas writes:
> I think the more important question is a policy question: do we want
> it to work like this? It seems like a policy question that ought to
> be left to the DBA, but we have no policy management framework for
> DBAs to configure what they do or do not wish to allow. Still, i
Greg Stark writes:
> On Mon, Mar 26, 2012 at 6:15 PM, Tom Lane wrote:
>> Could you give us a brain dump on the sketch? I've never seen how to
>> do it without unreasonable overhead.
> Hm. So my original plan was dependent on adding the state-merge
> function we've talked about in the past. Not
Daniel Farina writes:
> On Mon, Mar 26, 2012 at 1:57 PM, Tom Lane wrote:
>> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
>> production database.
> Okay, it was my precise intention to hand this to users so that not
> only could they cancel their queries, but also force
On Mon, Mar 26, 2012 at 6:15 PM, Tom Lane wrote:
> Greg Stark writes:
>> I have a sketch for how to handle spilling hash aggregates to disk in
>> my head. I'm not sure if it's worth the amount of complexity it would
>> require but I'll poke around a bit and see if it works out well.
>
> It'd be a
On Mon, Mar 26, 2012 at 4:57 PM, Tom Lane wrote:
>> I'm not sure - perhaps we're past that worry these days?
>
> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
> production database. It'll probably work, but what if it doesn't?
> Best-case scenario is you'll need to do a p
Robert Haas writes:
> On Mar 26, 2012, at 5:36 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> 2. I'm not sure which patches Tom is planning to look at or in what
>>> order, so I've been avoiding the ones he seems to be taking an
>>> interest in.
>> Well, I think I'm definitely on the hook for t
On Mon, Mar 26, 2012 at 1:57 PM, Tom Lane wrote:
> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
> production database. It'll probably work, but what if it doesn't?
> Best-case scenario is you'll need to do a panic shutdown to clear the
> stuck lock or whatever that the b
On 26 March 2012 23:16, Robert Haas wrote:
> On Mar 26, 2012, at 5:36 PM, Tom Lane wrote:
>> Well, I think I'm definitely on the hook for the pg_stat_statements,
>> pgsql_fdw, foreign table stats, and caching-stable-subexpressions
>> patches, and I should look at the libpq alternate row returning
On Mar 26, 2012, at 5:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2. I'm not sure which patches Tom is planning to look at or in what
>> order, so I've been avoiding the ones he seems to be taking an
>> interest in.
>
> Well, I think I'm definitely on the hook for the pg_stat_statements,
> p
Robert Haas writes:
> 2. I'm not sure which patches Tom is planning to look at or in what
> order, so I've been avoiding the ones he seems to be taking an
> interest in.
Well, I think I'm definitely on the hook for the pg_stat_statements,
pgsql_fdw, foreign table stats, and caching-stable-subexpr
On Mon, Mar 26, 2012 at 4:45 PM, Robert Haas wrote:
> As soon as we're done here, the CommitFest will end, and there won't
> be any other people's patches to review.
Hurray? :-)
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle
Magnus Hagander writes:
> I wasn't aware that was the reason there. I think it was the general
> "leftovers" from previous times. When we first created
> pg_terminate_backend() there was a general thought that it might not
> be safe to just SIGTERM a backend to make it quit.
Not just "might not b
On Mon, Mar 26, 2012 at 4:36 PM, Dimitri Fontaine
wrote:
> Well, wait a minute. There's a difference between half-baked and
> reacting to a review that changes the goal of a patch. My idea of the
> code I wanted to write here is extremely different from what we as a
> community decided to be doing
On Tue, Mar 20, 2012 at 18:48, Daniel Farina wrote:
> On Tue, Mar 20, 2012 at 10:13 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Maybe we should just not worry about this.
>>
>> That's been my reaction right along. There's no evidence that PID
>> recycling is a problem in the real world.
>
>
On 26 March 2012 21:36, Dimitri Fontaine wrote:
> Robert Haas writes:
>> Personally, I am about at the point where I'd like to punt everything
>> and move on. As nice as it would be to squeeze a few more things into
>> 9.2, there WILL be a 9.3. If a few less people had submitted
>> half-baked c
On Sun, Mar 25, 2012 at 4:29 PM, Jim Nasby wrote:
> I wouldn't be too quick to dismiss increasing checkpoint frequency (ie:
> decreasing checkpoint_timeout).
I'm not dismissing that, but my tests show only a very small gain in
that area. Now there may be another test where it shows a bigger
gain
Robert Haas writes:
> 1. It sure seems like there is an awful lot of code churn and design
> work going on.
There has only been minor adjustments for a while now, and they have
been visible because Thom was doing lots of testing for me and it was
way easier for me to publish a new version and hav
On Monday, March 26, 2012 10:18:59 PM Dimitri Fontaine wrote:
> don't know how to fix the plpython specifics he's talking
> about.
Just copy what is done in the normal trigger handling facility (the decref
both in the CATCH and in the normal path). Ping me some other way if you need
help...
And
Tom Lane writes:
> So I don't think that the mere fact of being an ANY trigger rather than
> a command-specific trigger should be taken to mean that a particular
> ordering is desirable. Trigger name order isn't the greatest solution
> by any means, but it's more flexible than hard-wiring accordi
On Mon, Mar 26, 2012 at 3:36 PM, Thom Brown wrote:
> Can someone clarify whether this will be reviewed by a committer?
> Will there be time to get this reviewed before the commitfest closes?
> I get the impression the commitfest closure is fairly imminent.
Well, I have been holding off for two re
Thom Brown writes:
> Can someone clarify whether this will be reviewed by a committer?
> Will there be time to get this reviewed before the commitfest closes?
> I get the impression the commitfest closure is fairly imminent.
I don't have that impression. (I wish I did.)
Dimitri Fontaine writes:
> Robert Haas writes:
>> Dimitri's proposed behavior would be advantageous if you have an ANY
>> trigger that wants to "take over the world" and make sure that nobody
>> else can run before it. I think, though, that's not a case we want to
>> cater to - all of this stuff
On Mon, Mar 26, 2012 at 3:24 PM, Dimitri Fontaine
wrote:
> One use case would be for londiste/slony/bucardo to rewrite the command
> and queue its text, that will be done in C and should probably be done
> first. Using an ANY command trigger means that code will run before user
> specific code (or
Peter Eisentraut writes:
> On mån, 2012-03-26 at 15:15 -0400, Tom Lane wrote:
>> I also do not think it does anything for readability for this call
>> of read_info() to be unexpectedly unlike all the others.
> I do not think that it is good code quality to assign something to a
> variable and t
Can someone clarify whether this will be reviewed by a committer?
Will there be time to get this reviewed before the commitfest closes?
I get the impression the commitfest closure is fairly imminent.
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On mån, 2012-03-26 at 15:15 -0400, Tom Lane wrote:
> init_sequence(seq_relid, &elm, &seq_rel);
> - seq = read_info(elm, seq_rel, &buf);
> + read_info(elm, seq_rel, &buf);
>
>
> I have to object to this patch. In the blind service of eliminating
> warnings from some tool or other, you wil
Robert Haas writes:
> Dimitri's proposed behavior would be advantageous if you have an ANY
> trigger that wants to "take over the world" and make sure that nobody
> else can run before it. I think, though, that's not a case we want to
> cater to - all of this stuff requires superuser privileges a
Peter Eisentraut writes:
> Remove dead assignment
> found by Coverity
init_sequence(seq_relid, &elm, &seq_rel);
- seq = read_info(elm, seq_rel, &buf);
+ read_info(elm, seq_rel, &buf);
I have to object to this patch. In the blind service of eliminating
warnings from some tool or other,
On 03/26/2012 04:29 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> On 03/26/2012 03:47 AM, Tom Lane wrote:
>>> Replace empty locale name with implied value in CREATE DATABASE and initdb.
>
>> hmm seems like this commit broken quagga:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=qua
Andrew Dunstan writes:
> On 03/26/2012 01:34 PM, Tom Lane wrote:
>> Hm. The test case is just a straight pg_restore of lots and lots of LOs?
>> What pg_dump version was the dump made with?
> 8.4.8, same as the target. We get the same issue whether we restore
> direct to the database from pg_res
On 03/26/2012 01:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/26/2012 01:06 PM, Heikki Linnakangas wrote:
Is it possible this job is inserting and then updating (or deleteing)
the row it just inserted and doing a large number of such
insert/update operations all within the same transa
Andrew Dunstan writes:
> On 03/26/2012 01:06 PM, Heikki Linnakangas wrote:
>>> Is it possible this job is inserting and then updating (or deleteing)
>>> the row it just inserted and doing a large number of such
>>> insert/update operations all within the same transaction? Or perhaps
>>> it's updat
On 03/26/2012 01:06 PM, Heikki Linnakangas wrote:
On 26.03.2012 19:59, Heikki Linnakangas wrote:
On 26.03.2012 19:51, Greg Stark wrote:
On Mon, Mar 26, 2012 at 5:41 PM, Andrew Dunstan
wrote:
Combo CIDs: 755490840 total in 100 blocks; 5161072 free (381
chunks); 750329768 used
I think you'll
Greg Stark writes:
> I have a sketch for how to handle spilling hash aggregates to disk in
> my head. I'm not sure if it's worth the amount of complexity it would
> require but I'll poke around a bit and see if it works out well.
It'd be awfully nice if those could spill to disk. I think that
cu
On 26.03.2012 19:59, Heikki Linnakangas wrote:
On 26.03.2012 19:51, Greg Stark wrote:
On Mon, Mar 26, 2012 at 5:41 PM, Andrew Dunstan
wrote:
Combo CIDs: 755490840 total in 100 blocks; 5161072 free (381
chunks); 750329768 used
I think you'll have to catch Heikki's attention to get a good answe
On Mon, Mar 26, 2012 at 5:43 PM, Tom Lane wrote:
> Hm. This illustrates that it's not too prudent to rely on a default
> numdistinct estimate to decide that a hash aggregation is safe :-(.
> We had probably better tweak the cost estimation rules to not trust
> that. Maybe, if we have a default e
On 26.03.2012 19:51, Greg Stark wrote:
On Mon, Mar 26, 2012 at 5:41 PM, Andrew Dunstan wrote:
Combo CIDs: 755490840 total in 100 blocks; 5161072 free (381
chunks); 750329768 used
I think you'll have to catch Heikki's attention to get a good answer to this.
Is it possible this job
On Mon, Mar 26, 2012 at 5:43 PM, Tom Lane wrote:
> Hm. This illustrates that it's not too prudent to rely on a default
> numdistinct estimate to decide that a hash aggregation is safe :-(.
> We had probably better tweak the cost estimation rules to not trust
> that. Maybe, if we have a default
On Mon, Mar 26, 2012 at 5:41 PM, Andrew Dunstan wrote:
> Combo CIDs: 755490840 total in 100 blocks; 5161072 free (381
> chunks); 750329768 used
I think you'll have to catch Heikki's attention to get a good answer to this.
Is it possible this job is inserting and then updating (or delete
On mån, 2012-03-19 at 15:53 -0400, Tom Lane wrote:
> This connects somewhat to the discussions we've had in the past about
> trying to get not-intended-for-public-use functions out of the
> standard search path. Not that you want to put a full visibility
> check into the tab-completion query, but
Andrew Dunstan writes:
> On 03/26/2012 12:11 PM, Tom Lane wrote:
>> That plan should not create a tuple hash table, so I think it's almost
>> certain that the plan changed. It might be interesting to remove the
>> pg_statistic rows for the table and then see what plan you get.
> Yeah, that gets
On 03/26/2012 12:20 PM, Greg Stark wrote:
On Mon, Mar 26, 2012 at 4:03 PM, Andrew Dunstan wrote:
TupleHashTable: 619175960 total in 95 blocks; 821528 free
(331 chunks); 618354432 used
I think the plan you showed isn't the plan that's running out of
memory. I think it's runni
On 03/26/2012 12:11 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/26/2012 11:18 AM, Tom Lane wrote:
Could we see EXPLAIN output for this query?
Currently it shows:
Limit (cost=19443025.87..19443025.89 rows=10 width=8
-> Sort (cost=19443025.87..19446451.29 rows=1370168 width=8)
On Mon, Mar 26, 2012 at 4:03 PM, Andrew Dunstan wrote:
> TupleHashTable: 619175960 total in 95 blocks; 821528 free
> (331 chunks); 618354432 used
I think the plan you showed isn't the plan that's running out of
memory. I think it's running out of memory because it's using a Hash
Ag
Andrew Dunstan writes:
> On 03/26/2012 11:18 AM, Tom Lane wrote:
>> Could we see EXPLAIN output for this query?
> Currently it shows:
> Limit (cost=19443025.87..19443025.89 rows=10 width=8
>-> Sort (cost=19443025.87..19446451.29 rows=1370168 width=8)
> Sort Key: (max(pageno))
>
On 03/26/2012 11:18 AM, Tom Lane wrote:
Andrew Dunstan writes:
I'm really perplexed as to why this fairly simple query should cause an
out of memory error:
select loid, max(pageno) from ldata group by loid order by 2 desc
limit 10;
Looks like the group by/aggregate step is eating l
Andrew Dunstan writes:
> I'm really perplexed as to why this fairly simple query should cause an
> out of memory error:
> select loid, max(pageno) from ldata group by loid order by 2 desc
> limit 10;
Looks like the group by/aggregate step is eating lots of memory:
> AggCont
hello,
does the problem show up on 2% of all problems after 2 weeks or so?
we had a similar problem on UNIX as well. it even materialized on 100 identical
boxes (on 2% of them). it pops up randomly and never stops …
i checked some code paths. some of those messages are direct output via stderr
(
On Fri, Mar 23, 2012 at 11:02 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié mar 21 21:50:24 -0300 2012:
>> heap_freeze_tuple() was apparently designed at one point to cope with
>> being called with either a shared or exclusive buffer lock. But none
>> of the current calle
I'm not sure if this is a bug, but I have wrestling with this problem
for a client.
Platform is Windows Servers 2003 64 bit, PostgreSQL 8.4.8., 4Gb RAM,
running on an Amazon VM.
Shared buffers: 512Mb, work_mem: 25Mb. There are only a handful of
connections to the database, and no other act
On Sat, Mar 24, 2012 at 1:01 PM, Michael Tautschnig wrote:
> Here, "the two writes on Worker 0" corresponds to lines 15 and 16. And indeed
> line 16 is exactly the call to SetLatch. For solving problem 1, the mp idiom,
> the following options are possible (in all cases stronger synchronisation
> p
Stefan Kaltenbrunner writes:
> On 03/26/2012 03:47 AM, Tom Lane wrote:
>> Replace empty locale name with implied value in CREATE DATABASE and initdb.
> hmm seems like this commit broken quagga:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2012-03-26%2002%3A03%3A04
Hm, it's hard
Robert Haas writes:
> On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander wrote:
>>> s/segment/file/g?
>> We're already using "file" to mean something different *internally*,
>> don't we? And since pg_controldata shows fairly internal information,
>> I'm not sure this is the best idea.
>>
>> Maybe
Hello Tom,
I started to look at this patch a bit. I'm quite confused by the fact
that some, but not all, of the possible FK action types now come in an
EACH variant. This makes no sense at all to me. ISTM that EACH is a
property of the FK constraint as a whole, that is that it says the
c
On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander wrote:
>>> s/segment/file/g?
>>
>> Yep, "file" might be more intuitive for a user than "segment". Attached is
>> the
>> "file" version of the patch.
>
> We're already using "file" to mean something different *internally*,
> don't we? And since pg_c
On Sun, Mar 25, 2012 at 12:15 PM, Andres Freund wrote:
> On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote:
>> > This will have the effect of calling triggers outside of alphabetic
>> > order. I don't think thats a good idea even if one part is ANY and the
>> > other a specific command.
Hello, This is new version of patch for dblink using row processor.
- Use palloc to allocate temporaly memoriy blocks.
- Memory allocation is now done in once. Preallocate a block of
initial size and palloc simplified reallocation code.
- Resurrected the route for command invoking. And sma
On 03/26/2012 03:47 AM, Tom Lane wrote:
> Replace empty locale name with implied value in CREATE DATABASE and initdb.
>
> setlocale() accepts locale name "" as meaning "the locale specified by the
> process's environment variables". Historically we've accepted that for
> Postgres' locale settings
On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
> >> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> >> outright kill a backend that they own (politely,
65 matches
Mail list logo
