On Jul 11, 2008, at 20:22, Tom Lane wrote:
Here's an updated version of citext.c. Some changes cosmetic, some
not so much ...
Thanks! Good catch on my missing all of the s/int/int32/ stuff related
to citextcmp(). Stupid oversites on my part. I'll submit a new patch
with these changes shor
On Jul 11, 2008, at 20:10, Tom Lane wrote:
Oh, got one of those too ... [ time passes ... ] Nope, no leak
seen here either, though you could possibly fry an egg on my laptop
right now ...
Yeah, gotta love that, right?
So the issue must be with my version for 8.3.x, meaning, likely, my
cust
Here's an updated version of citext.c. Some changes cosmetic, some
not so much ...
regards, tom lane
/*
* PostgreSQL type definitions for CITEXT 2.0.
*/
#include "postgres.h"
#include "access/hash.h"
#include "fmgr.h"
#include "utils/builtins.h"
#include "utils/format
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 11, 2008, at 19:18, Tom Lane wrote:
>> I tried it here and didn't see any apparent memory leak, on two
>> different systems. What platform are you testing on, and with
>> what encoding/locale settings?
> That's Mac OS X 10.5.4 "Leopard." Usi
On Jul 11, 2008, at 19:18, Tom Lane wrote:
I tried it here and didn't see any apparent memory leak, on two
different systems. What platform are you testing on, and with
what encoding/locale settings?
PostgreSQL 8.3.3 on i386-apple-darwin9.4.0, compiled by GCC i686-
apple-darwin9-gcc-4.0.1 (
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Unfortunately, CITEXT seems to have a memory leak somewhere,
I tried it here and didn't see any apparent memory leak, on two
different systems. What platform are you testing on, and with
what encoding/locale settings?
reg
On Sat, Jul 12, 2008 at 12:41 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > So it would seem that we need a way of handling temp tables that doesn't
>> > rely on catalog entries at all.
>>
>> That's
"Abhijit Menon-Sen" <[EMAIL PROTECTED]> writes:
> Hi Zoltán.
>
> I was reading through your posix_fadvise patch,
Actually Zoltan's patch was based on an earlier patch from me. The sections
you're highlighting here are from my original patch.
> and I wanted to ask about this change in particular
On Jul 11, 2008, at 16:45, Tom Lane wrote:
Not sure about a memory leak, but this code is clearly wrong if
str_tolower results in a change of physical string length (clearly
possible in Turkish, for instance, and probably in some other
locales too). You need to do strlen's on the lowercased str
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> lcstr = str_tolower(VARDATA_ANY(left), VARSIZE_ANY_EXHDR(left));
> rcstr = str_tolower(VARDATA_ANY(right), VARSIZE_ANY_EXHDR(right));
> result = varstr_cmp(
> lcstr,
> VARSIZE_ANY_EXHDR(left),
> rcstr,
>
On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So it would seem that we need a way of handling temp tables that doesn't
> > rely on catalog entries at all.
>
> That's a complete non-starter; I need go no farther than to point out
> that it would b
I've committed the multicolumn one with minor revisions (fix some poor
English in docs and comments, add regression-test coverage). Do you
Thank you very much.
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I should modify it to support/synchro
On Jul 11, 2008, at 13:02, Zdenek Kotala wrote:
Thank you, Zdenek. Have you had a chance to try citext yet? Or did
you just read the source?
I tested version two on Solaris/SPARC and Sun studio compiler. I
checked last version only quickly (comparing your changes).
Thanks.
I just update
Simon Riggs <[EMAIL PROTECTED]> writes:
> So it would seem that we need a way of handling temp tables that doesn't
> rely on catalog entries at all.
That's a complete non-starter; I need go no farther than to point out
that it would break clients that expect to see their temp tables
reflected in p
On Fri, 2008-06-27 at 12:43 -0400, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> >> The only solution proposed in that thread was to auto-delete temp
> >> tables at postmaster restart; which I opposed on the grounds that
> >> throwing away
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz
> http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz
I've committed the multicolumn one with minor revisions (fix some poor
English in docs and comments, add regression-test coverage). Do you
need more revi
Zdenek Kotala escribió:
> The example is when you have translation data (vocabulary) in database.
> But the reason is that ANSI specify (chapter 4.2) charset as a part of
> string descriptor. See below:
>
> — The length or maximum length in characters of the character string type.
> — The catal
I'm getting many Delivery Failures on list postings.
I think this is because my emails are now coming from a different
domain. I've changed this because it's used as the basis for permalinks.
So if you have me set in your spam filter White List then you'll need to
reset it. Thanks and sorry for
David E. Wheeler napsal(a):
On Jul 11, 2008, at 12:37, Zdenek Kotala wrote:
I'm sorry for late response. I'm little bit busy this week. I quickly
look on your latest changes and it seems to me that everything is OK.
I'm going to change status to ready for commit. After discussion with
Pavel S
Martijn van Oosterhout napsal(a):
On Thu, Jul 10, 2008 at 11:24:29PM +0200, Radek Strnad wrote:
Hi,
after long discussion with Mr. Kotala, we've decided to redesign our
collation support proposal.
For those of you who aren't familiar with my WIP patch and comments from
other hackers here's the
On Jul 11, 2008, at 12:37, Zdenek Kotala wrote:
I'm sorry for late response. I'm little bit busy this week. I
quickly look on your latest changes and it seems to me that
everything is OK. I'm going to change status to ready for commit.
After discussion with Pavel Stehule I changed meaning a
David E. Wheeler napsal(a):
Attached is a new version of a patch to add a CITEXT contrib module.
Changes since v2:
* Optimized citext_eq() and citext_ne() (the = and <> operators,
respectively) by having them use strncmp() instead of varstr_cmp(). Per
discussion.
* Added `RESTRICT` and `JOI
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It's often said that the golden rule of WAL is that we must log the
> changes before actually doing the changes.
No, the golden rule is that the log entry must hit disk before the
data-page changes do. This does not speak to the order in which you
make
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't want to discard this idea, because we're getting a very
> unusually high number of bogus entries. However, they are all (or a
> very high percentage of them) the very first entry on each index page.
> I want to confirm that the leftmost on a lea
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > We've detected what I think is some sort of index corruption in 8.1.
> > > The server is running 8.1.11, so AFAICT the problem with truncated pages
> > > in vacuum is already patched and accounted for (i.e.
Hi,
It's often said that the golden rule of WAL is that we must log the
changes before actually doing the changes. However it seems to me that
in _bt_delitems we're modifying the page (calling PageIndexMultiDelete)
before actually logging what's going to happen. Why is this OK?
I see that we're
On Wed, Jul 9, 2008 at 10:11 PM, Abhijit Menon-Sen <[EMAIL PROTECTED]> wrote:
> At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote:
>>
>> No, actually I meant having a lone "list = lappend(list, newseq);" in
>> the loop, so that ExecGrantStmt_oids is called only once.
>
> Yes, I understand what
Hi everybody,
I've been followed the postgres main page intruccion to build the examples
of libpq library.Unfortunatelly the examples was just for linux enviroment.
Nevertheless, i finally built the example program in my winxp, but i got
this message when i ran it: "the aplication could not inicia
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
Come to think of it, the current code is in a way a variant of Lossy
Counting, it's just doing the pruning after each and every new element,
isn't it?
Interesting comment. In LC's terms we have w=1 therefore e=1 the
On Fri, 2008-07-11 at 09:33 +, Dean Rasheed wrote:
> This new version
Thanks, I'll review this next week now.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Gregory Stark <[EMAIL PROTECTED]> writes:
> But the SPI api doesn't actually allow callers to get more than the typeid of
> the types in the result tupledesc of SPI_execute_plan:
> SPI_gettypeid(TupleDesc tupdesc, int fnumber)
> Should this function be replaced with one which allows returning a t
On Fri, 2008-07-11 at 16:15 +0530, Abhijit Menon-Sen wrote:
> At 2008-07-08 13:50:24 +0100, [EMAIL PROTECTED] wrote:
> >
> > > I can tell you from the perspective of CF coordinator, it's a PITA.
> >
> > I felt so too at first, but I'm comfortable with it now.
>
> Then I'm in awe of your wiki-edit
At 2008-07-08 13:50:24 +0100, [EMAIL PROTECTED] wrote:
>
> > I can tell you from the perspective of CF coordinator, it's a PITA.
>
> I felt so too at first, but I'm comfortable with it now.
Then I'm in awe of your wiki-editing skills. After keeping at it for a
few days, I've given up trying to do
At 2008-07-11 19:10:16 +0900, [EMAIL PROTECTED] wrote:
>
> And I have a question. Is it legal to use a pointer value as a
> condition, like `while (!pointer) ...' ?
Yes, it's fine.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
In March of last year Tom fixed up a lot of places to reduce the places where
we lose typmod info including Const structures:
> revision 1.128
> date: 2007-03-17 00:11:05 +; author: tgl; state: Exp; lines: +7 -6;
> Fix up the remaining places where the expression node structure would lose
Hi,
I updated the series of patches, as follows:
[1/4] Core facilities of PGACE/SE-PostgreSQL
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r953.patch
[2/4] "--security-context" option of pg_dump/pg_dumpall
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump
Hi Zoltán.
I was reading through your posix_fadvise patch, and I wanted to ask
about this change in particular:
> --- a/src/backend/executor/nodeIndexscan.c
> +++ b/src/backend/executor/nodeIndexscan.c
> @@ -290,7 +290,7 @@ ExecIndexEvalArrayKeys(ExprContext *econtext,
> /* We want to kee
Ooops. That last patch had an embarrassing little typo which caused it to not
actually record the planner times.
This new version fixes that and also includes a little patch to psql so that it
ignores any backend notices during tab-completion, which otherwise just get
in the way. Trace during tab
On Thu, Jul 10, 2008 at 11:24:29PM +0200, Radek Strnad wrote:
> Hi,
>
> after long discussion with Mr. Kotala, we've decided to redesign our
> collation support proposal.
> For those of you who aren't familiar with my WIP patch and comments from
> other hackers here's the original mail:
> http://a
On Mon, 2008-07-07 at 15:46 +0200, Bernd Helmle wrote:
> There's a behavior in pg_dump that annoyed me a little bit, the last few
> times i had to deal with it:
>
> Consider you have to dump a specific namespace only, you are going to use
>
> pg_dump -n [-t ].
>
> I found it a common use case
40 matches
Mail list logo
