2009/4/7 Tom Lane :
> I wrote:
>> Bruce suggested what seemed like an excellent idea, which is to make
>> this self-documenting using the new default-arguments feature ---
>> it'll look something like this in \df:
>
>> List of functions
>> Schema | Name | Result data t
Alvaro Herrera writes:
> Tom Lane wrote:
>> The only alternative that comes to mind is
>> to have initdb issue an additional SQL command to establish the default
>> after the bootstrap phase; that is, something like
>>
>> CREATE OR REPLACE FUNCTION
>> pg_start_backup(label text, fast boolean DEFA
Tom Lane wrote:
> The only alternative that comes to mind is
> to have initdb issue an additional SQL command to establish the default
> after the bootstrap phase; that is, something like
>
> CREATE OR REPLACE FUNCTION
> pg_start_backup(label text, fast boolean DEFAULT false)
> RETURNS text L
I wrote:
> Bruce suggested what seemed like an excellent idea, which is to make
> this self-documenting using the new default-arguments feature ---
> it'll look something like this in \df:
> List of functions
> Schema | Name | Result data type | Argument data
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I'm going to go ahead and make this happen, using the arrangement
>>
>> pg_start_backup('label') -> slow checkpoint (backwards compatible)
>> pg_start_backup('label', false) -> slow checkpoint
>> pg_start_backup('label', true) -> immediate checkpoin
Tom Lane wrote:
> I'm going to go ahead and make this happen, using the arrangement
>
> pg_start_backup('label') -> slow checkpoint (backwards compatible)
> pg_start_backup('label', false) -> slow checkpoint
> pg_start_backup('label', true) -> immediate checkpoint
Probably a dumb question, but
I wrote:
> Heikki Linnakangas writes:
>> Rather than deplore that you can't expedite the checkpoint, why don't we
>> just make it possible?
> +1
>> The first question is what the default behavior should be? We've seen
>> enough complaints and I've been bitten by that myself during development
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The solution Heikki is proposing is to let the user choose immediate
>> or slow checkpoint. I agree that there's not much point in the latter
>> if you are using something dumb like tar to take the filesystem backup,
>> but maybe the user has someth
Tom Lane wrote:
Bruce Momjian writes:
There was talk about making pg_start_backup do an immediate checkpoint
but there was some discussion that you wouldn't want an I/O storm from
pg_start_backup(). However, figuring you are going to do the tar backup
anyway, the pg_start_backup I/O seems triv
Bruce Momjian writes:
> Tom Lane wrote:
>> Still, I don't much like this solution. I agree with Heikki:
>> let's just fix it.
> Agreed, fixing it is better than trying to document/report odd behavior.
> There was talk about making pg_start_backup do an immediate checkpoint
> but there was some
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> + ereport(NOTICE,
> >> + (errmsg("performing checkpoint")));
>
> > You've *got* to be kidding.
>
> Sigh. I have to apologize for that over-hasty complaint: I misread
> where you intended to put the messa
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> + ereport(NOTICE,
> >> + (errmsg("performing checkpoint")));
>
> > You've *got* to be kidding.
>
> Sigh. I have to apologize for that over-hasty complaint: I misread
> where you intended to put the messa
--On Freitag, April 03, 2009 08:30:14 +0300 Heikki Linnakangas
wrote:
The first looks nicer, IMHO, because the word 'lazy' makes it
self-documenting. In the second form, you have to look at the manual to
figure out what the 2nd argument does.
Regarding that many catalog functions are already
Heikki Linnakangas writes:
> Rather than deplore that you can't expedite the checkpoint, why don't we
> just make it possible?
+1
> The first question is what the default behavior should be? We've seen
> enough complaints and I've been bitten by that myself during development
> of other stuff
I wrote:
> Bruce Momjian writes:
>> +ereport(NOTICE,
>> +(errmsg("performing checkpoint")));
> You've *got* to be kidding.
Sigh. I have to apologize for that over-hasty complaint: I misread
where you intended to put the message. (Seems like there is too
Bruce Momjian wrote:
Michael Renner wrote:
+ processing. Unfortunately it's currently not possible to expedite
+ the checkpointing done by pg_start_backup.
I have combined the above patch with another change that reports a
checkpoint is taking place:
test=> se
Bruce Momjian writes:
> + ereport(NOTICE,
> + (errmsg("performing checkpoint")));
You've *got* to be kidding.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Michael Renner wrote:
> Hi,
>
> small patch for the documentation describing the current pg_start_backup
> checkpoint behavior as per
> http://archives.postgresql.org//pgsql-general/2008-09/msg01124.php .
>
> Should we note down a TODO to revisit the current checkpoint handling?
>
> best regar
Hi,
small patch for the documentation describing the current pg_start_backup
checkpoint behavior as per
http://archives.postgresql.org//pgsql-general/2008-09/msg01124.php .
Should we note down a TODO to revisit the current checkpoint handling?
best regards,
Michael
diff --git a/doc/src/sgml/
19 matches
Mail list logo
