Re: [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace
Date
Msg-id 545BE646.7060808@BlueTreble.com
Whole thread Raw
In response to Re: [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/4/14, 10:45 AM, Tom Lane wrote:
> 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.

We could possibly remember what relations have been moved to different tablespaces in a transaction and avoid the call
inthat case, but that seems rather silly.
 

If there's any non-trivial actual data involved then presumably the buffer scan won't be noticed amidst all the IO, so
thiswould only be an issue if you're playing games with mostly empty tables, and only then if you've got really large
sharedbuffers. I can't actually come up with any real use case for that.
 

So +1 for doing the safe thing...
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Tweaking Foreign Keys for larger tables
Next
From: Andres Freund
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum