From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Markus Wanner <markus(at)bluegap(dot)ch> |
Subject: | Re: Proposal for CSN based snapshots |
Date: | 2014-05-15 20:16:51 |
Message-ID: | 20140515201651.GD16014@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-05-15 16:13:49 -0400, Bruce Momjian wrote:
> On Thu, May 15, 2014 at 10:06:32PM +0200, Andres Freund wrote:
> > > If the larger clog size is a show-stopper (and I'm not sure I have an
> > > intelligent opinion on that just yet), one way to get around the
> > > problem would be to summarize CLOG entries after-the-fact. Once an
> > > XID precedes the xmin of every snapshot, we don't need to know the
> > > commit LSN any more. So we could read the old pg_clog files and write
> > > new summary files. Since we don't need to care about subcommitted
> > > transactions either, we could get by with just 1 bit per transaction,
> > > 1 = committed, 0 = aborted. Once we've written and fsync'd the
> > > summary files, we could throw away the original files. That might
> > > leave us with a smaller pg_clog than what we have today.
> >
> > I think the easiest way for now would be to have pg_clog with the same
> > format as today and a rangewise much smaller pg_csn storing the lsns
> > that are needed. That'll leave us with pg_upgrade'ability without
> > needing to rewrite pg_clog during the upgrade.
>
> Yes, I like the idea of storing the CSN separately. One reason the
> 2-bit clog is so good is that we know we have atomic 1-byte writes on
> all platforms.
I don't think we rely on that anywhere. And in fact we don't have the
ability to do so for arbitrary bytes - lots of platforms can do that
only on specifically aligned bytes.
We rely on being able to atomically (as in either before/after no torn
value) write/read TransactionIds, but that's it I think?
> Can we assume atomic 64-bit writes?
Not on 32bit platforms.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Kaltenbrunner | 2014-05-15 20:30:45 | Re: buildfarm animals and 'snapshot too old' |
Previous Message | Tom Lane | 2014-05-15 20:15:29 | Re: buildfarm animals and 'snapshot too old' |