| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Christophe Pettus <xof(at)thebuild(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 |
| Date: | 2013-11-20 14:21:13 |
| Message-ID: | 1384957273.12016.YahooMailNeo@web162901.mail.bf1.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-11-20 05:59:58 -0800, Kevin Grittner wrote:
>> I don't understand where that would make sense; especially since
>> I thought that a database FREEZE followed by a checkpoint
>> releases old clog space anyway.
>
> It only releases them up to the (cluster wide) xmin horizon. So
> if there are older snapshots or prepared xacts around...
So as long as there are no open transactions or prepared
transactions on the master which started before the release with
the fix is applied, VACUUM FREEZE would be guaranteed to work?
Since I don't see how a non-prepared transaction would be running
from before a minor release upgrade, that just means we have to
make sure there are no prepared transactions from before the
upgrade?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2013-11-20 14:25:25 | ECPG FETCH readahead, was: Re: ECPG fixes |
| Previous Message | Boszormenyi Zoltan | 2013-11-20 14:20:53 | ECPG infrastructure changes, part 5, was: Re: ECPG fixes |