On Fri, Jan 6, 2012 at 12:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We could fix the direct symptom by inserting UnlockReleaseBuffer()
in front of the continue, but AFAICS that just makes this into a
busy-waiting equivalent of waiting unconditionally, so I don't really
see why we should not
On Thu, Jan 5, 2012 at 10:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would be in favor of that, or perhaps some other formula (eg, maybe
the minimum should be less than 8 for when
On Fri, Jan 6, 2012 at 1:10 AM, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
I discover that non-all-zeroes holes are fairly common, just not very
frequent.
Curious, might be interesting to find out why.
That may or may not be a problem, but not
On Friday, January 06, 2012 11:30:53 AM Simon Riggs wrote:
On Fri, Jan 6, 2012 at 1:10 AM, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
I discover that non-all-zeroes holes are fairly common, just not very
frequent.
Curious, might be interesting
On Thu, Jan 5, 2012 at 23:19, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Jan 5, 2012 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
I think link(2) would create race conditions of its own. I'd be
inclined to suggest that maybe we should just
In BufferSync(), we have this:
/*
* Unless this is a shutdown checkpoint, we write only permanent, dirty
* buffers. But at shutdown time, we write all dirty buffers.
*/
if (!(flags CHECKPOINT_IS_SHUTDOWN))
flags |= BM_PERMANENT;
On Fri, Jan 6, 2012 at 7:52 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
In BufferSync(), we have this:
/*
* Unless this is a shutdown checkpoint, we write only permanent,
dirty
* buffers. But at shutdown time, we write all dirty buffers.
On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 5, 2012 at 23:19, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Jan 5, 2012 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
I think link(2) would create race
On 01/05/2012 10:59 PM, Alex Hunsaker wrote:
After further digging I found it chokes on any non scalar (IOW any
reference). I attached a simple c program that I tested with 5.8.9,
5.10.1, 5.12.4 and 5.14.2 (for those who did not know about it,
perlbrew made testing across all those perls
On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I suppose Robert had something more intelligent in mind than a tight
loop when the buffer can't be exclusively locked, so maybe there is
some other change that should be made here instead.
My intention was to skip the tuple,
On Fri, Jan 6, 2012 at 2:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I suppose Robert had something more intelligent in mind than a tight
loop when the buffer can't be exclusively locked, so maybe there is
some other change
On Fri, Jan 6, 2012 at 9:53 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 6, 2012 at 2:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I suppose Robert had something more intelligent in mind than a tight
loop when
On Thu, Jan 5, 2012 at 5:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There is no compiler anywhere that implements always inline, unless
you are talking about a macro. inline is a hint and nothing more,
and if you think you can force it you are mistaken. So this controversy
is easily resolved:
Excerpts from Andrew Dunstan's message of vie ene 06 10:34:30 -0300 2012:
And yes, we should possibly add a regression test or two. Of course, we can't
use the cause of the original complaint ($^V) in them, though.
Why not? You obviously can't need output it verbatim, but you could
compare
On Thu, Jan 5, 2012 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would be in favor of that, or perhaps some other formula (eg, maybe
the minimum should be less than 8 for when
Simon Riggs si...@2ndquadrant.com writes:
Please can we either make it user configurable?
Weren't you just complaining that *I* was overcomplicating things?
I see no evidence to justify inventing a user-visible GUC here.
We have rough consensus on both the need for and the shape of a formula,
Robert Haas robertmh...@gmail.com writes:
After thinking about this a bit, I think the problem is that the
divisor we picked is still too high. Suppose we set num_clog_buffers
= (shared_buffers / 4MB), with a minimum of 4 and maximum of 32.
Works for me.
regards, tom
On Fri, Jan 6, 2012 at 3:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 6, 2012 at 9:53 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 6, 2012 at 2:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I
On 01/06/2012 10:49 AM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of vie ene 06 10:34:30 -0300 2012:
And yes, we should possibly add a regression test or two. Of course, we can't
use the cause of the original complaint ($^V) in them, though.
Why not? You obviously can't
On Fri, Jan 6, 2012 at 10:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
I *have* explained what is wrong. It leaves unused tuples in the heap
that would previously have been removed.
More simply: lazy_vacuum_page() does some work and we can't skip that
work just because we don't get the
On Fri, Jan 6, 2012 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Please can we either make it user configurable?
Weren't you just complaining that *I* was overcomplicating things?
I see no evidence to justify inventing a user-visible GUC here.
We
On 5 January 2012 20:23, Robert Haas robertmh...@gmail.com wrote:
I don't have a problem with the idea of a pg_always_inline, but I'm
wondering what sort of fallback mechanism you propose. It seems to me
that if the performance improvement is conditioned on inlining be done
and we're not
I started to wonder how likely it would be that some other process would
sit on a buffer pin for so long as to allow 134217727 iterations of
ReadBufferExtended, even given the slowdowns associated with
CLOBBER_CACHE_ALWAYS. This led to some fruitless searching for possible
deadlock conditions,
On Fri, Jan 6, 2012 at 12:10 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
As you know, all queries tested have lots and lots of duplicates (a
~1.5GB table that contains the same number of distinct elements as a
~10MB table once did), and removing the duplicate protection for
btrees, on top
On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I started to wonder how likely it would be that some other process would
sit on a buffer pin for so long as to allow 134217727 iterations of
ReadBufferExtended, even given the slowdowns associated with
CLOBBER_CACHE_ALWAYS.
I've been asked by someone to support pgshpere.
It would appear that the two project owners are MIA. If anyone knows
different can they let me know ?
Does anyone have any objection to me taking over the project?
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
--
Sent via
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So at this point I've got serious doubts as to the quality of testing of
that whole patch, not just this part.
I tested the case where we skip a block during the first pass, but I
On 01/06/2012 12:32 PM, Dave Cramer wrote:
I've been asked by someone to support pgshpere.
It would appear that the two project owners are MIA. If anyone knows
different can they let me know ?
Does anyone have any objection to me taking over the project?
One of the owners is Teodor, who
On Fri, Jan 6, 2012 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So at this point I've got serious doubts as to the quality of testing of
that whole patch, not just this part.
I
On Thu, Jan 5, 2012 at 3:46 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Jan 4, 2012 at 1:35 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Sure. I just think you are there already except for what I got into.
New version attached, with your suggested changes included. Hole
On 6 January 2012 17:29, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 6, 2012 at 12:10 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
As you know, all queries tested have lots and lots of duplicates (a
~1.5GB table that contains the same number of distinct elements as a
~10MB table
I've been asked by someone to support pgshpere.
It would appear that the two project owners are MIA. If anyone knows
different can they let me know ?
Does anyone have any objection to me taking over the project?
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
--
Sent via
Peter Geoghegan pe...@2ndquadrant.com writes:
I didn't bother isolating that, because it doesn't really make sense
to (not having it is probably only of particular value when doing what
I'm doing anyway, but who knows). Go ahead and commit something to
remove that code (get it in both
On Fri, Jan 6, 2012 at 06:34, Andrew Dunstan and...@dunslane.net wrote:
PFA that copies if its readonly and its not a scalar.
I didn't bother adding regression tests-- should I have?
I have several questions.
1. How much are we actually saving here? newSVsv() ought to be pretty cheap,
no?
On 01/06/2012 02:02 PM, Alex Hunsaker wrote:
3. The above is in any case almost certainly insufficient, because in my
tests a typeglob didn't trigger SvREADONLY(), but did cause a crash.
Hrm the glob I was testing was *STDIN. It failed to fail in my test
program because I was not testing
On Wed, Jan 04, 2012 at 10:19:16PM -0800, David Fetter wrote:
Folks,
Please find attached two patches, each under the PostgreSQL license,
one which implements page checksums vs. REL9_0_STABLE, the other which
depends on the first (i.e. requires that it be applied first) and
implements
On 6 January 2012 18:45, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
I didn't bother isolating that, because it doesn't really make sense
to (not having it is probably only of particular value when doing what
I'm doing anyway, but who knows). Go ahead and
On Friday, January 06, 2012 07:26:14 PM Simon Riggs wrote:
The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block in any checkpoint that has
not previously been changed. IMHO this fixes the torn page problem
correctly, though at some
On Fri, Jan 6, 2012 at 11:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
After thinking about this a bit, I think the problem is that the
divisor we picked is still too high. Suppose we set num_clog_buffers
= (shared_buffers / 4MB), with a minimum of 4 and
On 06.01.2012 20:26, Simon Riggs wrote:
The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block in any checkpoint that has
not previously been changed. IMHO this fixes the torn page problem
correctly, though at some additional loss of
On Friday, January 06, 2012 08:45:45 PM Heikki Linnakangas wrote:
On 06.01.2012 20:26, Simon Riggs wrote:
The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block in any checkpoint that has
not previously been changed. IMHO this fixes
On Fri, Jan 6, 2012 at 2:35 PM, Andres Freund and...@anarazel.de wrote:
On Friday, January 06, 2012 07:26:14 PM Simon Riggs wrote:
The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block in any checkpoint that has
not previously been
On Fri, Jan 6, 2012 at 2:48 PM, Andres Freund and...@anarazel.de wrote:
On Friday, January 06, 2012 08:45:45 PM Heikki Linnakangas wrote:
On 06.01.2012 20:26, Simon Riggs wrote:
The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block
On Friday, January 06, 2012 08:53:38 PM Robert Haas wrote:
On Fri, Jan 6, 2012 at 2:48 PM, Andres Freund and...@anarazel.de wrote:
On Friday, January 06, 2012 08:45:45 PM Heikki Linnakangas wrote:
On 06.01.2012 20:26, Simon Riggs wrote:
The following patch (v4) introduces a new WAL record
Corrections:
On Thu, Dec 29, 2011 at 11:35:00AM -0500, Noah Misch wrote:
On Wed, Nov 09, 2011 at 08:49:35PM +0400, Alexander Korotkov wrote:
+ *We set s to be the estimated frequency of the K'th element in a
natural
+ *language's frequency table, where K is the target
On Fri, Jan 6, 2012 at 7:49 PM, Robert Haas robertmh...@gmail.com wrote:
No, but I'd rather see us commit a checksum patch that sometimes
carries a major performance penalty and then work to reduce that
penalty later than never commit anything at all. I think it's
unrealistic to assume we're
Alex Hunsaker bada...@gmail.com writes:
Oh my... I dunno exactly what I was smoking last night, but its a good
thing I didn't share :-). Uh so my test program was also completely
wrong, Ill have to redo it all. I've narrowed it down to:
if ((type == SVt_PVGV || SvREADONLY(sv)))
Peter Geoghegan pe...@2ndquadrant.com writes:
On 6 January 2012 18:45, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, I'm going to object to reverting that commit, as I believe
that having equal-keyed index entries in physical table order may offer
some performance benefits at access time. If
On Fri, Jan 6, 2012 at 3:47 PM, Simon Riggs si...@2ndquadrant.com wrote:
Since we ignore hints during HS anyway,
No, we don't. We need to ignore visibility map bits, but we need not
and do not ignore HEAP_XMIN_COMMITTED, HEAP_XMAX_COMMITTED, etc.
not setting them seems OK if
checksums
On Fri, Jan 6, 2012 at 4:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Admittedly, I don't have any numbers quantifying just how useful that
might be, but on the other hand you've not presented any evidence
justifying removing the behavior either. If we believe your position
that indexes don't
On Tue, Jan 03, 2012 at 09:11:17PM -0500, Andrew Dunstan wrote:
Yeah, I'm with you and Pavel. Here's my quick perl one-liner to
produce a set of SPI_* constants for pl/perl. I'm looking at the
best way to include this in the bootstrap code.
perl -ne 'BEGIN { print use constant\n{\n; } END
On Fri, Jan 6, 2012 at 2:03 PM, Andres Freund and...@anarazel.de wrote:
The standby can set hint bits locally that weren't set on the data it
received from the master. This will require rechecksumming and
rewriting the page, but obviously we can't write the WAL records
needed to protect those
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look. Here's how they looked back in July:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg01373.php
Here are the results from a test I ran today
Another regression test failure that I've been seeing lately is a change
from index-only scan to seqscan in create_index, as for instance here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguardt=2012-01-02%2023%3A05%3A02
I've managed to duplicate and debug this one too. What I find
On Fri, Jan 6, 2012 at 7:53 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 6, 2012 at 2:48 PM, Andres Freund and...@anarazel.de wrote:
On Friday, January 06, 2012 08:45:45 PM Heikki Linnakangas wrote:
On 06.01.2012 20:26, Simon Riggs wrote:
The following patch (v4) introduces a new
On Fri, Jan 6, 2012 at 5:17 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Jan 6, 2012 at 2:03 PM, Andres Freund and...@anarazel.de wrote:
The standby can set hint bits locally that weren't set on the data it
received from the master. This will require rechecksumming and
rewriting the
On Fri, Jan 6, 2012 at 5:17 PM, Merlin Moncure mmonc...@gmail.com wrote:
Its funny. I have the feeling we all are missing a very obvious brilliant
solution to this...
Like getting rid of hint bits?
No.
First, that solution has been proposed before, and it crashed and
burned before. You may
On Fri, Jan 6, 2012 at 6:48 PM, Aidan Van Dyk ai...@highrise.ca wrote:
I think I've said it before, but I'm guessing OLTP style database
rarely have pages written that are dirty that aren't covered by real
changes (so have the FPW anyways) and OLAP type generally freeze after
loads to avoid
There's a corner case in the SSI cleanup code that isn't handled
correctly. It can arise when running workloads that are comprised
mostly (but not 100%) of READ ONLY transactions, and can corrupt the
finished SERIALIZABLEXACT list, potentially causing a segfault. The
attached patch fixes it.
In 367bc426a1c22b9f6badb06cd41fc438fd034639, I introduced a
CheckIndexCompatible() that approves btree and hash indexes having changed to
a different operator class within the same operator family. To make that
valid, I also tightened the operator family contracts for those access methods
to
On Fri, Jan 6, 2012 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look. Here's how they looked back in July:
On Fri, Jan 6, 2012 at 9:29 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 6, 2012 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look.
On Tue, Jan 3, 2012 at 12:11 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/12/23 Robert Haas robertmh...@gmail.com:
On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'd like the regression test on select_view test being committed also
to detect unexpected changed in
On Fri, Dec 23, 2011 at 5:45 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas robertmh...@gmail.com wrote:
Assuming the command in
question can be stuffed inside a function, the most you're gaining is
a little notational convenience
I can answer that
Hello
There is broken link on http://yum.postgresql.org/repopackages.php page
PostgreSQL 9.1 - Fedora 14 -
http://yum.postgresql.org/9.1/fedora/fedora-14-i386/pgdg-fedora-9.1-2.noarch.rpm
- 404 - Not Found
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list
On 07.01.2012 00:24, Robert Haas wrote:
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look. Here's how they looked back in July:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg01373.php
66 matches
Mail list logo
