From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without |
Date: | 2010-02-01 16:13:50 |
Message-ID: | 20935.1265040830@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Mon, Feb 1, 2010 at 7:27 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Fujii Masao wrote:
>>> The cause of the problem seems to be the new heap created by
>>> rebuild_relation() and copy_heap_data(), i.e., new VACUUM FULL.
>>> Since it's not a temporary heap, its rd_istemp is off. OTOH
>>> it needs to be synced after physical copy from old heap.
>>
>> Why does it need to be synced?
>>
>> ISTM the bug is that rd_istemp is off at that point.
> Umm... ISTM that new heap needs to be synced before calling
> swap_relation_files(), but, in the now, I'm not sure whether
> it's really required or not. Sorry.
If the original table is temp, then none of this work needs to be
fsync'd. Ever. So ISTM that CLUSTER ought to be copying the istemp
bit. Another reason to do that is to make sure that the new instance
of the table goes into the temp tablespace and not the regular one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-01 16:23:30 | Re: Re: [COMMITTERS] pgsql: Define INADDR_NONE on Solaris when it's missing. |
Previous Message | Bruce Momjian | 2010-02-01 15:48:35 | pgsql: Remove tabs in sgml. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-01 16:22:10 | Re: Allow parentheses around the query expression that follows a WITH clause |
Previous Message | Tom Lane | 2010-02-01 16:06:11 | Re: BUG #5304: psql using conninfo fails in connecting to the server |