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 query
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.conf
On Fri, Nov 26, 2010 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us 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,
2010/11/25 pasman pasmański pasma...@gmail.com:
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
On Thu, Nov 25, 2010 at 1:18 AM, KaiGai Kohei kai...@ak.jp.nec.com 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
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:
On Saturday, November 27, 2010, Nikhil Sontakke nikkh...@gmail.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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-connected-to
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
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 tough
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't give
Robert Haas robertmh...@gmail.com 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
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
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 should
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost sfr...@snowman.net 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
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Nov 27, 2010, at 2:49 PM, Bruce Momjian br...@momjian.us 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 Haas robertmh...@gmail.com writes:
On Nov 27, 2010, at 2:49 PM, Bruce Momjian br...@momjian.us 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
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
--
Andreas 'ads' Scherbaum adsm...@wars-nicht.de 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
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
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
They sound
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)
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 br...@momjian.us
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
On Sat, Nov 27, 2010 at 2:27 PM, Tom Lane t...@sss.pgh.pa.us 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:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org 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
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 after fork() when those
On 11/27/2010 10:28 PM, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=wulc...@wulczer.org 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
On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Nov 27, 2010, at 2:49 PM, Bruce Momjian br...@momjian.us 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,
On Sat, Nov 27, 2010 at 11:18 PM, Bruce Momjian br...@momjian.us 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
33 matches
Mail list logo
