On Mon, Dec 26, 2011 at 5:08 AM, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
I’m new here so maybe someone else already has this in the works ?
No, as far as I know.
And so on ... any comments are welcome :)
Basically I like this whole idea, but I'd like to know why do you
think
Hello and thank you for your feedback I appreciate it.
Updated patch : sync-standalone-v2.patch
I am sorry to be spamming the list but I just cleaned it up a little
bit, wrote better comments and tried to move most of the logic into
syncrep.c since that's where it belongs anyway and also fixed a
On Mon, Dec 26, 2011 at 13:51, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Hello and thank you for your feedback I appreciate it.
Updated patch : sync-standalone-v2.patch
I am sorry to be spamming the list but I just cleaned it up a little
bit, wrote better comments and tried to
I don't think this is a given ... In fact, IMO if we're only two or
three fixes away from having it all nice and consistent, I think
reverting is not necessary.
Sure. It's the if part of that sentence that I'm not too sure about.
Any specific area of the code that you think is/has
Interesting discussion!
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle the situation where all
standbys have failed ?
Well, I think this is one of those cases where you could argue either
way.
Magnus Hagander mag...@hagander.net writes:
If you don't care about the absolute guarantee of data, why not just
use async replication? It's still going to replicate the data over to
the client as quickly as it can - which in the end is the same level
of guarantee that you get with this switch
On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle the situation where all
standbys have failed ?
Well, I think
On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle
Hmm,
I suppose this conversation would lend itself better to a whiteboard
or a maybe over a few beers instead of via e-mail ...
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle the situation where
On Mon, Dec 26, 2011 at 5:18 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Basically I like this whole idea, but I'd like to know why do you
On Mon, Dec 26, 2011 at 18:01, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Hmm,
I suppose this conversation would lend itself better to a whiteboard
or a maybe over a few beers instead of via e-mail ...
mmm. beer... :-)
Well, I think this is one of those cases where you could
Apparently we forgot to update the README file in contrib/. I wonder if
it's necessary to explain that within each directory you find one or
more .control file that determines what can be run ... or maybe just
mention the pg_extensions views?
What about this?
diff --git a/contrib/README
Excerpts from Volker Grabsch's message of mar dic 06 06:34:37 -0300 2011:
Dear PostgreSQL hackers,
While all xpath_*() functions seem to have been successfully
collapsed into a generic xpath() function, and xml_is_well_formed()
has been moved into the type check for the XML type, I wonder
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Apparently we forgot to update the README file in contrib/.
I wonder whether it's time to drop that file altogether ... it served a
purpose back before we integrated contrib into the SGML docs, but now
I'm not quite sure why we should bother with
14 matches
Mail list logo
