hello! pgAdmins :D
I am trying to use the dblink in a trigger, however when the computer
(source) that is running the triggers are not accessible by ethernet to the
target computer, the dblink returns me an error and the trigger is not
executed as planned, it is terminated and input records in the
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Thomaz Luiz Santos
Sent: Thursday, April 25, 2013 10:22 AM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] DBLink
hello! pgAdmins :D
I am trying to use the dblink in a trigger, however when the computer
Isn't that basically what replication is supposed to do?
RobR, quite possibly revealing his ignorance about replication.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
No. Here it's the master pushing change to the slave, rather than the slave
pulling it (as you'd normally expect), hence the inner fragility of the
model. Moreover, replication is about having "exactly the same thing" in
two places, while this could be an audit log he keeps in its
historical comple
Paul Hinze writes:
> [ multiple CREATE INDEX CONCURRENTLY commands will deadlock with each other ]
Hm. I guess the reason nobody noticed this before now is that generally
the idea with CREATE INDEX CONCURRENTLY is to minimize the impact on
system load, hence you wouldn't do more than one at a ti
On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
> Paul Hinze writes:
> > [ multiple CREATE INDEX CONCURRENTLY commands will deadlock with each other
> > ]
>
> Hm. I guess the reason nobody noticed this before now is that generally
> the idea with CREATE INDEX CONCURRENTLY is to minimize the impac
Andres Freund writes:
> On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
>> Since we know that C.I.C. executes in its own transaction, and there
>> can't be more than one on the same table due to locking, it seems to me
>> that it'd be safe to drop our own snapshot before waiting for other
>> xacts t
Tom Lane schrieb:
>Andres Freund writes:
>> On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
>>> Since we know that C.I.C. executes in its own transaction, and there
>>> can't be more than one on the same table due to locking, it seems to
>me
>>> that it'd be safe to drop our own snapshot before
"anara...@anarazel.de" writes:
> I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY has
> a similar problem? Depends a bit on how the waiting is done...
It's not a problem --- that code doesn't depend on waiting for snapshots
to expire, it just checks for other sessions ho
How can the archive process fall behind? Postgres will never reuse WAL
files which are not yet archived.
Regarding your question about slowing down WAL generation, that is not
possible to do, unless you slow down the application which is doing the
writing into the database.
Regards,
Strahinja
On
Hello, guys.
I was getting a lot of pg_stat timeout messages from postgres and I saw
people na dpostgres doc suggesting to set this file to ram disk to reduce
IO.
But how large can this file be? I'm worried that it gets so large that it
will get all the memory.
Does anybody know?
11 matches
Mail list logo
