Re: [GENERAL] BDR: DDL lock problem with function inside a schema

> > Questions: > --- > -Is it a known bug? If yes should I report it (and where)? > Please open a report on github for this - https://github.com/2ndQuadrant/bdr/issues > -How to recover such DDL lock problems operation without recreating the > database? In other words, what is the pr

Re: [GENERAL] Momentary Delay

On Mon, 8 Jun 2015 11:59:31 -0300 Anderson Valadares wrote: > Hi > We are experiencing an intermittent problem in a GIS database from a > client. Some times of the day is as if the PostgreSQL executed the slowest > operations see below an example. The query was performed three times, twice > I c

Re: [GENERAL] Postgresql BDR Replication Setup Issue

Hi On 15/06/09 2:31, Ravi Tammineni wrote: > We are setting up 2-node Postgresql BDR replication at our place and I am > getting > the following error after bdr_init_copy command. (...) > > Could not update security label: ERROR: cannot execute DELETE in a read-only > transaction (...) > >

Re: [GENERAL] Joins between foreign tables

Hi Geoff, Thanks for your swift reply. Breaking the query up like this would seem to address the problem: CREATE UNLOGGED TABLE tmp ASSELECT * FROM table_on_server2 WHERE created_at >= date_trunc('day', now()); SELECT email FROM table_on_server1 WHERE id IN (SELECT user_id FROM tmp); It would s

Re: [GENERAL] Momentary Delay

2015-06-08 13:58 GMT-03:00 Adrian Klaver : > On 06/08/2015 09:25 AM, Anderson Valadares wrote: > >> 2015-06-08 12:30 GMT-03:00 Adrian Klaver > >: >> >> > >> >> >> Adrian >> forgiveness for my english the meant "Exists a job run every 2 seconds >> capturing infor

[GENERAL] BDR: DDL lock problem with function inside a schema

Hello All, I am doing some tests with BDR to study the ability of replacing bucardo with BDR. I experience some DDL locks problem when a function is in a schema, and I try to remove the whole schema. Node 1: --- mydb=# CREATE SCHEMA IF NOT EXISTS test; mydb=# CREATE OR REPLACE FUNC

[GENERAL] Postgresql BDR Replication Setup Issue

Hi, We are setting up 2-node Postgresql BDR replication at our place and I am getting the following error after bdr_init_copy command. FYI, We have a production Postgres database and we are setting up the Master-Master BDR replication for the production database. Postgres Version Postgres

Re: [GENERAL] Joins between foreign tables

On Mon, Jun 8, 2015 at 10:29 AM, Jason Dusek wrote: > The databases involved are all Postgres 9.4 or 9.3. The FDW is the Postgres > FDW. > > The join node (the one from which queries are issued) is Postgres 9.4 > installed yesterday from the Postgres Apt repository. It's using the version > of the

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Robert Haas wrote: > On Mon, Jun 8, 2015 at 1:23 PM, Alvaro Herrera > wrote: > > (My personal alarm bells go off when I see autovac_naptime=15min or > > more, but apparently not everybody sees things that way.) > > Uh, I'd echo that sentiment if you did s/15min/1min/ Yeah, well, that too I gue

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On 2015-06-08 14:23:32 -0300, Alvaro Herrera wrote: > Sure. I just concern that we might be putting excessive trust on > emergency workers being launched at a high pace. I'm not sure what to do about that. I mean, it'd not be hard to simply ignore naptime upon wraparound, but I'm not sure that'd

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Mon, Jun 8, 2015 at 1:23 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera >> wrote: >> >I might be misreading the code, but PMSIGNAL_START_AUTOVAC_LAUNCHER >> >only causes things to happen (i.e. a new worker to be started) when >> >autov

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Andres Freund wrote: > On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera > wrote: > >I might be misreading the code, but PMSIGNAL_START_AUTOVAC_LAUNCHER > >only causes things to happen (i.e. a new worker to be started) when > >autovacuum is disabled. If autovacuum is enabled, postmaster > >r

[GENERAL] Inserting from multiple processes?

I'm using Postgres 8.4 on RHEL 6 and I need to support inserting data into a table from multiple processes with there occasionally being duplicates from the different processes. Here's a simple example table: CREATE TABLE test (tutc TIMESTAMP WITHOUT TIME ZONE, id INTEGER, value INTEGER, PRIMARY KE

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera wrote: >Andres Freund wrote: > >> A first version to address this problem can be found appended to this >> email. >> >> Basically it does: >> * Whenever more than MULTIXACT_MEMBER_SAFE_THRESHOLD are used, signal >> autovacuum once per member

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Andres Freund wrote: > A first version to address this problem can be found appended to this > email. > > Basically it does: > * Whenever more than MULTIXACT_MEMBER_SAFE_THRESHOLD are used, signal > autovacuum once per members segment > * For both members and offsets, once hitting the hard limi

Re: [GENERAL] BDR - Failure of Primary Server - How to recover?

I understand removing the BDR node with bdr.bdr_part_by_node_names (). But if I need create another BDR node what would I reference for the join_using_dsn string on the new node, if the primary doen't exist any more? Thanks! Carter -- View this message in context: http://postgresql.nabble.co

Re: [GENERAL] Momentary Delay

On 06/08/2015 09:25 AM, Anderson Valadares wrote: 2015-06-08 12:30 GMT-03:00 Adrian Klaver mailto:adrian.kla...@aklaver.com>>: Adrian forgiveness for my english the meant "Exists a job run every 2 seconds capturing information of locks, long running queries, etc." So have you looked at

[GENERAL] Joins between foreign tables

Dear Postgres, Consider a query like: SELECT table_on_server1.email FROM table_on_server1 JOIN table_on_server2 ON (table_on_server1.id = table_on_server2.user_id) WHERE table_on_server2.created_at >= date_trunc('day', now()) One could imagine the plan being something like: 1. Fin

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On 2015-06-08 15:15:04 +0200, Andres Freund wrote: > 1) the autovacuum trigger logic isn't perfect yet. I.e. especially with > autovacuum=off you can get into situations where emergency vacuums > aren't started when necessary. This is particularly likely to happen > if either very large multi

Re: [GENERAL] Momentary Delay

2015-06-08 12:30 GMT-03:00 Adrian Klaver : > On 06/08/2015 07:59 AM, Anderson Valadares wrote: > >> Hi >> We are experiencing an intermittent problem in a GIS database from a >> client. Some times of the day is as if the PostgreSQL executed the >> slowest operations see below an example. The que

Re: [GENERAL] Momentary Delay

On 06/08/2015 07:59 AM, Anderson Valadares wrote: Hi We are experiencing an intermittent problem in a GIS database from a client. Some times of the day is as if the PostgreSQL executed the slowest operations see below an example. The query was performed three times, twice I canceled and the thi

[GENERAL] Momentary Delay

Hi We are experiencing an intermittent problem in a GIS database from a client. Some times of the day is as if the PostgreSQL executed the slowest operations see below an example. The query was performed three times, twice I canceled and the third time I left it to end. The consultation took 10 se

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

otheus uibk wrote: > Just to nit-pick, I see nowhere in either version of the manual the > indication that it is normal for > postgresql to continue to update files in its data catalog between > pg_start_backup and pg_stop_backup. > The closest I see comes in this paragraph: > > ** Some file sys

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

On Mon, Jun 8, 2015 at 9:26 AM, otheus uibk wrote: > On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk wrote: > >> Thank you, all. The manual for 9.4 is indeed clearer on this point than >> the 9.1 version. >> > > Just to nit-pick, I see nowhere in either version of the manual the > indication that i

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

On 06/08/2015 06:26 AM, otheus uibk wrote: On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk mailto:otheus.u...@gmail.com>> wrote: Thank you, all. The manual for 9.4 is indeed clearer on this point than the 9.1 version. Just to nit-pick, I see nowhere in either version of the manual the ind

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

On 06/08/2015 05:45 AM, otheus uibk wrote: The manual and in this mailing list, the claim is made that consistent, file-level backups may be made by bracketing the file-copy operation with the postgresql pg_start_backup and pg_stop_backup operations. Many people including myself have found that

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk wrote: > Thank you, all. The manual for 9.4 is indeed clearer on this point than > the 9.1 version. > Just to nit-pick, I see nowhere in either version of the manual the indication that it is normal for postgresql to continue to update files in its da

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On 2015-06-05 16:56:18 -0400, Tom Lane wrote: > Andres Freund writes: > > On June 5, 2015 10:02:37 PM GMT+02:00, Robert Haas > > wrote: > >> I think we would be foolish to rush that part into the tree. We > >> probably got here in the first place by rushing the last round of > >> fixes too much

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

Thank you, all. The manual for 9.4 is indeed clearer on this point than the 9.1 version.

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

On 06/08/15 14:45, otheus uibk wrote: The manual and in this mailing list, the claim is made that consistent, file-level backups may be made by bracketing the file-copy operation with the postgresql pg_start_backup and pg_stop_backup operations. Many people including myself have found that in so

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

Le 8 juin 2015 2:48 PM, "otheus uibk" a écrit : > > The manual and in this mailing list, the claim is made that consistent, file-level backups may be made by bracketing the file-copy operation with the postgresql pg_start_backup and pg_stop_backup operations. Many people including myself have fou

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

otheus uibk wrote: > The manual and in this mailing list, the claim is made that consistent, > file-level backups may be made > by bracketing the file-copy operation with the postgresql pg_start_backup and > pg_stop_backup > operations. Many people including myself have found that in some > cir

Re: [GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

Am 2015-06-08 14:45, schrieb otheus uibk: The manual and in this mailing list, the claim is made that consistent, file-level backups may be made by bracketing the file-copy operation with the postgresql pg_start_backup and pg_stop_backup operations.  Many people including myself have found that

[GENERAL] pg_start_backup does not actually allow for consistent, file-level backup

The manual and in this mailing list, the claim is made that consistent, file-level backups may be made by bracketing the file-copy operation with the postgresql pg_start_backup and pg_stop_backup operations. Many people including myself have found that in some circumstances, using "tar" to copy th