From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_buffercache causes assertion failure |
Date: | 2005-05-30 04:19:29 |
Message-ID: | 429A9451.7090200@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>
> Fixed; turns out to be an ancient parse-analysis bug that was causing
> the view definition to not agree with the function definition if the
> function definition included a nondefault typmod.
>
> I wonder though why this contrib module is defining its output as
> numeric(10) --- seems like a pretty inefficient choice compared to,
> say, int8; or even int4 which is what the pg_locks view is using.
>
I couldn't use int4 as the underlying datatype is unsigned int (not
available as exposed Pg type). However, using int8 sounds promising (is
int8 larger than unsigned int on 64-bit platforms?).
> And it's arguably a wrong specification anyway, since the code is doing
> nothing to enforce that precision.
Hmmm - that's right, not sure why I did that :-( just using numeric in
the view might have been more sensible.
cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-30 06:29:40 | Re: O_DIRECT for WAL writes |
Previous Message | Christopher Kings-Lynne | 2005-05-30 04:10:46 | Re: Escape handling in COPY, strings, psql |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-30 06:29:40 | Re: O_DIRECT for WAL writes |
Previous Message | Christopher Kings-Lynne | 2005-05-30 04:10:46 | Re: Escape handling in COPY, strings, psql |