Re: Contrib -- PostgreSQL shared variables

Mohawksoft,

> Actually that are not involved with transactions in any way.
>
> There classes of problems in which proper ACID implementation is not
> nessisary. In fact, there are subclasses within a larger system that need
> not have the overhead imposed by transactions.

Hmmm, wait, are you implementing this, or is Jonathan?  

As a database developer who would use this or a similar feature, I do not 
agree that the lack of transactionality is a benefit.   Quite the contrary.   
Imagine this scenario, once we have error-trapping in place for 8.1 (pardon 
the syntax if it's off the proposal, I think you'll see the point anyway):

BEGINSAVEPOINT before_udpate;    UPDATE jehosaphat SET slivy = 60 WHERE status = 4;    SET SHARED
jehosaphat_last_update= now();    IF transaction_error > 0 THEN         ROLLBACK TO before_update;    ELSE
COMMIT;   END IF;
 
...

Now assume that the reason I'm using a shared variable is that "jehosaphat" 
needs to be updated every 500ms, and thus we don't want to be storing it in a 
table.   In that case, if shared variables are not transactional, the above 
would be deceptive; the system would think that jeshosaphat had been updated 
when it had not.   

Ah, you say, but you could work around that if you coded correctly.   Maybe 
so, although I find the idea that transactions don't apply to some objects 
very liable to cause confusion.   Also consider this case:

CREATE FUNCTION update_jeshosaphat_last () RETURNS TRIGGER AS '
BEGINSET SHARED jehosaphat_last_update = now();
END; ' language plpgsql;

CREATE TRIGGER tg_jehosaphat_update
BEFORE UPDATE OR DELETE ON jehosaphat 
FOR EACH STATEMENT EXECUTE PROCEDURE update_jehosaphat_last();

NOW imagine if your update gets rolled back; the shared variable will be 
misreporting the last update and there isn't any coding around it.   

My personal perspective is that shared variables should be transactional, just 
like everything else in PostgreSQL except sequences.    Just because they are 
transactional does not mean they have to be saved on disk; that's where most 
of your "dead tuple overhead" comes in.   If you could place the variables in 
"reserved" shared memory and never sync, then needing to have several copies 
which split and collapse to remain current with the existing transactions 
should not be a major performance cost.    Of course, it will make the code a 
lot harder, but that's one of the reasons why nobody has done it before now.

Now, if you're telling me that it's too difficult for you to implement 
transactions at this time, and that you want to push this patch without 
transactions for them to be added sometime later, then we can have it out on 
that basis.   But you're going to have a hard time convincing me or several 
other people that ignoring transactions is somehow a benefit.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco