I've been going through the thread that Andrew Dunstan started with his
enumkit.
Maybe I missed it, but I didn't see any conclusion. If I want to design an
Open Source system now that may be in beta in three to six months and I'd
like to use enums, is this a good place to look?
I guess I'm w
When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
Sorry, I'll just trickle out the information.
tassiv=# \d catalog_ra_decl_index
Index "public.catalog_ra_decl_index"
Column | Type
+---
loc| spherekey
gist, for tab
Hi,
i was trying to compile CVS using --with-plperl (perl installed is
5.6.1) and i get this error when make go inside plperl:
make[3]: *** No rule to make target `SPI.xs', needed by `SPI.c'. Stop.
make[2]: *** [all] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2
--
regards,
Jaime C
When grilled further on (Mon, 7 Nov 2005 08:07:14 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
I'm currently attached to the dead (dying) process. spl_nright seems pretty
large...
(gdb) print v->spl_nright
$3 = 138311580
Program received signal SIGSEGV, Segmentation fault.
0x08082057
On Tue, November 8, 2005 00:02, Marc G. Fournier wrote:
> On Mon, 7 Nov 2005, Andrew Dunstan wrote:
>> Oh, the top level interfaces directory. I misunderstood. Why is anybody
>> checking that out at all? Are we keeping it for historical purposes?
I think the person in question was doing a regula
I import some of my data into my postgres database, win32 platform, via
the COPY table FROM with CSV. My CSV file is created from a Crystal
Report (v.9). I run the report and have Crystal export the results into
a CSV file (using the default settings).
I have some data which looks like this when
On a few occasions I've come across vacuums that result in more pages
stored than needed, ie:
INFO: free space map: 81 relations, 235349 pages stored; 220672 total pages
needed
DETAIL: Allocated FSM size: 1000 relations + 200 pages = 11817 kB shared
memory.
I see that PrintFreeSpaceMapSta
From what I understand DTrace is rather tough to use. Secondly it will provide
Solaris only information, so if you are suggesting helpfulness for just Solaris,
then yes it would be. I don't think that DTrace is available for Solaris 8 and
9, the company I work for is still on 8 with possibly som
I'm starting to think about what it'll take to allow arrays to contain
elements that are NULL. The behavioral semantics seem pretty
straightforward, but there are a couple of areas that need discussion.
One trouble spot is what the I/O representation should look like.
Since 8.0, the array input p
Bruce Momjian writes:
> My guess is that there is a one-off bug in there.
At least a two-off ... but I think it's more likely some sort of
wrong-state error, given the narrow places where it happens. I have not
observed any non-comment code being mis-justified, for instance.
Tom Lane wrote:
> Bruce Momjian writes:
> > Good point. I see the maximum length changed in this commit:
> > revision 1.70
> > date: 2004/10/02 01:10:58; author: momjian; state: Exp; lines: +1 -1
> > Update length from 75 to 79.
>
> > We were discussing some pgindent issues at tha
Thanks a lot, but I still getting an error message like this:
ERROR: cache lookup failed for type 0
What is wrong?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Lunes, 07 de Noviembre de 2005 05:17 p.m.
To: Cristian Prieto
Cc: pgsql-gener
"Cristian Prieto" <[EMAIL PROTECTED]> writes:
> Datum
> test_array(PG_FUNCTION_ARGS)
> {
> ArrayType *v = PG_GETARG_ARRAYTYPE_P(1);
> Datum element;
> Oidarray_type = get_array_type(v);
I think you want get_element_type, instead. And you definitely ought to
be check
Bruce Momjian writes:
> Good point. I see the maximum length changed in this commit:
> revision 1.70
> date: 2004/10/02 01:10:58; author: momjian; state: Exp; lines: +1 -1
> Update length from 75 to 79.
> We were discussing some pgindent issues at that time on hackers, but I
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> My current code works by using MemoryContextCreate() to create a child
> context to MessageContext and using the Init()/Delete() functions to
> initialise and destroy a cache in the local backend. However, this doesn't
> really work particularly well
Tom Lane wrote:
> I'm noticing that the latest pgindent run has frequently rejustified
> block comments to end in column 80 or 81, causing them to wrap in an
> ugly way (at least in emacs). I thought the agreement was to limit
> lines to 79 chars max?
>
> For one example see lines 475 ff in /src/
Hello, I'm doing a very simple C language function in PostgreSQL but I can't
figure out why this is not working, the documentation about the PostgreSQL
internals is not so good about arrays and I couldn't find a suitable example
of the use of some kind of array functions inside the pgsql source tre
Marc Munro <[EMAIL PROTECTED]> writes:
> PGDATA is installed on a Netapp network storage device.
This is generally not recommended--it should be on a local disk (SAN,
etc) rather than NFS.
> We are using slony 1.1.0 for replication.
>
> The (provider) database locked-up after I killed a slony cl
I skimmed the thread "Spinlocks, yet again: analysis
and proposed patches". Wouldn't Solaris 10's DTrace
be helpful in seeing what's going on? It seems DTrace
was meant for these types of problems.
__
Yahoo! FareChase: Search multiple travel sit
Pgindent adds spaces after the stars if it doesn't recognize the thing
before the star as a typedef... Could it be that somehow the list of
typedefs included in pgindent got corrupted?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of To
Last week I managed to lock-up and then crash a development database.
I'm going to try to reproduce it today and would like to know what I can
do to further investigate the problem.
I am running Linux 2.6.9-11.ELsmp X86_64 on a Quad Dual-Core Opteron
I have the following postgres RPMs installed:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Fri, Nov 04, 2005 at 08:06:39PM -0500, Tom Lane wrote:
>> Um, what's your log_line_prefix setting, and is the next format code
>> %i by any chance? I've just noticed an utterly brain-dead assumption
>> somebody stuck into ps_status.c awhile back.
>
On 07 Nov 2005 14:22:37 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
> IIRC, floating point registers are actually longer than a double so if the
> entire calculation is done in registers and then the result rounded off to
> store in memory it may get the right answer. Whereas if it loses the extra
On Fri, Nov 04, 2005 at 08:06:39PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > My client (same one with the slru.c issue) has had 3 of these in the
> > past day...
>
> > (gdb) print *str
> > $39 = {data = 0x848030 "2005-11-04 00:01:02 EST|2005-11-04 00:00:08
> > EST|21
Hi everyone,
I'm currently in the middle of trying to implement a cache for a PostGIS
server-side function that uses an external library with an expensive startup
cost, and was hoping to find some advice on the best way to implement it.
The function currently takes 2 parameters - a customised C g
c.f.:
`-ffloat-store'
Do not store floating point variables in registers, and inhibit
other options that might change whether a floating point value is
taken from a register or memory.
This option prevents undesirable excess precision on machines such
as the 68000 where
Tom Lane <[EMAIL PROTECTED]> writes:
> I think we can still file this as a compiler bug, because I'm pretty sure
> the C spec does not allow rearrangement of floating-point calculations ...
It may have more to do with whether the floating point value can stay in a
floating point register long en
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> 8.1 had been tagged, may I develope/commit new tsearch2 code in HEAD branch?
Yes, HEAD is 8.2devel now.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your fr
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> hm...I'm using named statements over ExecPrepared. I can also confirm
> the results inside psql with prepare/execute. I can send you a test
> case, but was just wondering if your change to makelimit was supposed to
> address this case.
Nope, sorry.
Hi!
8.1 had been tagged, may I develope/commit new tsearch2 code in HEAD branch?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The statements are invariably in form of
> select a,b,c,d from t
> where a >= $1 and
> (a > $1 or b >= $2) and
> (a > $1 or b > $2 or c >= $3) and
> (a > $1 or b > $2 or c > $3 or d > $4)
> > ^^
> > If I hardcode $5 to any sub-ridiculous value, I get a proper index
plan.
> > Does your patch assume a limit of 1 or 10% of table rows?
>
> If it doesn't have a value for the parameter, it'll assume 10% of
table
> rows, which is what it's done for a long t
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Is this correct?
>
> Sure, what do you think is wrong with it? plan_rows is initially a
copy
> of the child node's output-rows estimate, and then it gets modified.
OK, just a stab in the dark...not familiar at all with this code (seemed
odd to
I wrote:
> Michael Paesold <[EMAIL PROTECTED]> writes:
>> I am definatly not going to use -march=pentium4 in any production
>> system. Should I open a bug report with RedHat (gcc vendor)?
> Yeah, but they'll probably want a smaller test case than "Postgres fails
> its regression tests" :-(
I hav
On Mon, 7 Nov 2005, Andrew Dunstan wrote:
Jeroen T. Vermeulen wrote:
On Sat, Nov 05, 2005 at 09:46:15AM -0500, Andrew Dunstan wrote:
A libpqxx user just informed me that the anonymous CVS repository at
anoncvs.postgresql.org still contained a 2002 version of libpqxx in the
interfaces dire
Actually I want to do this from inside the postgres code i.e. I want to
get table name and tuple values from OID of corresponding table OID and
tuple OID.
Is there any built in function in postgres code to do this?
Paresh
Christopher Kings-Lynne wrote:
> Try
>
> SELECT 12341234::regclass;
>
> Wh
Neil Conway <[EMAIL PROTECTED]> writes:
> On a related note, most of these changes are completely bogus:
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c.diff?r1=1.152;r2=1.153
Oy vey! Why did it insert spaces after the stars in all those function
declarations? Th
Where someone is doing real work and pgindent creates so many
cosmetic changes for the current CVS repository, would it be
feasible to first commit a "whitespace only" noop revision, so that
real changes can be easily identified. I have seen this approach
work well for others.
-Kevin
>>> Neil C
On Mon, 2005-07-11 at 09:19 -0300, Alvaro Herrera wrote:
> I have another gripe regarding pgindent. Why does it change indenting
> of function declarations?
On a related note, most of these changes are completely bogus:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.
On Mon, 2005-07-11 at 20:39 +0530, Sreejesh O S wrote:
> How can I access CVS ?
http://www.postgresql.org/developer/sourcecode/
Please try to do at least a little research before posting.
-Neil
---(end of broadcast)---
TIP 5: don't forget to inc
How can I access CVS ?
When grilled further on (Sun, 6 Nov 2005 20:00:38 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
Didn't set the core big enough (1Mb). It's now at 50Mb.
I am using PGSphere, which should be the only gist indexes in use.
gdb /usr/local/pgsql810/bin/postgres core.28053
...
warning: core
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Is this correct?
Sure, what do you think is wrong with it? plan_rows is initially a copy
of the child node's output-rows estimate, and then it gets modified.
regards, tom lane
---(end of broadcast)---
I noticed your 8/18 commit to address an issue I raised regarding
parameterized limit statements. Specifically, prepared statements with
a variable limit would tend to revert to bitmap or seqscan.
I check out cvs tip and am still getting that behavior :(. So, I had a
look at createplan.c to see
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I have another gripe regarding pgindent. Why does it change indenting
> of function declarations?
What it's doing is indenting the additional lines in the same way as
they'd be indented in the function definition, that is
static void foo(int p1,
i
Try
SELECT 12341234::regclass;
Where 12341234 is the OID of a table.
Otherwise try:
SELECT tableoid, * FROM table;
To get the tableoid on each row.
Chris
Paresh Bafna wrote:
Is there any way to retrieve table name and/or tuple values from OID of
table/tuple?
---(en
Michael Paesold <[EMAIL PROTECTED]> writes:
> I have tested these combination of CFLAGS:
> -O2 OK
> -O2 -mcpu=i686 -march=i686 OK (good, RPMS are built with these)
> -O2 -mcpu=pentium4 -march=i686 OK
> -O2 -mcpu=pentium4 -march=pentium4 fails
> I am d
Paresh Bafna schrieb:
Is there any way to retrieve table name and/or tuple values from OID of
table/tuple?
Yes.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
Is there any way to retrieve table name and/or tuple values from OID of
table/tuple?
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Jeroen T. Vermeulen wrote:
On Sat, Nov 05, 2005 at 09:46:15AM -0500, Andrew Dunstan wrote:
A libpqxx user just informed me that the anonymous CVS repository at
anoncvs.postgresql.org still contained a 2002 version of libpqxx in the
interfaces directory. I checked it out and otherwise it
On Mon, Nov 07, 2005 at 07:50:20AM +0100, Lars Kanis wrote:
> We're using Postgres 8.0.2 on SuSE10.0 (64-Bit). Tests on 8.1 beta 4 have
> shown no problems but this one:
>
> SELECT * FROM mitglieder WHERE lower(vorname::text)='lars'
>
> does a bitmap-index-scan like this:
Check your locales.
We're using Postgres 8.0.2 on SuSE10.0 (64-Bit). Tests on 8.1 beta 4 have
shown no problems but this one:
SELECT * FROM mitglieder WHERE lower(vorname::text)='lars'
does a bitmap-index-scan like this:
Bitmap Heap Scan on mitglieder (cost=10.68..3770.52 rows=1051 width=226)
Recheck Cond
Hi,
I have another gripe regarding pgindent. Why does it change indenting
of function declarations? An example is at the end. I think it may be
thinking that declarations should be aligned using 8-spaces tabs. Can
this be corrected?
It annoyed me just now, because I'm adjusting my vacuum patc
Michael Glaesemann wrote:
So what do you have in results/interval.out?
@ 4 years 1 mon 9 days 28 hours 18 mins 23 secs seems wrong to me, no?
select avg(f1) from interval_tbl;
avg
-
@ 4 years 1 mon 9 days 28 hours 18 mins 2
On Nov 7, 2005, at 18:28 , Michael Paesold wrote:
Ok, forgot. This is *without* integer-datetimes, RHEL 3 (Linux
2.4.21, glibc 2.3.2, gcc 3.2.3 20030502) on i686 (Xeon without
x86-64).
I just ran make check on for PostgreSQL 8.1.0 on Mac OS X 10.4.3
Heh. I forgot, too ;) My test was also
Michael Paesold wrote:
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected "9 days 28 hours" seem wrong,
don't they? Th
Michael Glaesemann wrote:
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected "9 days 28 hours" seem wrong,
don't they?
I have tested on pgsql-8.1-beta3 on Windows 2003.
It works fine.
I changed the line in postmaster.conf between "on" and "off".
(Remember to save it each time). And paste the two lines in
psql to see the results.
select pg_reload_conf();
select setting from pg_settings where name = 'const
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected "9 days 28 hours" seem wrong,
don't they? The actual value seems to b
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I get
a regression failure in the interval tests. I am no export for the
interval type, but the expected "9 days 28 hours" seem wrong, don't
they? The actual value seems to be the same.
Is it possible that this is broken on the
On Sat, Nov 05, 2005 at 09:46:15AM -0500, Andrew Dunstan wrote:
> >A libpqxx user just informed me that the anonymous CVS repository at
> >anoncvs.postgresql.org still contained a 2002 version of libpqxx in the
> >interfaces directory. I checked it out and otherwise it seems to be the
> >current
61 matches
Mail list logo