Prev: [HACKERS] CIText and pattern_ops
Next: pgsql: Add missing optimizer hooks for functioncost and number of rows.
From: "Kevin Grittner" on 23 Apr 2010 14:43
Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> As a concrete example, there is nothing logically wrong with
> driving a hot standby slave from WAL records shipped via old-style
> pg_standby. Or how about wanting to turn off recovery_connections
> temporarily, but not wanting the archived WAL to be unable to
> support HS?

As one more concrete example, we are likely to find SR beneficial if
it can feed into a warm standby, but only if we can also do
traditional WAL file archiving from the same source at the same
time. The extra logging for HS would be useless for us in any
event.

+1 for *not* tying WAL contents to the transport mechanism.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 23 Apr 2010 15:05
On Fri, Apr 23, 2010 at 2:43 PM, Kevin Grittner
<Kevin.Grittner(a)wicourts.gov> wrote:
> Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>
>> As a concrete example, there is nothing logically wrong with
>> driving a hot standby slave from WAL records shipped via old-style
>> pg_standby.  Or how about wanting to turn off recovery_connections
>> temporarily, but not wanting the archived WAL to be unable to
>> support HS?
>
> As one more concrete example, we are likely to find SR beneficial if
> it can feed into a warm standby, but only if we can also do
> traditional WAL file archiving from the same source at the same
> time.  The extra logging for HS would be useless for us in any
> event.
>
> +1 for *not* tying WAL contents to the transport mechanism.

OK. Well, it's a shame we didn't get this settled last week when I
first brought it up, but it's not too late to try to straighten it out
if we have a consensus behind changing it, which it's starting to
sound like we do.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 23 Apr 2010 15:18
On Fri, Apr 23, 2010 at 3:11 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote:
> On Fri, 2010-04-23 at 15:05 -0400, Robert Haas wrote:
>> we have a consensus behind changing it, which it's starting to
>> sound like we do.
>
> I think you misread the +1s from Masao and myself.
>
> Those confusing things are options and I want them to remain optional,
> not compressed into a potentially too simple model based upon how the
> world looks right now.

I didn't, but Heikki, Kevin and Tom seem to be on the other side, so
we at least have to consider where to go with it. We're going to need
a bunch of GUCs any way we slice it. The issue is whether there's a
way to slice it that involves fewer AND and OR operators that have to
be understood by users. I'm still unconvinced of our ability to come
up with a solid design in the time we have, but I think it would make
sense to listen to proposals people want to make. I poked some holes
in Heikki's design from this morning (which was, more or less, my
design from last week) but that doesn't mean they can't be plugged.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 23 Apr 2010 15:23
Simon Riggs <simon(a)2ndQuadrant.com> writes:
> Those confusing things are options and I want them to remain optional,
> not compressed into a potentially too simple model based upon how the
> world looks right now.

What are you arguing is too simple? What *I* think is too simple is
what we have got now, namely a GUC that controls both the availability
of replication connections and the contents of WAL.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 23 Apr 2010 15:34
Robert Haas <robertmhaas(a)gmail.com> writes:
> ... I'm still unconvinced of our ability to come
> up with a solid design in the time we have, but I think it would make
> sense to listen to proposals people want to make. I poked some holes
> in Heikki's design from this morning (which was, more or less, my
> design from last week) but that doesn't mean they can't be plugged.

The only hole I saw poked was the one about how archive_mode is used to
decide whether to start the archiver process. I think we could
reasonably deal with that by starting the archiver iff wal_mode > 'crash'.
There's no point in archiving otherwise, and the overhead of an idle
archiver is small enough that we can live with the corner cases where
you're starting an archiver you don't really need.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] CIText and pattern_ops
Next: pgsql: Add missing optimizer hooks for functioncost and number of rows.