From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Contrib -- PostgreSQL shared variables |
Date: | 2004-08-29 14:42:55 |
Message-ID: | 873c26kntc.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Question: How will these "system variables" behave regarding transactions?
> If I update a system variable and roll back the transaction, does it change
> back? Do changes in a running transaction remain invisible until COMMIT?
> Excuse me if you've already answered these; I've not caught up on my -hackers
> backlog since I broke my foot.
I think this is precisely the objection. He wants something that allows him to
break out of transaction semantics entirely. Other backends would see the
value he sets before he commits. If he rolls back his changes would remain.
I expect to see substantial resistance to incorporating such a feature. One
argument will be that he should simply use a separate system for such data.
For example, memcached would be much faster and more scalable than
communicating via postgres.
The only disadvantage to using something like memcached would be that you
couldn't transparently use values from there inside your queries. You would
have to fetch them and then pass them as parameters to postgres.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-29 15:07:53 | Re: [BUGS] server crash in very big transaction [postgresql |
Previous Message | Tom Lane | 2004-08-29 14:27:25 | Re: psql questions: SQL, progname, copyright dates |