From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Marc Munro <marc(at)bloodnok(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #11867: Strange behaviour with composite types after resetting database tablespace |
Date: | 2014-11-08 02:47:30 |
Message-ID: | CA+TgmobSKzfRxANRyXBhxyLVomxWk9XQeDh_X8SrdmZ4eNSr_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Nov 4, 2014 at 11:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> However: at no point in this sequence did we flush the original catalog
>> blocks out of shared buffers. Therefore, a read of the database's
>> pg_class or pg_type at this point is likely to find the previous states of
>> those pages (pre-composite-type-drop) as valid, matching entries, so that
>> we skip reading the up-to-date page contents back from disk.
>
>> A quick fix for this would be to issue DropDatabaseBuffers during
>> movedb()
>
> BTW, I wondered whether the exact same hazard didn't exist for ALTER TABLE
> SET TABLESPACE. At first glance it looks bad, because ATExecSetTableSpace
> doesn't forcibly drop old shared buffers for the moved table either.
> Closer examination says we're safe though:
>
> * The buffers will be dropped during smgrdounlink at end of transaction,
> so you could only be at risk if you moved a table, modified it, and moved
> it back in a single transaction.
>
> * A new relfilenode will be assigned during each movement.
>
> * When assigning a relfilenode during the move-back, we'd be certain to
> choose a relfilenode different from the original one, because the old
> relation still exists on-disk at this point.
>
> So it's safe as things stand; but this seems a bit, um, rickety. Should
> we insert a DropRelFileNodesAllBuffers call into ATExecSetTableSpace to
> make it safer? It's kind of annoying to have to scan the buffer pool
> twice, but I'm afraid that sometime in the future somebody will try to get
> clever about optimizing away the end-of-transaction buffer pool scan, and
> break this case. Or maybe I'm just worrying too much.
I think you're worrying too much. Adding a comment to the code that
drives the end-of-transaction buffer pool scan to warn future
optimizers not to be too clever might be warranted; adding run-time
overhead to avoid a bug we don't have seems excessive.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-11-08 06:00:43 | Re: BUG #11903: Segmentation fault |
Previous Message | Sergey Koposov | 2014-11-08 01:39:28 | Re: BUG #11904: out of memory when scanning large number of partitions |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-11-08 02:49:41 | Re: [PATCH] HINT: pg_hba.conf changed since last config reload |
Previous Message | Robert Haas | 2014-11-08 02:41:17 | Re: Add CREATE support to event triggers |