Skip site navigation (1) Skip section navigation (2)

Re: WAL logging of SELECT ... INTO command

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: WAL logging of SELECT ... INTO command
Date: 2006-03-24 13:59:46
Message-ID: 20060324135946.GJ90527@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-patchespgsql-performance
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(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

pgsql-performance by date

Next:From: Dave DutcherDate: 2006-03-24 14:46:54
Subject: Re: Problem with query, server totally unresponsive
Previous:From: Alvaro HerreraDate: 2006-03-24 13:47:20
Subject: Re: WAL logging of SELECT ... INTO command

pgsql-patches by date

Next:From: Kris JurkaDate: 2006-03-24 18:09:26
Subject: Re: [PERFORM] WAL logging of SELECT ... INTO command
Previous:From: Alvaro HerreraDate: 2006-03-24 13:47:20
Subject: Re: WAL logging of SELECT ... INTO command

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group