Re: Sobre pg_advisory_locks

Alvaro Herrera escribió:
> Oswaldo Hernández escribió:
>
>> 1.
>> Si para 'marcar' un registro en uso utilizo:
>> pg_try_advisory_lock(oid_de_tabla, id_registro)
>>
>> me puedo encontrar en un futuro que el id_registro (bigint) supera
>> la capacidad del int4.
>>
>> De momento estoy parcheando la situación, robandole un byte al oid
>> de la tabla (asumo que el oid de tabla nunca sobrepasará
>> 16.777.215), y asignándoselo al id de registro con la siguiente
>> formula:
>> pg_try_advisory_lock( (oid_de_tabla::int8 << 40) + id_registro )
>>
>> Pero, ¿hay alguna forma de obtener un id único, tipo bigint, que
>> identifique un registro de forma global?
>
> No. Tus suposiciones son peligrosas. Podrías usar
> pg_advisory_lock(int8) pero entonces no tendrías acceso a poner el OID
> de la tabla. Creo que lo más sano sería no usar un id_registro int8;
> ¿no te alcanza con los cuatro mil millones de identificadores que provee
> int4?
>

La cuestión es que mis id de registro no son normales, simplificando
avanzan de 100 en 100, entonces en rango se reduce a 42 millones. Esa es
la causa de querer aprovechar ese byte. Lo meditaré a ver que solución tomo.

>
>> 2.
>> En algunos momentos utilizo pg_advisory_unlock_all() para asegurarme
>> que no queda ningún advisory lock pendiente de liberar.
>>
>> La duda es que si, al igual que postgres genera locks
>> automaticamente al realizar select, etc. ¿puede postgres utilizar
>> también advisory_locks y entonces anularlos yo indebidamente al
>> ejecutar pg_advisory_unlock_all?
>
> No. Los candados de pg_advisory están en un espacio de locks separado
> de los locks de sistema. Lo que sí puede pasar es que en un año más
> agregues otros candados "advisory" que no quieras liberar. Te
> recomendaría no usar unlock_all si puedes evitarlo.
>

OK. He hecho una función que lee la tabla pg_locks, obtiene los advisory
del pid actual y los desbloquea uno a uno, reservando un rango para
otros posibles usos.

Gracias Alvaro.

--
Oswaldo Hernández