Robert Haas wrote:
I suppose one interesting question is to figure out if there's a way I
can optimize the disk configuration in this machine, or the Linux I/O
scheduler, or something, so as to reduce the amount of time it spends
waiting for the disk.
I'd be curious to know if using the
On Sun, Apr 1, 2012 at 11:12 PM, Greg Stark st...@mit.edu wrote:
On Sun, Apr 1, 2012 at 10:27 PM, Simon Riggs si...@2ndquadrant.com wrote:
So lock starvation on the control lock would cause a long wait after
each I/O, making it look like an I/O problem.
Except that both of the locks involved
On Mon, Apr 2, 2012 at 1:17 AM, Joe Van Dyk j...@tanga.com wrote:
Anyone else want event scheduling / cron / temporal triggers in
postgresql? http://dev.mysql.com/doc/refman/5.1/en/events-overview.html
shows how it works in mysql.
Can we throw money at someone to get this in postgres? Is
On Mon, Apr 2, 2012 at 12:00 AM, Greg Stark st...@mit.edu wrote:
On Sun, Apr 1, 2012 at 4:05 AM, Robert Haas robertmh...@gmail.com wrote:
My guess based on previous testing is
that what's happening here is (1) we examine a tuple on an old page
and decide we must look up its XID, (2) the
On Sat, Mar 31, 2012 at 6:37 AM, Dobes Vandermeer dob...@gmail.com wrote:
On Sat, Mar 31, 2012 at 1:44 AM, Daniel Farina dan...@heroku.com wrote:
On Fri, Mar 30, 2012 at 10:21 AM, Daniel Farina dan...@heroku.com wrote:
Any enhancement here that can't be used with libpq via, say, drop-in
.so
On Mon, Apr 2, 2012 at 8:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Apr 2, 2012 at 1:17 AM, Joe Van Dyk j...@tanga.com wrote:
Anyone else want event scheduling / cron / temporal triggers in
postgresql? http://dev.mysql.com/doc/refman/5.1/en/events-overview.html
shows how it works
On Mon, Apr 2, 2012 at 12:29 AM, Jay Levitt jay.lev...@gmail.com wrote:
At this point I agree with you, but I'm still going to go into detail,
because I think there are two markets for Postgres, and the database
community has been so focused around enterprise for so long that you're
missing
On Mon, Apr 2, 2012 at 8:15 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not true, please refer to code at line 544, as I already indicated.
My understanding of the instrumentation is that the lock acquired at
line 526 will show as the blocker until we reach line 555, so anything
in between
On Mon, Apr 2, 2012 at 11:49 AM, Greg Stark st...@mit.edu wrote:
On Mon, Apr 2, 2012 at 8:15 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not true, please refer to code at line 544, as I already indicated.
My understanding of the instrumentation is that the lock acquired at
line 526 will show
On 04/02/2012 05:23 AM, Dave Page wrote:
There are hundreds of thousands of pieces of malware for Windows that
relied on the ability to write to system directories like this to do
their misdeeds. Anywhere they can write (or modify existing) software
that may get executed at boot time or by an
On 1 April 2012 06:41, Robert Haas robertmh...@gmail.com wrote:
There seem to be too relevant differences between your test and mine:
(1) your test is just a single insert per transaction, whereas mine is
pgbench's usual update, select, update, update, insert and (2) it
seems that, to really
Dave Page wrote:
On Mon, Apr 2, 2012 at 12:29 AM, Jay Levittjay.lev...@gmail.com wrote:
Just as an FYI, a large percentage of the PostgreSQL developers are
Mac users, including myself. They're also the company standard at
EnterpriseDB - so we're not entirely unfamiliar with software
development
:) yah that makes sense no big deal. i'll probably just push this head
buiild of pg_dump onto the production machines till it comes out.
Thanks again!
On Sat, Mar 31, 2012 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Mike Roest mike.ro...@replicon.com writes:
Any idea when 9.1.4 with
On Mon, Apr 2, 2012 at 8:17 AM, Jay Levitt jay.lev...@gmail.com wrote:
Sure, and if humans read docs, instead of just glancing at them, that'd be
all you needed. In any case, I could counter myself that nobody reads the
doc period, so it doesn't matter what version is listed; that's just the
On 04/01/2012 06:34 PM, Andrew Dunstan wrote:
Some of my PostgreSQL Experts colleagues have been complaining to me
that servers under load with very large queries cause CSV log files
that are corrupted, because lines are apparently multiplexed. The log
chunking protocol between the errlog
Andrew Dunstan and...@dunslane.net writes:
On 04/01/2012 06:34 PM, Andrew Dunstan wrote:
Some of my PostgreSQL Experts colleagues have been complaining to me
that servers under load with very large queries cause CSV log files
that are corrupted,
We could just increase CHUNK_SLOTS in
David Johnston wrote:
Just trying to bridge an apparent gap since the original e-mail seems to
have come across as too adversarial that the underlying thoughts have
been overlooked. Trying to contribute in my own way with my current
resources.
Thanks, but it's my own fault for basing a
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
2012-03-29 19:03 keltez?ssel, Noah Misch ?rta:
one of the new sections about readahead should somehow reference the hazard
around volatile functions.
Done.
I don't see the mention in your latest patch. You do mention it for
On 04/02/2012 12:00 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 04/01/2012 06:34 PM, Andrew Dunstan wrote:
Some of my PostgreSQL Experts colleagues have been complaining to me
that servers under load with very large queries cause CSV log files
that are corrupted,
We
On Mon, Apr 2, 2012 at 7:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
Do you consider this proof that it can only be I/O? Or do we still
need to find out?
I stuck a bunch more debugging instrumentation into the SLRU code. It
was fairly clear from the previous round of instrumentation that
Andrew Dunstan and...@dunslane.net writes:
On 04/02/2012 12:00 PM, Tom Lane wrote:
This seems like it isn't actually fixing the problem, only pushing out
the onset of trouble a bit. Should we not replace the fixed-size array
with a dynamic data structure?
But maybe your're right. If we do
On 04/02/2012 12:44 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 04/02/2012 12:00 PM, Tom Lane wrote:
This seems like it isn't actually fixing the problem, only pushing out
the onset of trouble a bit. Should we not replace the fixed-size array
with a dynamic data
Robert Haas robertmh...@gmail.com wrote:
This particular example shows the above chunk of code taking 13s
to execute. Within 3s, every other backend piles up behind that,
leading to the database getting no work at all done for a good ten
seconds.
My guess is that what's happening here is
Andrew Dunstan and...@dunslane.net writes:
On 04/02/2012 12:44 PM, Tom Lane wrote:
You could do something like having a list of pending chunks for each
value of (pid mod 256). The length of each such list ought to be plenty
short under ordinary circumstances.
Yeah, ok, that should work. How
a
href=http://mojicacnc.com/wp-content/plugins/extended-comment-options/02efpk.html;
http://mojicacnc.com/wp-content/plugins/extended-comment-options/02efpk.html/a
On Mon, Apr 2, 2012 at 5:29 AM, Jay Levitt jay.lev...@gmail.com wrote:
So this is pointless to the discussion now, but if you want to engage
off-list, I'd frankly love to be reconvinced:
It may not be an unreasonable thing for an individual user to do to
their own machine. But it's not really
On tor, 2012-03-29 at 14:48 -0400, Robert Haas wrote:
Frankly, I'm not sure we bet on the right horse in not mandating a
version numbering scheme from the beginning. But given that we
didn't, we probably don't want to get too forceful about it too
quickly. However, we could ease into it by
On Apr 2, 2012, at 11:24 AM, Peter Eisentraut wrote:
Or an extension could specify itself which version numbering scheme it
uses. This just has to be a reference to a type, which in turn could be
semver, debversion, or even just numeric or text (well, maybe name).
Then you'd just need to use
David E. Wheeler da...@justatheory.com writes:
On Apr 2, 2012, at 11:24 AM, Peter Eisentraut wrote:
Or an extension could specify itself which version numbering scheme it
uses. This just has to be a reference to a type, which in turn could be
semver, debversion, or even just numeric or text
On Apr 2, 2012, at 11:58 AM, Tom Lane wrote:
Sounds like a lot of work for core to maintain various version comparison
schemes
Well, the primary argument for avoiding version comparison semantics to
begin with was exactly that we didn't want to mandate a particular
version-numbering
Robert Haas robertmh...@gmail.com writes:
Long story short, when a CLOG-related stall happens,
essentially all the time is being spent in this here section of code:
/*
* If not part of Flush, need to fsync now. We assume this happens
* infrequently enough that it's not a
On Mon, Apr 2, 2012 at 8:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Long story short, when a CLOG-related stall happens,
essentially all the time is being spent in this here section of code:
/*
* If not part of Flush, need to fsync now. We
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm getting HEAD errors on my build farm animal fennec.
I've narrowed it down to this test case:
greg=# CREATE TEMP TABLE boom AS SELECT 'ABC'::bytea;
greg=# SELECT table_to_xml('boom',false,false,'');
server closed the connection
Simon Riggs si...@2ndquadrant.com writes:
I suggest we optimise that by moving the dirty block into shared
buffers and leaving it as dirty. That way we don't need to write or
fsync at all and the bgwriter can pick up the pieces. So my earlier
patch to get the bgwriter to clean the clog would
Greg Sabino Mullane g...@turnstep.com writes:
I'm getting HEAD errors on my build farm animal fennec.
Oh, I looked at that the other day. The animal started failing after
you installed a new libxml in /usr/local. It looks like it is compiling
against the /usr/local copy but still executing
On Mon, Apr 2, 2012 at 8:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
Agreed, though I think it means the fsync is happening on a filesystem
that causes a full system fsync. That time is not normal.
I don't know what you mean. It looks like there are two cases where
this code path executes.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm getting HEAD errors on my build farm animal fennec.
Oh, I looked at that the other day. The animal started failing after
you installed a new libxml in /usr/local.
Ah, okay, that makes sense. So MediaWiki wanted a new version but
On Mon, Apr 2, 2012 at 12:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Long story short, when a CLOG-related stall happens,
essentially all the time is being spent in this here section of code:
/*
* If not part of Flush, need to fsync now. We
On Apr 2, 2012, at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Seems like basically what you've proven is that this code path *is* a
performance issue, and that we need to think a bit harder about how to
avoid doing the fsync while holding locks.
Hmm, good idea. I wonder if we couldn't just
On Apr 2, 2012, at 3:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
Agreed, though I think it means the fsync is happening on a filesystem
that causes a full system fsync. That time is not normal.
It's ext4, which AFAIK does not have that problem.
...Robert
--
Sent via pgsql-hackers
On Mon, Apr 2, 2012 at 8:14 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
While the graph that I produced was about the same shape as yours, the
underlying hardware was quite different, and indeed with my benchmark
group commit's benefits are more apparent earlier - at 32 clients,
On Sun, Apr 1, 2012 at 12:31 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Currently, only regular backends set the stack base pointer, for the
check_stack_depth() mechanism, in PostgresMain. We don't have stack overrun
protection in auxiliary processes. However, autovacuum
On Mon, Apr 2, 2012 at 12:58 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I can't help thinking that the background hinter I had ideas about
writing would prevent many of the reads of old CLOG pages, taking a
lot of pressure off of this area. It just occurred to me that the
43 matches
Mail list logo
