Voy a procurar también de modificar mi código fuente para no hacer las llamadas al SPI_connect() en el bucle for de alguna manera. Muchas gracias por el consejo. Saludos cordiales, Yessica
El mié., 18 sept. 2019 a las 17:32, Yessica Brinkmann (< yessica.brinkm...@gmail.com>) escribió: > Entiendo. El tema es que por cada índice candidato del Index Adviser (que > tiene su tabla/columnas asociados) hago una llamada al SPI_connect(). Por > eso es el bucle. Un índice candidato es aquel que ha sido preseleccionado > para ser índice pero aún no ha sido elegido definitivamente. > Por si sirva de algo adjunto el log del Postgres luego de mi última > ejecución del Index Adviser de recién. > Yo estaré mirando el log también a ver si me ayuda. > Saludos cordiales, > Yessica > > El mié., 18 sept. 2019 a las 17:23, Alvaro Herrera (< > alvhe...@2ndquadrant.com>) escribió: > >> Yessica Brinkmann escribió: >> > Mmm bueno, en realidad, el error que pasó fue el de get_distinct. En >> esa >> > función fue que le puse el SPI_push y SPI_pop, y ya realiza el >> SPI_execute. >> > Pero sigue dándome el mismo error SPI_ERROR_CONNECT en la función >> > get_columnnames. >> > En dicha función, si se pone el SPI_push y SPI_pop (probé nomás de >> onda), >> > se pierde la conexión con el servidor, supongo que por un desborde de la >> > pila. Alguna idea de porqué sigue apareciendo SPI_ERROR_CONNECT en la >> > función get_columnnames? >> >> Igual es raro que llames a SPI_connect()/SPI_finish() múltiples veces en >> un bucle for(). Yo habría puesto una sola llamada al principio y al >> final de la función. Ahora, la verdad es que sin más contexto (el >> código completo de la función SQL que se ejecuta) no es posible más >> diagnóstico. >> >> Saludos >> >> -- >> Álvaro Herrera https://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> >
