Re: pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data
Date
Msg-id CABOikdM2f03191gO9GSHLHe7SBCtAzRaSzbX-ac0co5+p9VcMg@mail.gmail.com
Whole thread Raw
In response to Re: pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data
List pgsql-hackers
On Thu, Mar 31, 2016 at 6:27 AM, Craig Ringer <craig@2ndquadrant.com> wrote:

Can you describe the process used to generate the sample WAL segment?

 
Shame that I can't find the sql file used to create the problematic WAL segment. But this is what I did.

I wrote a plpgsql function which inserts rows in a loop, every time checking if the remaining space in the WAL segment  has fallen to less than couple of hundred bytes. Of course, I used pg_settings to get the WAL segment size, WAL page size and pg_current_xlog_insert_location() to correctly compute remaining bytes in the WAL segment. At this point, do a non-HOT update, preferably to table which is already fully vacuumed and CHECKPOINTed to avoid getting any other WAL records in between. Assuming FPW is turned ON, the UPDATE should generate enough WAL to cross over the first page in the new WAL segment.

Let me know if you would like to me to put together a sql based on this description.

Thanks,
Pavan
 
--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Tom Lane
Date:
Subject: Re: So, can we stop supporting Windows native now?