¿hay alguna manera de evitar llamar a nextval() si la inserción falla en PostgreSQL?

Question

En una base de datos PostgreSQL tengo una tabla con una clave principal y otro campo que debe ser único.

CREATE TABLE users (
    id  INTEGER PRIMARY KEY DEFAULT nextval('groups_id_seq'::regclass), 
    name VARCHAR(255) UNIQUE NOT NULL 
); 

    INSERT users (name) VALUES ('foo'); 
    INSERT users (name) VALUES ('foo'); 
    INSERT users (name) VALUES ('bar'); 

El segundo inserto falla pero la groups_id_seq secuencia ya se incrementa de modo que cuando 'bar' se añade que deja un hueco en los números de ID.

¿Hay alguna manera de decirle a PostgreSQL que obtenga el siguiente valor solo si se cumplen otras restricciones o debo verificar primero con SELECT si el nombre no está duplicado? Esto aún no garantizaría la ausencia de lagunas, pero al menos reduciría su número a los raros casos en que hay otro proceso que intenta insertar el mismo nombre al mismo tiempo

Answer 1

No lo creo: una característica básica de secuencias es que las lagunas son posibles (piense en dos transacciones simultáneas, con una realización de un ROLLBACK). Debes ignorar las lagunas. ¿Por qué son un problema en tu caso?

Answer 2

Si necesita secuencias sin intervalos, hay formas de hacerlo, pero no es trivial, y definitivamente mucho más lento.

Además, si le preocupa "usar demasiados identificadores", simplemente defina id como bigserial.

Answer 3

Es posible, aunque engorroso, hacer esto. Como bortzmeyer says, es peligroso confiar en los valores de las secuencias que son contiguas, por lo que es mejor dejar las cosas como están si es posible.

Si no puede:

Cada acceso a la tabla que podría causar una fila para tener un cierto nombre (es decir, todos los INSERT a la mesa, y si usted lo permite (aunque es una mala práctica) cada UPDATE que podría cambiar el campo name) debe hacerlo dentro de una transacción que bloquee primero todo. La opción más simple y menos eficiente es simplemente bloquear toda la tabla usando LOCK users IN EXCLUSIVE MODE (agregar las últimas 3 palabras permite el acceso de lectura concurrente por otros procesos, lo cual es seguro).

Sin embargo, es un bloqueo muy grueso que ralentizará el rendimiento si hay muchas modificaciones simultáneas en users; una mejor opción sería bloquear una única fila correspondiente en otra tabla que ya debe existir. Esta fila se puede bloquear con SELECT ... FOR UPDATE. Esto tiene sentido solo cuando se trabaja con una tabla "secundaria" que tiene una dependencia FK en otra tabla "principal".

Por ejemplo, imagina por el momento que estamos tratando de crear de forma segura orders para un customer, y que estas órdenes de alguna manera tienen 'nombres' identificativos. (Lo sé, pobre ejemplo ...) orders tiene una dependencia de FK en customers. A continuación, para evitar que alguna vez la creación de dos órdenes con el mismo nombre para un cliente determinado, se puede hacer lo siguiente:

BEGIN; 

-- Customer 'jbloggs' must exist for this to work. 
SELECT 1 FROM customers 
WHERE id = 'jbloggs' 
FOR UPDATE 

-- Provided every attempt to create an order performs the above step first, 
-- at this point, we will have exclusive access to all orders for jbloggs. 
SELECT 1 FROM orders 
WHERE id = 'jbloggs' 
AND order_name = 'foo' 

-- Determine if the preceding query returned a row or not. 
-- If it did not: 
INSERT orders (id, name) VALUES ('jbloggs', 'foo'); 

-- Regardless, end the transaction: 
END; 

en cuenta que es no suficiente para simplemente bloquear la fila correspondiente en users con SELECT ... FOR UPDATE - si la fila aún no existe, varios procesos concurrentes pueden informar simultáneamente que la fila no existe, y luego intentar inserciones simultáneas, lo que da como resultado transacciones fallidas y, por lo tanto, espacios de secuencia.

Cualquiera de los dos esquemas de bloqueo funcionará; lo importante es que cualquiera que intente crear una fila con el mismo nombre debe intentar bloquear el mismo objeto.