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

Re: intercepting WAL writes

From: Decibel! <decibel(at)decibel(dot)org>
To: Hannu Krosing <hannu(at)krosing(dot)net>
Cc: Mike <mike(at)fonolo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: intercepting WAL writes
Date: 2008-06-04 12:35:04
Message-ID: 50D3DDD3-A96C-46D6-BDB2-ED23FCE27CCD@decibel.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On May 29, 2008, at 1:57 AM, Hannu Krosing wrote:
> On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
>
>>
>> Can somebody point to the most logical place in the code to intercept
>> the WAL writes? (just a rough direction would be enough)- or if this
>> doesn’t make sense at all, another suggestion on where to get the
>> data?
>
> I don't think that intercepting (and then decoding ) WAL is very
> productive. It is too low level to be of much help.
>
> The way I'd do it would be using pgQ from SkyTools package where  
> change
> events can be queued when happening and then moved in bulk to  
> memcached
> with not too much effort.


Actually, you might look one step further and see about adding  
memcached as a subscriber type to londiste; it might be easier than  
just using PgQ... not that using PgQ would be all that hard.

Also, keep in mind that no matter what you do you'll always have a  
race condition between data in the database and in memcached.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828


In response to

pgsql-hackers by date

Next:From: Decibel!Date: 2008-06-04 12:36:41
Subject: Re: DISTINCT -> GROUP BY
Previous:From: Heikki LinnakangasDate: 2008-06-04 12:22:58
Subject: Re: cannot use result of (insert..returning)

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