On 11/21/2014 09:19 AM, Michael Paquier wrote:
On Fri, Nov 21, 2014 at 2:06 AM, 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.
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
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:
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
On Fri, Nov 21, 2014 at 2:06 AM, 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.
This comment on top of XLogRecordAssemble is not
On Tue, Nov 18, 2014 at 4:31 AM, Heikki Linnakangas hlinnakan...@vmware.com
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:
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,
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,
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 Fri, Nov 14, 2014 at 5:31 PM, Michael Paquier
michael.paqu...@gmail.com 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
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 Thu, Nov 13, 2014 at 7:03 PM, Heikki Linnakangas hlinnakan...@vmware.com
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
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
BRIN. I've also fixed the laundry list of small things you reported, as
well as a bunch
On Tue, Nov 11, 2014 at 2:15 PM, Heikki Linnakangas hlinnakan...@vmware.com
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
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
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
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
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 way
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
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
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() staying in
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
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 only
On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas hlinnakan...@vmware.com
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
On Tue, Nov 4, 2014 at 10:03 PM, Heikki Linnakangas hlinnakan...@vmware.com
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 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.
I'd like to
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
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 Fri, Oct 31, 2014 at 2:52 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
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 hlinnakan...@vmware.com
wrote:
So I now have a refactoring patch ready that I'd like to commit (the
attached two patches together), but to
On Mon, Oct 6, 2014 at 8:19 PM, Heikki Linnakangas hlinnakan...@vmware.com
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
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 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
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 for
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-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 9:16 PM, Michael Paquier
michael.paqu...@gmail.com 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
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 Mon, Sep 15, 2014 at 7:03 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Mon, Sep 15, 2014 at 8:00 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Tue, Sep 2, 2014 at 9:23 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Tue, Sep 2, 2014 at 9:23 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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
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 change
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
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
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 saying that
On Thu, Aug 14, 2014 at 3:04 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Thu, Aug 14, 2014 at 2:05 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On 08/14/2014 10:29 AM, Michael Paquier wrote:
On Thu, Aug 14, 2014 at 3:04 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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, just a
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
alvhe...@2ndquadrant.com wrote:
Heikki Linnakangas wrote:
What's with XLogReplayLSN and XLogReplayRecord? IMO the xlog code has
more than
On Tue, Aug 12, 2014 at 6:44 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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) !=
On Wed, Aug 13, 2014 at 4:49 PM, Michael Paquier
michael.paqu...@gmail.com 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.
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 redo
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 -
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
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/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.c,
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 in
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
nicer,
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
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.
*
On Sat, Aug 2, 2014 at 1:40 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
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
On Wed, Jul 2, 2014 at 4:23 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jul 2, 2014 at 4:09 PM, Michael Paquier michael.paqu...@gmail.com
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
On Tue, Jul 1, 2014 at 7:18 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
On Wed, Jul 2, 2014 at 4:09 PM, Michael Paquier michael.paqu...@gmail.com
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
On Mon, Jun 30, 2014 at 4:51 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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,
On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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 +
On Sun, Jun 15, 2014 at 6:11 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
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
On Thu, Apr 3, 2014 at 7:44 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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,
On 04/04/2014 02:40 AM, Andres Freund wrote:
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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. PageRepairFragmentation
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
- {
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;
}
else
- {
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
Heikki Linnakangas hlinnakan...@vmware.com 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,
On 04/04/2014 04:56 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com 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,
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. The RelFileNode and block number are
currently part of the
Heikki Linnakangas hlinnakan...@vmware.com 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
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 hlinnakan...@vmware.com 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
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
On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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 2014-04-03 19:08:27 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 3, 2014 at 10:14 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
(Instead of using a new XLogRegisterBuffer() function to register the
buffers, perhaps they should be passed to
Andres Freund and...@2ndquadrant.com 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
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
90 matches
Mail list logo
