Re: Hot standby and removing VACUUM FULL

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby and removing VACUUM FULL
Date: 2009-12-04 11:31:10
Message-ID: 4B18F2FE.6070801@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> ISTM premature to remove all traces of VF from code. We may yet need it
> for some reason, especially if doing so creates complex dependencies on
> important features.

Well, it's still in the repository.

> So modified proposal looks like this
>
> 1. (In normal running) Provide information to HS so it can identify VF
> commit records.
> Implement in code either
> a) Just before we issue the first VFI commit we send a new type of WAL
> message to indicate VFI-in-progress, including the xid.
> b) Alter the API of RecordTransactionCommit(), and send the info within
> the commit record. This was pretty much how we did that before.
> I prefer (a) now because the ugliness is better isolated.

With a), you need to keep track of the seen VFI-in-progress records,
remember to expire the state at a shutdown record etc. And you have to
deal with the possibility that a checkpoint happens between the
VFI-in-progress record and the commit record; a recovery starting from
the checkpoint/running-xacts record must see both records or it will
release the locks prematurely.

b) seems much simpler to me.

> 2. (In HS recovery) When we see first commit record for the VF xid we
> commit the transaction in clog, yet maintain locks and KnownAssigned
> xids
>
> 3. (In HS recovery) When we see second commit record for the VF xid we
> skip clog updates but then perform remaining parts of commit.

I's harmless to set a clog entry as committed twice, so you can treat
the 2nd commit record the same as a regular commit record.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jasen Betts 2009-12-04 11:34:54 Re: Installing PL/pgSQL by default
Previous Message Tim Bunce 2009-12-04 11:18:24 Re: First feature patch for plperl - draft [PATCH]