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
On Mon, Jun 17, 2013 at 1:22 PM, Soroosh Sardari
soroosh.sard...@gmail.comwrote:
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
Is this a TODO?
---
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Bruce Momjian br...@momjian.us wrote:
Is this a TODO?
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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,
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
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 09.06.2011 15:50, Robert Haas wrote:
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
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
13 matches
Mail list logo