Robert Haas wrote:
On Mon, Jun 8, 2015 at 1:23 PM, Alvaro Herrera alvhe...@2ndquadrant.com
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,
On Mon, Jun 8, 2015 at 1:23 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Andres Freund wrote:
On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I might be misreading the code, but PMSIGNAL_START_AUTOVAC_LAUNCHER
only causes things to happen (i.e. a
Andres Freund wrote:
On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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
On Mon, Jun 8, 2015 at 10:29 AM, Jason Dusek jason.du...@gmail.com 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
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
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
2015-06-08 13:58 GMT-03:00 Adrian Klaver adrian.kla...@aklaver.com:
On 06/08/2015 09:25 AM, Anderson Valadares wrote:
2015-06-08 12:30 GMT-03:00 Adrian Klaver adrian.kla...@aklaver.com
mailto:adrian.kla...@aklaver.com:
Adrian
forgiveness for my english the meant Exists a job run
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
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.
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:
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 limits,
On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera alvhe...@2ndquadrant.com
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
On 06/08/2015 09:25 AM, Anderson Valadares wrote:
2015-06-08 12:30 GMT-03:00 Adrian Klaver adrian.kla...@aklaver.com
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.
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
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 proper
On Mon, 8 Jun 2015 11:59:31 -0300
Anderson Valadares anderva...@gmail.com 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
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
(...)
==
On 2015-06-05 20:47:33 +0200, Andres Freund wrote:
On 2015-06-05 14:33:12 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
1. The problem that we might truncate an SLRU members page away when
it's in the buffers, but not drop it from the buffers, leading to a
failure
On Mon, Jun 8, 2015 at 9:26 AM, otheus uibk otheus.u...@gmail.com wrote:
On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk 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
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 system
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
Thank you, all. The manual for 9.4 is indeed clearer on this point than
the 9.1 version.
Le 8 juin 2015 2:48 PM, otheus uibk otheus.u...@gmail.com 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
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
On 2015-06-05 16:56:18 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On June 5, 2015 10:02:37 PM GMT+02:00, Robert Haas robertmh...@gmail.com
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
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
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
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
On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk 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
indication that it is normal for postgresql to continue to
On 06/08/2015 06:26 AM, otheus uibk wrote:
On Mon, Jun 8, 2015 at 3:13 PM, otheus uibk otheus.u...@gmail.com
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
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
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
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
2015-06-08 12:30 GMT-03:00 Adrian Klaver adrian.kla...@aklaver.com:
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
35 matches
Mail list logo
