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
Int
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 (pgsql-hackers@postgresql.
On Fri, Dec 23, 2011 at 5:45 AM, Daniel Farina wrote:
> On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas 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 one (why a full-blown mechanism
On Tue, Jan 3, 2012 at 12:11 PM, Kohei KaiGai wrote:
> 2011/12/23 Robert Haas :
>> On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai wrote:
>>> I'd like the regression test on select_view test being committed also
>>> to detect unexpected changed in the future. How about it?
>>
>> Can you resend that
On Fri, Jan 6, 2012 at 9:29 PM, Jeff Janes wrote:
> On Fri, Jan 6, 2012 at 2:24 PM, 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:
On Fri, Jan 6, 2012 at 2:24 PM, 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
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 addre
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.
Speci
On Fri, Jan 6, 2012 at 6:48 PM, Aidan Van Dyk 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 the hint-bit-wr
On Fri, Jan 6, 2012 at 5:17 PM, Merlin Moncure 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 as well propo
On Fri, Jan 6, 2012 at 5:17 PM, Merlin Moncure wrote:
> On Fri, Jan 6, 2012 at 2:03 PM, Andres Freund 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
On Fri, Jan 6, 2012 at 7:53 PM, Robert Haas wrote:
> On Fri, Jan 6, 2012 at 2:48 PM, Andres Freund 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
>>
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=jaguar&dt=2012-01-02%2023%3A05%3A02
I've managed to duplicate and debug this one too. What I find i
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 o
On Fri, Jan 6, 2012 at 2:03 PM, Andres Freund 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 writes dur
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";
On Fri, Jan 6, 2012 at 4:14 PM, Tom Lane 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 generally have lo
On Fri, Jan 6, 2012 at 3:47 PM, Simon Riggs 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 defined. Or we can recomm
Peter Geoghegan writes:
> On 6 January 2012 18:45, Tom Lane 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 you don't like the
>> comment, we
Alex Hunsaker 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)))
> {
>
On Fri, Jan 6, 2012 at 7:49 PM, Robert Haas 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 going to get this
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 tar
On Friday, January 06, 2012 08:53:38 PM Robert Haas wrote:
> On Fri, Jan 6, 2012 at 2:48 PM, Andres Freund 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
On Fri, Jan 6, 2012 at 2:48 PM, Andres Freund 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 in any che
On Fri, Jan 6, 2012 at 2:35 PM, Andres Freund 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 changed. IMHO
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
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 perf
On Fri, Jan 6, 2012 at 11:05 AM, Tom Lane wrote:
> Robert Haas 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.
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 som
On 6 January 2012 18:45, Tom Lane wrote:
> Peter Geoghegan 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
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 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 *STDI
On Fri, Jan 6, 2012 at 06:34, Andrew Dunstan 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? I imagine
Peter Geoghegan 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 comparetup_index_btree and
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 pg
On 6 January 2012 17:29, Robert Haas wrote:
> On Fri, Jan 6, 2012 at 12:10 PM, Peter Geoghegan
> 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 "dupli
On Thu, Jan 5, 2012 at 3:46 PM, Simon Riggs wrote:
> On Wed, Jan 4, 2012 at 1:35 PM, Kevin Grittner
> wrote:
>> Sure. I just think you are there already except for what I got into.
> New version attached, with your suggested changes included. Hole check
> code is there as well, but ifdef'd out
On Fri, Jan 6, 2012 at 12:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane 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 th
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 is
Robert Haas writes:
> On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane 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
> admit that I punted on testing the
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 pg
On Fri, Jan 6, 2012 at 12:24 PM, Tom Lane 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. This led to some
On Fri, Jan 6, 2012 at 12:10 PM, Peter Geoghegan 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 of everything e
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, but
On 5 January 2012 20:23, Robert Haas 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 confident that we can
On Fri, Jan 6, 2012 at 3:55 PM, Tom Lane wrote:
> Simon Riggs 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 n
On Fri, Jan 6, 2012 at 10:51 AM, Simon Riggs 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 lock. Elsewhere in
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 3:28 PM, Robert Haas wrote:
> On Fri, Jan 6, 2012 at 9:53 AM, Simon Riggs wrote:
>> On Fri, Jan 6, 2012 at 2:29 PM, Robert Haas wrote:
>>> On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane wrote:
I suppose Robert had something more intelligent in mind than a tight
loop w
Robert Haas 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 lane
--
Sent via
Simon Riggs 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,
with just minor discuss
On Thu, Jan 5, 2012 at 5:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane wrote:
>>> I would be in favor of that, or perhaps some other formula (eg, maybe
>>> the minimum should be less than 8 for when you've got very little shmem).
>
>> I have some result
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:27 PM, Tom Lane 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: we do not
On Fri, Jan 6, 2012 at 9:53 AM, Simon Riggs wrote:
> On Fri, Jan 6, 2012 at 2:29 PM, Robert Haas wrote:
>> On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane 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
On Fri, Jan 6, 2012 at 2:29 PM, Robert Haas wrote:
> On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane 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
On Thu, Jan 5, 2012 at 7:37 PM, Tom Lane 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, but I failed to no
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 relati
On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander wrote:
> On Thu, Jan 5, 2012 at 23:19, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
> >>> I think link(2) would create race conditions of its own. I'd be
> >>> inclined to suggest that maybe we s
On Fri, Jan 6, 2012 at 7:52 AM, Heikki Linnakangas
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.
>> */
>> if (!(flag
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;
Tha
On Thu, Jan 5, 2012 at 23:19, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
>>> I think link(2) would create race conditions of its own. I'd be
>>> inclined to suggest that maybe we should just special-case a zero length
>>> postmaster.pid file as me
On Friday, January 06, 2012 11:30:53 AM Simon Riggs wrote:
> On Fri, Jan 6, 2012 at 1:10 AM, Stephen Frost 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 fin
On Fri, Jan 6, 2012 at 1:10 AM, Stephen Frost 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 something to
On Thu, Jan 5, 2012 at 10:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane wrote:
>>> I would be in favor of that, or perhaps some other formula (eg, maybe
>>> the minimum should be less than 8 for when you've got very little shmem).
>
>> I have some resul
On Fri, Jan 6, 2012 at 12:37 AM, Tom Lane 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 revert the above
66 matches
Mail list logo
