On 11/08/2014 04:21 PM, Simon Riggs wrote:
On 5 November 2014 17:32, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:
Why does sequence_alloc need the current value? If it's a "remote" seqam,
the current value is kept in the remote server, and the last value that was
given to this PostgreSQL server is irrelevant.
That irks me with this API. The method for acquiring a new value isn't fully
abstracted behind the AM interface, as sequence.c still needs to track it
itself. That's useful for the local AM, of course, and maybe some others,
but for others it's totally useless.
Please bear in mind what seqam is for...
At present it's only use is to provide Global Sequences. There's a few
ways of doing that, but they all look sorta similar.
Ok.
The only other use we thought of was shot down, so producing the
perfect API isn't likely to help anyone. It's really not worth the
effort to produce a better API.
Your argument seems to be that because this API is only used for
creating global sequences, it's not worth it to make it better for that
purpose. That doesn't make much sense, so that's probably not what you
meant. I'm confused.
To be clear: I don't think this API is very good for its stated purpose,
for implementing global sequences for use in a cluster. For the reasons
I've mentioned before. I'd like to see two changes to this proposal:
1. Make the AM implementation solely responsible for remembering the
"last value". (if it's a global or remote sequence, the current value
might not be stored in the local server at all)
2. Instead of the single amdata field, make it possible for the
implementation to define any number of fields with any datatype in the
tuple. That would make debugging, monitoring etc. easier.
BDR doesn't require Global Sequences, nor are Global Sequences
restricted in their use to just BDR - lots of cluster configurations
would want something like this.
Sure. (I don't see how that's relevant to this discussion, however).
(marking this as "Returned with Feedback" in the commitfest)
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
