Re: List all columns referencing an FK

On 2/8/18 05:31, Andreas Joseph Krogh wrote: > Back in 2008 I asked this > question:  > http://www.postgresql-archive.org/Finding-all-tables-that-have-foreign-keys-referencing-a-table-td2153236.html > I wonder, is this now possible using information_schema only, or are > there still pieces 

Re: algo for canceling a deadlocked transaction

> On Apr 9, 2018, at 07:33, Thomas Poty wrote: > > ok, and long answer ? is it random? It's not literally random, but from the application point of view, it's not predictable. For example, it's not always the one that opened first, or any other consistent measure. --

Re: best way to write large data-streams quickly?

> On Apr 9, 2018, at 8:49 AM, Mark Moellering > wrote: > > Everyone, > > We are trying to architect a new system, which will have to take several > large datastreams (total of ~200,000 parsed files per second) and place them > in a database. I am trying to

Re: algo for canceling a deadlocked transaction

Christophe Pettus writes: >> On Apr 9, 2018, at 07:33, Thomas Poty wrote: >> ok, and long answer ? is it random? > It's not literally random, but from the application point of view, it's not > predictable. For example, it's not always the one that

best way to write large data-streams quickly?

Everyone, We are trying to architect a new system, which will have to take several large datastreams (total of ~200,000 parsed files per second) and place them in a database. I am trying to figure out the best way to import that sort of data into Postgres. I keep thinking i can't be the first

Re: How to monitor logical replication initial sync?

On 3/15/18 09:19, bricklen wrote: > How does one monitor the status or progress of an initial sync under > logical replication?  For example: > > * I create a publication in database db_pub > * I create a subscription in database db_sub > * In 15 minutes I want to check an see

Re: Conflict between JSON_AGG and COPY

On 04/08/2018 08:44 PM, Đỗ Ngọc Trí Cường wrote: Dear Arian Klaver, I think there is a misunderstood here. I think that I quite understand how is the second query run. The question I asked here is why exporting data, which is generated by a query "JSON_AGG" , with command "COPY". The data

Re: Conflict between JSON_AGG and COPY

Đỗ Ngọc Trí Cường wrote: > I want to export it to a file in JSON format so I run the query as below: > COPY (SELECT...) TO '/home/postgres/test1.json' COPY TO applies its own format rules on top of the data, which include among other things, quoting the newline characters. What you seem

Carto ODBC_FDW issue "ERROR: Connecting to driver" from PG to DB2

Hi Guru's, I am trying to access few table present in DB2 LUW from postgres database. All commands work fine, however when I try to select data from table it throws error: pg@a92a3741d40e:~/odbc_fdw$ psql -d postgres psql (10.1) Type "help" for help. postgres=# create extension odbc_fdw; CREATE

Fwd: Carto ODBC_FDW issue "ERROR: Connecting to driver" from PG to DB2

On 04/09/2018 01:01 PM, karthik kumar wrote: > Hi Guru's, > > I am trying to access few table present in DB2 LUW from postgres database. > All commands work fine, however when I try to select data from table it > throws error: > > pg@a92a3741d40e:~/odbc_fdw$ psql -d postgres > psql (10.1) > Type

Re: Fwd: Carto ODBC_FDW issue "ERROR: Connecting to driver" from PG to DB2

On 04/09/2018 02:10 PM, karthik kumar wrote: On 04/09/2018 01:01 PM, karthik kumar wrote: Hi Guru's, I am trying to access few table present in DB2 LUW from postgres database. All commands work fine, however when I try to select data from table it throws error:

Re: ERROR: found multixact from before relminmxid

On Mon, Apr 9, 2018 at 7:01 AM, Tomas Vondra wrote: > The bigger question is whether this can actually detect the issue. If > it's due to an storage issue, then perhaps yes. But if you only see > multixact issues consistently and nothing else, it might easily be a >

Re: Rationale for aversion to the central database?

Peter J. Holzer writes: > In my applications I use SQL heavily. RDBMs are good at processing > queries, so use them for that. If all you want is a key-value store, > don't use PostgreSQL. I'm not very fond of ORMs. I know what I want to > do and can express it in SQL. An ORM

Re: Fwd: Carto ODBC_FDW issue "ERROR: Connecting to driver" from PG to DB2

On 04/09/2018 02:37 PM, karthik kumar wrote: On Mon, Apr 9, 2018 at 5:13 PM, Adrian Klaver > wrote: On 04/09/2018 02:10 PM, karthik kumar wrote: Assuming using this: https://github.com/ZhengYang/odbc_fdw

Re: Fwd: Carto ODBC_FDW issue "ERROR: Connecting to driver" from PG to DB2

On 04/09/2018 04:52 PM, Adrian Klaver wrote: On 04/09/2018 02:37 PM, karthik kumar wrote: On Mon, Apr 9, 2018 at 5:13 PM, Adrian Klaver > wrote:     On 04/09/2018 02:10 PM, karthik kumar wrote:     Assuming using this:    

Re: ERROR: found multixact from before relminmxid

2018-04-09 18:23 GMT-03:00 Peter Geoghegan : > > On Mon, Apr 9, 2018 at 7:01 AM, Tomas Vondra > wrote: > > The bigger question is whether this can actually detect the issue. If > > it's due to an storage issue, then perhaps yes. But if you only see > >

Re: Fwd: Carto ODBC_FDW issue "ERROR: Connecting to driver" from PG to DB2

On Mon, Apr 9, 2018 at 7:52 PM, Adrian Klaver wrote: > On 04/09/2018 02:37 PM, karthik kumar wrote: > >> >> >> On Mon, Apr 9, 2018 at 5:13 PM, Adrian Klaver > > wrote: >> >> On 04/09/2018 02:10 PM,

Re: ERROR: found multixact from before relminmxid

On Mon, Apr 9, 2018 at 5:55 PM, Alexandre Arruda wrote: > I ran amcheck in all index of a table and I only get empty returns. Did you try doing so with the "heapallindexed" option? That's what's really interesting here. -- Peter Geoghegan

Re: ERROR: found multixact from before relminmxid

On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda wrote: > (... and all other indexes returns null too) > > I tried with bt_index_check too. Same results. That's interesting, because it tells me that you have a table that appears to not be corrupt, despite the CLUSTER error.

Re: ERROR: found multixact from before relminmxid

On April 9, 2018 7:51:19 PM PDT, Peter Geoghegan wrote: >On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda >wrote: >> (... and all other indexes returns null too) >> >> I tried with bt_index_check too. Same results. > >That's interesting, because it tells me

Re: algo for canceling a deadlocked transaction

Hello Tom, Thank you for the clarification! Regards, Thomas Le lun. 9 avr. 2018 à 17:04, Tom Lane a écrit : > Christophe Pettus writes: > >> On Apr 9, 2018, at 07:33, Thomas Poty wrote: > >> ok, and long answer ? is it random?

Re: Conflict between JSON_AGG and COPY

On Mon, Apr 9, 2018 at 7:14 AM, Adrian Klaver wrote: > On 04/08/2018 08:44 PM, Đỗ Ngọc Trí Cường wrote: > > Presently, COPY TO will never emit an octal or hex-digits backslash > sequence, but it does use the other sequences listed above for those > control characters.

Re: algo for canceling a deadlocked transaction

Hello Stephen, > The short answer is "it's whichever one detected the deadlock." The > deadlock timeout fires after a lock has been held that long and if a > deadlock is detected then the process detecting it will be canceled. ok, and long answer ? is it random? > I'd strongly recommend

Re: Conflict between JSON_AGG and COPY

Dear Arian Klaver, I think there is a misunderstood here. I think that I quite understand how is the second query run. The question I asked here is why exporting data, which is generated by a query "JSON_AGG" , with command "COPY". The data contain "\n" as 2 characters instead of "new

pg_stat_all_tables not updated when VACUUM ANALYZE execution finishes

Hi, I face a surprising behaviour with VACUUM ANALYZE. For a table with a structure like like this (and few records): create table my_table ( my_column numeric ); When I run the following: VACUUM ANALYZE my_table; SELECT relname, last_analyze, last_vacuum FROM pg_stat_all_tables where

Re: ERROR: found multixact from before relminmxid

2018-04-06 13:11 GMT-03:00 Tomas Vondra : > > > On 04/06/2018 04:29 PM, Alexandre Arruda wrote: > > 2018-04-06 9:39 GMT-03:00 Tomas Vondra > >: > > > > > > > > On 04/06/2018 02:09 AM, Alexandre

Re: ERROR: found multixact from before relminmxid

On 04/09/2018 01:49 PM, Alexandre Arruda wrote: > > > 2018-04-06 13:11 GMT-03:00 Tomas Vondra >: > > > > On 04/06/2018 04:29 PM, Alexandre Arruda wrote: > > 2018-04-06 9:39 GMT-03:00 Tomas Vondra

Re: Rationale for aversion to the central database?

On 2018-04-08 19:39:43 -0400, Stephen Frost wrote: > * Alvaro Aguayo Garcia-Rada (aagu...@opensysperu.com) wrote: > > 1. Portability. Being tied to a single database engine is not always > > a good idea. When you write business logic in database, you have to > > write and maintain your store

Re: Conflict between JSON_AGG and COPY

On 04/08/2018 08:44 PM, Đỗ Ngọc Trí Cường wrote: Dear Arian Klaver, I think there is a misunderstood here. I think that I quite understand how is the second query run. The question I asked here is why exporting data, which is generated by a query "JSON_AGG" , with command "COPY". The data

Re: pg_stat_all_tables not updated when VACUUM ANALYZE execution finishes

On 04/09/2018 03:37 AM, Sebastien Arod wrote: Hi, I face a surprising behaviour with VACUUM ANALYZE. For a table with a structure like like this (and few records): create table my_table (     my_column numeric ); When I run the following: VACUUM ANALYZE my_table; SELECT relname,

Re: Rationale for aversion to the central database?

On 2018-04-08 14:39:49 -0700, Guyren Howe wrote: > I am a Rails developer at a medium-large size company. I’ve mostly worked at > smaller companies. I’ve some exposure to other web development communities. > > When it comes to databases, I have universally encountered the attitude that > one

Re: Rationale for aversion to the central database?

Maintaining your database logic in version control and versioning the deployed code can be a bit problematic. Conversely, providing a standardized pgsql module through which data is updated and retrieved can help standardize access logic across multiple languages and libraries. And I concur that

algo for canceling a deadlocked transaction

Good afternoon, My question is : In case of a deadlock between 2 transaction, how to know which transaction will be canceled? Is it predictable? I have tried to look into sources but i have found nothing. ( probably, i am the problem) Regards, Thomas

Re: algo for canceling a deadlocked transaction

Greetings, * Thomas Poty (thomas.p...@gmail.com) wrote: > My question is : In case of a deadlock between 2 transaction, how to know > which transaction will be canceled? Is it predictable? The short answer is "it's whichever one detected the deadlock." The deadlock timeout fires after a lock

Re: Rationale for aversion to the central database?

On Mon, Apr 9, 2018 at 9:45 AM, Ray Cote wrote: > Maintaining your database logic in version control and versioning the > deployed code can be a bit problematic. > > Conversely, providing a standardized pgsql module through which data is > updated and retrieved