| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Incomplete freezing when truncating a relation during vacuum |
| Date: | 2013-11-30 17:29:41 |
| Message-ID: | 20131130172941.GI31100@awork2.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2013-11-30 12:22:16 -0500, Noah Misch wrote:
> On Sat, Nov 30, 2013 at 05:00:58PM +0100, Andres Freund wrote:
> > The problem with log_newpage_buffer() is that we'd quite possibly issue
> > one such call per item on a page. And that might become quite
> > expensive. Logging ~1.5MB per 8k page in the worst case sounds a bit
> > scary.
>
> I had in mind issuing at most one call per page. heap_page_prune() has a
> structure conducive to that.
That, at least as far as I can imagine, would make the fix quite
complicated though. In the first phase heap_page_prune() we aren't in a
critical section and cannot modify the buffer yet, so we would make all
the involved code cope with the unfixed xids and hint bits.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-11-30 17:43:39 | select_common_type()'s behavior doesn't match the documentation |
| Previous Message | Noah Misch | 2013-11-30 17:22:16 | Re: Incomplete freezing when truncating a relation during vacuum |