Yeah. One nasty property that async multi master solutions share is
that they change the definition of what 'COMMIT' means -- the database
can't guarantee the transaction is valid because not all the
supporting facts are necessarily known. Even after libpq gives you
the green light that transa
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> course, but it is trigger based. One notable difference between
>> Bucardo and Slony is that whereas Slony's triggers store the entire
>> row data in a separate log table when something changes, Bucardo
>> stores only the primary key.
> T
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Yeah. One nasty property that async multi master solutions share is
> that they change the definition of what 'COMMIT' means -- the database
> can't guarantee the transaction is valid because not all the
> supporting facts are necessarily kno
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I only see perl-DBD-Pg 1.49 in the RHEL repos, and I don't see
> perl-ExtUtils-MakeMaker in there at all (or in EPEL or in RpmForge).
For the record, only DBD::Pg is really necessary - everything will
still work fine with an older verison o
On May 8, 2011, at 11:40 AM, Adrian Klaver wrote:
> No, PST has an offset of -8.
Head > desk. Thank you.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Sunday, May 08, 2011 10:23:44 am Christophe Pettus wrote:
> Either I am exceptionally confused, or the documentation in 8.5.3 appears
> to be wrong. Could someone clarify what I'm missing?
>
> The documentation states: "In short, this is the difference between
> abbreviations and full names: a
Either I am exceptionally confused, or the documentation in 8.5.3 appears to be
wrong. Could someone clarify what I'm missing?
The documentation states: "In short, this is the difference between
abbreviations and full names: abbreviations always represent a fixed offset
from UTC, whereas most
Clemens Eisserer writes:
> I've defined a small trigger to increment a field each time the row is
> updated:
>> CREATE TRIGGER inc_trigger BEFORE UPDATE ON Table FOR EACH ROW EXECUTE
>> PROCEDURE inc_function();
> Works quite well, however the trigger is also fired if the table
> itself is mod
Hi,
I've defined a small trigger to increment a field each time the row is updated:
> CREATE TRIGGER inc_trigger BEFORE UPDATE ON Table FOR EACH ROW EXECUTE
> PROCEDURE inc_function();
Works quite well, however the trigger is also fired if the table
itself is modified.
When deleting or insertin
On Tue, 2011-05-03 at 01:14 -0400, Tom Lane wrote:
> Craig Ringer writes:
> > This message is very weird: "could not read from file "pg_clog/02CD" at
> > offset 73728: Success".
>
> Probably indicates an attempted read from beyond EOF. The main
> relation-access code paths have been fixed to giv
10 matches
Mail list logo
