On Fri, 2007-03-09 at 18:05 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
> >> We do that anyway; but certainly Simon's patch ought not be injecting
> >> an additional one.
>
> > It should be possible to pass that down fro
On Sat, 2007-03-10 at 07:59 +, Simon Riggs wrote:
> On Fri, 2007-03-09 at 18:05 -0500, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
> > >> We do that anyway; but certainly Simon's patch ought not be injecting
> > >> an ad
uick test using the setup for "Buffer cache is not scan resistant"
thread:
Firstly vanilla 8.3 from 20070310:
Shared Buffers Elapsed vmstat IO rate
-- --- --
400MB 101 s122 MB/s
128KB79 s155 MB/s [1]
Now apply cycle scan v2
Hello
this patch contains function ArmorCustomVariables. This function set flag
armored on any custom variable. From this moment only superuser can change
this variable.
p.s. use it together with ResetPGVariable()
Regards
Pavel Stehule
___
Joachim Wieland wrote:
> Attached is the long-awaited guc patch that makes values fall back to
> their default values when they got removed (or commented) from the
> configuration file. This has always been a source of confusion.
This patch makes, in its source code comments and error messages, ov
not scan resistant"
> thread:
>
> Firstly vanilla 8.3 from 20070310:
>
> Shared Buffers Elapsed vmstat IO rate
> -- --- --
> 400MB 101 s122 MB/s
> 128KB79 s155 MB/s [1]
>
> Now apply cy
On Sat, Mar 10, 2007 at 09:35:38PM +0100, Peter Eisentraut wrote:
> This patch makes, in its source code comments and error messages, overly
> enthusiastic references to the fact that a parameter setting was
> supposedly "commented". The only information that is really available,
> however, is
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this patch contains function ArmorCustomVariables. This function set flag
> armored on any custom variable. From this moment only superuser can change
> this variable.
Why is this a good idea? Why don't you just fix the problem as
previously agreed,
This is what I've done so far on the plan-invalidation project. This
creates a plan cache manager module and restructures things enough for
prepared statements to use it (both those generated at the SQL level
by PREPARE, and those coming from extended query protocol messages).
I haven't yet done a
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Comments?
Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> Comments?
>
> Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?
sigh, nevermind.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Comments?
> Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?
I moved those calls into ProcessUtility to avoid having to pass an extra
argument to those functions. You could call this
Fix a race condition that caused pg_database_size() and pg_tablespace_size()
to fail if an object was removed between calls to ReadDir() and stat().
Per discussion in pgsql-hackers.
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00671.php
--
Michael Fuhr
Index: src/backend/utils/adt/dbs
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this patch contains function ArmorCustomVariables. This function set
flag
> armored on any custom variable. From this moment only superuser can
change
> this variable.
Why is this a good idea? Why don't you just fix the problem as
previously agr
14 matches
Mail list logo
