On 11/21/2014 05:58 AM, Amit Kapila wrote:
On Thu, Nov 20, 2014 at 10:36 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
As you may have noticed, I committed this (after some more cleanup). Of
course, feel free to still review it, and please point out any issues you
may find.
Few
On 11/21/2014 09:19 AM, Michael Paquier wrote:
On Fri, Nov 21, 2014 at 2:06 AM, Heikki Linnakangas
wrote:
As you may have noticed, I committed this (after some more cleanup). Of
course, feel free to still review it, and please point out any issues you
may find.
This comment on top of XLogR
On Fri, Nov 21, 2014 at 2:06 AM, Heikki Linnakangas wrote:
> As you may have noticed, I committed this (after some more cleanup). Of
> course, feel free to still review it, and please point out any issues you
> may find.
>
This comment on top of XLogRecordAssemble is not adapted as
page_writes_o
On Thu, Nov 20, 2014 at 10:36 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
>
> As you may have noticed, I committed this (after some more cleanup). Of
course, feel free to still review it, and please point out any issues you
may find.
>
Few minor observations:
1. Readme
void XLogReset
As you may have noticed, I committed this (after some more cleanup). Of
course, feel free to still review it, and please point out any issues
you may find.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
On 11/18/2014 10:28 AM, Michael Paquier wrote:
Btw, did you do a run with the buffer capture facility and checked for page
differences?
Yes. That's how I bumped into the bug fixed in c73669c0. That tool has
been tremendously helpful.
Except that, after going through the code once again, IST
On Tue, Nov 18, 2014 at 4:31 AM, Heikki Linnakangas
wrote:
> WAL insertion performance
> =
> To measure the performance of generating WAL, I ran the
> wal-update-testsuite.sh that Amit also ran earlier. The cluster was
> initialized with:
>
> shared_buffers=512MB
> checkpoi
On 11/17/2014 03:22 PM, Heikki Linnakangas wrote:
Here is an updated version of the patch. It's rebased over current
master, and fixes a bunch of issues you and Michael pointed out, and a
ton of other cleanup.
That patch had two extra, unrelated patches applied to it. One to use
the Intel CRC
On 11/14/2014 10:31 AM, Michael Paquier wrote:
5) Here why not using the 2nd block instead of the 3rd (@_bt_getroot)?
+ XLogBeginInsert();
+ XLogRegisterBuffer(0, rootbuf, REGBUF_WILL_INIT);
+ XLogRegisterBuffer(2, metabuf, REGBUF_
On Fri, Nov 14, 2014 at 5:31 PM, Michael Paquier
wrote:
> 3) pg_xlogdump does not seem to work:
> $ pg_xlogdump 0001000D
> pg_xlogdump: FATAL: could not find a valid record after 0/D00
This one is a bad manipulation from my side. Please forget this comment.
--
Michael
--
S
On Thu, Nov 13, 2014 at 10:33 PM, Heikki Linnakangas
wrote:
> In quick testing, this new WAL format is somewhat more compact than the 9.4
> format. That also seems to have more than bought back the performance
> regression I saw earlier. Here are results from my laptop, using the
> wal-update-test
On Thu, Nov 13, 2014 at 7:03 PM, Heikki Linnakangas
wrote:
>
> On 11/11/2014 04:42 PM, Amit Kapila wrote:
>>
>> I have done some performance testing of this patch using attached
>> script and data is as below:
>>
>> ...
>>
>> It seems to me that there is a regression of (4 ~ 8%) for small records,
On 2014-11-13 15:33:44 +0200, Heikki Linnakangas wrote:
> Here's a new version, with big changes again to the record format. Have a
> look at xlogrecord.h for the details, but in a nutshell:
>
> 1. The overall format is now: XLogRecord, per-block headers, header for main
> data portion, per-block
On Tue, Nov 11, 2014 at 2:15 PM, Heikki Linnakangas
wrote:z
>
> On 11/11/2014 09:39 AM, Michael Paquier wrote:
>>
>> On Tue, Nov 11, 2014 at 4:29 AM, Heikki Linnakangas <
hlinnakan...@vmware.com
>>>
>>> wrote:
>>
>>
>>> Attached is a new version. It's rebased on current git master, including
>>> B
On 11/11/2014 09:39 AM, Michael Paquier wrote:
On Tue, Nov 11, 2014 at 4:29 AM, Heikki Linnakangas
wrote:
Attached is a new version. It's rebased on current git master, including
BRIN. I've also fixed the laundry list of small things you reported, as
well as a bunch of bugs I uncovered during
On Tue, Nov 11, 2014 at 4:29 AM, Heikki Linnakangas wrote:
> Attached is a new version. It's rebased on current git master, including
> BRIN. I've also fixed the laundry list of small things you reported, as
> well as a bunch of bugs I uncovered during my own testing.
This patch needs a small re
Attached is a new version. It's rebased on current git master, including
BRIN. I've also fixed the laundry list of small things you reported, as
well as a bunch of bugs I uncovered during my own testing.
Alvaro: you still have the BRIN WAL-logging code fresh in your memory,
so could you take a
On 2014-11-06 17:32:33 +0200, Heikki Linnakangas wrote:
> Replying to some of your comments below. The rest were trivial issues that
> I'll just fix.
>
> On 10/30/2014 09:19 PM, Andres Freund wrote:
> >* Is it really a good idea to separate XLogRegisterBufData() from
> > XLogRegisterBuffer() the
Replying to some of your comments below. The rest were trivial issues
that I'll just fix.
On 10/30/2014 09:19 PM, Andres Freund wrote:
* Is it really a good idea to separate XLogRegisterBufData() from
XLogRegisterBuffer() the way you've done it ? If we ever actually get
a record with a la
On 11/05/2014 11:30 AM, Andres Freund wrote:
On 2014-11-04 18:33:34 +0200, Heikki Linnakangas wrote:
On 10/30/2014 06:02 PM, Andres Freund wrote:
On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
On 10/06/2014 02:29 PM, Andres Freund wrote:
I've not yet really looked,
but on a quick rea
On 11/06/2014 07:57 AM, Amit Kapila wrote:
On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas
wrote:
On 11/05/2014 09:06 AM, Amit Kapila wrote:
2.
XLogRecPtr
XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn)
So the scenario is that:
* XLogRecordAssemble decides that a page doesn't n
On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas
wrote:
> On 11/05/2014 09:06 AM, Amit Kapila wrote:
>>
>> 2.
>> XLogRecPtr
>> XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn)
>
> So the scenario is that:
>
> * XLogRecordAssemble decides that a page doesn't need to be backed up
> * both
On 2014-11-05 23:08:31 +0200, Heikki Linnakangas wrote:
> On 10/30/2014 09:19 PM, Andres Freund wrote:
> >Some things I noticed while reading the patch:
>
> A lot of good comments, but let me pick up just two that are related:
>
> >* There's a couple record types (e.g. XLOG_SMGR_TRUNCATE) that on
On 10/30/2014 09:19 PM, Andres Freund wrote:
Some things I noticed while reading the patch:
A lot of good comments, but let me pick up just two that are related:
* There's a couple record types (e.g. XLOG_SMGR_TRUNCATE) that only
refer to the relation, but not to the block number. These st
On 2014-11-04 18:33:34 +0200, Heikki Linnakangas wrote:
> On 10/30/2014 06:02 PM, Andres Freund wrote:
> >On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
> >>On 10/06/2014 02:29 PM, Andres Freund wrote:
> >>>I've not yet really looked,
> >>>but on a quick readthrough XLogInsertRecData() sta
On 11/05/2014 09:06 AM, Amit Kapila wrote:
1.
+XLogRecPtr
+XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)
{
..
+ /* info's high bits are reserved for use by me */
+ if (info & XLR_INFO_MASK)
+ elog(PANIC, "invalid xlog info mask %02X", info);
..
}
Earlier before this check, we use to ch
On Tue, Nov 4, 2014 at 10:03 PM, Heikki Linnakangas
wrote:
>
> On 10/30/2014 06:02 PM, Andres Freund wrote:
>>
>> On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
>>>
>>> On 10/06/2014 02:29 PM, Andres Freund wrote:
On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
>
>>>
On Fri, Oct 31, 2014 at 2:52 AM, Heikki Linnakangas wrote:
> On 10/30/2014 06:02 PM, Andres Freund wrote:
>
>> On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
>>
>>> On 10/06/2014 02:29 PM, Andres Freund wrote:
>>>
I've not yet really looked,
but on a quick readthrough XLogInser
Hi,
On 2014-09-15 15:41:22 +0300, Heikki Linnakangas wrote:
> The second patch contains the interesting changes.
Heikki's pushed the newest version of this to the git tree.
Some things I noticed while reading the patch:
* potential mismerge:
+++ b/src/bin/pg_basebackup/pg_receivexlog.c
@@ -408,7
On 10/30/2014 06:02 PM, Andres Freund wrote:
On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
On 10/06/2014 02:29 PM, Andres Freund wrote:
I've not yet really looked,
but on a quick readthrough XLogInsertRecData() staying in xlog.c doesn't
make me happy...
Ok.. Can you elaborate?
To
On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
> On 10/06/2014 02:29 PM, Andres Freund wrote:
> >On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
> >>Barring objections, I'll commit this, and then continue benchmarking the
> >>second patch with the WAL format and API changes.
> >
>
On Mon, Oct 6, 2014 at 8:19 PM, Heikki Linnakangas
wrote:
> On 10/06/2014 04:42 AM, Michael Paquier wrote:
>
>> On Fri, Oct 3, 2014 at 9:51 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com>
>> wrote:
>>
>>> So I now have a refactoring patch ready that I'd like to commit (the
>>>
>> attached tw
On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
> On 10/06/2014 04:42 AM, Michael Paquier wrote:
> >On Fri, Oct 3, 2014 at 9:51 PM, Heikki Linnakangas
> >wrote:
> >>So I now have a refactoring patch ready that I'd like to commit (the
> >attached two patches together), but to be honest, I h
On Fri, Oct 3, 2014 at 9:51 PM, Heikki Linnakangas
wrote:
> So I now have a refactoring patch ready that I'd like to commit (the
attached two patches together), but to be honest, I have no idea why the
second patch is so essential to performance.
Thanks. I did some more tests with master, master+p
On 10/03/2014 04:10 PM, Andres Freund wrote:
On 2014-10-03 15:51:37 +0300, Heikki Linnakangas wrote:
After a lot of experimentation, I figured out that the slowdown is already
apparent with the *first* patch, the one that just refactors existing
XLogInsert, without any changes to the WAL format
On 2014-10-03 15:51:37 +0300, Heikki Linnakangas wrote:
> After a lot of experimentation, I figured out that the slowdown is already
> apparent with the *first* patch, the one that just refactors existing
> XLogInsert, without any changes to the WAL format or to the callers. I
> fiddled with that f
On Mon, Sep 15, 2014 at 9:16 PM, Michael Paquier
wrote:
> 2) XLogCheckBufferNeedsBackup is not used. It can be removed.
Please ignore this comment, XLogCheckBufferNeedsBackup is used in heapam.c.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 2014-09-15 15:41:22 +0300, Heikki Linnakangas wrote:
> Here we go. I've split this again into two patches. The first patch is just
> refactoring the current code. It moves XLogInsert into a new file,
> xloginsert.c, and the definition of XLogRecord to new xlogrecord.h header
> file. As a result,
On Mon, Sep 15, 2014 at 8:00 PM, Michael Paquier
wrote:
> Alvaro got faster than me... I was just looking at the first patch and
> +1 on those comments. It is worth noting that the first patch, as it
> does only a large refactoring, does not impact performance or size of
> WAL records.
Some comme
On Mon, Sep 15, 2014 at 7:03 PM, Alvaro Herrera
wrote:
> Heikki Linnakangas wrote:
>
>> Here we go. I've split this again into two patches. The first patch
>> is just refactoring the current code. It moves XLogInsert into a new
>> file, xloginsert.c, and the definition of XLogRecord to new
>> xlog
Heikki Linnakangas wrote:
> Here we go. I've split this again into two patches. The first patch
> is just refactoring the current code. It moves XLogInsert into a new
> file, xloginsert.c, and the definition of XLogRecord to new
> xlogrecord.h header file. As a result, there is a a lot of churn in
On Tue, Sep 2, 2014 at 9:23 PM, Heikki Linnakangas
wrote:
> I committed the redo-routine refactoring patch. I kept the XLog prefix in
> the XLogReadBufferForRedo name; it's redundant, but all the other similar
> functions in xlogutils.c use the XLog prefix so it would seem inconsistent
> to not ha
On Tue, Sep 2, 2014 at 9:23 PM, Heikki Linnakangas
wrote:
> I committed the redo-routine refactoring patch. I kept the XLog prefix in
> the XLogReadBufferForRedo name; it's redundant, but all the other similar
> functions in xlogutils.c use the XLog prefix so it would seem inconsistent
> to not ha
On 08/19/2014 05:38 PM, Andres Freund wrote:
On 2014-08-19 10:33:29 -0400, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Barring objections or better ideas, I'm leaning towards
XLogReadBufferForRedo.
WFM
for me too. Although we could imo strip the 'XLog' in the beginning if
we want to ma
On 2014-08-19 10:33:29 -0400, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
> > Barring objections or better ideas, I'm leaning towards
> > XLogReadBufferForRedo.
>
> WFM
for me too. Although we could imo strip the 'XLog' in the beginning if
we want to make it shorter. The ForRedo is sayin
Heikki Linnakangas wrote:
> Barring objections or better ideas, I'm leaning towards
> XLogReadBufferForRedo.
WFM
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On 08/19/2014 11:07 AM, Michael Paquier wrote:
Patch 1 looks good. The main difference with the v1 submitted a couple of
days back is that the global variable approach is replaced with additional
arguments for the LSN position and record pointer in XLogReplayBuffer. I
have as well run a couple of
On Mon, Aug 18, 2014 at 10:55 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> All rightey.
>
> Here's the next version of this work. It now comes as two patches. The
first
> one refactors adds the XLogReplayBuffer() function and refactors all the
> redo functions to use it. It doesn't ch
On 2014-08-14 12:41:35 +0300, Heikki Linnakangas wrote:
> On 08/14/2014 10:29 AM, Michael Paquier wrote:
> >On Thu, Aug 14, 2014 at 3:04 AM, Alvaro Herrera
> > wrote:
> >>Heikki Linnakangas wrote:
> >>What's with XLogReplayLSN and XLogReplayRecord? IMO the xlog code has
> >>more than enough global
On 08/14/2014 11:22 AM, Michael Paquier wrote:
1) Why changing that from ERROR to PANIC?
/* Caller specified a bogus block_index */
- elog(ERROR, "failed to restore block_index %d", block_index);
+ elog(PANIC, "failed to restore block_index %d", block_index);
No reason, jus
On 08/14/2014 10:29 AM, Michael Paquier wrote:
On Thu, Aug 14, 2014 at 3:04 AM, Alvaro Herrera
wrote:
Heikki Linnakangas wrote:
What's with XLogReplayLSN and XLogReplayRecord? IMO the xlog code has
more than enough global variables already, it'd be good to avoid two
more if possible. Is there
On Thu, Aug 14, 2014 at 2:05 AM, Heikki Linnakangas
wrote:
> Here's a full version of this refactoring patch, all the rmgr's have now
> been updated to use XLogReplayBuffer(). I think this is a worthwhile change
> on its own, even if we drop the ball on the rest of the WAL format patch,
> because
On Thu, Aug 14, 2014 at 3:04 AM, Alvaro Herrera
wrote:
> Heikki Linnakangas wrote:
> What's with XLogReplayLSN and XLogReplayRecord? IMO the xlog code has
> more than enough global variables already, it'd be good to avoid two
> more if possible. Is there no other good way to get this info down t
Heikki Linnakangas wrote:
> Here's a full version of this refactoring patch, all the rmgr's have
> now been updated to use XLogReplayBuffer(). I think this is a
> worthwhile change on its own, even if we drop the ball on the rest
> of the WAL format patch, because it makes the redo-routines more
>
Heikki Linnakangas wrote:
> Here's a full version of this refactoring patch, all the rmgr's have
> now been updated to use XLogReplayBuffer(). I think this is a
> worthwhile change on its own, even if we drop the ball on the rest
> of the WAL format patch, because it makes the redo-routines more
>
On 08/13/2014 04:15 PM, Heikki Linnakangas wrote:
Hmm, thinking about this some more, there is one sensible way to split
this patch: We can add the XLogReplayBuffer() function and rewrite all
the redo routines to use it, without changing any WAL record formats or
anything in the way the WAL recor
On 08/13/2014 02:07 PM, Andres Freund wrote:
On 2014-08-13 02:36:59 +0300, Heikki Linnakangas wrote:
On 08/13/2014 01:04 AM, Andres Freund wrote:
* The patch mixes the API changes around WAL records with changes of how
individual actions are logged. That makes it rather hard to review -
a
On 2014-08-13 02:36:59 +0300, Heikki Linnakangas wrote:
> On 08/13/2014 01:04 AM, Andres Freund wrote:
> >* I'm distinctly not a fan of passing around both the LSN and the struct
> > XLogRecord to functions. We should bit the bullet and use something
> > encapsulating both.
>
> You mean, the r
On Wed, Aug 13, 2014 at 4:49 PM, Michael Paquier
wrote:
> Yes indeed. As XLogBeginInsert() is already part of xlogconstruct.c,
> it is not weird. This approach has the merit to make XLogRecData
> completely bundled with the insertion and construction of the WAL
> records. Then for the name xlogins
On Tue, Aug 12, 2014 at 6:44 PM, Heikki Linnakangas
wrote:
> On 08/05/2014 03:50 PM, Michael Paquier wrote:
>>
>> - When testing pg_xlogdump I found an assertion failure for record
>> XLOG_GIN_INSERT:
>> Assertion failed: (((bool) (((const void*)(&insertData->newitem.key) !=
>> ((void*)0)) && ((&i
On 08/13/2014 01:04 AM, Andres Freund wrote:
On 2014-08-12 12:44:22 +0300, Heikki Linnakangas wrote:
Here's a new patch with those little things fixed.
I've so far ignored this thread... I'm now taking a look. Unfortunately
I have to admit I'm not unequivocally happy.
* XLogRegisterData/XLogR
On 2014-08-12 12:44:22 +0300, Heikki Linnakangas wrote:
> Here's a new patch with those little things fixed.
I've so far ignored this thread... I'm now taking a look. Unfortunately
I have to admit I'm not unequivocally happy.
* XLogRegisterData/XLogRegisterRecData imo don't really form a
consis
Heikki Linnakangas wrote:
> On 08/05/2014 03:50 PM, Michael Paquier wrote:
> >- XLogRecGetBlockRefIds needing an already-allocated array for *out is not
> >user-friendly. Cannot we just do all the work inside this function?
>
> I agree it's not a nice API. Returning a palloc'd array would be
> ni
Heikki Linnakangas wrote:
> On 08/05/2014 03:50 PM, Michael Paquier wrote:
> >- All the functions in xlogconstruct.c could be defined in a separate
> >header xlogconstruct.h. What they do is rather independent from xlog.h. The
> >same applies to all the structures and functions of xlogconstruct.c
On 08/05/2014 03:50 PM, Michael Paquier wrote:
- When testing pg_xlogdump I found an assertion failure for record
XLOG_GIN_INSERT:
Assertion failed: (((bool) (((const void*)(&insertData->newitem.key) !=
((void*)0)) && ((&insertData->newitem.key)->ip_posid != 0, function
gin_desc, file gindesc
On Sat, Aug 2, 2014 at 1:40 AM, Heikki Linnakangas
wrote:
> I ran this through my WAL page comparison tool to verify that all the WAL
> record types are replayed correctly (although I did some small cleanup
after
> that, so it's not impossible that I broke it again; will re-test before
> committin
Here's a new version of this patch, please review.
I've cleaned up a lot of stuff, fixed all the bugs reported so far, and
a bunch of others I found myself while testing.
I'm not going to explain again what the patch does; the README and
comments should now be complete enough to explain how i
On Wed, Jul 2, 2014 at 4:23 PM, Michael Paquier
wrote:
>
>
>
> On Wed, Jul 2, 2014 at 4:09 PM, Michael Paquier
> wrote:
>>
>> 3) I noticed a bug in gin redo code path when trying to use the WAL replay
>> facility.
This patch has been on status "Waiting on author" for a little bit of
time, marking
On Wed, Jul 2, 2014 at 4:09 PM, Michael Paquier
wrote:
>
> 3) I noticed a bug in gin redo code path when trying to use the WAL replay
> facility.
>
Looking at the backtrace, it seems that a page for gin is corrupted. The
buffer capture patch does some sanity checks on the page format when
perform
On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas
wrote:
> On 06/27/2014 09:12 AM, Michael Paquier wrote:
>
>> 2) Description of XLogBeginInsert, XLogHasBlockRef, XLogGetBlockRef and
>> XLogGetBlockRefIds are missing in src/backend/access/transam/README.
>>
>
> Added descriptions of XLogBeginIns
On Tue, Jul 1, 2014 at 7:18 AM, Fujii Masao wrote:
> On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas
> wrote:
> > Thanks for the review!
> >
> >
> > On 06/27/2014 09:12 AM, Michael Paquier wrote:
> >>
> >> Looking at this patch, it does not compile when assertions are enabled
> >> because of
On Mon, Jun 30, 2014 at 4:51 PM, Heikki Linnakangas
wrote:
> Another big change in the attached patch version is that XLogRegisterData()
> now *copies* the data to a working area, instead of merely adding a
> XLogRecData entry to the chain. This simplifies things in xlog.c, now that
> the XLogRecD
On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas
wrote:
> Thanks for the review!
>
>
> On 06/27/2014 09:12 AM, Michael Paquier wrote:
>>
>> Looking at this patch, it does not compile when assertions are enabled
>> because of this assertion in heapam.c:
>> Assert(recdata == data + datalen);
>> It
On Sun, Jun 15, 2014 at 6:11 AM, Heikki Linnakangas wrote:
> On 06/14/2014 09:43 PM, Alvaro Herrera wrote:
>
>> Heikki Linnakangas wrote:
>>
>> Here's a new version, rebased against master. No other changes.
>>>
>>
>> This is missing xlogrecord.h ...
>>
>
> Oops, here you are.
>
Looking at this
Heikki Linnakangas wrote:
> Here's a new version, rebased against master. No other changes.
This is missing xlogrecord.h ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Thu, Apr 3, 2014 at 7:44 PM, Heikki Linnakangas
wrote:
> I'd like to do some changes to the WAL format in 9.5. I want to annotate
> each WAL record with the blocks that they modify. Every WAL record already
> includes that information, but it's done in an ad hoc way, differently in
> every rmgr
On 04/04/2014 04:56 PM, Tom Lane wrote:
Heikki Linnakangas writes:
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer, because it's known to viol
Heikki Linnakangas writes:
> Ok, I fixed the issues that the assertion fixed. I also committed a
> patch to add the assertion itself; let's see if the buildfarm finds more
> cases that violate the rule.
> It ignores the checkpointer, because it's known to violate the rule,
... uh, isn't that a
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer, because it's known to violate the rule, and
allocations in ErrorContext, which is used during e
On 2014-04-04 12:50:25 +0300, Heikki Linnakangas wrote:
> On 04/04/2014 11:41 AM, Andres Freund wrote:
> >On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
> >>@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page)
> >>((PageHeader) page)->pd_upper = pd_special;
> >>}
> >>
On 04/04/2014 11:41 AM, Andres Freund wrote:
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page)
((PageHeader) page)->pd_upper = pd_special;
}
else
- {
Hi,
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
> But if we give the checkpointer process a free pass, running the regression
> tests with an assertion in AllocSetAlloc catches five genuine bugs:
>
> 1. _bt_newroot
> 2. XLogFileInit
> 3. spgPageIndexMultiDelete
> 4. PageRepairFragment
On 04/04/2014 02:40 AM, Andres Freund wrote:
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
A somewhat more relevant concern is where are we going to keep the state
data involved in all this. Since this code is, by definition
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> >> A somewhat more relevant concern is where are we going to keep the state
> >> data involved in all this. Since this code is, by definition, going to be
> >> called in criti
Andres Freund writes:
> On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
>> A somewhat more relevant concern is where are we going to keep the state
>> data involved in all this. Since this code is, by definition, going to be
>> called in critical sections, any solution involving internal pallocs is
On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
> > wrote:
> >> (Instead of using a new XLogRegisterBuffer() function to register the
> >> buffers, perhaps they should be passed to XLogInsert as a separate list or
> >> ar
Robert Haas writes:
> On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
> wrote:
>> (Instead of using a new XLogRegisterBuffer() function to register the
>> buffers, perhaps they should be passed to XLogInsert as a separate list or
>> array. I'm not wedded on the details...)
> That would have
On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
wrote:
> (Instead of using a new XLogRegisterBuffer() function to register the
> buffers, perhaps they should be passed to XLogInsert as a separate list or
> array. I'm not wedded on the details...)
That would have the advantage of avoiding the
On 04/03/2014 07:11 PM, Tom Lane wrote:
More generally, I'm pretty sure that your proposal is already going to
involve some small growth of WAL records compared to today,
Quite possible.
but I think
that's probably all right; the benefits seem significant.
Yep.
OTOH, once we store the rel
Heikki Linnakangas writes:
> On 04/03/2014 06:37 PM, Tom Lane wrote:
>> +1, but one important step here is finding the data to be replayed.
>> That is, a large part of the complexity of replay routines has to do
>> with figuring out which parts of the WAL record were elided due to
>> full-page-ima
On 04/03/2014 06:37 PM, Tom Lane wrote:
Also, IIRC there are places that WAL-log full pages that aren't in a
shared buffer at all (btree build does this I think). How will that fit
into this model?
Hmm. We could provide a function for registering a block with given
content, without a Buffer.
Heikki Linnakangas writes:
> The big change in creating WAL records is that the buffers involved in
> the WAL-logged operation are explicitly registered, by calling a new
> XLogRegisterBuffer function.
Seems reasonable, especially if we can make the buffer numbering business
less error-prone.
92 matches
Mail list logo
