On Mon, Oct 11, 2010 at 10:17 PM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
>> > Yes. I had the idea of trying to fix this by allowing the standby to
>> > retain old versions of entire pages that got cleaned up on the master,
>> > until the transactions that might want to read the old pages were
>> > gone. But that may be prohibitively difficult, not sure.
>>
>> I think you'd end up having a notion of a snapshot of block information
>> (like a FS with snapshots) inside of postgres.
>>
>> Sounds like a lot of complexity to me, and the only benefit I see is
>> moving bloat from the primary to the standby. Granted, that would be
>> nice, but I would expect some costs aside from just the complexity.
>
> I had this idea when HS was being initially implemented, and I saw two
> problems with it.
>
> .) Identifying block versions in buffers. Our XID based MVCC like scheme
> would work, but we already have a block header which we would want to trim.
I was thinking of stuffing the old versions of the blocks into a
relation fork... and then having some kind of mapping... thing...
> .) Effectively every block cleanup will have to create a copy of the block
> because more often than not there's at least one transaction in the system,
> and when it asks, we need to hand it the old version.
This is probably true. And then, of course, you need the equivalent
of VACUUM to get rid of the old blocks, which kind of sucks.
Hence my earlier comments about being unsure that physical replication
is the way to go.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company