From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org> |
Cc: | <marc(at)bloodnok(dot)com>, <pgsql-bugs(at)postgreSQL(dot)org> |
Subject: | Re: [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace |
Date: | 2014-11-06 21:21:10 |
Message-ID: | 545BE646.7060808@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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 in that 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 this would only be an issue if you're playing games with mostly empty tables, and only then if you've got really large shared buffers. 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
From | Date | Subject | |
---|---|---|---|
Next Message | 'Andres Freund' | 2014-11-06 21:24:12 | Re: BUG #11902: PostgreSQL 9.5 crashes on alter table in function |
Previous Message | Tom Lane | 2014-11-06 21:15:15 | Re: BUG #11902: PostgreSQL 9.5 crashes on alter table in function |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-11-06 21:30:15 | Re: Proposal: Log inability to lock pages during vacuum |
Previous Message | Kevin Grittner | 2014-11-06 21:17:28 | Re: Tweaking Foreign Keys for larger tables |