From: Jim C. Nasby <jnasby@pervasive.com>
To: Qingqing Zhou <zhouqq@cs.toronto.edu>
To: pgsql-performance@postgresql.org
Subject: Re: WAL logging of SELECT ... INTO command
Date: Fri, 24 Mar 2006 07:59:46 -0600
Message-ID: <20060324135946.GJ90527@pervasive.com> (raw)
In-Reply-To: <20060324134720.GA25359@surnet.cl>
References: <20060321122211.GU15742@pervasive.com>
<1142973230.24487.501.camel@localhost.localdomain>
<dvqqi5$1nmv$1@news.hub.org>
<20060324100731.GO90527@pervasive.com>
<20060324123902.GA14217@surnet.cl>
<20060324130121.GE90527@pervasive.com>
<20060324134720.GA25359@surnet.cl>
On Fri, Mar 24, 2006 at 09:47:20AM -0400, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote:
> > > Jim C. Nasby wrote:
> > >
> > > > Why would the content of the old_table be unreliable? If we've replayed
> > > > logs up to the point of the CTAS then any data that would be visible to
> > > > the CTAS should be fine, no?
> > > >
> > > > Though, the way Tom put it in one of his replies it sounds like WAL
> > > > doesn't do any kind of statement logging, only data logging. If that's
> > > > the case I'm not sure that the CTAS would actually get replayed. But I
> > > > suspect I'm just misunderstanding...
> > >
> > > The CTAS doesn't get logged (nor replayed obviously). What happens is
> > > that the involved files are fsync'ed before transaction commit, AFAIR.
> >
> > Ahh, yes, that sounds right. Might be a nice gain to be had if there was
> > some way to log the statement, but I suspect getting WAL to support that
> > would be extremely non-trivial.
>
> None at all, at least in the current incarnation, I think, because said
> query execution is dependent on the contents of the FSM, which is itself
> dependent on the timing of VACUUM and other stuff. Such an action,
> running with a different FSM content, can very trivially cause data
> corruption.
Oh, duh, because subsiquent operations will depend on the heap being in
a very specific state. Oh well.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jnasby@pervasive.com, zhouqq@cs.toronto.edu
Subject: Re: WAL logging of SELECT ... INTO command
In-Reply-To: <20060324135946.GJ90527@pervasive.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox