The following bug has been logged on the website:
Bug reference: 8135
Logged by: Frank van den Heuvel
Email address: fr...@heuveltop.nl
PostgreSQL version: 9.1.8
Operating system: Ubuntu 12.04
Description:
Dear developers,
I think I have found a bug. I am building
have read the docs first to see that it expects something else
as an argument, but still ;)
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 6006
Logged by: Frank Brown
Email address: francis.br...@agfa.com
PostgreSQL version: 9.0.4 Win x64
Operating system: Windows 2008 Server x64
Description:Will not install
Details:
Initdb.exe - System Error
t know for sure. But if planner was called at
run time for all (or almost all) query statements inside the function,
then it is a big design/implementation issue.
Once again, I appreciate the messages from all three of you who try to
help people, and I understand the difficulty people face.
Rega
-Original Message-
From: Korry Douglas [mailto:korry.doug...@enterprisedb.com]
Sent: Sunday, January 09, 2011 2:34 PM
To: frank
Cc: 'Kevin Grittner'; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5816: index not used in function
> We may have different perceptions
ut if resource constraint is a factor, I may offer to fix
the problem if you could kindly provide with your lexer code and the
code files that are/may be affected, as well as POC for QA.
Once again, I appreciate your reply and thank you for the attention.
Regards,
Frank
-Original Mes
The following bug has been logged online:
Bug reference: 5816
Logged by: frank
Email address: fr...@ros-i.com
PostgreSQL version: 8.3.7
Operating system: linux
Description:index not used in function
Details:
Linux: Linux 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17
The manual looks fine, I found the information as well. I started using the
wiki, that's why I got confused.
Thanks!
Frank
-Oorspronkelijk bericht-
Van: Tom Lane [mailto:t...@sss.pgh.pa.us]
Verzonden: vrijdag 6 augustus 2010 17:04
Aan: Frank Heikens
CC: pgsql-bugs@postgresq
n the manual and wiki?
Regards,
Frank Heikens
-Oorspronkelijk bericht-
Van: Tom Lane [mailto:t...@sss.pgh.pa.us]
Verzonden: vrijdag 6 augustus 2010 16:14
Aan: Frank Heikens
CC: pgsql-bugs@postgresql.org
Onderwerp: Re: [BUGS] BUG #5606: DEFERRABLE and DEFERRABLE INITIALLY DEFERRED
are th
The following bug has been logged online:
Bug reference: 5606
Logged by: Frank Heikens
Email address: f.heik...@anva.nl
PostgreSQL version: PostgreSQL9.0b4
Operating system: WinXP
Description:DEFERRABLE and DEFERRABLE INITIALLY DEFERRED are the
same
Details:
Today
Pode falar ingles? This is an english mailinglist, otherwise you
should try the portuguese mailinglist.
What kind of query are you trying to execute? And what about the
settings in postgresql.conf?
Abraço,
Frank
Op 6 aug 2009, om 20:30 heeft Dielton Paulo het volgende geschreven
The following bug has been logged online:
Bug reference: 4935
Logged by: Frank Spies
Email address: frank.sp...@biotronik.com
PostgreSQL version: 8.4
Operating system: Linux
Description:Weird input syntax for intervals, part 2
Details:
After finding out that bug
btransaction abort. Try this patch and see if you notice
> any bad side-effects.
All examples I had that crashed and burned, now work correctly and/or bail out
correctly where needed.
No side-effects noticed.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgres
=> to avoid possible confusion
db=# select version();
version
---
PostgreSQL 8.4.0 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.2.4, 64-bit
Looking forward to your reply.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hi,
I played a bit with the interval syntax and found this, this time on a 8.4
release:
psql -ddb_frank
psql (8.4.0)
Type "help" for help.
db_frank=# select interval '2.5' year;
interval
--
2 years
(1 row)
db_frank=# select interval '2.5 year';
interval
2 year
would for example help if I could
get a clue on what table is involved with the problematic tuples. I could
easily add extra debug/log statements to the locations these errors come from,
but would appreciate a hint as to what to add exactly ;)
--
Best,
Frank.
--
Sent via pgsql-bugs
sources for that, could we help with creating a backtrace?
>
> You did show a backtrace --- it proves only what was already obvious,
> namely that the problem is in transaction cleanup.
Ok, working on it.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
he rest is
> collateral damage). May we have a test case?
Scripts, triggers and stuff are a bit complex, before assigning the resources
for that, could we help with creating a backtrace? That we could do
immediately ;)
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bug
B,
the queries/checks/etc used are not recursive, so I found the above a bit
suspicious.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hi,
> I think the attached patch will fix it for you.
Great, thanks!
I'll apply this tonight, will get back with results tomorrow.
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgr
idates plans much more often, this might become
tricky. the 'SPI_execute_plan may fail' part can be handled, but I'm a bit
worried about the 'may return different results' part..... Is there a way to
determine (efficiently) that such a save plan has been invalidated?
Or maybe for the future: would a kind of guarded plan pointer be handy...?
--
Best,
Frank.
s plain sql functions, just to see what would happen...?
(I'm reaching, I know ;) )
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hi Tom,
you are right, it's an RC I was running on.
Sorry...
Frank
www.biotronik.com
BIOTRONIK GmbH & Co. KG
Woermannkehre 1, 12359 Berlin, Germany
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
Vertreten durch ihre Komplementärin:
BIOTRONIK Mess- und Thera
ave catched the situation and should now
show a prompt again
- type 'bt' to get a backtrace, just copy&paste&post ;)
You can quit gdb by a plain -c, just confirm when it asks you to detach.
The backend will continue to run, your app should now show the error.
--
Best,
verLoop ()
#38 0x005a5c2a in PostmasterMain ()
#39 0x0055498e in main ()
Looking forward to your reply !
--
Best,
Frank.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4918
Logged by: Frank Spies
Email address: frank.sp...@biotronik.com
PostgreSQL version: 8.4
Operating system: Linux
Description:Weird input syntax for intervals
Details:
It feels totally weird that the two
Hi Tom,
Op maandag 13 juli 2009, schreef Tom Lane:
> Frank van Vugt writes:
> > Any clues as to how to gather additional information that might bring us
> > closer to a solution is appreciated also.
>
> A stack trace from the point of the error would probably tell us a gre
er, this might
simply be due to the usage-pattern of my application.
Any clues as to how to gather additional information that might bring us
closer to a solution is appreciated also. I'd have no problem with applying
some patch as long as it's safe enough for a production environment ;)
t age. The same occurs with
years, a year can be 365 days or 366 days. And there are also issues
with extra seconds and summer and wintertime.
time === trouble
Regards,
Frank
Op 25 jun 2009, om 12:50 heeft Philippe Amelant het volgende geschreven:
Le jeudi 25 juin 2009 à 11:40 +0200, Frank
the actual comparison:
select interval '1 mon 11 day' > interval '1 mon 11 day 16 hour';
I don't see a problem nor a bug.
Regards,
Frank
Op 25 jun 2009, om 11:28 heeft pamel...@companeo.com het volgende
geschreven:
The following bug has been logged online:
Bug re
Looks like you have a hidden character before DROP. Character 2584 is
called the Lower Half Block, it might be there. Cleanup your code,
make sure there is nothing left and then execute your query again.
Good luck!
Frank
Op 16 jun 2009, om 08:58 heeft Jim Michaels het volgende geschreven
The following bug has been logged online:
Bug reference: 4759
Logged by: Frank Heikens
Email address: fr...@jakaree.com
PostgreSQL version: 8.4beta1
Operating system: Windows XP
Description:RETURNS TABLE not supported in pgAdmin
Details:
pgAdmin 1.10.0 Beta 1 (and
The following bug has been logged online:
Bug reference: 4212
Logged by: Frank Millman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Fedora 7
Description:Documentation re upgrading
Details:
Section 15.4 of the Manual - Upgrading
The following bug has been logged online:
Bug reference: 4058
Logged by: Frank F.
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5-2PGDG
Operating system: Centos
Description:xml_table() segfaults on null
Details:
The xml_table() function in the xml2
s not too surprising.
> >
> > Can you grant one of us access to the machine to work on it?
>
> I don't own any alpha machine, but maybe Frank, Steven, or anyone from
> the Debian alpha porter list can create a temporary account for you?
I'm not sure how we handle
tation of xmin
I was too hasty with that one, it obviously still won't work because of the
lack of operators like '<', '>', etc.
So using xidsend() for that still seems to be the only 'valid' trick.
--
Best,
Frank.
it anxious as to how this will
be 'fixed', if at all ;)
db=# select version();
version
PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
RAISE EXCEPTION 'employee % not found', myname;
WHEN TOO_MANY_ROWS THEN
RAISE EXCEPTION 'employee % not unique', myname;
END;
The semicolumn after BEGIN was probably not meant to be there.
--
Best,
Frank.
---(end of broadcast)-
se TBLOCK_SUBABORT_RESTART:
- case TBLOCK_PREPARE:
elog(FATAL, "BeginInternalSubTransaction: unexpected
state %s",
BlockStateAsString(s->blockState));
break;
So Tom, thanks a lot for your swift rep
Ok, so for patch-sake, when I change BeginInternalSubTransaction() in xact.c
by moving these two cases to the upper set
(TBLOCK_STARTED/INPROGRESS/SUBINPROGRESS), then I should be ok?
At the moment, this looks like a showstopper, so I'd prefer patching and move
on ;)
_def();
drop function f1_crash();
Looking forward to your remarks !
--
Best,
Frank.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
The following bug has been logged online:
Bug reference: 2994
Logged by: Frank F. Burmo
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: i386-portbld-freebsd6.1
Description:avg() calculates wrong on Interval-type
Details:
The following
The following bug has been logged online:
Bug reference: 2714
Logged by: Frank Schmidt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Windows
Description:Wrong Result with static number
Details:
Follow skript works fine:
SELECT
ething...
Got that, looks like an acceptable workaround in this case, though.
Is there a guaranteed order of the resulting array, i.e. is this guaranteed to
return the temp schema, given there is one:
'select (current_schemas(true))[1]'.?
(obviously, regexp's will als
g the current session? I need to find out
whether a specific temporary table exists and is accessible for the current
user in the current session.
--
Best,
Frank.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
> I concluded that patching vacuum.c was much the cleanest way to do it.
> Here's the patch against 8.1 branch.
Great, it looks like this patch fixes the remainder of my original problem as
well !
( http://archives.postgresql.org/pgsql-bugs/2005-11/msg00276.php )
--
Best
y.
Would you be interested in the coredump itself (5MB bzipped) or can I do
anything else to assist?
--
Best,
Frank.
---(end of broadcast)---
TIP 6: explain analyze is your friend
rgv=0x0) at autovacuum.c:681
#17 0x08194366 in autovac_start () at autovacuum.c:170
#18 0x0819a101 in ServerLoop () at postmaster.c:1269
#19 0x0819b292 in PostmasterMain (argc=3, argv=0x833b8a0) at postmaster.c:943
#20 0x0815bf3e in main (argc=3, argv=0x833b8a0) at main.c:256
Again and still, relation
x27;
VOLATILE
STRICT
SECURITY INVOKER
AS 'DECLARE
BEGIN
RETURN NULL;
END;';
CREATE CONSTRAINT TRIGGER purchaseorder_line_def AFTER INSERT OR UPDATE OR
DELETE ON purc
ecd in AutoVacMain (argc=0, argv=0x0) at autovacuum.c:680
#17 0x08194216 in autovac_start () at autovacuum.c:170
#18 0x08199fb1 in ServerLoop () at postmaster.c:1268
#19 0x0819b142 in PostmasterMain (argc=3, argv=0x833b8a0) at postmaster.c:943
#20 0x0815bece in main (argc
URITY INVOKER
AS 'SELECT id FROM purchaseorder_line_status WHERE abbreviation
= $1';
If you were interested in some other relid, just let me know.
--
Best,
Frank.
---(end of broadcast)---
TIP 1: if posting/reading
hot());
>
> This seems more future-proof. The patch as proposed is assuming a whole
> lot about where snapshots might or might not get used.
Will try the patch tonight.
Tom, is your patch meant for the exact same location? Also, don't we need a
'CommitTransactionCommand
) at main.c:256
Both dumps are still available for additional info on variable-values, etc.
db=# select version();
version
----
PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.3
--
Best,
Frank.
---(end of broadcas
-
PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.3
(1 row)
--
Best,
Frank.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
The following bug has been logged online:
Bug reference: 1840
Logged by: Frank Papa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Windows XP Home
Description:Does not install
Details:
Downloaded the zipped up package for Win 32
sap
and simply repeating the copy/paste action did exactly that.
It would be great if this gave someone enough clues to pinpoint the problem,
but if not, what kind of action could I take (queries on system tables, etc.)
in order to provide more info on this the next time it happens?
--
Best,
ot; is a perfectly valid outer reference
You're right, now why didn't I see that myself ;)
Sorry to have bothered you guys / the list!
--
Best,
Frank.
an Oost 102-008
5013 CD Tilburg
Tel: (+31).13.5425551, Fax: (+31).13.5452087
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
of the temporary one
select count(*) from full_sequence(1, 100) where id in (select id from f1);
count
---
100
(1 row)
USE THIS TO CLEANUP
DROP FUNCTION full_sequence(integer, integer);
DROP TYPE full_sequence_type;
DROP TABLE f1;
DROP TABLE f1;
--
Best,
Frank.
-
erminal:
"ERROR: too many trigger records found for relation "
=> re-issuing the analyse after the restore is done completes successfully
--
Best,
Frank.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
the mem-alloc error occured earlier, so it would
seem we're in the clear on this one.
Thanks for the quick fix !
I guess this patch is already in the RC2 tree?
--
Best,
Frank.
---(end of broadcast)---
TIP 7: don't forget to incr
g of
some other function. But I'll know soon enough if it isn't ;)
Looking forward to your assesment.
--
Best,
Frank.
--
-- ** DROP THE LOT
--
DROP
t; first time the trigger is fired in a particular session
I've tried to run all immutable functions used at least once before running
the query-set, this made no difference, same error on the same location.
> (unless you are using EXECUTE to invoke the update command?)
No, n
that the handling of pol X and creation of
pol Y from within spawn_pol() is somehow messing things up, but..
If this doesn't ring any alarm bells, then I'll start working on a script
first thing next Monday.
--
Best,
Frank.
---(end of broadc
e, though. I take it you didn't run the watchpointed backend
> far enough to get the memory-alloc error?
Oh, but I did.
All the breaks are at sinval.c:888 and at some point the memory-alloc simply
occurs. Do you mean you want a backtrace of the last brea
ant to back off the compiler optimization level a step so you can get
> more readable tracebacks ...
Yup, will do that as well.
Will read any comments you may have on the TRAP backtrace in a couple of
hours, need to take myself offline for a while ;)
--
Best,
Frank.
-
6', i.e. there is no occurence of the word
'savepoint' in the whole tree.
--
Best,
Frank.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PRO
atchpoints are available, so I'll
follow this up first thing in the morning.
--
Best,
Frank.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
t postmaster.c:2453
#15 0x0816ff6f in ServerLoop () at postmaster.c:1198
#16 0x0816f4a3 in PostmasterMain (argc=3, argv=0x8307788) at postmaster.c:917
#17 0x0813d22d in main (argc=3, argv=0x8307788) at main.c:268
#18 0x400f5d06 in __libc_start_main () from /lib/libc.so.6
Obviously, continuing w
points to begin with
(or arguably, there's nothing 'before' a savepoint ;))
> Now that you see which plpgsql function is failing, do you have a better
> shot at making a self-contained example?
Not really, but if tracing the transaction won't reveal anything else I
to) drop the table
- create the table
- grant select on this table to public
- copy table from a textfile
That's it, so there is no explicit user-handling at all.
Anything particular I can take a look at?
--
Best,
Frank.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
in BackendStartup (port=0x83177f0) at postmaster.c:2453
#13 0x0816ff6f in ServerLoop () at postmaster.c:1198
#14 0x0816f4a3 in PostmasterMain (argc=3, argv=0x8307788) at postmaster.c:917
#15 0x0813d22d in main (argc=3, argv=0x8307788) at main.c:268
#16 0x400f5d06 in __libc_start_main () fro
0816ff6f in ServerLoop () at postmaster.c:1198
#14 0x0816f4a3 in PostmasterMain (argc=3, argv=0x8307788) at postmaster.c:917
#15 0x0813d22d in main (argc=3, argv=0x8307788) at main.c:268
#16 0x400f5d06 in __libc_start_main () from /lib/libc.so.6
I'm able to issue 'cont' to
n and will focus on creating the
backtrace for the memory alloc problem first.
When needed / wanted I can always try and go over any assertion failures
later.
Will be able to post a backtrace in a few hours, I hope.
--
Best,
Frank.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
elopers.
In order to find out whether this was some hardware glitch, I immediately
restarted the process and just now it ended with exactly the same error on
exactly the same spot.
Any hints on how to dig deeper ?
--
Best,
Frank.
---(end of broadcast)
;
lc_ctype
--
C
(1 row)
Hopefully some other Slackware / Debian user can confirm the segfault?
--
Best,
Frank.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
090) at postmaster.c:2817
#41 0x8153015 in BackendStartup (port=0x82f3090) at postmaster.c:2453
#42 0x8151878 in ServerLoop () at postmaster.c:1198
#43 0x8151351 in PostmasterMain (argc=3, argv=0x82deaf8) at postmaster.c:917
#44 0x8127281 in main (argc=3, argv=0xb8f4) at main.c:268
#45 0x400d4577 in __libc_start_main () from /lib/libc.so.6
-
Best,
Frank.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
.base:
ERROR: relation "level" does not exist
CONTEXT: SQL function "get_level" during startup
Omitting the index creation makes vacuumlo finish succesfully.
--
Best,
Frank.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
whether it should?
>
> ALTER TABLE ADD CONSTRAINT can handle primary keys.
Now how did I miss *that* ;-\
> I think you probably want:
> alter table f_test add primary key (id);
Yep, that does the trick.
Thank!
--
Best,
Frank.
---(end of broadcast)
for ways to get to a temporary table with a copied structure
AND a primary key.
--
Best,
Frank.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
it should be a problem for the db.?
Please, can you help me??
best regards from germany
Frank Illner
Teamleiter Enwicklung-Neue Medien / Abteilung IT
LAND BRANDENBURG LOTTO GmbH
Steinstraße 104 - 106; 14480 Potsdam
Tel.: +49 (0
> anything I can verify on that one to help?
free4testing=# select timestamptz('1901-12-14 0:0:0');
timestamptz
-
1901-12-13 23:40:32
(1 row)
Frank.
---(end of broadcast)---
TIP 9: the planner will ignor
unsetting TZ and restarting the postmaster I got the same old behaviour back
(my 19 minute wide timezone) with output equal to the one above.
Frank.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
1901-12-14 00:19:00+00:19
Just let me know what you're interested in, if anything.
Best,
Frank.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
be this had
something to do with it?
At this moment, I still have that second server that's still showing the
problem, anything I can verify on that one to help?
Best,
Frank.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
ptions and got the same result
select version();
version
PostgreSQL 7.4beta1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
Best,
Frank.
---(end of broadcast)-
> "Mathew Frank" <[EMAIL PROTECTED]> writes:
> > The documentation on this is very thin on the ground - I`ve just spend 4
Ho=
> > urs googling and the best I could find was one of the main developers
(Bruc=
> > e?? sorry - too long ago) replying to
I have had a lot of trouble getting a DELETE
trigger to do nothing (ie let the delete operation occur instead of cancelling
it, as required)
The documentation on this is very thin on the
ground - I`ve just spend 4 Hours googling and the best I could find was one of
the main developers (Bru
be the old one used.
However, the encoding seems to be changed, as 'show client_encoding' will
show.
Regards,
Frank van Vugt
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
bufHdr->tag.blockNum,
! (char *) MAKE_PTR(bufHdr->data));
! /* drop refcount incremented by
RelationNodeCacheGetRelation */
! RelationDecrementReferenceCount(bufrel);
! }
! LocalBufferFlushCount++;
}
i have the following utility function, which I use to easily return the OID
of an the new row created by an INSERT query:
---
CREATE FUNCTION insert_record_return_oid(text) RETURNS int4 AS
' DECLARE
s_query ALIAS FOR $1;
oid int4;
BEGIN
EXECUTE s_query;
GET DIAGNOSTICS oid
> which appears correct (you misspelled the column name).
>
> 7.2 does foreign key validity checking in a funny order that causes it
> to produce the other error message first. While not incorrect, it's
> sure misleading :-(
Thanks a bunch.
I'm always a bit nervous about calling anything a bug.
Hello people,
I'm a newbie to this list (though I've been hanging around on the ODBC list
for some time and I've been working with pgSQL for about 8months) so go
easy? ;-)
I realise this error is to stop a bad foreign key reference being created.
However I have a table with a multi-column primary
. Building, installing and initialising went without a hitch,
so it must be something sparc32-specific.
--
Frank Van Damme
homepage: www.student.kuleuven.ac.be/~m9917684
jabber (=IM): [EMAIL PROTECTED]
errorlogs.tar.bz2
Description: application/tbz
---
in this situation
because "it was there" when I took over the project, but what
I'm doing would be difficult or impossible with other SQL
products I've seen.
(Or maybe it just lets me get away with really arcane syntax I
shouldn't be using (;-))
> Frank McKenney <[
arts at (0, 414)
The Data Base System is starting up
Failed.
!# DEBUG: ReadRecord: record with zero len at (0, 4170876)
DEBUG: redo done at (0, 4170840)
DEBUG: database system is in production state
...
Great program hopping I'm helping improving it.
bye
--
"L'idea d
On Fri, 10 Nov 2000, Tom Lane wrote:
> Frank Miles <[EMAIL PROTECTED]> writes:
> >> which surprises me not at all, because at the point where this function
> >> is invoked, the new record with tt_id 3 hasn't been entered into the
> >> table yet.
>
On Fri, 10 Nov 2000, Tom Lane wrote:
> Frank Miles <[EMAIL PROTECTED]> writes:
> > If an index is created based on a function of the primary key,
> > you cannot insert new entries into the database.
>
> I think the critical point here is that your "function o
Your name : Frank Miles
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux
tecture of which I'm aware (although I'm sure there are some
warped, perverted architectures out there that use that, sigh).
> The short-term answer for Frank is "don't specify index opclasses in
> handwritten CREATE INDEX commands, unless you're really sure that you
&
1 - 100 of 101 matches
Mail list logo
