On 2013-11-18 12:50:21 +0200, Heikki Linnakangas wrote: > On 18.11.2013 11:48, Andres Freund wrote: > I don't think the sequence AM should be in control of 'cached'. The caching > is done outside the AM. And log_cnt probably should be passed to the _alloc > function directly as an argument, ie. the server code asks the AM to > allocate N new values in one call.
Sounds sane. > I'm thinking that the alloc function should look something like this: > > seqam_alloc(Relation seqrel, int nrequested, Datum am_private) I don't think we can avoid giving access to the other columns of pg_sequence, stuff like increment, limits et all need to be available for reading, so that'd also need to get passed in. And we need to signal that am_private can be NULL, otherwise we'd end up with ugly ways to signal that. So I'd say to pass in the entire tuple, and return a copy? Alternatively we can return am_private as a 'struct varlena *', so we can properly signal empty values. We also need a way to set am_private from outside seqam_alloc/setval/... Many of the fancier sequences that people talked about will need preallocation somewhere in the background. As proposed that's easy enough to write using log_sequence_tuple(), this way we'd need something that calls a callback with the appropriate buffer lock held. So maybe a seqam_update(Relation seqrel, ...) callback that get's called when somebody executes pg_sequence_update(oid)? It'd probably a good idea to provide a generic function for checking whether a new value falls in the boundaries of the sequence's min, max + error handling. > I'm not thinking that we'd change sequences to not be relations. I'm > thinking that we might not want to store the state as a one-page file > anymore. In fact that was just discussed in the other thread titled > "init_sequence spill to hash table". Yes, I read and even commented in that thread... But nothing in the current proposed API would prevent you from going in that direction, you'd just get passed in a different tuple/buffer. > >b) It's not actually easy to get similar semantics in "userspace". How > >would you emulate the crash-safe but non-transactional semantics of > >sequences without copying most of sequence.c? Without writing > >XLogInsert()s which we cannot do from a out-of-tree code? > > heap_inplace_update() That gets the crashsafe part partially (doesn't allow making the tuple wider than before), but not the caching/stateful part et al. The point is that you need most of sequence.c again. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
