From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [COMMITTERS] pgsql: Properly access a buffer's LSN using existing access macros |
Date: | 2008-10-20 22:54:04 |
Message-ID: | 5757.1224543244@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Hmm, I just noticed this comment in bufpage.h (which was also in Jonah's
> patch) :-(
> typedef struct PageHeaderData
> {
> /* XXX LSN is member of *any* block, not only page-organized ones */
> ...
We don't have any non-page-organized blocks ;-)
Seriously, if the issue ever became significant I'd expect that we'd add
a buffer flag to tell whether the buffer had a LSN or not, and set this
appropriately at buffer readin time depending on where we got the page
from. That would then cue the write logic to know what to do. (In
particular, I suppose we'd need to do this if we try to migrate clog and
friends into the main buffer arena.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Drake | 2008-10-21 06:33:33 | varint - varint: create cast to get typmod working. |
Previous Message | Jonah H. Harris | 2008-10-20 21:49:15 | Re: Re: [COMMITTERS] pgsql: Properly access a buffer's LSN using existing access macros |
From | Date | Subject | |
---|---|---|---|
Next Message | John DeSoi | 2008-10-21 00:18:40 | Re: Lisp as a procedural language? |
Previous Message | Tom Lane | 2008-10-20 22:45:31 | Re: [HACKERS] Hot Standby utility and administrator functions |