On Sat, Nov 27, 2010 at 11:18 PM, Bruce Momjian wrote:
> Not sure that information moves us forward. If the postmaster cleared
> the memory, we would have COW in the child and probably be even slower.
Well, we can determine the answers to these questions empirically. I
think some more scrutiny
On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Nov 27, 2010, at 2:49 PM, Bruce Momjian wrote:
>>> Who's going to be the first to say that being git-centric can't ever be
>>> a bad thing? ;-)
>
>> At least for me, referring to it that way makes finding the original
On 11/27/2010 10:28 PM, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
I noticed that PL/Python uses a simple wrapper around malloc that does
ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
normally do ERROR if we run out of memory?
And while looking at how PL
Robert Haas wrote:
> >> In fact, it wouldn't be that hard to relax the "known at compile time"
> >> constraint either. ?We could just declare:
> >>
> >> char lotsa_zero_bytes[NUM_ZERO_BYTES_WE_NEED];
> >>
> >> ...and then peel off chunks.
> > Won't this just cause loads of additional pagefaults aft
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> I noticed that PL/Python uses a simple wrapper around malloc that does
> ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
> normally do ERROR if we run out of memory?
> And while looking at how PL/Perl does these things I find that
On Sat, Nov 27, 2010 at 2:27 PM, Tom Lane wrote:
> For testing purposes, I figured that what I wanted to stress was
> postgres process swapping and shmem access. I built current git HEAD
> with --enable-debug and no other options, and tested with these
> non-default settings:
> shared_buffers
In recent discussions of the plan-tree representation for KNNGIST index
scans, there seemed to be agreement that it'd be a good idea to explicitly
represent the expected sort ordering of the output. While thinking about
how best to do that, it struck me that there's some pretty horrendous
impedanc
Josh Berkus wrote:
> All,
>
> Whatever we pick, someone will be confused by it and about equal numbers
> regardless. Let's just stick with the current patch.
>
> Or we could call it "extraint conclusions". ;-)
I vote for "extraint confusions".
--
Bruce Momjian http://momjian.us
I noticed that PL/Python uses a simple wrapper around malloc that does
ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
normally do ERROR if we run out of memory?
And while looking at how PL/Perl does these things I find that one
failed malloc (in compile_plperl_function) thr
Vaibhav Kaushal wrote:
> I am going through the Executor code and come across the following terms
> quite often. Can someone tell me what do they mean (in a few (may be a
> couple of) sentences)?
>
> 1. Scan State
> 2. Plan State
> 3. Tuple Projection
> 4. EState
> 5. Qual
> 6. Expression
>
> The
I ran some tests on my dual-Xeon machine to see what speedup using
parallel gmake. After two builds to warm up the cache, I saw when
alternating gmake and gmake -j2:
gmake 0m57.207s
gmake -j2 0m44.305s
gmake 0m58.691s
gmake -j2 0m33.979s
As you can see, gmake -j2
"Andreas 'ads' Scherbaum" writes:
> last week someone raised in a german webforum the question why
> "default_tablespace" is not used for "CREATE DATABASE". After a brief
> discussion on irc (thanks RhodiumToad) I added a note to the
> documentation mentioning this point.
> Patch attached.
Pe
Hello,
last week someone raised in a german webforum the question why
"default_tablespace" is not used for "CREATE DATABASE". After a brief
discussion on irc (thanks RhodiumToad) I added a note to the
documentation mentioning this point.
Patch attached.
Bye
--
Robert Haas writes:
> On Nov 27, 2010, at 2:49 PM, Bruce Momjian wrote:
>> Who's going to be the first to say that being git-centric can't ever be
>> a bad thing? ;-)
> At least for me, referring to it that way makes finding the original patch an
> order of magnitude faster (git show hash). Y
On Nov 27, 2010, at 2:49 PM, Bruce Momjian wrote:
> Who's going to be the first to say that being git-centric can't ever be
> a bad thing? ;-)
At least for me, referring to it that way makes finding the original patch an
order of magnitude faster (git show hash). YMMV.
...Robert
--
Sent via
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Remove outdated comments from the regression test files.
> >>
> >> Since 2004, int2 and int4 operators do detect overflow; this was fixed by
> >> commit 4171bb869f234281a13bb862d3b1e577bf336242.
> >>
> >> Extracted from a larger
Bruce Momjian writes:
> Robert Haas wrote:
>> Remove outdated comments from the regression test files.
>>
>> Since 2004, int2 and int4 operators do detect overflow; this was fixed by
>> commit 4171bb869f234281a13bb862d3b1e577bf336242.
>>
>> Extracted from a larger patch by Andres Freund.
> I no
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
> * Jan Urbański (wulc...@wulczer.org) wrote:
>> On 04/11/10 14:09, Robert Haas wrote:
>> > Hmm, I wonder how useful this is given that restriction.
>>
>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
>> consuming), ri
Heikki Linnakangas wrote:
> There's no on-disk format changes, except for the additional flag in the
> page headers, so this does not affect pg_upgrade. However, if there's
> any "invalid" keys in the old index because of an incomplete insertion,
> the new code will not understand that. So you s
We've gotten a few inquiries about whether Postgres can use "huge pages"
under Linux. In principle that should be more efficient for large shmem
regions, since fewer TLB entries are needed to support the address
space. I spent a bit of time today looking into what that would take.
My testing was
Robert Haas writes:
> Committed, after various changes and corrections. One noteworthy one
> is that I removed the _oid variants, since those would be dead code at
> the moment.
Thanks!
The _oid variants will have to re-appear in the "alter extension set
schema" patch, which is the last of the
Josh Berkus wrote:
>
> > I think the difficulty is figuring out what to get the existing
> > workers to give us some memory when a new one comes along. You want
> > the first worker to potentially use ALL the memory... until worker #2
> > arrives.
>
> Yeah, doing this would mean that you couldn'
Jeroen Vermeulen wrote:
> On 2010-11-15 18:49, Greg Stark wrote:
>
> > I've seen papers on doing relational joins using GPUs and I'm sure
> > there are other algorithms we wonderful stuff we could do. But if it
> > comes at the cost of being able to handle arbitrary join clauses it'll
> > be a tou
Thanks, everyone, for all the feedback! I am nowhere near a database expert
yet, but you guys have been very helpful in clearing up some of my
confusion. I have checked out Postgres-XC and it looks like the version 1.0
that will be released soon probably covers everything I have been looking
for in
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of lun nov 15 02:41:40 -0300 2010:
>
> > I believe also that there are probably race conditions in several of
> > the steps you listed; in particular there is certainly a risk involved
> > in changing the database-we-advertise-being-connecte
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> PQping is supposed to be smarter about classifying errors
> >> than this.
>
> > I was not aware this was discussed last week because I am behind on
> > email. I was fixing a report from a month ago. I did explain how I was
> > doi
On Saturday, November 27, 2010, Nikhil Sontakke wrote:
> Hi, a very good business company, I suggest you go to see:
> mobiles3gs.com, and now all of products enjoy great discount, saving
> time and money.
>
> h--)
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To ma
Hi, a very good business company, I suggest you go to see:
mobiles3gs.com, and now all of products enjoy great discount, saving
time and money.
h--)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
On Thu, Nov 25, 2010 at 1:18 AM, KaiGai Kohei wrote:
> The attached patch is revised version.
>
> - Logging part within auth_delay was removed. This module now focuses on
> injection of a few seconds delay on authentication failed.
> - Documentation parts were added like any other contrib modules
2010/11/25 pasman pasmański :
>>I've seen this as well be a performance issue, in particular with partitioned
>>tables.
>>Out of habit I now write functions that always cache the value of the
>>function in
>>a variable and use the variable in the actual query to avoid this particular
>>"gotcha".
On Fri, Nov 26, 2010 at 7:27 PM, Tom Lane wrote:
>> In fact, now that I think about it, what I'm proposing would actually
>> substantially REDUCE the risk of deadlock on the standby, because the
>> master would only ever need to lock a backing file long enough to drop
>> or truncate it, whereas un
Hi, all
I created a pg_ctl patch to fix:
* BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
Allow pg_ctl to work properly with configuration files located outside the
PGDATA directory
I tested it under Windows XP sp3.
All of configuration files(postgresql.conf pg_hba.con
On Fri, 2010-11-26 at 18:35 -0500, Tom Lane wrote:
> Speaking of which, is there any code in there to ensure that a
> deadlock
> in the standby is resolved by killing HS queries and not the replay
> process? Because deadlocks are certainly going to be possible no
> matter
> what.
Locks cause que
33 matches
Mail list logo
