Oh, sorry, forgot to do a random table test. The test used:
DROP TABLE test;
CREATE TABLE test (x INTEGER);
INSERT INTO test SELECT random()*100 FROM generate_series(1,
100);
As expected the unpatched version is consistent for all LIMIT values
(first query was s
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If we see it as a manual test tool only, contrib is OK. But it has to be
> in the backend to be usable in the regression test suite, so thats where
> it was designed to go.
The core regression tests have depended on some contrib stuff forever,
so the abo
Neil Conway <[EMAIL PROTECTED]> writes:
>> * ResetPlanCache() is implemented as PlanCacheCallback((Datum)0,
>> InvalidOid); That seems to leave plans for utility commands untouched.
>> Is it problem?
> Yes, I'd think you'd also want to cleanup plans for utility commands.
Utility commands haven't
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> This patch makes CLUSTER MVCC-safe. Visibility information and update
>> chains are preserved like in VACUUM FULL.
> Here's an update, fixing conflict by Tom's recent commit of Simon's
> patch to skip WAL-inserts when archiving is not enabled.
A
I reran the test using:
test=> CREATE TABLE test (x INTEGER);
test=> INSERT INTO test SELECT * FROM generate_series(1, 100);
test=> SET log_min_duration_statement = 0;
and got on an unpatched system:
1751.320 ms select * from (select * from test order by x l
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >
> >
> > BTW, is anybody working on enabling the fill factor to the tables used
> > by pgbench? 8.3 will introduce HOT, and I think adding the feature
> > will make it easier to tes
Updated patch applied. Thanks.
I added a mention of the old syntax at the bottom of the CLUSTER manual
page, and cleaned up the grammar a little. Also did a little comment
cleaning in gram.y.
---
Holger Schurig wrote:
>
Patch rejected; please continue discussion and resubmit.
---
Pavel Stehule wrote:
> Hello
>
> this patch contains function ArmorCustomVariables. This function set flag
> armored on any custom variable. From this moment on
On Sat, 2007-04-07 at 14:11 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I did some performance testing of the patch, and the results were good.
> > I did this:
>
> > test=> CREATE TABLE test (x INTEGER);
> > test=> INSERT INTO test SELECT * FROM generate_series(
Simon Riggs wrote:
> On Sat, 2007-04-07 at 11:53 -0400, Bruce Momjian wrote:
>
> > This looks useful, but shouldn't it be part of /contrib/pgstattuple
> > rather than in the backend?
>
> Well, this was written with a view to it being usable for writing test
> cases that checked the various tuple
On Sat, 2007-04-07 at 11:53 -0400, Bruce Momjian wrote:
> This looks useful, but shouldn't it be part of /contrib/pgstattuple
> rather than in the backend?
Well, this was written with a view to it being usable for writing test
cases that checked the various tuple states as we went. It was
origina
On Tue, 2007-04-03 at 10:15 +0300, Marko Kreen wrote:
> New commands:
>
> CLOSE ALL -- close all cursors
> DEALLOCATE ALL -- close all prepared stmts
> RESET PLANS-- drop all plans
> RESET TEMP | TEMPORARY -- drop all temp tables
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I did some performance testing of the patch, and the results were good.
> I did this:
> test=> CREATE TABLE test (x INTEGER);
> test=> INSERT INTO test SELECT * FROM generate_series(1, 100);
> test=> SET log_min_duration_statement
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> How does a user protect a custom variable using your code? I don't see
>> any API that would allow that.
> Every module is responsibile for protectiong own custom variables. Only
> module knows if some variable needs protection. And after module
>
Furthermore I believe the patch is incomplete/wrong, because it adds
only one check on the "armored" flag, whereas PGC_SUSET affects behavior
in a number of places. I also notice that it will make setting of a
an armored custom variable from postgresql.conf fail outright in
non-superuser session
I did some performance testing of the patch, and the results were good.
I did this:
test=> CREATE TABLE test (x INTEGER);
test=> INSERT INTO test SELECT * FROM generate_series(1, 100);
test=> SET log_min_duration_statement = 0;
test=> SELECT * FROM test ORDER
How does a user protect a custom variable using your code? I don't see
any API that would allow that.
Every module is responsibile for protectiong own custom variables. Only
module knows if some variable needs protection. And after module
inicialisation module can call ArmorCustomVariable f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> My patch allows to allert somebody so any custom variable is protected.
> How does a user protect a custom variable using your code? I don't see
> any API that would allow that.
The call would have to come from the loadable libr
On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it easier to test HOT.
Please see if the attached patch looks good. It adds a new -F option
w
Pavel Stehule wrote:
> Hello Bruce
>
> My patch allows to allert somebody so any custom variable is protected. I
> dont understand Tom's arguments. Probably this patch do more than is
> necessary. Really important for protection is only calling ResetPGVariable()
> function. My funcionality has
Hello Bruce
My patch allows to allert somebody so any custom variable is protected. I
dont understand Tom's arguments. Probably this patch do more than is
necessary. Really important for protection is only calling ResetPGVariable()
function. My funcionality has only information value.
Regard
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > Pavel, would you remind me how this is useful?
> >
> > ---
> >
> > Pavel Stehule wrote:
> >
> >> Hello
> >>
> >> this patch contains function ArmorCustomVariables. This functi
Bruce Momjian wrote:
Pavel, would you remind me how this is useful?
---
Pavel Stehule wrote:
Hello
this patch contains function ArmorCustomVariables. This function set flag
armored on any custom variable. From this mo
Patch applied. Thanks.
---
Greg Smith wrote:
> This patch adds the usage count statistic to the information available in
> contrib/pgbuffercache. Earlier this month a discussion about my first
> attempt to instrument th
Pavel, would you remind me how this is useful?
---
Pavel Stehule wrote:
> Hello
>
> this patch contains function ArmorCustomVariables. This function set flag
> armored on any custom variable. From this moment only superuse
This looks useful, but shouldn't it be part of /contrib/pgstattuple
rather than in the backend?
---
Simon Riggs wrote:
> New functions to examine the contents of heap pages, as discussed
> recently on -hackers. These are ful
Michael Fuhr wrote:
> On Fri, Apr 06, 2007 at 11:34:39PM -0400, Bruce Momjian wrote:
> > Patch applied. Thanks. Your documentation changes can be viewed in
> > five minutes using links on the developer's page,
>
> Thanks. 8.1 and 8.2 have the same typo -- any reason not to backpatch
> this?
OK
On Fri, Apr 06, 2007 at 11:34:39PM -0400, Bruce Momjian wrote:
> Patch applied. Thanks. Your documentation changes can be viewed in
> five minutes using links on the developer's page,
Thanks. 8.1 and 8.2 have the same typo -- any reason not to backpatch
this?
--
Michael Fuhr
28 matches
Mail list logo
