*** src/backend/nodes/copyfuncs.c.orig 2008-06-26 18:18:19.0 -0700
--- src/backend/nodes/copyfuncs.c 2008-06-26 07:26:46.0 -0700
***
*** 2568,2573
--- 2568,2575
COPY_NODE_FIELD(query);
COPY_SCALAR_FIELD(verbose);
COPY_SCALAR_FIEL
On Thu, 2008-06-26 at 21:48 -0700, [EMAIL PROTECTED] wrote:
> *** src/backend/nodes/copyfuncs.c.orig2008-06-26 18:18:19.0
> -0700
> --- src/backend/nodes/copyfuncs.c 2008-06-26 07:26:46.0 -0700
You probably need to say a whole lot more about this patch.
I've updated
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> If only VACUUM is going to set "flexible" to off, maybe it's better to
> leave the APIs as they are and have a global that's set by VACUUM only
> (and reset in a PG_CATCH block).
Ugh. Perhaps it would be simpler to have a wrapper function HTSV() macr
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The default and minimum value for this parameter is 1, so very similar to
> existing behaviour. Expected settings would be 2-5, possibly as high as 20,
> though those are just educated guesses. So the maximum is set arbitrarily as
> 100.
Not a fan of ar
On Fri, 2008-06-27 at 15:25 +0100, Gregory Stark wrote:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > If only VACUUM is going to set "flexible" to off, maybe it's better to
> > leave the APIs as they are and have a global that's set by VACUUM only
> > (and reset in a PG_CATCH block).
>
>
On Fri, 2008-06-27 at 15:36 +0100, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > The default and minimum value for this parameter is 1, so very similar to
> > existing behaviour. Expected settings would be 2-5, possibly as high as 20,
> > though those are just educated gu
Gregory Stark wrote:
I'm also a bit concerned that *how many hint bits* isn't enough information to
determine how important it is to write out the page.
Agreed, that doesn't seem like a very good metric to me either.
Or how many *unhinted* xmin/xmax
values were found? If HTSV can hint xmin f
Hi.
It seems that this is required in order to return the righter message.
Please take into consideration. Thanks!
Regards,
Hiroshi Saito
pg8.3.3_libpq_win32_patch
Description: Binary data
CVSHEAD_libpq_win32_patch
Description: Binary data
--
Sent via pgsql-patches mailing list (pgsql-pat
Hiroshi Saito wrote:
> Hi.
>
> It seems that this is required in order to return the righter message.
> Please take into consideration. Thanks!
Thanks, applied.
//Magnus
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.post
Simon Riggs <[EMAIL PROTECTED]> writes:
> You probably need to say a whole lot more about this patch.
> I've updated the wiki with things I've learned while submitting patches.
> http://wiki.postgresql.org/wiki/Submitting_a_Patch
Anybody mind if I update that to put more emphasis on the need for
d
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > You probably need to say a whole lot more about this patch.
> > I've updated the wiki with things I've learned while submitting patches.
> > http://wiki.postgresql.org/wiki/Submitting_a_Patch
>
> Anybody mind if I update that to put mor
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Anybody mind if I update that to put more emphasis on the need for
>> documentation? As in "documentation patches are *required* if
>> your patch adds or changes user-visible behavior"?
> Sure, but I do documentation updates for non-E
That's no problem and it makes a lot of sense. I will prepare a patch
for the documentation.
-Tom Raney
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
You probably need to say a whole lot more about this patch.
I've updated the wiki with things I've learned while submitting patch
13 matches
Mail list logo
