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

Re: Is Patch Ok for deferred trigger disk queue?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Stuart <deststar(at)blueyonder(dot)co(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is Patch Ok for deferred trigger disk queue?
Date: 2003-07-31 00:38:21
Message-ID: 200307310038.h6V0cLX02535@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Stuart wrote:
> Sorry for the tardiness in replying, I've been away for the past week or so.
> I didn't intend for 7.4 partly because I knew I'd be away & partly 
> because I had seen there was a problem I hadn't realised with the 
> previous patch and didn't want to submit something that may not be 
> stable just before beta. Currently it compiles but there are some, er, 
> issues - shouldn't take to long to fix but it might not be till 
> wednesday as I've got a bit of a backlog to get through.
> I could use sortmem, but if this is to be the case maybe there should be 
> a change the call it something like max_local_mem with a way to register 
> that you are using it. Maybe the memory allocs could automatically add 
> to it and remove as memory is assigned. Alternativly just make a global 
> to record the memory currently used by interested parties (currently the 
> trigger & sortmem I'd guess). The only trouble with this that I can see 
> is that the first one to claim the memory may claim it all, leaving 
> nothing for the other. I'll carry on using the dedicated guc variable 
> for the moment as I can't really see the correct way to solve this cleanly.
> regards,

OK, we can do the trigger queue file for 7.5.  The issue with sortmem is
that its effect is to spill a sort out to file when it gets too large,
the same for the trigger queue representation.  We could rename it, but
because it is _mostly_ used for sorts, we would probably keep the name
the same and just mention the trigger queue effect in the docs.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-07-31 00:41:04
Subject: Re: now about psql and one function
Previous:From: Sean ChittendenDate: 2003-07-30 23:42:31
Subject: Re: [PATCHES] [PATCH] Re: Why READ ONLY transactions?

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