Alvaro Herrera 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 it.
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 won
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 b/con
On Mon, Dec 26, 2011 at 18:01, Alexander Björnhagen
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 argue either
>
On Mon, Dec 26, 2011 at 5:18 PM, Guillaume Lelarge
wrote:
> On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
>> On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
>> wrote:
>> Basically I like this whole idea, but I'd like to know why do you think
>> this functionality is req
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 si
On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
> On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
> 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 situa
On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
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 this i
Magnus Hagander 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 set, isn't it?
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
> > 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
On Mon, Dec 26, 2011 at 13:51, Alexander Björnhagen
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 move most of the logic
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 5:08 AM, Alexander Björnhagen
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 this functionality is requi
14 matches
Mail list logo