On 03/31/2015 09:09 PM, Jeff Janes wrote:
On Tue, Mar 31, 2015 at 6:19 AM, Heikki Linnakangas wrote:
On 03/30/2015 09:01 PM, Jeff Janes wrote:
commit 2c03216d831160bedd72d45f7 has invalidated the part of the docs
saying "If no WAL has been written since the previous checkpoint, new
checkpoin
On 03/30/2015 09:01 PM, Jeff Janes wrote:
commit 2c03216d831160bedd72d45f7 has invalidated the part of the docs
saying "If no WAL has been written since the previous checkpoint, new
checkpoints will be skipped even if checkpoint_timeout has passed",
presumably by accident.
It seems that this par
commit 2c03216d831160bedd72d45f7 has invalidated the part of the docs
saying "If no WAL has been written since the previous checkpoint, new
checkpoints will be skipped even if checkpoint_timeout has passed",
presumably by accident.
It seems that this part is no longer true when it should be true:
On Thu, Jun 14, 2012 at 10:01 PM, Heikki Linnakangas
wrote:
> This has the advantage that you can calculate the CRC for all the other
> fields before acquiring WALInsertLock. For xl_prev, you need to know where
> exactly the record is inserted, so it's handy that it's the last field
> before CRC.
On fre, 2012-06-15 at 00:01 +0300, Heikki Linnakangas wrote:
> 1. Use a 64-bit segment number, instead of the log/seg combination. And
> don't waste the last segment on each logical 4 GB log file. The concept
> of a "logical log file" is now completely gone. XLogRecPtr is unchanged,
> but it sho
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Heikki Linnakangas writes:
>> So I think we should change pg_resetxlog -l option to take a WAL file
>> name as argument, and fix pg_upgrade accordingly.
> Seems reasonable I guess. It's
Heikki Linnakangas writes:
> So I think we should change pg_resetxlog -l option to take a WAL file
> name as argument, and fix pg_upgrade accordingly.
Seems reasonable I guess. It's really specifying a starting WAL
location, but only to file granularity, so treating the argument as a
file name
Excerpts from Heikki Linnakangas's message of lun jun 25 20:09:34 -0400 2012:
> On 25.06.2012 21:01, Robert Haas wrote:
> > On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masao wrote:
> >>> "<<" should be">>". The attached patch fixes this typo.
> >>
> >> Oh, I forgot to attach the patch.. Here is the pa
On 25.06.2012 21:01, Robert Haas wrote:
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masao wrote:
"<<" should be">>". The attached patch fixes this typo.
Oh, I forgot to attach the patch.. Here is the patch.
I committed both of the patches you posted to this thread.
Thanks Robert. I was thinkin
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masao wrote:
>> "<<" should be ">>". The attached patch fixes this typo.
>
> Oh, I forgot to attach the patch.. Here is the patch.
I committed both of the patches you posted to this thread.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enter
On Tue, Jun 26, 2012 at 2:53 AM, Fujii Masao wrote:
> On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
> wrote:
>> Ok, committed all the WAL format changes now.
>
> I found the typo.
>
> In walsender.c
> - reply.write.xlogid, reply.write.xrecoff,
> - reply.flush.x
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
wrote:
> Ok, committed all the WAL format changes now.
I found the typo.
In walsender.c
-reply.write.xlogid, reply.write.xrecoff,
-reply.flush.xlogid, reply.flush.xrecoff,
-reply.apply.xlogid, rep
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
wrote:
> Ok, committed all the WAL format changes now.
This breaks pg_resetxlog -l at all. When I ran "pg_resetxlog -l 0x01,0x01,0x01"
in the HEAD, I got the following error message though the same command
successfully completed in 9.1.
pg_
On 24 June 2012 17:24, Heikki Linnakangas
wrote:
> Ok, committed all the WAL format changes now.
Nice!
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Ok, committed all the WAL format changes now.
On 19.06.2012 18:57, Robert Haas wrote:
Should we keep the old representation in the replication protocol messages?
That would make it simpler to write a client that works with different
server versions (like pg_receivexlog). Or, while we're at it, p
On 20.06.2012 20:43, Fujii Masao wrote:
On Wed, Jun 20, 2012 at 8:19 PM, Magnus Hagander wrote:
On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas wrote:
On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
wrote:
Well, that was easier than I thought. Attached is a patch to make XLogRecPtr
a uint
On Wed, Jun 20, 2012 at 8:19 PM, Magnus Hagander wrote:
> On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas wrote:
>> On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
>> wrote:
>>> Well, that was easier than I thought. Attached is a patch to make XLogRecPtr
>>> a uint64, on top of my other WAL for
On Tue, Jun 19, 2012 at 5:57 PM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
> wrote:
>> Well, that was easier than I thought. Attached is a patch to make XLogRecPtr
>> a uint64, on top of my other WAL format patches. I think we should go ahead
>> with this.
>
> +1.
>
Hi,
On Wednesday, June 20, 2012 12:24:54 AM Heikki Linnakangas wrote:
> On 19.06.2012 18:46, Andres Freund wrote:
> > On Tuesday, June 19, 2012 10:14:08 AM Heikki Linnakangas wrote:
> >> Well, that was easier than I thought. Attached is a patch to make
> >> XLogRecPtr a uint64, on top of my other
On 19.06.2012 18:46, Andres Freund wrote:
On Tuesday, June 19, 2012 10:14:08 AM Heikki Linnakangas wrote:
Well, that was easier than I thought. Attached is a patch to make
XLogRecPtr a uint64, on top of my other WAL format patches. I think we
should go ahead with this.
Cool. You plan to merge X
On Tue, Jun 19, 2012 at 4:14 AM, Heikki Linnakangas
wrote:
> Well, that was easier than I thought. Attached is a patch to make XLogRecPtr
> a uint64, on top of my other WAL format patches. I think we should go ahead
> with this.
+1.
> The LSNs on pages are still stored in the old format, to avoi
On Tuesday, June 19, 2012 10:14:08 AM Heikki Linnakangas wrote:
> On 18.06.2012 21:08, Heikki Linnakangas wrote:
> > On 18.06.2012 21:00, Robert Haas wrote:
> >> On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund
> >>
> >> wrote:
> 1. Use a 64-bit segment number, instead of the log/seg combinatio
On Monday, June 18, 2012 09:19:48 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:45, Andres Freund wrote:
> > On Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote:
> >> On 18.06.2012 21:13, Andres Freund wrote:
> >>> On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> Th
On 18.06.2012 21:45, Andres Freund wrote:
On Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote:
On 18.06.2012 21:13, Andres Freund wrote:
On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
The page header contains an XLogRecPtr (LSN), so if we change it we'll
have to deal
On Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:13, Andres Freund wrote:
> > On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> >> The page header contains an XLogRecPtr (LSN), so if we change it we'll
> >> have to deal with pg_upgrade. I guess we cou
On 18.06.2012 21:13, Andres Freund wrote:
On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
The page header contains an XLogRecPtr (LSN), so if we change it we'll
have to deal with pg_upgrade. I guess we could still keep XLogRecPtr
around as the on-disk representation, and convert b
On Mon, Jun 18, 2012 at 2:08 PM, Heikki Linnakangas
wrote:
> On 18.06.2012 21:00, Robert Haas wrote:
>> On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund
>> wrote:
1. Use a 64-bit segment number, instead of the log/seg combination. And
don't waste the last segment on each logical 4 GB
On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:00, Robert Haas wrote:
> > On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund
wrote:
> >>> 1. Use a 64-bit segment number, instead of the log/seg combination. And
> >>> don't waste the last segment on each logical 4 GB
On 18.06.2012 21:00, Robert Haas wrote:
On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund wrote:
1. Use a 64-bit segment number, instead of the log/seg combination. And
don't waste the last segment on each logical 4 GB log file. The concept
of a "logical log file" is now completely gone. XLogRecPt
On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund wrote:
>> 1. Use a 64-bit segment number, instead of the log/seg combination. And
>> don't waste the last segment on each logical 4 GB log file. The concept
>> of a "logical log file" is now completely gone. XLogRecPtr is unchanged,
>> but it should n
On Thursday, June 14, 2012 11:01:42 PM Heikki Linnakangas wrote:
> As I threatened earlier
> (http://archives.postgresql.org/message-id/4fd0b1ab.3090...@enterprisedb.co
> m), here are three patches that change the WAL format. The goal is to
> change the format so that when you're inserting a WAL re
On Thursday, June 14, 2012 11:01:42 PM Heikki Linnakangas wrote:
> As I threatened earlier
> (http://archives.postgresql.org/message-id/4fd0b1ab.3090...@enterprisedb.co
> m), here are three patches that change the WAL format. The goal is to
> change the format so that when you're inserting a WAL re
32 matches
Mail list logo
