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):

BEGIN
SAVEPOINT 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 '
BEGIN
SET 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