Skip site navigation (1) Skip section navigation (2)

Re: bg worker: patch 1 of 6 - permanent process

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bg worker: patch 1 of 6 - permanent process
Date: 2010-08-26 19:40:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 08/26/2010 09:22 PM, Tom Lane wrote:
> Not having to have a hard limit on the space for unconsumed messages?

Ah, I see. However, spilling to disk is unwanted for the current use 
cases of imessages. Instead the sender needs to be able to deal with 
out-of-(that-specific-part-of-shared)-memory conditions.

> Please note the coding rule that says that the code should not execute
> more than a few straight-line instructions while holding a spinlock.
> If you're copying long messages while holding the lock, I don't think
> spinlocks are acceptable.

Writing the payload data for imessages to shared memory doesn't need any 
kind of lock. (Because the relevant chunk of shared memory got allocated 
via wamalloc, which grants the allocator exclusive control over the 
returned chunk). Only appending and removing (the pointer to the data) 
to and from the queue requires taking a spinlock. And I think that still 

However, your concern is valid for wamalloc, which is more critical in 
that regard.



In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-08-26 20:19:19
Subject: Re: CopyReadLineText optimization revisited
Previous:From: Tom LaneDate: 2010-08-26 19:22:22
Subject: Re: bg worker: patch 1 of 6 - permanent process

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group