Re: Is Patch Ok for deferred trigger disk queue?

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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073