Prev: [HACKERS] CIText and pattern_ops
Next: pgsql: Add missing optimizer hooks for functioncost and number of rows.
From: Fujii Masao on 23 Apr 2010 08:28
On Fri, Apr 23, 2010 at 8:54 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Fri, Apr 23, 2010 at 7:40 AM, Heikki Linnakangas
> <heikki.linnakangas(a)enterprisedb.com> wrote:
>> Ok, that brings us back to square one. We could still add the wal_mode
>> GUC to explicitly control how much WAL is written (replacing
>> recovery_connections in the primary), I think it would still make the
>> system easier to explain. But it would add an extra hurdle to enabling
>> archiving, you'd have to set wal_mode='archive', archive_mode='on', and
>> archive_command. I'm not sure if that would be better or worse than the
>> current situation.
>
> I wasn't either, that's why I gave up.  It didn't seem worth doing a
> major GUC reorganization on the eve of beta unless there was a clear
> win.  I think there may be a way to improve this but I don't think
> it's we should take the time now to figure out what it is.  Let's
> revisit it for 9.1, and just improve the error reporting for now.

+1

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
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 13:45
On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
>> <heikki.linnakangas(a)enterprisedb.com> wrote:
>>> Streaming replication needs the same information in the WAL as archiving
>>> does,
>
>> True.
>
> FWIW, I still don't believe that claim, and I think it's complete folly
> to set the assumption in stone by choosing a user-visible GUC API that
> depends on it being true.

Huh? We're clearly talking about two different things here, because
that doesn't make any sense. Archiving and streaming replication are
just two means of transporting WAL records from point A to point B.
By definition, any two manners of moving a byte stream around are
isomorphic and can't possibly affect what that byte stream does or
does not need to contain. What affects the WAL that must be emitted
is the purpose for which it is to be used. As to that, I believe
everyone (including the code) is in agreement that a minimum amount of
WAL is always needed for crash recovery, plus if we want to do archive
recovery on another server there are some additional bits that must be
emitted (XLogIsNeeded) and plus if further want to process queries on
the standby then there are a few more bits beyond that
(XLogStandbyInfoActive).

....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 14:09
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Fri, Apr 23, 2010 at 12:09 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> FWIW, I still don't believe that claim, and I think it's complete folly
>> to set the assumption in stone by choosing a user-visible GUC API that
>> depends on it being true.

> Huh? We're clearly talking about two different things here, because
> that doesn't make any sense. Archiving and streaming replication are
> just two means of transporting WAL records from point A to point B.

Sorry, not enough caffeine. What I should have said was that Hot
Standby could put stronger requirements on what gets put into WAL than
archiving for recovery does. Heikki's proposal upthread was
wal_mode='standby' versus wal_mode='archive' (versus 'off'), which
seemed sensible to me.

We realized some time ago that it was a good idea to separate
archive_mode (what to put in WAL) from archive_command (whether we are
actually archiving right now). If we fail to apply that same principle
to Hot Standby, I think we'll come to regret it.

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 14:36
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
> Tom Lane wrote:
>> We realized some time ago that it was a good idea to separate
>> archive_mode (what to put in WAL) from archive_command (whether we are
>> actually archiving right now). If we fail to apply that same principle
>> to Hot Standby, I think we'll come to regret it.

> The recovery_connections GUC does that. If you enable it, the extra
> information required for hot standby is written to the WAL, otherwise
> it's not.

No, driving it off recovery_connections is exactly NOT that. It's
confusing the transport mechanism with the desired WAL contents.
I maintain that this design is exactly isomorphic to our original PITR
GUC design wherein what got written to WAL was determined by the current
state of archive_command. We eventually realized that was a bad idea.
So is this.

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?

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: Robert Haas on 23 Apr 2010 14:40
On Fri, Apr 23, 2010 at 2:36 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
>> Tom Lane wrote:
>>> We realized some time ago that it was a good idea to separate
>>> archive_mode (what to put in WAL) from archive_command (whether we are
>>> actually archiving right now).  If we fail to apply that same principle
>>> to Hot Standby, I think we'll come to regret it.
>
>> The recovery_connections GUC does that. If you enable it, the extra
>> information required for hot standby is written to the WAL, otherwise
>> it's not.
>
> No, driving it off recovery_connections is exactly NOT that.  It's
> confusing the transport mechanism with the desired WAL contents.
> I maintain that this design is exactly isomorphic to our original PITR
> GUC design wherein what got written to WAL was determined by the current
> state of archive_command.  We eventually realized that was a bad idea.
> So is this.
>
> 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?

You're all confused about what the different GUCs actually do. Which
is probably not a good sign for their usability. But yeah, that's one
of the things that concerned me, too. If you turn off
max_wal_senders, it doesn't just make it so that no WAL senders can
connect: it actually changes what gets WAL-logged.

....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

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.