Re: WAL logs and segment files
От | scott |
---|---|
Тема | Re: WAL logs and segment files |
Дата | |
Msg-id | 001b01c3f80f$2fcd7de0$9edfddd1@scott обсуждение исходный текст |
Ответ на | Re: WAL logs and segment files (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-admin |
Take me off your list! You have the wrong scott! ----- Original Message ----- From: "Bruce Momjian" <pgman@candle.pha.pa.us> To: "Eduardo Leva" <eeeggg499@netscape.net> Cc: <pgsql-admin@postgresql.org> Sent: Friday, February 20, 2004 12:29 PM Subject: Re: [ADMIN] WAL logs and segment files > Eduardo Leva wrote: > > Hi, guys... I'm reading the version 7.3.4 documentation and I found this: " > > > > "WAL logs are stored in the directory $PGDATA/pg_xlog, as a set of segment > > files, each 16 MB in size. Each segment is divided into 8 kB pages. The > > log record headers are described in access/xlog.h; record content is > > dependent on the type of event that is being logged. Segment files are > > given ever-increasing numbers as names, starting at 0000000000000000. The > > numbers do not wrap, at present, but it should take a very long time to > > exhaust the available stock of numbers. " > > > > in item 12.2 Implementation. The question is: How do I solve this > > situation, the remarked situation? The answer is not in the docs. Thanks. > > What situation do you need to solve? The wrapping? The documention > states "a very long time", but it more of a joke. That number would be > huge to wrap around and you would be updating your PostgreSQL version > long before it would ever wrap. > > The number is actually an int8 that has a maximum value of: > > 18446744073709551616 > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match
В списке pgsql-admin по дате отправления: