Re: Logging the query executed on the server
Hi Igor, Before you issue your query, try something like this: (from psql, but hopefully you get the idea) b2bcreditonline=# set log_min_duration_statement to 0; SET b2bcreditonline=# set log_statement to 'all'; SET Ref: https://www.postgresql.org/docs/current/sql-set.html, https://www.postgresql.org/docs/current/config-setting.html Then submit your query and it will be set to the server log. You can get the name of the current logfile with: b2bcreditonline=# select pg_current_logfile(); pg_current_logfile /log/pg.csv HTH, Steve On Sun, Jul 24, 2022 at 3:26 PM Igor Korot wrote: > Hi, > Is it possible to log the query that will be executed > on the server? > > I'm writing an application that connects to the server > through ODBC and libpq. > For some reason ODBC interface is failing - it desn't > return any rows > > So I'm thinking if I have a proof that the query I am > actually executing is the same as the one I run through > the psql - I will know where to look. > > I am actually binding some parameters and trying to > execute the query. > > Thank you. > > >
Logging the query executed on the server
Hi, Is it possible to log the query that will be executed on the server? I'm writing an application that connects to the server through ODBC and libpq. For some reason ODBC interface is failing - it desn't return any rows So I'm thinking if I have a proof that the query I am actually executing is the same as the one I run through the psql - I will know where to look. I am actually binding some parameters and trying to execute the query. Thank you.
Re: 20220722-pg_dump: error: invalid number of parents 0 for table
On 7/23/22 07:54, Adrian Klaver wrote: On 7/22/22 21:27, Techsupport wrote: Thanks for your reply Adrian Klaver, Yes, I have the tablespace. It is not located in the default data directory. It is comes under new directory Please expand on this: 1) Did it change location when you moved the data directory? 2) If so where was it previously and where is it now? Where I am going with this: https://www.postgresql.org/docs/current/manage-ag-tablespaces.html "PostgreSQL makes use of symbolic links to simplify the implementation of tablespaces. This means that tablespaces can be used only on systems that support symbolic links. The directory $PGDATA/pg_tblspc contains symbolic links that point to each of the non-built-in tablespaces defined in the cluster. Although not recommended, it is possible to adjust the tablespace layout by hand by redefining these links. Under no circumstances perform this operation while the server is running. Note that in PostgreSQL 9.1 and earlier you will also need to update the pg_tablespace catalog with the new locations. (If you do not, pg_dump will continue to output the old tablespace locations.)" Thanks, Karthick Ramu -- Adrian Klaver adrian.kla...@aklaver.com
Re: 20220722-pg_dump: error: invalid number of parents 0 for table
On 7/22/22 21:27, Techsupport wrote: Thanks for your reply Adrian Klaver, Yes, I have the tablespace. It is not located in the default data directory. It is comes under new directory Please expand on this: 1) Did it change location when you moved the data directory? 2) If so where was it previously and where is it now? Thanks, Karthick Ramu -- Adrian Klaver adrian.kla...@aklaver.com
Logical replication versus pglogical on PostgreSQL 14
I'm keen to learn of the differences between logical replication in PostgreSQL 14 and how this is different from the pglogical extension. Our intended use case is to have 200-300 publishers off many small databases aggregating to 20-30 central databases on another PostgreSQL instance on the same machine. My questions are: Is native logical replication and pglogical replication fundamentally the same? Is pglogical likely to be continue to be supported? Is there a roadmap for including more pglogical functionality in native logical replication? The following pglogical management functions seem particularly useful to our use case: * pglogical.replicate_ddl_command sync publisher ddl changes with subscriber * pglogical.alter_subscription_synchronize pglogical.wait_for_subscription_sync_complete/ pglogical.wait_slot_confirm_lsn sync subscription tables * pglogical.wait_slot_confirm_lsn assess if all subscribers are up-to-date (monitoring this in native logical replication seems tricky) Thanks for any comments Rory
