On Thu, Aug 13, 2009 at 1:49 PM, Josh Berkus wrote:
>
>> Yeah, that would work. Although it would probably take as much verbiage
>> to document the utility as it does to document how to do it manually.
>
> Yes, but it would *feel* less hackish to sysadmins and DBAs, and make
> them more confident
Josh Berkus wrote:
Yeah, that would work. Although it would probably take as much verbiage
to document the utility as it does to document how to do it manually.
Yes, but it would *feel* less hackish to sysadmins and DBAs, and make
them more confident about moving the xlogs.
Getting it
> Yeah, that would work. Although it would probably take as much verbiage
> to document the utility as it does to document how to do it manually.
Yes, but it would *feel* less hackish to sysadmins and DBAs, and make
them more confident about moving the xlogs.
Getting it to work on windows will
Josh Berkus writes:
>> Now admittedly it's not hard to screw yourself with a careless manual
>> move of xlog, either. But at least the database didn't hand you a knob
>> that invites clueless frobbing.
> So really rather than a GUC we should have a utility for moving the xlog.
Yeah, that would
> Now admittedly it's not hard to screw yourself with a careless manual
> move of xlog, either. But at least the database didn't hand you a knob
> that invites clueless frobbing.
So really rather than a GUC we should have a utility for moving the xlog.
--
Josh Berkus
PostgreSQL Experts Inc.
ww
Josh Berkus writes:
>> That was proposed and rejected quite a long time ago. We don't *want*
>> people to be able to "just change a GUC" and have their xlog go
>> somewhere else, because of the foot-gun potential. You need to be sure
>> that the existing WAL files get moved over when you do some
Tom,
> That was proposed and rejected quite a long time ago. We don't *want*
> people to be able to "just change a GUC" and have their xlog go
> somewhere else, because of the foot-gun potential. You need to be sure
> that the existing WAL files get moved over when you do something like
> that,
Josh Berkus writes:
> While we're at this, can we add xlog_location as a file-location GUC?
That was proposed and rejected quite a long time ago. We don't *want*
people to be able to "just change a GUC" and have their xlog go
somewhere else, because of the foot-gun potential. You need to be sur
All,
> The other reason is what I think Greg Smith was mentioning --
> simplifying the process of grabbing a usable PITR backup for novice
> users. That seems like it has merit.
While we're at this, can we add xlog_location as a file-location GUC?
It seems inconsistent that we're still requirin
Robert Haas wrote:
> *scratches head*
>
> I don't really know how you COULD pick a safe default location.
> Presumably any location that's in the default postgresql.conf file
> would be under $PGDATA, which kind of defeats the purpose of the
> whole thing. In other words, you're always going
On Tue, 11 Aug 2009, Dimitri Fontaine wrote:
We should somehow provide a default archive and restore command integrated
into the main product, so that it's as easy as turning it 'on' in the
configuration for users to have something trustworthy: PostgreSQL will keep
past logs into a pg_xlog/arc
Hi,
On Wed, Aug 12, 2009 at 6:50 AM, Robert Haas wrote:
> I don't really know how you COULD pick a safe default location.
> Presumably any location that's in the default postgresql.conf file
> would be under $PGDATA, which kind of defeats the purpose of the whole
> thing. In other words, you're a
On Tue, Aug 11, 2009 at 5:40 PM, Dimitri Fontaine wrote:
> Le 11 août 09 à 23:30, Robert Haas a écrit :
>
>> On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine
>> wrote:
>>>
>>> We should somehow provide a default archive and restore command
>>> integrated
>>> into the main product, so that it's as
On Tue, 2009-08-11 at 17:30 -0400, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine
> wrote:
> > We should somehow provide a default archive and restore command integrated
> > into the main product, so that it's as easy as turning it 'on' in the
> > configuration for users to
Le 11 août 09 à 23:30, Robert Haas a écrit :
On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine> wrote:
We should somehow provide a default archive and restore command
integrated
into the main product, so that it's as easy as turning it 'on' in the
configuration for users to have something trus
On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine wrote:
> We should somehow provide a default archive and restore command integrated
> into the main product, so that it's as easy as turning it 'on' in the
> configuration for users to have something trustworthy: PostgreSQL will keep
> past logs int
Hi,
Le 11 août 09 à 07:50, Heikki Linnakangas a écrit :
>2009/8/11 Robert Haas
> We should probably have a separate discussion about what the least
> committable unit would be for this patch. I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a
standalone
> t
Hi,
On Tue, Aug 11, 2009 at 1:25 PM, Robert Haas wrote:
> But just to kick off the discussion, here is Heikki's review of Synch
> Rep on 7/15:
>
> http://archives.postgresql.org/pgsql-hackers/2009-07/msg00913.php
>
> I think the key phrases in this review are "I believe we have
> consensus on four
Hi,
On Tue, Aug 11, 2009 at 3:33 PM, Magnus Hagander wrote:
>> We should probably have a separate discussion about what the least
>> committable unit would be for this patch. I wonder if it might be
>> sufficient to provide a facility for streaming WAL, plus a standalone
>> tool for receving it a
On Tuesday, August 11, 2009, Heikki Linnakangas
wrote:
>
>
> 2009/8/11 Robert Haas
>
> We should probably have a separate discussion about what the least
> committable unit would be for this patch. I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a standalone
>
2009/8/11 Robert Haas
> We should probably have a separate discussion about what the least
> committable unit would be for this patch. I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a standalone
> tool for receving it and storing it to a file. This might be d
On Mon, Aug 10, 2009 at 9:51 PM, Bruce Momjian wrote:
> What is the status of hot standby and synchronous replication? Is there
> a design specification? Who are the lead developers? Who is assisting?
> What open item do we have for each feature? Where is the most recent
> patch? Can we increm
What is the status of hot standby and synchronous replication? Is there
a design specification? Who are the lead developers? Who is assisting?
What open item do we have for each feature? Where is the most recent
patch? Can we incrementally start applying patches for these features?
Would some
23 matches
Mail list logo