Re: Instalacion desatendida de Postgres

[Haroon]

Greetings Jaime and José,

Thank you for reaching out!

On Mon, 8 Jul 2019 at 10:12, Jose Mercedes Venegas Acevedo
 wrote:
>
> Hola Jaime
>
> Ok voy a probar el instalador de 2ndquadrant pero creo que seria mucho mas 
> interesante usando el instalador de 2UDA hay algun manual de como instalar 
> 2UDA de manera desatendida para instalar en modo text como parametros en el 
> instalador para windows?

I understand that you are willing to give Postgres Installer a try and
are also interested in 2UDA, however, that is all I could understand
from the email conversation using translate feature from Spanish to
English. From the email subject, I understand that the original
question is related to unattended install.

Jaime, when you get the chance, could you please translate the
question for me in English so that I could understand it better and
help accordingly ? Thanks!


Regards,

>
>
>
>
> El lun., 24 jun. 2019 a las 11:58, Jaime Casanova 
> () escribió:
>>
>> On Sun, 16 Jun 2019 at 09:14, Carlos Perez  
>> wrote:
>>>
>>> https://www.enterprisedb.com/es/docs/en/9.6/pginstguide/PostgreSQL_Installation_Guide.1.12.html
>>>
>>>
>>>
>>>
>>> Remitente notificado con
>>> Mailtrack 06/16/19, 10:15:40 AM
>>>
>>> El sáb., 15 jun. 2019 a las 13:52, Jose Mercedes Venegas Acevedo 
>>> () escribió:

 Buen dia a todos

 En la version 10 de postgres en el manual de instalacion hay una forma de 
 instalar postgres de manera desatendida a traves de la linea de comandos 
 por casualidad alguien sabe cual es la hoja de ruta de EDB al respecto es 
 decir acabo de descargar postgres 12 Beta y el manual de instalacion y ya 
 no veo esta opcion en manual se que aun es la version beta pero queria 
 saber si EDB mantendra esta forma de instalar o sera retirada para 
 postgres 12 para windows.

>>
>> Saludos José,
>>
>> Podrías probar el método que se indica en la documentación del instalador de 
>> EDB para 9.6 del enlace que te paso Carlos, puede que sea solo un error en 
>> la documentación de ellos.
>>
>> O puedes probar el "2ndQuadrant postgres installer" que soporta instalación 
>> desatendida: 
>> https://www.2ndquadrant.com/es/recursos/postgresql-installer-2ndquadrant/
>>
>> --
>> Jaime Casanova  www.2ndQuadrant.com
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>
> --
> José Mercedes Venegas Acevedo
> cel Mov RPC 964185205
>
>

--
Haroonhttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: como transformar punto decimal a coma decimal

[Francisco Olarte]

Ernesto:

On Mon, Jul 8, 2019 at 5:53 PM Ernesto Ruiz  wrote:
> Ante todo reciban de mi parte un cordial saludo. La presente es para saber si 
> existe una sentencia SQL  que me permita transformar el punto decimal en coma 
> decimal de una tabla ya creada y cargada.

Dinos primero que es lo que quieres con un poco mas de detalle.

Me explico, si tienes, una columna numerica los datos se mandan de una
forma al cliente, que luego los formatea como quiere, y tendrias que
explorar opciones de formateado ( en el cliente y en el servidor ),
pero no habrias de hacer nada en la tabla. Si tienes una columna de
texto con un numero dentro tendrias que hacer sustituciones de texto.

Las columnas numericas se guardan en un formato que depende de su
tipo, y se transforman para presentarlas, las de texto son triviales,
suele ser simplemente copiarlas ( y luego codificarlas en el charset
de la conexion, utf o lo que sea ) . En las numericas el punto decimal
es un tema de presentacion de los datos, que tiene que ver con los
locales y similares.

Para que alguien te pueda contestar con una minima precision
necesitariamos saber que tipo tienen las columnas ( i.e.,
numeric(12,7), double, text ), DONE ves el punto decimal que quieres
cambiar por una coma ( i.e., "Cuando hago un select en pgadmin x.y",
"Cuando ejectuto un query en el psql", "Cuando las cojo con mi
programa en Java que usa el driver psql-jdvbc-x.y.z" ), asi como
probablemente cual es el locale del servidor y de la maquina que los
presenta con puntos ( aparte de lo tipico, version de pg, SO de
servidor y cliente etc ).

Tal y como lo preguntas pueden ser cien cosas con mil soluciones,
puede que alguien quiera suponer una de las cien y presentar una de
las soluciones, pero es mejor si nos dices que te pasa.

Francisco Olarte.

PG11: particionado, parallel query y performance

[Ruben Fitó]

Buenos días lista,

Estamos pensando en actualizar nuestro servidor de PG9.5 a PG11.04.

Hemos estado mirando las funcionalidades de particionado, parallel query
entre otras y nos gustaría saber si han tenido experiencia.

Empezaré con nuestros propósitos y después ya me comentan si digo alguna
locura:

   - Nuestro objetivo para el uso de particionado(por año) es la de evitar
   hacer purgados.
   - El otro objetivo es de optimizar consultas porque reducimos el volumen
   de datos por tabla.

Partiendo de las premisas anteriores, aunque es posible que sean erróneas,
me gustaría saber varias cosas:

   - Si una consulta afecta a varias tablas particionadas, cómo afecta al
   rendimiento. "Parallel query" ayuda? Entiendo que los índices se heredan en
   PG11, ...
   - Cuándo tiene efecto el "Parallel query"?
   - Qué tal han trabajado con JIT?
   - ¿Qué debería tener en cuenta en el momento que empiece a trabajar con
   particionado? Algún consejo, alguna mala experiencia, alguna buena...
   - Cómo funciona el particionado con Streaming Replication?
   - Y con Logical replication? → Supongo que he de crear todas las tablas
   igual que en master... también se heredan índices?

En resumen, me gustaría saber si han tenido experiencia en estos campos y
qué recomendaciones tienen.

Muchas gracias de antemano.

Saludos

-- 
*Ruben Fitó *
Software Engineer
[image: Ubiquat Technologies, SL]
r.f...@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.

Re: PG11: particionado, parallel query y performance

[Alvaro Herrera]

Ruben Fitó escribió:

Hola

>- Nuestro objetivo para el uso de particionado(por año) es la de evitar
>hacer purgados.

Excelente, ese es uno de los principales motivos para particionar.

>- El otro objetivo es de optimizar consultas porque reducimos el volumen
>de datos por tabla.

Cierto, siempre y cuando esas consultas tengan que recorrer grandes
porciones de las tablas.  Si tus consultas usan mayormente recorridos
localizados de índice, no ganarás mucho con particionar.

>- Si una consulta afecta a varias tablas particionadas, cómo afecta al
>rendimiento. "Parallel query" ayuda? Entiendo que los índices se heredan en
>PG11, ...

El particionamiento ayuda a las consultas sobre todo porque ocurre "pruning",
es decir que el optimizador puede evitar recorrer las particiones que
pueda demostrar (basado en los WHERE y demás) que no necesita recorrer.
Parallel query ayuda tal como si fuera una consulta sobre una sola
tabla.  Los índices se "heredan" pero esto sólo quiere decir que los
índices se crean automáticamente en las particiones; no tiene ninguna
implicancia desde el punto de vista de la optimización de la consulta.

>- Cuándo tiene efecto el "Parallel query"?

Siempre que sea útil.

>- Qué tal han trabajado con JIT?

Está bueno, puede darte un pequeño % de mejora pero no esperes nada muy
increíble todavía.  Quizás en un par de años más.  Pero sí está algo
verde en algunas partes, así que pruébalo con cuidado y reporta
cualquier comportamiento inesperado o sospechoso.

>- ¿Qué debería tener en cuenta en el momento que empiece a trabajar con
>particionado? Algún consejo, alguna mala experiencia, alguna buena...

Aconsejo probar las operaciones que vas a realizar con cantidades
razonables de datos, y verificar los planes de ejecución.

Ojo con las definiciones de índices.  Hay algunas limitaciones ... por
ej. si tienes llaves primarias en las tablas particionadas, la PK debe
incluir la llave de partición.

>- Cómo funciona el particionado con Streaming Replication?

No afecta. Son ortogonales.

>- Y con Logical replication? → Supongo que he de crear todas las tablas
>igual que en master... también se heredan índices?

La replicación lógica tiene algunas limitaciones todavía con tablas
particionadas.  Recomiendo probar con cuidado.

En resumen: es mejor que el año anterior, pero podría ser mejor, y
seguro que el próximo año será mejor.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: problema al intentar recuperar PITR

[Guillermo E. Villanueva]

Gracias por tu respuesta, perdón por no responder antes, para descartar le
puse permisos 777 postgres:postgres.
La verdad que no se si selinux estaba habilitado, pero si funcionó en las
pruebas, creo que no sería un factor no?



El vie., 5 jul. 2019 a las 23:07, Horacio Miranda ()
escribió:

> Revisa los permisos que tiene el archivo, revisa sí selinux esta
> habilitado.
>
>
> On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote:
> > Hola, hice todos los pasos necesarios para una recuperación correcta
> > usando PITR.
> > Es mas, hicimos pruebas en meses atras y funcionaron bien.
> > Ahora que lo necesito en serio, tengo un problema, intento levantar en
> > modo de recuperación (recovery.conf) y obtengo lo siguiente:
> > 2019-07-05 18:48:47.864 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  0 LOG:  el sistema de bases de datos fue
> > interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART
> > 2019-07-05 18:48:47.864 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  0 LOG:  creando el directorio WAL faltante
> > «pg_xlog/archive_status»
> > cp: no se puede efectuar `stat' sobre
> > «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o
> > el directorio
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  0 LOG:  comenzando proceso de recuperación
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  58P01 LOG:  no se pudo abrir
> > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento
> > 172): No existe el fichero o el directorio
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  0 LOG:  el registro del punto de control
> > primario no es válido
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  58P01 LOG:  no se pudo abrir
> > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento
> > 172): No existe el fichero o el directorio
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  0 LOG:  el registro del punto de control
> > secundario no es válido
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> >  5d1fc5bf.5a54 %;   %;  XX000 PANIC:  no se pudo localizar un registro
> > de punto de control válido
> > 2019-07-05 18:48:47.869 ART %;  %;  %;  0 %;   %;  23122 %;
> >  5d1fc5bf.5a52 %;   %;  0 LOG:  proceso de inicio (PID 23124) fue
> > terminado por una señal 6: Aborted
> > 2019-07-05 18:48:47.869 ART %;  %;  %;  0 %;   %;  23122 %;
> >  5d1fc5bf.5a52 %;   %;  0 LOG:  abortando el inicio debido a una
> > falla en el procesamiento de inicio
> >
> > El archivo 000206DA00AC si está en el directorio de
> > recuperación: /usr/local/pgsql/BK20190705/
> >
> > Por favor, me pueden orientar en que está pasando?
> >
> > Gracias
>

Re: problema al intentar recuperar PITR

[Guillermo E. Villanueva]

Gracias por la respuesta y disculpas por no responder antes.
si existe el archivo con el tamaño correcto.

El vie., 5 jul. 2019 a las 23:10, Juan ()
escribió:

> El archivo existe, cuánto mide? Cual es la longitud seteada de wall?
>
> El vie., 5 de jul. de 2019 11:07 PM, Horacio Miranda 
> escribió:
>
>> Revisa los permisos que tiene el archivo, revisa sí selinux esta
>> habilitado.
>>
>>
>> On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote:
>> > Hola, hice todos los pasos necesarios para una recuperación correcta
>> > usando PITR.
>> > Es mas, hicimos pruebas en meses atras y funcionaron bien.
>> > Ahora que lo necesito en serio, tengo un problema, intento levantar en
>> > modo de recuperación (recovery.conf) y obtengo lo siguiente:
>> > 2019-07-05 18:48:47.864 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  0 LOG:  el sistema de bases de datos fue
>> > interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART
>> > 2019-07-05 18:48:47.864 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  0 LOG:  creando el directorio WAL faltante
>> > «pg_xlog/archive_status»
>> > cp: no se puede efectuar `stat' sobre
>> > «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o
>> > el directorio
>> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  0 LOG:  comenzando proceso de recuperación
>> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  58P01 LOG:  no se pudo abrir
>> > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento
>> > 172): No existe el fichero o el directorio
>> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  0 LOG:  el registro del punto de control
>> > primario no es válido
>> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  58P01 LOG:  no se pudo abrir
>> > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento
>> > 172): No existe el fichero o el directorio
>> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  0 LOG:  el registro del punto de control
>> > secundario no es válido
>> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
>> >  5d1fc5bf.5a54 %;   %;  XX000 PANIC:  no se pudo localizar un registro
>> > de punto de control válido
>> > 2019-07-05 18:48:47.869 ART %;  %;  %;  0 %;   %;  23122 %;
>> >  5d1fc5bf.5a52 %;   %;  0 LOG:  proceso de inicio (PID 23124) fue
>> > terminado por una señal 6: Aborted
>> > 2019-07-05 18:48:47.869 ART %;  %;  %;  0 %;   %;  23122 %;
>> >  5d1fc5bf.5a52 %;   %;  0 LOG:  abortando el inicio debido a una
>> > falla en el procesamiento de inicio
>> >
>> > El archivo 000206DA00AC si está en el directorio de
>> > recuperación: /usr/local/pgsql/BK20190705/
>> >
>> > Por favor, me pueden orientar en que está pasando?
>> >
>> > Gracias
>>
>>
>>

Re: problema al intentar recuperar PITR

[Guillermo E. Villanueva]

Gracias por tu respuesta Alvaro,
recovery.con tiene:
restore_command = '/usr/local/pgsql/BK20190705/%f %p'

Les cuento que pude resolverlo de una manera no muy convincente, antes del
start copié todos los archivos wal de respaldo al directorio pg_xlog y
arrancó bien, pero... pero... y el restore_command? por qué no funcionó?

El sáb., 6 jul. 2019 a las 0:21, Alvaro Herrera ()
escribió:

> Guillermo E. Villanueva escribió:
> > Hola, hice todos los pasos necesarios para una recuperación correcta
> usando
> > PITR.
> > Es mas, hicimos pruebas en meses atras y funcionaron bien.
> > Ahora que lo necesito en serio, tengo un problema, intento levantar en
> modo
> > de recuperación (recovery.conf) y obtengo lo siguiente:
>
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> 5d1fc5bf.5a54
> > %;   %;  0 LOG:  comenzando proceso de recuperación
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> 5d1fc5bf.5a54
> > %;   %;  58P01 LOG:  no se pudo abrir «pg_xlog/000206DA00AC»
> > (archivo de registro 1754, segmento 172): No existe el fichero o el
> > directorio
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> 5d1fc5bf.5a54
> > %;   %;  0 LOG:  el registro del punto de control primario no es
> válido
> > 2019-07-05 18:48:47.868 ART %;  %;  %;  0 %;   %;  23124 %;
> 5d1fc5bf.5a54
> > %;   %;  58P01 LOG:  no se pudo abrir «pg_xlog/000206DA00AC»
> > (archivo de registro 1754, segmento 172): No existe el fichero o el
> > directorio
>
> > El archivo 000206DA00AC si está en el directorio de
> > recuperación: /usr/local/pgsql/BK20190705/
>
> OK, pero no es ahí donde lo está buscando.  ¿qué dice tu recovery.conf?
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: Instalacion desatendida de Postgres

[Alvaro Herrera]

Hi Haroon,

Haroon escribió:

> > Ok voy a probar el instalador de 2ndquadrant pero creo que seria
> > mucho mas interesante usando el instalador de 2UDA hay algun manual
> > de como instalar 2UDA de manera desatendida para instalar en modo
> > text como parametros en el instalador para windows?
> 
> I understand that you are willing to give Postgres Installer a try and
> are also interested in 2UDA, however, that is all I could understand
> from the email conversation using translate feature from Spanish to
> English. From the email subject, I understand that the original
> question is related to unattended install.
> 
> Jaime, when you get the chance, could you please translate the
> question for me in English so that I could understand it better and
> help accordingly ? Thanks!

The question that opened the thread was whether the EDB installer will
continue to support unattended installation -- José is concerned because
apparently they removed the option from their manual.

Then Jaime suggests trying out 2ndQ's pginstaller.  To which José
responds that he is much more interested in the 2UDA installer, and asks
whether that one supports unattended (scripted) installation using a
command line of some sort.  As far as I understand, he wants to embed
Postgres in some larger product.  (I suppose it's fair to answer whether
2UDA license permits this, also).

José wished you all a great father day to you, too (a month ago, so
you're a little late but that's okay).

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: problema al intentar recuperar PITR

[Alvaro Herrera]

Guillermo E. Villanueva escribió:
> Gracias por tu respuesta Alvaro,
> recovery.con tiene:
> restore_command = '/usr/local/pgsql/BK20190705/%f %p'
> 
> Les cuento que pude resolverlo de una manera no muy convincente, antes del
> start copié todos los archivos wal de respaldo al directorio pg_xlog y
> arrancó bien, pero... pero... y el restore_command? por qué no funcionó?

Si el archivo realmente se llama recovery.con, eso lo explicaría, porque
el servidor sólo busca un archivo recovery.conf.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: problema al intentar recuperar PITR

[Guillermo E. Villanueva]

no no perdón fue un error de tipeo en el mensaje, el nombre es correcto, se
llama recovery.conf

El mar., 9 jul. 2019 a las 13:02, Alvaro Herrera ()
escribió:

> Guillermo E. Villanueva escribió:
> > Gracias por tu respuesta Alvaro,
> > recovery.con tiene:
> > restore_command = '/usr/local/pgsql/BK20190705/%f %p'
> >
> > Les cuento que pude resolverlo de una manera no muy convincente, antes
> del
> > start copié todos los archivos wal de respaldo al directorio pg_xlog y
> > arrancó bien, pero... pero... y el restore_command? por qué no funcionó?
>
> Si el archivo realmente se llama recovery.con, eso lo explicaría, porque
> el servidor sólo busca un archivo recovery.conf.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: problema al intentar recuperar PITR

[Daymel Bonne]

Buenas:

El mar., 9 de jul. de 2019 a la(s) 11:02, Alvaro Herrera (
alvhe...@2ndquadrant.com) escribió:

> Guillermo E. Villanueva escribió:
> > Gracias por tu respuesta Alvaro,
> > recovery.con tiene:
> > restore_command = '/usr/local/pgsql/BK20190705/%f %p'
>

No te falta el cp? o sea debería ser:

restore_command = 'cp /usr/local/pgsql/BK20190705/%f %p'

Saludos

Re: Instalacion desatendida de Postgres

[Haroon]

Hi,

On Tue, 9 Jul 2019 at 20:59, Alvaro Herrera 
wrote:
>
> Hi Haroon,
>
> Haroon escribió:
>
> > > Ok voy a probar el instalador de 2ndquadrant pero creo que seria
> > > mucho mas interesante usando el instalador de 2UDA hay algun manual
> > > de como instalar 2UDA de manera desatendida para instalar en modo
> > > text como parametros en el instalador para windows?
> >
> > I understand that you are willing to give Postgres Installer a try and
> > are also interested in 2UDA, however, that is all I could understand
> > from the email conversation using translate feature from Spanish to
> > English. From the email subject, I understand that the original
> > question is related to unattended install.
> >
> > Jaime, when you get the chance, could you please translate the
> > question for me in English so that I could understand it better and
> > help accordingly ? Thanks!
>
> The question that opened the thread was whether the EDB installer will
> continue to support unattended installation -- José is concerned because
> apparently they removed the option from their manual.
>
> Then Jaime suggests trying out 2ndQ's pginstaller.  To which José
> responds that he is much more interested in the 2UDA installer, and asks
> whether that one supports unattended (scripted) installation using a
> command line of some sort.

Thank you Alvaro for kindly helping with the translation :)

Yes, both 2UDA  and 2ndQ's
Postgres Installer

support unattended mode on Windows, macOS and Linux platforms. An example
of unattended installation command on Windows would look like:

*PostgreSQL-10.9-1-windows-installer.exe --mode unattended
--unattendedmodeui none --data_dir C:\ProgramData\postgresql\10\data
--pg_port 5432 --pg_password  --superuser_password
*

That said, IIUC, José seemed interested in PG 12 Beta as well and therefore
I would like to mention that while 2ndQ's Postgres Installer is available
for PG12 Beta, 2UDA is not yet available for PG12. We are working on 2UDA
release for PG 12 and it will hopefully be available some time later.

>  As far as I understand, he wants to embed
> Postgres in some larger product.  (I suppose it's fair to answer whether
> 2UDA license permits this, also).

I will need to get back on this after discussing this internally.

>
> José wished you all a great father day to you, too (a month ago, so
> you're a little late but that's okay).

:)

Thanks!
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Regards,
-- 
Haroonhttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services