On May 19, 2008, at 6:53 PM, Tom Lane wrote:
Another response I've heard is but I don't want to make
inside-the-database changes, I want to propagate the state to
someplace
external. Of course that's completely broken too, because there is
*absolutely no way* you will ever make such
On Mon, 2008-05-19 at 21:53 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I wish someone
would add an entry to the FAQ about it, or add it to the TODO list's
Hi, Thanks for the reply...When you are saying that I need to install 32 bit version of Libraries, are you referring to the libraries that are specified in the error message, I infact searched for the libraries and got it installed but some of the libraries are not available for SUSE Linux, if you
Hello All,
I am trying to install PostgreSQL(postgresql-8.2.4-1PGDG.i686.rpm) on
a 64 bit machine, when I try to install I get the following error
message:
:/home/dump/postgres32bit # rpm -ivh
postgresql-server-8.2.4-1PGDG.i686.rpm
postgresql-8.2.4-1PGDG.i686.rpm
Greg Smith wrote
On Fri, 16 May 2008, Josh Berkus wrote:
For a hard-core benchmark, I'd try EAStress (SpecJAppserver Lite)
This reminds me...Jignesh had some interesting EAStress results at the
East conference I was curious to try and replicate more publicly one day.
Now that there
Dear Tom,
trigger on prepare, commit, rollback, savepoint,
I'm sure I've ranted on this several times before, but a quick archive
search doesn't find anything. So, here are a few points to chew on:
I agree that not all of them may make sense, but some may do, and I do not
know which of
Hi,
Within exec_prepare_plan there are calls to exec_eval_datum to identify the
argtypes of the involved parameters. However exec_eval_datum actually fills
up value, isnull entries in these cases causing unnecessary additional calls
when all we need is the datum type. Such unnecessary evaluation
On Tue, May 20, 2008 at 06:38:17AM +0100, James Mansion wrote:
Tom Lane wrote:
Another response I've heard is but I don't want to make
inside-the-database changes, I want to propagate the state to someplace
external. Of course that's completely broken too, because there is
Some
things are
On Tue, 2008-05-20 at 12:09 +0200, Fabien COELHO wrote:
As for replication, I was naively thinking of using BEFORE PREPARE to
forward a prepare and possibly fail in the master if the slave fails, and
then an AFTER PREPARE or BEFORE COMMIT/ROLLBACK PREPARE would forward the
final
On Wed, 2008-05-14 at 23:29 +0300, Marko Kreen wrote:
There are few code beautification ideas on which I'd like to
get feedback from wider audience:
- Drop CONNECT statement. This was added to make creating
simple dblink style calls easier, but actually its not
maintainable compared
I'm not claiming this is easy, on the contrary, but ISTM that the 2PC
semantics is all what is fundamentaly needed to achieve synchroneous
replication
There are probably easier solutions for achieving this, like using two
connections at client level
Sure, but that means doing the
On Tue, 2008-05-20 at 13:36 +0200, Fabien COELHO wrote:
or running data modifications through pl/proxy functions where
partitioning function always returns two partitions
I don't think that pl/proxy takes care of 2PC semantics in any useful way.
Possibly something like pgpool could
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I wish someone
would add an entry to the FAQ about it, or add it to the TODO list's
Features we don't want section.
OK, remind me
Hi,
On Mon, 2008-05-19 at 17:10 +0530, cinu wrote:
This installation is being done on SUSE linux 10
This is not a list for PostgreSQL installation issues, please use
-general or -admin.
...and those packages are *not* for SuSE.
Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication,
On Tue, 20 May 2008, Hannu Krosing wrote:
Tell others that this trx failed, maybe log a failure ? OTOH, this can
be implemented by a daemon that sits on tail -f logfile | grep
ROLLBACK
In order to follow the log files like that successfully in many
environments, you need to stay in sync as
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place. There
are basically two reasons for this:
*) preserve initial formatting, etc.
Database functions when viewed with \df+ in psql appear nice and clean
as I wrote them.
On Tue, May 20, 2008 at 01:20:48PM -0400, Greg Smith wrote:
On Tue, 20 May 2008, Hannu Krosing wrote:
Tell others that this trx failed, maybe log a failure ? OTOH, this can
be implemented by a daemon that sits on tail -f logfile | grep
ROLLBACK
In order to follow the log files like that
On Tue, May 20, 2008 at 02:03:17PM -0400, Merlin Moncure wrote:
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place.
There are basically two reasons for this:
+1 for DDL in general, including the original CREATE and
Merlin Moncure [EMAIL PROTECTED] writes:
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place.
No, there isn't.
As counterexamples look at pg_constraint.consrc and pg_attrdef.adsrc,
both of which were mistakes from the
David Fetter wrote:
On Tue, May 20, 2008 at 02:03:17PM -0400, Merlin Moncure wrote:
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place.
There are basically two reasons for this:
+1 for DDL in general, including the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
trigger on prepare, commit, rollback, savepoint,
This is a sufficiently frequently asked question that I
wish someone
would add an entry to the FAQ about it, or add it to the
TODO list's
Features we don't want section.
21 matches
Mail list logo
