-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Bertram Scharpf wrote:
>>> Wouldn't the release be a good opportunity for providing
>>> this little tool?
> As for whether we could accept this for 8.4, I thought the general
> consens
Joshua D. Drake wrote:
I believe this patch is an update to the table_funcs contrib module.
I spent 2 minutes looking. It has no Makefile and no comments. It
doesn't use our code conventions either. At that stage I stopped looking.
The author needs to spend some time looking at the dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Dunstan wrote:
>
>
> Joshua D. Drake wrote:
>> I believe this patch is an update to the table_funcs contrib module.
>>
>>
>
> I spent 2 minutes looking. It has no Makefile and no comments. It
> doesn't use our code conventions either. At t
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Joshua D. Drake wrote:
I believe this patch is an update to the table_funcs contrib module.
I spent 2 minutes looking. It has no Makefile and no comments. It
doesn't use our code conventions either. At that stage I stopped look
Joshua D. Drake wrote:
Tom Lane wrote:
Bertram Scharpf wrote:
Wouldn't the release be a good opportunity for providing
this little tool?
As for whether we could accept this for 8.4, I thought the general
consensus was that we should implement the SQL-spec WITH syntax.
The only good reason fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Conway wrote:
> Joshua D. Drake wrote:
>> Tom Lane wrote:
Bertram Scharpf wrote:
> Wouldn't the release be a good opportunity for providing
> this little tool?
>>
>>> As for whether we could accept this for 8.4, I thought the general
>
On Fri, 10 Aug 2007, Tom Lane wrote:
> I noticed the following behavior in CVS HEAD, using a pattern that is
> capable of matching no characters:
>
> regression=# SELECT foo FROM regexp_matches('ab cde', $re$\s*$re$, 'g') AS
> foo;
> foo
> ---
> {""}
> {""}
> {" "}
> {""}
> {""}
> {"
I was just tracing through a memory leak occurring when regexp_matches()
is executed a lot of times within one query, for instance this rather
stupid test case:
select count(*) from
(select regexp_matches(repeat('xyxxy',100), '[xy]', 'g')
from generate_series(1,10)) ss;
I thought it was
Robert,
> I am working on a data integrity check tool (pgcheck).
> I would like to discuss the following issues:
I'm a little confused. I assumed that your project would check the pages of a
*shut-down* database or one in recovery (single-user) mode as part of
recovery after a crash or HW fail
* Tom Lane ([EMAIL PROTECTED]) wrote:
[...]
> 3. When regexp_matches is done with the current call, it politely
> releases the chunk, and AllocSetFree sticks it into the freelist for
> 4K chunks.
>
> 4. The next call of regexp_matches asks for a 2K chunk. There's nothing
> in the 2K chunk freelis
Jason,
> Aside from running into a known bug with "too many triggers" when creating
> gratuitous indices on these tables, I feel as it may be possible to do what
> I want without breaking everything. But then again, am I taking too many
> liberties with technology that maybe didn't have use cases
Stephen Frost <[EMAIL PROTECTED]> writes:
> This is likely to be naive, but perhaps it'll help others understand
> too. Would it be sensible to look at trying to fill a 2K request from
> the next-larger (4K-chunk) freelist before allocating a new chunk?
That doesn't sound like a very good idea --
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Perhaps we should just remove lines 934-982 of aset.c, and always handle
> small-chunk reallocs with the "brute force" case. Can anyone see a way
> to salvage something from the "realloc-in-place" idea?
>
> One thought that comes to mind is to try to make
Tom Lane commits
(http://www.postgresql.org/community/weeklynews/pwn20070121.html)
- Fix incorrect permissions check in
information_schema.key_column_usage view: it was checking a
pg_constraint OID instead of pg_class OID, resulting in "relation with
OID n does not exist" failures for anyone w
Gregory Stark <[EMAIL PROTECTED]> writes:
> We could also only do the realloc-in-place only if there isn't a 4k chunk in
> the 4k freelist. I'm imagining that usually there wouldn't be.
Or in general, if there's a free chunk of the right size then copy to
it, else consider realloc-in-place. Count
Hi,
Am Samstag, 11. Aug 2007, 10:22:24 -0400 schrieb Andrew Dunstan:
> Joshua D. Drake wrote:
> >I believe this patch is an update to the table_funcs contrib module.
> >
> >
>
> I spent 2 minutes looking. It has no Makefile and no comments. It
> doesn't use our code conventions either. At that
Bertram Scharpf wrote:
All I wanted to do is to float an idea by presenting a piece
of code that does what I mean instead of describing what it
should do if I considered right.
But that's exactly what I was making a point about. If you want to get
something included in PostgreSQL (and that'
Josh Berkus wrote:
> Robert,
>
>
>> I am working on a data integrity check tool (pgcheck).
>> I would like to discuss the following issues:
>>
>
> I'm a little confused. I assumed that your project would check the pages of
> a
> *shut-down* database or one in recovery (single-user) mod
"April Lorenzen" <[EMAIL PROTECTED]> writes:
> I had to feel my way carrying out this fix, and I don't know if I did
> it right - I only know that it appears I no longer have the error.
> Please confirm whether I was supposed to execute all of
> share/information_schema.sql --- or just the portion
19 matches
Mail list logo
