jeje, ya te entendí. Añado unos comentarios mas abajo.
2016-05-19 12:37 GMT+02:00 Horacio Miranda <hmira...@gmail.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.f...@ubiquat.com <j.catari...@ubiquat.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.
