> -Original Message-
> From: Jim Nasby [mailto:j...@nasby.net]
> Sent: Tuesday, April 02, 2013 4:43 AM
> To: Amit Kapila
> Cc: 'Ants Aasma'; 'Merlin Moncure'; 'Tom Lane'; 'Atri Sharma'; 'Greg
> Stark'; 'PostgreSQL-development'
> Subject: Re: [HACKERS] Page replacement algorithm in buffer
On Mon, Apr 1, 2013 at 6:09 PM, Jim Nasby wrote:
> On 4/1/13 4:55 PM, Merlin Moncure wrote:
>>
>> On Mon, Apr 1, 2013 at 4:09 PM, Andres Freund
>> wrote:
>>>
>>> >On 2013-04-01 08:28:13 -0500, Merlin Moncure wrote:
>>On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes
>> wrote:
>
>
On Tue, Apr 2, 2013 at 1:24 AM, Tom Lane wrote:
> Jeff Janes writes:
>> The problem is that the state is maintained only to an integer number of
>> milliseconds starting at 1, so it can take a number of attempts for the
>> random increment to jump from 1 to 2, and then from 2 to 3.
>
> Hm ... fai
> I don't be believe there is any reasonable argument that
> sitting and spinning while holding the BufFreelistLock is a good idea.
I completely agree. The idea of spinning for a lock while already
inside a lock seems like a source of a hit to performance.
Regards,
Atri
--
Regards,
Atri
l'
Jeff Janes writes:
> The problem is that the state is maintained only to an integer number of
> milliseconds starting at 1, so it can take a number of attempts for the
> random increment to jump from 1 to 2, and then from 2 to 3.
Hm ... fair point, if you assume that the underlying OS has a sleep
Hello
2013/4/2 Brendan Jurd
> On 2 April 2013 11:34, David E. Wheeler wrote:
> > On Apr 1, 2013, at 4:59 PM, Robert Haas wrote:
> >
> >> I think the only people for whom nothing will break are the people who
> >> aren't using arrays in the first place. Anyone who is is likely to
> >> have de
While stracing a process that was contending for a spinlock, I noticed that
the sleep time would often have a longish sequence of 1 and 2 msec sleep
times, rather than the rapidly but randomly increasing sleep time intended.
(At first it looked like it was sleeping on a different attempt each time
On Monday, April 1, 2013, Jeff Davis wrote:
> On Mon, 2013-04-01 at 10:37 -0700, Jeff Janes wrote:
>
> > Over 10,000 cycles of crash and recovery, I encountered two cases of
> > checksum failures after recovery, example:
> >
> >
> > 14264 SELECT 2013-03-28 13:08:38.980 PDT:WARNING: page verificat
On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes wrote:
> On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
>
>>
>> Patch attached. Only brief testing done, so I might have missed
>> something. I will look more closely later.
>>
>
> After applying your patch, I could run the stress test described he
I installed cygwin and ran ./configure on it. It says cannot run /bin/sh
config/config.sub
I was already following that link.
On Mon, Apr 1, 2013 at 8:15 PM, Tom Lane wrote:
> Chamila Wijayarathna writes:
> > I'm new to postresql development. I cloned the project from git and tried
> > to buil
On Mon, 2013-04-01 at 10:37 -0700, Jeff Janes wrote:
> Over 10,000 cycles of crash and recovery, I encountered two cases of
> checksum failures after recovery, example:
>
>
> 14264 SELECT 2013-03-28 13:08:38.980 PDT:WARNING: page verification
> failed, calculated checksum 7017 but expected 1098
On 2 April 2013 11:34, David E. Wheeler wrote:
> On Apr 1, 2013, at 4:59 PM, Robert Haas wrote:
>
>> I think the only people for whom nothing will break are the people who
>> aren't using arrays in the first place. Anyone who is is likely to
>> have dependencies on the way array_lower/upper work
On 2 April 2013 10:59, Robert Haas wrote:
> On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd wrote:
>> It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in
>> existing applications, so there is no way for that idiom in existing
>> applications to be broken by upgrading. If testing for eq
On Apr 1, 2013, at 4:59 PM, Robert Haas wrote:
> I think the only people for whom nothing will break are the people who
> aren't using arrays in the first place. Anyone who is is likely to
> have dependencies on the way array_lower/upper work today.
Well, what if we add new functions that retur
On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd wrote:
> It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in
> existing applications, so there is no way for that idiom in existing
> applications to be broken by upgrading. If testing for equality with
> '{}' works now, it will also work
On 3/24/13 8:11 AM, Greg Smith wrote:
On 3/22/13 8:45 AM, Ants Aasma wrote:
However, I think the main issue isn't finding new algorithms that are
better in some specific circumstances. The hard part is figuring out
whether their performance is better in general.
Right. The current page replac
On 3/23/13 4:43 AM, Amit Kapila wrote:
I have tried one of the idea's : Adding the buffers background writer finds
reusable to freelist.
http://www.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C382852FF97@szxeml509-mbs
This can reduce the clock swipe as it can find buffers from freelist
On 4/1/13 4:55 PM, Merlin Moncure wrote:
On Mon, Apr 1, 2013 at 4:09 PM, Andres Freund wrote:
>On 2013-04-01 08:28:13 -0500, Merlin Moncure wrote:
>>On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes wrote:
>> >On Friday, March 22, 2013, Ants Aasma wrote:
>> >>
>> >>On Fri, Mar 22, 2013 at 10:22 P
On 3/23/13 7:41 AM, Ants Aasma wrote:
On Sat, Mar 23, 2013 at 6:04 AM, Jim Nasby wrote:
Partitioned clock sweep strikes me as a bad idea... you could certainly get
unlucky and end up with a lot of hot stuff in one partition.
Surely that is not worse than having everything in a single partitio
On 1 April 2013 21:57, Robert Haas wrote:
> On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd wrote:
>> On 27 March 2013 06:47, Robert Haas wrote:
>>> rhaas=# select '{}'::int4[] = '{}'::int4[];
>>
>> The good news is, if anybody out there is using that idiom to test for
>> emptiness, they will not
On 4/1/13 8:58 AM, Merlin Moncure wrote:
On Mon, Apr 1, 2013 at 6:43 AM, Robert Haas wrote:
On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane wrote:
Robert Haas writes:
Well, you could easily change array_ndims() to error out if ARR_NDIM()
is negative or more than MAXDIM and return NULL only if it'
On Mon, Apr 1, 2013 at 4:09 PM, Andres Freund wrote:
> On 2013-04-01 08:28:13 -0500, Merlin Moncure wrote:
>> On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes wrote:
>> > On Friday, March 22, 2013, Ants Aasma wrote:
>> >>
>> >> On Fri, Mar 22, 2013 at 10:22 PM, Merlin Moncure
>> >> wrote:
>> >> > wel
On Mon, Mar 25, 2013 at 2:38 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Mar 25, 2013 at 1:50 AM, Tom Lane wrote:
> >> Similarly, pushing PG-specific declarations like RE_compile_and_cache()
> >> into regex/regex.h is completely not the right thing for preserving a
> >> clear l
On 2013-04-01 08:28:13 -0500, Merlin Moncure wrote:
> On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes wrote:
> > On Friday, March 22, 2013, Ants Aasma wrote:
> >>
> >> On Fri, Mar 22, 2013 at 10:22 PM, Merlin Moncure
> >> wrote:
> >> > well if you do a non-locking test first you could at least avoid
On Mon, Apr 1, 2013 at 3:32 PM, Bruce Momjian wrote:
> On Mon, Apr 1, 2013 at 11:55:07AM -0500, Merlin Moncure wrote:
>> > In fact, BufFreelistLock is really misnamed, because for the most
>> > part, the "free list" as we implement is going to be empty. What the
>> > BufFreelistLock is really do
On Mon, Apr 1, 2013 at 10:53 PM, Andres Freund wrote:
> On 2013-04-01 21:24:06 +0200, Magnus Hagander wrote:
>> On Mon, Apr 1, 2013 at 9:09 PM, Andres Freund wrote:
>> > Hi,
>> >
>> > On 2013-04-01 20:43:36 +0200, Magnus Hagander wrote:
>> >> Maybe my thinking is just missing something obvious he
On 2013-04-01 21:24:06 +0200, Magnus Hagander wrote:
> On Mon, Apr 1, 2013 at 9:09 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2013-04-01 20:43:36 +0200, Magnus Hagander wrote:
> >> Maybe my thinking is just missing something obvious here. But looking
> >> at a fresh initdb, I'm seeing a number of
On Mon, Apr 1, 2013 at 11:55:07AM -0500, Merlin Moncure wrote:
> > In fact, BufFreelistLock is really misnamed, because for the most
> > part, the "free list" as we implement is going to be empty. What the
> > BufFreelistLock is really doing is serializing the process of scanning
> > for a free b
On Tue, Jan 15, 2013 at 3:28 PM, Kohei KaiGai wrote:
> This patch adds sepgsql support for permission checks equivalent
> to the existing SCHEMA USE privilege.
>
> This feature is constructed on new OAT_SCHEMA_SEARCH event
> type being invoked around pg_namespace_aclcheck().
> So, its expected beh
Hello all
I would to draw a plan for 9.4. This patch was moved second times to next
release and now is time do decision about direction, how to implement this
functionality be acceptable (or leave it).
RECAPITULATION
What this patch does:
* it try to prepare plans for all expressions
* it check
On Mon, Apr 1, 2013 at 9:09 PM, Andres Freund wrote:
> Hi,
>
> On 2013-04-01 20:43:36 +0200, Magnus Hagander wrote:
>> Maybe my thinking is just missing something obvious here. But looking
>> at a fresh initdb, I'm seeing a number of files in the data directory
>> for this database that don't have
Hi,
On 2013-04-01 20:43:36 +0200, Magnus Hagander wrote:
> Maybe my thinking is just missing something obvious here. But looking
> at a fresh initdb, I'm seeing a number of files in the data directory
> for this database that don't have corresponding entries in pg_class. I
> looked for entries bas
I've had a buildfarm module testing cross-version pg_upgrade for a while
now. It's fairly stable - it considered there's a success when the diffs
from the original and the converted dumps match the following perl table:
#targetsource
my $expected_dif
Maybe my thinking is just missing something obvious here. But looking
at a fresh initdb, I'm seeing a number of files in the data directory
for this database that don't have corresponding entries in pg_class. I
looked for entries based on relfilenode in pg_class - am I missing
some other way we put
On Sun, Feb 10, 2013 at 3:27 PM, Jeff Janes wrote:
...
> Will add to commitfest-next.
>
> Cheers,
>
> Jeff
>
I realized the original patch was broken for multithreaded use due to an
errant "static".
Also, I've cleaned up some carelessness in where I did the copy-and-paste
for parameter parsin
On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
> On Tue, 2013-03-26 at 02:50 +0900, Fujii Masao wrote:
> > Hi,
> >
> > I found that the regression test failed when I created the database
> > cluster with the checksum and set wal_level to archive. I think that
> > there are some bugs around ch
On Mon, Apr 1, 2013 at 10:03 AM, Robert Haas wrote:
> On Mon, Apr 1, 2013 at 9:28 AM, Merlin Moncure wrote:
>>> That is one of multiple issues. Contention on the BufFreelistLock is
>>> another one. I agree that usage_count maintenance is unlikely to become a
>>> bottleneck unless one or both of
I wrote:
> Perhaps what we should do is charge the hash_qual_cost only for some
> small multiple of the number of tuples that we expect will *pass* the
> hash quals, which is a number we have to compute anyway. The multiple
> would represent the rate of hash-code collisions we expect.
I tried the
On Mon, Apr 1, 2013 at 2:35 AM, Jeff Davis wrote:
> On Sun, 2013-03-31 at 15:45 -0400, Tom Lane wrote:
>> Really, when we're traipsing down a bucket
>> list, skipping over bucket entries with the wrong hash code is just
>> about free, or at least it's a whole lot cheaper than applying ExecQual.
>>
On Mon, Apr 1, 2013 at 9:28 AM, Merlin Moncure wrote:
>> That is one of multiple issues. Contention on the BufFreelistLock is
>> another one. I agree that usage_count maintenance is unlikely to become a
>> bottleneck unless one or both of those is fixed first (and maybe not even
>> then)
>
> usa
Chamila Wijayarathna writes:
> I'm new to postresql development. I cloned the project from git and tried
> to build it. When I tried to run it using gmake, it gave me an error saying
> '! is unexpected at this time gmake: *** [world] Error 255', Can somebody
> please tell me where I got it wrong.
Hello Everyone,
I'm new to postresql development. I cloned the project from git and tried
to build it. When I tried to run it using gmake, it gave me an error saying
'! is unexpected at this time gmake: *** [world] Error 255', Can somebody
please tell me where I got it wrong.
--
*Chamila Dilshan
On Mon, Apr 1, 2013 at 6:43 AM, Robert Haas wrote:
> On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, you could easily change array_ndims() to error out if ARR_NDIM()
>>> is negative or more than MAXDIM and return NULL only if it's exactly
>>> 0. That wouldn't b
On Sun, Mar 31, 2013 at 1:27 PM, Jeff Janes wrote:
> On Friday, March 22, 2013, Ants Aasma wrote:
>>
>> On Fri, Mar 22, 2013 at 10:22 PM, Merlin Moncure
>> wrote:
>> > well if you do a non-locking test first you could at least avoid some
>> > cases (and, if you get the answer wrong, so what?) by
On Thu, Mar 28, 2013 at 11:48 AM, Simon Riggs wrote:
> What we want to do is make recovery parameters into GUCs, allowing
> them to be reset by SIGHUP and also to allow all users to see the
> parameters in use, from any session.
>
> The existing mechanism for recovery is that
> 1. we put parameter
On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, you could easily change array_ndims() to error out if ARR_NDIM()
>> is negative or more than MAXDIM and return NULL only if it's exactly
>> 0. That wouldn't break backward compatibility because it would throw
>> an e
On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd wrote:
> On 27 March 2013 06:47, Robert Haas wrote:
>> On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd wrote:
>>> We can't sensibly test for whether an array is empty. I'd call that a
>>> functional problem.
>>
>> Sure you can. Equality comparisons w
On Monday, April 01, 2013 1:03 PM Greg Smith wrote:
> At this point SET PERSISTENT is looking complete enough that some parts
> of it might be committed. There's been a lot of useful progress in
> nailing down the early/obvious problems and what fundamental approach
> makes sense. Accepting the w
At this point SET PERSISTENT is looking complete enough that some parts
of it might be committed. There's been a lot of useful progress in
nailing down the early/obvious problems and what fundamental approach
makes sense. Accepting the whole thing still seems a bit too invasive
to chew on thi
49 matches
Mail list logo
