pgsql: Correctly align page's images in generic wal API
Correctly align page's images in generic wal API
Page image should be MAXALIGN'ed because existing code could directly align
pointers in page instead of align offset from beginning of page.
Found during play with indexes as extenstion, Alexander Korotkov and me
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/7c8345f67f3008a394adccae262f2a2162b6f5c7
Modified Files
--------------
src/backend/access/transam/generic_xlog.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Tue, May 17, 2016 at 6:01 AM, Teodor Sigaev <teodor@sigaev.ru> wrote:
Correctly align page's images in generic wal API
Page image should be MAXALIGN'ed because existing code could directly align
pointers in page instead of align offset from beginning of page.Found during play with indexes as extenstion, Alexander Korotkov and me
Instead of allocating this memory unconditionally for each buffer,
wouldn't it be better to set all the page pointers to NULL in
GenericXLogStart and allocate memory only once a buffer is registered
in GenericXLogRegisterBuffer when finding a free slot? This patch is
wasting many cycles.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Instead of allocating this memory unconditionally for each buffer,
wouldn't it be better to set all the page pointers to NULL in
GenericXLogStart and allocate memory only once a buffer is registered
in GenericXLogRegisterBuffer when finding a free slot? This patch is
wasting many cycles.
GenericXLogRegisterBuffer() could be called in another MemoryContext what
can be a reason for strange bugs. Right now only a few pages could be
involved in one round of GenericWal. I don't believe that such allocation
could be a reason of noticable performance degradation. Although I didn't
check that.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
Instead of allocating this memory unconditionally for each buffer,
wouldn't it be better to set all the page pointers to NULL in
GenericXLogStart and allocate memory only once a buffer is registered
in GenericXLogRegisterBuffer when finding a free slot? This patch is
wasting many cycles.
GenericXLogRegisterBuffer() could be called in another MemoryContext what
can be a reason for strange bugs. Right now only a few pages could be
involved in one round of GenericWal. I don't believe that such allocation
could be a reason of noticable performance degradation. Although I didn't
check that.
You could allocate all the pages in one palloc, though, and then just
set the pointers via address arithmetic.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers