Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Fila no encontrada después de un INSERT

jeje, ya te entendí.

Añado unos comentarios mas abajo.

2016-05-19 12:37 GMT+02:00 Horacio Miranda <hmiranda(at)gmail(dot)com>:

> Entendí tu pregunta.
> Creo que no me entendiste la respuesta.
>

Una cosa que no había comentado, No siempre nos pasa, aunque tiene un 80%
de posibilidades de que suceda este fallo.

>
> Postgresql no es como Oracle ( Oracle soporta basicamente dos tipos de
> modos transaccionales ), postgresql 4 ( de lo que recuerdo ).
>

Okis, te refieres a los niveles de aislamiento transaccional, estoy poco
informado pero le ahora miso me pongo.

>
> En los links que te envie. una persona tiene un problema similar al que tu
> tienes.
>
> Puedes revisar lo que envie por favor.
>
>
> http://dba.stackexchange.com/questions/62024/how-to-set-isolation-to-serializable-deferrable-for-a-whole-postgresql-database
>
> revisa si tienes esta opcion por favor.
>
> transaction_deferrable = on.
>

Concretamente lo tenemos comentado: #default_transaction_deferrable = off

>
> Lo pregunto por que me tinca que alguien cambio algunas cosas para que la
> base de datos sea más rápida ( pero eso te genera otro otros problemas de
> consistencia ).
>
> Ahora si estas usando pool, revisa que estes realmente conectado al master
> y no al esclavo, ( de hecho yo probaría con el esclavo abajo ).
>

Comprobamos que la consulta se hace en el master a través de los logs del
master.
Más os digo, hemos probado que la consulta se realice en el esclavo y el
porcentage de que falle se queda en un 20-30%, aquí sí que me quedé
perplejo en comparación del 80% de errores en la master.

>
> Algo esta mostrando datos sucios ( dirty read ).
>

Según he encontrado en la WEB: "*DIRTY READ cuando la transacción accede a
datos escritos por otra transacción que aún no hace Commit.*"
Por lo que entiendo y trasladándolo a mi caso, el autocommit de la
aplicación en C aún no ha finalizado cuando el backend de la WEB hace la
consulta, ya que por defecto SELECT y INSERTS no se bloquean según el MVCC
de postgresql.
Podría ser que el el primer BEGIN "congelara" el estado de la BBDD para su
uso, y el "descongelarla" con los cambios tuviera un pequeño lag? (
Perdonen por lo de congelar. )

Hasta ahí podría entenderlo, lo que pasa es que hemos partido de una
premisa errónea, pensábamos que al obtener el resultado del "INSERT ...
RETURNING" en un Autocommit, esa transacción ya estaba *finalizada por
completo*, pero por lo que veo NO.

:-( Seguro que estoy diciendo alguna tontería.

>
> Lo otro que puede estar afectando es que un componente este conectado al
> pool y el otro a la base de datos de forma directa, ( imagino que el pool
> tiene algun delay para tener velocidad ) pero esto es pura conjetura.
>

Correcto, backend-WEB al pool y la aplicación de forma directa. Aunque no
entiendo en que influye un delay en el pool para este caso.

Gracias por su respuesta, seguiré investigando. Tendré que estudiar los
niveles de aislamiento con más profundidad y ver cómo influye en nuestro
pipeline de trabajo.

Si se les ocurre algo más, no duden en decirmelo.

--
*Ruben Fitó *
Software Engineer
[image: Ubiquat Technologies, SL]
r(dot)fito(at)ubiquat(dot)com <j(dot)catarineu(at)ubiquat(dot)com>
www.ubiquat.com
Tota la informació continguda en aquest document i arxius adjunts és
CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
error, si us plau elimini'l i posi's en contacte amb l'emissor.

All information contained in this document and any attachments are
CONFIDENTIAL and protected under trade secret laws. If you receive this
message by mistake, please delete it and notify it immediately to the
sender.