On Mon, Jun 17, 2013 at 1:22 PM, Soroosh Sardari
wrote:
> Hey
>
> I was reading the multi transaction log manager, multixact.c.
> I didn't get what SLRU does.
>
> I want the goal of this module, and why we use it.
> I'm kind of newbie, be patient with me ;)
>
>
Did you look at src/backend/access/
Hey
I was reading the multi transaction log manager, multixact.c.
I didn't get what SLRU does.
I want the goal of this module, and why we use it.
I'm kind of newbie, be patient with me ;)
Regards
Soroosh
Bruce Momjian wrote:
> Is this a TODO?
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> If we don't want to change it wholesale, one option would be to
>>> support different lengths of filenames in slru.c for different
>>> slrus. At a quick glance, it seems pretty easy. That would allow
Is this a TODO?
---
Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 09.06.2011 15:50, Robert Haas wrote:
> >> And I would guess that there's a lot more interest in raising BLCKSZ
> >> than lowering it. It might not be
On 09.06.2011 19:24, Tom Lane wrote:
(BTW, while I've not looked at the SLRU code in several years, I'm quite
unconvinced that this is only a matter of filename lengths.)
I don't see anything but the filename length needing adjustment. In
fact, when I hacked predicate.c to ignore the issue and
Heikki Linnakangas writes:
> On 09.06.2011 15:50, Robert Haas wrote:
>> And I would guess that there's a lot more interest in raising BLCKSZ
>> than lowering it. It might not be a bad idea to adopt the fix you
>> propose anyway, but it doesn't seem urgent.
> I guess we could fix pg_subtrans by n
On 09.06.2011 15:50, Robert Haas wrote:
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
wrote:
While reviewing the SLRU code in predicate.c again, I remembered this old
thread:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
SLRU has a limit of 64k segment files, because
Heikki Linnakangas writes:
> It's awfully late in the release cycle, but how about we add another
> digit to the filenames used by SLRU, to up the limit?
It's way too late for that kind of thing, unless you are saying that SSI
in and of itself is going to cause a release slip. (Which I'm gettin
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
wrote:
> While reviewing the SLRU code in predicate.c again, I remembered this old
> thread:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
>
> SLRU has a limit of 64k segment files, because the files are named using
> four
While reviewing the SLRU code in predicate.c again, I remembered this
old thread:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
SLRU has a limit of 64k segment files, because the files are named using
four hex digits like "00CE". Kevin's math shows that that's just enough
Excerpts from Kevin Grittner's message of mié dic 29 20:46:55 -0300 2010:
> Attached is a small patch to avoid putting an opaque structure into
> the slru.h file and using it in an external function call where
> external callers must always specify NULL.
Thanks, committed.
--
Álvaro Herrera
The
Attached is a small patch to avoid putting an opaque structure into
the slru.h file and using it in an external function call where
external callers must always specify NULL.
-Kevin
*** a/src/backend/access/transam/clog.c
--- b/src/backend/access/transam/clog.c
***
*** 445,451
Is there an overview of SLRU anywhere? I've looked over the code
enough to know that it'll save me a day or two if I can get an
overview of correct usage, rather than to reverse engineer it from
source code. There is no README with useful information, and
searches of the Wiki and the docs have co
13 matches
Mail list logo
