Re: [HACKERS] Install issue on Windows and directory permission
Here I found an installation issue: - I was installing pg 8.1 on a Windows 2000 box. - I chose a different folder than default (D:\PGSERVER did not exist yet) - When installing, the setup complained about not being able to write into the directory - I check the directory permissions and saw that the Everyone group does not have Modify permissions - After setting the Modify permission, the setup continued and finished okay. Um, so what actually is the problem? //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
I fixed path in pg_sphere (and done some more clean up). BTW, I usially install contrib modules before restoring database (of course, it need to dump db without content of modules)... -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] dbsamples - dbsamples: Imported Sources
Christopher Kings-Lynne wrote: Anyone know how I can turn off these emails to the pgsql committer's list? Well, each pgfoundry project can turn it off if they like - it's driven from their CVSROOT - I think it's the loginfo or commitinfo file. But if you don't want to see them, why not just filter them? You can base your filter on the X-Mailing-List headers (and then you can filter more than just your own projects). cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Underlying view columns?
This one is quite long, but I guess the quality of the answer depends on the quality of the question :). I use views to simplify the underlying database schema for the end users. The end do however still like to know about relations. Here is a very simple example: CREATE TABLE t_orgs ( ID SERIAL PRIMARY KEY, name varchar(32) NOT NULL ); CREATE TABLE t_ppl ( ID SERIAL PRIMARY KEY, org integer REFERENCES t_orgs (ID), name varchar(48) ); CREATE VIEW organisations AS SELECT ID, name FROM t_orgs; CREATE VIEW people AS SELECT ID, org AS organisation, name AS fullname FROM t_ppl; And to this some rules and added defaults on the views to make them updateable in a nice fashion. But now the problem; the organisation column of the people view above is implicitly referencing the organisations view, as the underlying tables have this constraint. And I want the end user to be able to know about this. So I created a type and a function to query for this info such as: CREATE TYPE tableinfo_ret AS ( column name, default text, notnull boolean, references name ); CREATE FUNCTION tableinfo(a_table name) RETURNS SETOF tableinfo_ret AS $$ ... $$ LANGUAGE plpgsql STABLE SECURITY DEFINER; In my first attempt I depend on tables and views having the same names for columns to get it working, an ugly solution. It work for 9 of 10 cases but fails miserably for the rest. So I thought that maybe pg_depend could be used, after all a view is depending on the table it fetches data from. So I did some testing, for example: SELECT *, (SELECT relname FROM pg_class WHERE oid=refobjid LIMIT 1) FROM pg_depend WHERE objid=(SELECT oid FROM pg_class WHERE relname='people') AND deptype='n'; I find the result somewhat confusing. I get only one row as result, maybe this is fine as a view perhaps does not have dependencies for each of it's columns, but only one as a whole? But the fetched refobjid is not in pg_class, so surely not the underlying table? I do the select on the objid as the documentation specify this as the dependent object, and I interpret this as the view is dependent on the underlying table. This is not quite true in my opinion as one should be able to drop columns not used by the view in the underlying table. So there should be one row for each referenced column, should there not? If I swap objid for refobjid I do get more results, but none where objid and refobjid references to the table and view in any combination. Have I misunderstood the concept of pg_depend? Can it even be used for what I intend, and if not in what direction should I be searching next? Regards -- //Fredrik Olsson Treyst AB +46-19-362182 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] plperl error when making 8.2dev CVS
On 11/9/05, Tom Lane [EMAIL PROTECTED] wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Jaime Casanova wrote: ok, i execute 'make distclean' and then get the same error when making after configuring with --with-perl Is this a clean source tree? Try cvs update -C (beware it'll destroy all your local changes) I'm wondering about a clock skew problem (if machine's clock is in the past then SPI.xs might appear newer than derived files). If not that, it sounds like it would have to be a bug in gmake. regards, tom lane mmm... sorry for the noise... i download the CVS from my windows box (because i can't get my internal modem to work with linux :) for some reason i don't know sometimes when moving from windows to a linux dir shared with smb (in the same machine)... it converts file names from uppercase to lowercase so the file in linux was named spi.xs not SPI.xs... i realize that this was the problem just when replacing the entire source tree with same i downloaded in windows... this time the names got right and everything is fine... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Install issue on Windows and directorypermission
Are you talking about make install, initdb, or somethingi else? Not just the windows setup MSI. Without permissions to everyone it won't install -Original Message- From: Kevin Grittner [mailto:[EMAIL PROTECTED] Sent: Thursday, November 10, 2005 12:28 AM To: pgsql-hackers@postgresql.org; [EMAIL PROTECTED] Subject: Re: [HACKERS] Install issue on Windows and directorypermission In any event, is it really something you want to give Everyone the right to directly modify? -Kevin Gevik babakhani [EMAIL PROTECTED] Here I found an installation issue: - I was installing pg 8.1 on a Windows 2000 box. - I chose a different folder than default (D:\PGSERVER did not exist yet) - When installing, the setup complained about not being able to write into the directory - I check the directory permissions and saw that the Everyone group does not have Modify permissions - After setting the Modify permission, the setup continued and finished okay. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Underlying view columns?
Fredrik Olsson wrote: Have I misunderstood the concept of pg_depend? Can it even be used for what I intend, and if not in what direction should I be searching next? I'd take a few minutes to investigate the new-sys-views project and see if they've got anything you can steal: http://pgfoundry.org/projects/newsysviews -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Install issue on Windows and directorypermission
Gevik, this list is the wrong place to discuss this - please ask on the installer project site on the link I gave in an earlier reply. cheers andrew Gevik Babakhani wrote: Are you talking about make install, initdb, or somethingi else? Not just the windows setup MSI. Without permissions to everyone it won't install ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] pg_proc.h
contains the following: /* * initial contents of pg_proc * */ /* keep the following ordered by OID so that later changes can be made easier */ which has manifestly not been followed. Should we fix the file or remove the second comment? cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_proc.h
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Dunstan Sent: 10 November 2005 14:30 To: PostgreSQL-development Subject: [HACKERS] pg_proc.h contains the following: /* * initial contents of pg_proc * */ /* keep the following ordered by OID so that later changes can be made easier */ which has manifestly not been followed. Should we fix the file or remove the second comment? I vote for fixing the file (but then I'm not doing the work). Unused_oids or whatevers it's called is fine, but it's still handy to be able to read the file easily. Regards, Dave ---(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
[HACKERS] win32 8.1 pgadmin dll issues
My dev box was running 8.1rc1 and I thought it was time to put 8.1 on it. I downloaded the 8.1 binaries-only dist off of postgresql.org (bt version), did a binary swap on my server and nothing ran...it turns out all the binaries like initdb.exe, postgres.exe have a dll dependency on various pgAdmin dlls like comerr32.dll and several others. pgAdmin was not installed on my server so nothing worked. I copied the .dlls from the pgAdmin folder on my workstation and postgres starts up. Normally I roll my own so this may or may not be an issue...but when did initdb.exe acquire a pgAdmin dependency? Merlin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Comments from a Firebird user via Borland Newsgroups.
Tom Lane wrote: http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-set-transaction.html http://candle.pha.pa.us/main/writings/pgsql/sgml/transaction-iso.html It's a bit amusing that this person is dissing us for not having REPEATABLE READ, when what he actually seems to want is SERIALIZABLE (which we've had since 1999). Certainly REPEATABLE READ does *not* guarantee a stable view of data during one transaction --- see the discussion of phantom reads in the second link given above. regards, tom lane Tom, This is what the firebird guy said: Serializable is stricter and somehwat unusable in a multi-user, loaded database, because only one transaction can run at any time. Let's say you would have one long running serializable transaction encapsulating a reporting query, this will cause other transactions to wait. There is a pretty good paper on discussing why it was a somewhat bad idea to describe transaction isolation levels in terms of phenomena in the SQL standard. This paper also describes transaction isolation levels for MVCC databases. The paper is from 1995. http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/berenson-etal-1995.pdf SNAPSHOT in Firebird isn't a SQL standard compliant REPEATBLE READ either. SNAPSHOT in Firebird is between REPEATABLE READ and SERIALIZABLE, but without blocking other transactions. Is this true? will SERIALIZABLE block all transactions on the whole server, or just on that one connection? Thanks, Tony ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] win32 8.1 pgadmin dll issues
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Merlin Moncure Sent: 10 November 2005 14:56 To: pgadmin-hackers@postgresql.org Cc: pgsql-hackers@postgresql.org Subject: [HACKERS] win32 8.1 pgadmin dll issues My dev box was running 8.1rc1 and I thought it was time to put 8.1 on it. I downloaded the 8.1 binaries-only dist off of postgresql.org (bt version), did a binary swap on my server and nothing ran...it turns out all the binaries like initdb.exe, postgres.exe have a dll dependency on various pgAdmin dlls like comerr32.dll and several others. pgAdmin was not installed on my server so nothing worked. I copied the .dlls from the pgAdmin folder on my workstation and postgres starts up. Normally I roll my own so this may or may not be an issue...but when did initdb.exe acquire a pgAdmin dependency? It doesn't - they're all libpq dependencies, not pgAdmin ones (though pgAdmin does need them because it uses libpq of course). Commerr32 brb5_32 are Kerberos. Libiconv-2.dll libintl-2.dll are Gettext. Libeay32.dll and ssleay32.dll are Open SSL Regards, Dave. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] win32 8.1 pgadmin dll issues
My dev box was running 8.1rc1 and I thought it was time to put 8.1 on it. I downloaded the 8.1 binaries-only dist off of postgresql.org (bt version), did a binary swap on my server and nothing ran...it turns out all the binaries like initdb.exe, postgres.exe have a dll dependency on various pgAdmin dlls like comerr32.dll and several others. pgAdmin was not installed on my server so nothing worked. I copied the .dlls from the pgAdmin folder on my workstation and postgres starts up. Normally I roll my own so this may or may not be an issue...but when did initdb.exe acquire a pgAdmin dependency? It doesn't - they're all libpq dependencies, not pgAdmin ones (though pgAdmin does need them because it uses libpq of course). hm that makes sense...however those dlls are not provided in the binary only installation but are required because it is compiled with ssl, etc. The bt page doesn't state if ssl is required or not. I just assumed pgAdmin because that was the only place I could find a copy of the libraries. Merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Comments from a Firebird user via Borland Newsgroups.
On Thu, 10 Nov 2005, Tony Caduto wrote: Serializable is stricter and somehwat unusable in a multi-user, loaded database, because only one transaction can run at any time. Let's say you would have one long running serializable transaction encapsulating a reporting query, this will cause other transactions to wait. There is a pretty good paper on discussing why it was a somewhat bad idea to describe transaction isolation levels in terms of phenomena in the SQL standard. This paper also describes transaction isolation levels for MVCC databases. The paper is from 1995. http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/berenson-etal-1995.pdf SNAPSHOT in Firebird isn't a SQL standard compliant REPEATBLE READ either. SNAPSHOT in Firebird is between REPEATABLE READ and SERIALIZABLE, but without blocking other transactions. Is this true? will SERIALIZABLE block all transactions on the whole server, or just on that one connection? I don't believe so ... my understanding was that MVCC took care of any blocking issues, since we are looking at a 'snapshot' or 'layer' of data, based on the time you started the transaction ... other transactions can still work on data while the SERIALIZABLE transaction is going on ... The way I've thought about it is akin to going to a cash register to pay for groceries ... you don't want prices to change part way through the cashier ringing up your bill, but you also don't want to have the office shut everyone off while they update the price list ... so the cash register would be running the 'bill tally' in a SERIALIZABLE transaction, so that the prices are based on when (s)he started to ring things up ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Underlying view columns?
Fredrik Olsson [EMAIL PROTECTED] writes:
Have I misunderstood the concept of pg_depend? Can it even be used for
what I intend, and if not in what direction should I be searching next?
What you missed is that the per-column dependencies you are looking for
go from the view's rewrite rule to the underlying table.
Here's an example in CVS tip:
regression=# create table foo (f1 int, f2 text);
CREATE TABLE
regression=# create view bar as select * from foo;
CREATE VIEW
regression=# select
classid::regclass,objid,objsubid,refclassid::regclass,refobjid,refobjsubid,deptype
from pg_depend where refobjid in ('foo'::regclass,'bar'::regclass);
classid | objid | objsubid | refclassid | refobjid | refobjsubid | deptype
+---+--++--+-+-
pg_type| 62950 |0 | pg_class |62949 | 0 | i
pg_class | 62951 |0 | pg_class |62949 | 0 | i
pg_type| 62955 |0 | pg_class |62954 | 0 | i
pg_rewrite | 62956 |0 | pg_class |62954 | 0 | i
pg_rewrite | 62956 |0 | pg_class |62949 | 1 | n
pg_rewrite | 62956 |0 | pg_class |62949 | 2 | n
pg_rewrite | 62956 |0 | pg_class |62954 | 0 | n
(7 rows)
What we have there is:
* implicit dependency of foo's rowtype on foo.
* implicit dependency of foo's toast table on foo.
* implicit dependency of bar's rowtype on bar.
* implicit dependency of bar's ON SELECT rewrite rule on bar.
* normal dependency of bar's rewrite rule on foo.f1 (refobjsubid is the
column number).
* normal dependency of bar's rewrite rule on foo.f2.
* normal dependency of bar's rewrite rule on foo as a whole.
That last dependency comes from the appearance of foo in bar's FROM
list, while the per-column dependencies come from the individual column
references in the SELECT output list.
There isn't anything in pg_depend that would let you associate
particular columns of bar's output with particular dependencies, so I'm
not sure it really will help for your problem. I don't think there's
any way you could find that out except by parsing the stored rule
expression, which I would strongly NOT recommend, as your code will
inevitably break every time we modify expression trees (which is often).
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_proc.h
Andrew Dunstan [EMAIL PROTECTED] writes: contains the following: /* keep the following ordered by OID so that later changes can be made easier */ which has manifestly not been followed. Should we fix the file or remove the second comment? Reordering the file into strict OID order is certainly a loser, as it'd remove whatever semblance of logical structure remains. However I think the comment has some historical value. Perhaps reword it a bit. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_proc.h
Dave Page dpage@vale-housing.co.uk writes: I vote for fixing the file (but then I'm not doing the work). Unused_oids or whatevers it's called is fine, but it's still handy to be able to read the file easily. Our convention is that hand-assigned OIDs are *globally* unique, not just within the particular catalog. This means you *must* use unused_oids to find a free OID; eyeballing the catalog listing isn't enough, even if it were in strict order. Given that, I think readability really consists in keeping related functions together. If we were going to do any wholesale reordering, I'd want to see it done with an eye to sorting the functions into logical groups, not a blind numeric sort. regards, tom lane ---(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
Re: [HACKERS] Comments from a Firebird user via Borland Newsgroups.
Tony Caduto [EMAIL PROTECTED] writes: Tom, This is what the firebird guy said: Serializable is stricter and somehwat unusable in a multi-user, loaded database, because only one transaction can run at any time. He's already demonstrated that he has no clue what he's talking about, so I think you can discount the rest ;-) Serializability means that the database has to *give the illusion* of one-at-a-time execution, not that it must actually do things that way. Certainly we don't do things that way. See the extensive discussion in the MVCC chapter of our docs. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] win32 8.1 pgadmin dll issues
My dev box was running 8.1rc1 and I thought it was time to put 8.1 on it. I downloaded the 8.1 binaries-only dist off of postgresql.org (bt version), did a binary swap on my server and nothing ran...it turns out all the binaries like initdb.exe, postgres.exe have a dll dependency on various pgAdmin dlls like comerr32.dll and several others. pgAdmin was not installed on my server so nothing worked. I copied the .dlls from the pgAdmin folder on my workstation and postgres starts up. Exactly what DLLs are those? comerr32.dll is a Kerberos DLL and not a pgAdmin DLL.. Normally I roll my own so this may or may not be an issue...but when did initdb.exe acquire a pgAdmin dependency? It really shouldn't. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] win32 8.1 pgadmin dll issues
On Thu, Nov 10, 2005 at 04:24:46PM +0100, Magnus Hagander wrote: My dev box was running 8.1rc1 and I thought it was time to put 8.1 on it. I downloaded the 8.1 binaries-only dist off of postgresql.org (bt version), did a binary swap on my server and nothing ran...it turns out all the binaries like initdb.exe, postgres.exe have a dll dependency on various pgAdmin dlls like comerr32.dll and several others. pgAdmin was not installed on my server so nothing worked. I copied the .dlls from the pgAdmin folder on my workstation and postgres starts up. Exactly what DLLs are those? comerr32.dll is a Kerberos DLL and not a pgAdmin DLL.. I wonder if this is an artifact of the link everything into every binary even if we don't use it procedure. Hence the postmaster can depend on readline even though it doesn't use it. With gcc we're proposing --as-needed to resolve this, but how would that work for a windows platform? Can you examine a binary to see what it depends on? Hope this helps, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgp9XczJxLMID.pgp Description: PGP signature
Re: [HACKERS] win32 8.1 pgadmin dll issues
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martijn van Oosterhout Sent: 10 November 2005 15:42 To: Magnus Hagander Cc: Merlin Moncure; pgadmin-hackers@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] win32 8.1 pgadmin dll issues On Thu, Nov 10, 2005 at 04:24:46PM +0100, Magnus Hagander wrote: My dev box was running 8.1rc1 and I thought it was time to put 8.1 on it. I downloaded the 8.1 binaries-only dist off of postgresql.org (bt version), did a binary swap on my server and nothing ran...it turns out all the binaries like initdb.exe, postgres.exe have a dll dependency on various pgAdmin dlls like comerr32.dll and several others. pgAdmin was not installed on my server so nothing worked. I copied the .dlls from the pgAdmin folder on my workstation and postgres starts up. Exactly what DLLs are those? comerr32.dll is a Kerberos DLL and not a pgAdmin DLL.. I wonder if this is an artifact of the link everything into every binary even if we don't use it procedure. Hence the postmaster can depend on readline even though it doesn't use it. With gcc we're proposing --as-needed to resolve this, but how would that work for a windows platform? Can you examine a binary to see what it depends on? Those are the only dependencies, and are all intentional. Regards, Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] generic builtin functions
I am looking at creating a few generic functions builtin for the enum stuff. These would be tied to each enum type as it is created. However, they should not really appear in pg_proc initially, as there wouldn't be any enum types to tie them to anyway. But I want them to have reserved oids and appear in the list of builtins. So I could hack genbki to exclude them, or I could add some code to remove them from pg_proc after the event. Bioth of these some a bit hackish. Maybe there's a trick I'm not aware of? cheers andrew ---(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
Re: [HACKERS] generic builtin functions
On Thu, Nov 10, 2005 at 12:02:58PM -0500, Andrew Dunstan wrote: I am looking at creating a few generic functions builtin for the enum stuff. These would be tied to each enum type as it is created. However, they should not really appear in pg_proc initially, as there wouldn't be any enum types to tie them to anyway. But I want them to have reserved oids and appear in the list of builtins. Why? What's wrong with creating the functions when people use the module, like every other module in contrib? Is there a reason you need fixed oids? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpRSycCWBbcd.pgp Description: PGP signature
Re: [HACKERS] generic builtin functions
Martijn van Oosterhout wrote: On Thu, Nov 10, 2005 at 12:02:58PM -0500, Andrew Dunstan wrote: I am looking at creating a few generic functions builtin for the enum stuff. These would be tied to each enum type as it is created. However, they should not really appear in pg_proc initially, as there wouldn't be any enum types to tie them to anyway. But I want them to have reserved oids and appear in the list of builtins. Why? What's wrong with creating the functions when people use the module, like every other module in contrib? Is there a reason you need fixed oids? This is not intended for contrib. The whole point of the exercise is to have language support, which means either it's builtin or it doesn't happen. See my email with a general outline from a few days ago. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Possible savepoint bug
On Wed, 2005-11-09 at 14:20 -0500, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: As you can see, we have duplicates within the table (heap) of a primary key value. The index itself only references one of these tuples. Can you put together a test case to reproduce this? It doesn't have to fail every time, as long as it fails once in awhile ... Seems not. I've done millions of iterations of the same type of functionality that happens with these structures and haven't produced a single case. These are fairly low usage structures, so I think I've done about 3 months worth of work, which in production had 20 bad tuples. I tried playing with various delays, vacuum schedules, and number of parallel processes. Whatever is happening is from interaction not contained within the structures showing the symptoms. I'll watch it a bit closer now that I know the problem exists to see if I can find a pattern. -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] generic builtin functions
Andrew Dunstan [EMAIL PROTECTED] writes: I am looking at creating a few generic functions builtin for the enum stuff. These would be tied to each enum type as it is created. However, they should not really appear in pg_proc initially, as there wouldn't be any enum types to tie them to anyway. But I want them to have reserved oids and appear in the list of builtins. This feels wrong to me. Ways that might work include: 1. Invent a pseudotype 'anyenum' comparable to 'anyarray', and define the generic functions as taking 'anyenum'. 2. Don't try to define the generic operations as true functions, but make them special syntactic constructs comparable to ROW() or ARRAY[]. I think I like #1 better, but it's hard to be sure when discussing it in a vacuum. How about being more specific about what you want to accomplish? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I am looking at creating a few generic functions builtin for the enum stuff. These would be tied to each enum type as it is created. However, they should not really appear in pg_proc initially, as there wouldn't be any enum types to tie them to anyway. But I want them to have reserved oids and appear in the list of builtins. This feels wrong to me. Ways that might work include: 1. Invent a pseudotype 'anyenum' comparable to 'anyarray', and define the generic functions as taking 'anyenum'. 2. Don't try to define the generic operations as true functions, but make them special syntactic constructs comparable to ROW() or ARRAY[]. I think I like #1 better, but it's hard to be sure when discussing it in a vacuum. How about being more specific about what you want to accomplish? Yeah, after a bit more thought I came to the conclusion that it wouldn't fly. What I want to have is some builtin functions that can be used as the input/output/cast/etc functions for each enum type. The idea wasn't to allow users to overload the functions. I guess we could invent an anyenum pseudotype without actually exposing it via the grammar. Will keep thinking ... cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] generic builtin functions
Andrew Dunstan [EMAIL PROTECTED] writes: What I want to have is some builtin functions that can be used as the input/output/cast/etc functions for each enum type. The hard part of that is going to be figuring out how to get the information to the functions about which enum type they're being invoked for. Output functions in particular are handed little except the data value itself. Possibly the internal representation of an enum could be 8 bytes: 4 bytes for type OID and 4 more for value. No doubt the mysql guys would rag on us for using too much disk space :-(. But if you did that then the generics would just be anyenum and done. I guess we could invent an anyenum pseudotype without actually exposing it via the grammar. Why do you think you need to hide it? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Obtaining a source tree from CVS
Hello, how can i make a checkout from CVS server ? What is the address? Thanks, Gustavo
Re: [HACKERS] Obtaining a source tree from CVS
On Thu, 2005-10-11 at 15:22 -0300, Gustavo Tonini wrote: how can i make a checkout from CVS server ? What is the address? http://www.postgresql.org/developer/sourcecode/ -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Comments from a Firebird user via Borland
Hi Tony, As the referenced documentation states, the PostgreSQL SERIALIZABLE transaction isolation level complies with the ANSI/ISO requirements, but not with a mathematically pure interpretation of the term. (The only quibble I have with that documentation is that you have to be averting your eyes to not find several commercial products which do enforce the stricter interpretation.) As far as I can see, the difference is only significant if you need to have two concurrent transactions where one transaction is selecting from a set of data A to modify something within a set of data B at the same time that another transaction is selecting from B to modify something within A -- without any overlap between the rows updated by the transactions. In practice, this seems unlikely to be meaningful outside of some theoretical science; you don't normally want recursive redundancies in your database. So to address the original concern -- PostgreSQL absolutely gives you a stable view of the data during a SERIALIZABLE transaction. The only thing it doesn't give you is a guarantee that some other transaction hasn't made modifications which would change what the same SELECTs would show if you were to start a NEW transaction. -Kevin Tony Caduto [EMAIL PROTECTED] Tom Lane wrote: http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-set-transaction.html http://candle.pha.pa.us/main/writings/pgsql/sgml/transaction-iso.html It's a bit amusing that this person is dissing us for not having REPEATABLE READ, when what he actually seems to want is SERIALIZABLE (which we've had since 1999). Certainly REPEATABLE READ does *not* guarantee a stable view of data during one transaction --- see the discussion of phantom reads in the second link given above. regards, tom lane Tom, This is what the firebird guy said: Serializable is stricter and somehwat unusable in a multi-user, loaded database, because only one transaction can run at any time. Let's say you would have one long running serializable transaction encapsulating a reporting query, this will cause other transactions to wait. There is a pretty good paper on discussing why it was a somewhat bad idea to describe transaction isolation levels in terms of phenomena in the SQL standard. This paper also describes transaction isolation levels for MVCC databases. The paper is from 1995. http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/berenson-etal-1995.pdf SNAPSHOT in Firebird isn't a SQL standard compliant REPEATBLE READ either. SNAPSHOT in Firebird is between REPEATABLE READ and SERIALIZABLE, but without blocking other transactions. Is this true? will SERIALIZABLE block all transactions on the whole server, or just on that one connection? Thanks, Tony ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload
I've also modified the Makefile. I removed the special .sql.in : .sql implicit rule and re-organized the Makefile. I didn't commit as it was after 12:00pm when I finished... I'll send you what I did when I return home. If you just replaced the $libdir with $$libdir, then a merge will be easy. Cheers, Rob On Thu, 10 Nov 2005 14:43:30 +0300 Teodor Sigaev [EMAIL PROTECTED] wrote: I fixed path in pg_sphere (and done some more clean up). BTW, I usially install contrib modules before restoring database (of course, it need to dump db without content of modules)... -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(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
Re: [HACKERS] Another pgindent gripe
FYI, I am looking into all the reports of pgindent failures and will have those fixed and a sample re-run diff posted in a few days. --- Chuck McDevitt wrote: 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 Tom Lane Sent: Monday, November 07, 2005 8:19 AM To: Neil Conway Cc: Bruce Momjian; Hackers Subject: Re: [HACKERS] Another pgindent gripe 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_e xe c.c.diff?r1=1.152;r2=1.153 Oy vey! Why did it insert spaces after the stars in all those function declarations? That's certainly not in conformance with project style ... and I don't see it having happened elsewhere. Seems like pgindent has suffered some significant regressions since the 8.0 run. I thought it had not been changed much at all, but evidently that's wrong. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Obtaining a source tree from CVS
On Thursday 10 November 2005 10:22, Gustavo Tonini wrote: Hello, how can i make a checkout from CVS server ? What is the address? You can find all the information you need to know about how to check pgsql out of cvs at: http://www.postgresql.org/developer/sourcecode/ Thanks, Gustavo -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Install issue on Windows and directory permission
Just a point of attention... Perhaps one is interested to fix this (if it is a bug); Um, so what actually is the problem? //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Install issue on Windows and directory permission
If you mean that you have to grant permissions, that's already in the FAQ. //Magnus Just a point of attention... Perhaps one is interested to fix this (if it is a bug); Um, so what actually is the problem? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] generic builtin functions
Greg Stark [EMAIL PROTECTED] writes: Maybe my conception of enums is different from yours. My conception is basically that of C enums. Where they're purely a creature of the syntax and type system. At run-time they don't make any effort to prevent you from treating them as integers. Well, C is notorious for its weak notions of type, so I hardly think that counts as precedent for what we should do in SQL ;-) I don't mind offering a cast from enum to integer, at all, but I think it needs to be explicit-only. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
On Thu, Nov 10, 2005 at 01:15:07PM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: What I want to have is some builtin functions that can be used as the input/output/cast/etc functions for each enum type. The hard part of that is going to be figuring out how to get the information to the functions about which enum type they're being invoked for. Output functions in particular are handed little except the data value itself. For my taggedtypes module I simply created an output function for each type, but they all referred to the same C function. The fmgr interface does allow you to retreive your own OID, which allows you to search the catalog to determine what type you were called with and/or need to return. I actually built a little LRU cache for the function-to-return-type lookup to avoid most of the overhead. Possibly the internal representation of an enum could be 8 bytes: 4 bytes for type OID and 4 more for value. No doubt the mysql guys would rag on us for using too much disk space :-(. But if you did that then the generics would just be anyenum and done. That's another way, but it is really worth the effort to make another any* type. For arrays it's worth it because people assume you can make an array of most things. But enums needs to be explicitly defined and how many enums are you expecting anyway. Is pg_proc bloat an actual concern? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpT5eDXudibb.pgp Description: PGP signature
Re: [HACKERS] Obtaining a source tree from CVS
On Thu, 2005-11-10 at 11:00 -0800, Darcy Buskermolen wrote: On Thursday 10 November 2005 10:22, Gustavo Tonini wrote: Hello, how can i make a checkout from CVS server ? What is the address? You can find all the information you need to know about how to check pgsql out of cvs at: http://www.postgresql.org/developer/sourcecode/ Also if you are looking for a pretty interface to the source code and all the revision notes you may want to take a look at: http://projects.commandprompt.com/projects/public/pgsql Sincerely, Joshua D. Drake Thanks, Gustavo -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] generic builtin functions
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: What I want to have is some builtin functions that can be used as the input/output/cast/etc functions for each enum type. The hard part of that is going to be figuring out how to get the information to the functions about which enum type they're being invoked for. Output functions in particular are handed little except the data value itself. Possibly the internal representation of an enum could be 8 bytes: 4 bytes for type OID and 4 more for value. No doubt the mysql guys would rag on us for using too much disk space :-(. But if you did that then the generics would just be anyenum and done. Eek! I would be prepared to go to quite a lot of trouble to avoid that. My idea was to have the functions that need access to the text values look up fcinfo-flinfo-fn_oid and then use that to look up the type info. But that would mean we would need pg_proc entries for these functions for each enum, even if it's the same function underneath, wouldn't it? I guess we could invent an anyenum pseudotype without actually exposing it via the grammar. Why do you think you need to hide it? Just desire not to clutter needlessly. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] generic builtin functions
Andrew Dunstan [EMAIL PROTECTED] writes: My idea was to have the functions that need access to the text values look up fcinfo-flinfo-fn_oid and then use that to look up the type info. But that would mean we would need pg_proc entries for these functions for each enum, even if it's the same function underneath, wouldn't it? Yeah, and you still have to have a pg_proc entry for the original underlying function, else it doesn't get into the builtins list. It's worth pointing out also that while aliasing a builtin function after-the-fact like that is possible, lookup for it is substantially slower than a normal builtin (because we can't do a binary search on OID for it). That's on top of the function-to-type-oid lookup you'll have to do within the function. I'm not convinced that using bigint-equivalent space for an enum is a mortal sin... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 8.0 - 8.1 dump duplicate key problem?
I have an interesting situation...am staging a mock upgrade from 8.0 to 8.1 on a bzip compressed backup image from one of our production servers. The dump image is big (270 mb compressed) and so is the file in question ~ 440k rows. Am piping the backup image to the server via psql -cd backup.bz2 | psql zyx When the dump gets to the point where the indexes/keys are built, the primary key fails to build due to duplicate key constraint failure. However, after dump is complete, I can create the p-key without any modification to the table and everything is fine. The error is reproducible...I have confirmed in two separate runs. The source 8.0 database is still up and does not report any dups in the p-key fields, which of course it shouldn't. Merlin ---(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
Re: [HACKERS] generic builtin functions
On Thu, Nov 10, 2005 at 03:28:55PM -0500, Andrew Dunstan wrote: Eek! I would be prepared to go to quite a lot of trouble to avoid that. My idea was to have the functions that need access to the text values look up fcinfo-flinfo-fn_oid and then use that to look up the type info. But that would mean we would need pg_proc entries for these functions for each enum, even if it's the same function underneath, wouldn't it? There are functions in the backend already to help you: argoid = procLookupArgType( fcinfo-flinfo-fn_oid, 0 ); returns the OID of the type of your first arguments. returnoid = procLookupRettype( fcinfo-flinfo-fn_oid ); returns your return type. These work even if you are in a type input/output function. Here is some code that uses these: http://svana.org/kleptog/pgsql/taggedtypes.html Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgp6gRYaYw6T1.pgp Description: PGP signature
Re: [HACKERS] generic builtin functions
Greg Stark wrote: I know the tendency has been to want to discourage implicit casts, but I think this is a good use for them. The whole point of enums is to have syntactic sugar over integers that let you use nicer syntax but that imposes minimal additional complexity over simply using integers. Maybe my conception of enums is different from yours. My conception is basically that of C enums. Where they're purely a creature of the syntax and type system. At run-time they don't make any effort to prevent you from treating them as integers. Well, for one thing, I have no plan to allow explicit setting of the internal representational value, as one can do in C. And the fact that it's an int underneath is in implementation detail, IMNSHO. After all, KL just advised using a text domain with a check constraint for enums, so int storage is hardly a fundamental part of enum-ness. Maybe this all just reflects my background in languages that are more strongly typed than C and have first class enums. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
Andrew Dunstan [EMAIL PROTECTED] writes: Well, for one thing, I have no plan to allow explicit setting of the internal representational value, as one can do in C. And the fact that it's an int underneath is in implementation detail, IMNSHO. After all, KL just advised using a text domain with a check constraint for enums, so int storage is hardly a fundamental part of enum-ness. Well it is in that there's not much point to them if it's not. That is, you can _already_ use a text domain with check constraints if you want. The only point to enums is to let you get the syntax niceness that provides without burdening the implementation with any costs. That is, the whole point of enums is to let you have your cake and eat it to. You get to give the programmers a nice safe interface but tell your DBA you're storing the most space efficient storage format possible. If you don't get that then you may as well use integers or text strings as you prefer. Maybe this all just reflects my background in languages that are more strongly typed than C and have first class enums. I suspect this is a matter of perspective. If you speak to the programmers they're liable to agree with you that these languages give this abstract enum thing that could just as easily be stored as strings. But if you speak to the language designers they'll tell you that the whole point was to package up an integer-backed storage in an abstract way and if you implemented them as text there wouldn't have been any point in having them in the language. Even languages like lisp treat symbols as integers internally. The whole point of having symbols is to give an abstraction that programmers can use to hide the internally grungy details that allow reasonably efficient implementations. symbols in lisp can be stored and compared efficiently because they're interned and can be treated as integers. If they were stored as strings there would be no point in having them. -- greg ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
Tom Lane wrote: I'm not convinced that using bigint-equivalent space for an enum is a mortal sin... at least venial ... cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
On Thu, Nov 10, 2005 at 04:08:29PM -0500, Andrew Dunstan wrote: Tom Lane wrote: I'm not convinced that using bigint-equivalent space for an enum is a mortal sin... at least venial ... Heh. Would ORDER BY somehow know about enums' given ordering? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Obtaining a source tree from CVS
On Thu, 2005-11-10 at 15:23, Joshua D. Drake wrote:
On Thu, 2005-11-10 at 11:00 -0800, Darcy Buskermolen wrote:
On Thursday 10 November 2005 10:22, Gustavo Tonini wrote:
Hello,
how can i make a checkout from CVS server ? What is the address?
You can find all the information you need to know about how to check pgsql
out
of cvs at: http://www.postgresql.org/developer/sourcecode/
Also if you are looking for a pretty interface to the source code and
all the revision notes you may want to take a look at:
http://projects.commandprompt.com/projects/public/pgsql
Does anyone have an opinion on linking to this from the page Darcy gave
above? Like they are against it unless its hosted on a pg server? Or
they are against it until it can be more real time? Otherwise I think I
will add it.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] generic builtin functions
David Fetter wrote: On Thu, Nov 10, 2005 at 04:08:29PM -0500, Andrew Dunstan wrote: Tom Lane wrote: I'm not convinced that using bigint-equivalent space for an enum is a mortal sin... at least venial ... Heh. Would ORDER BY somehow know about enums' given ordering? ORDER BY (and all inequality operators) will reflect the defined enumeration ordering, as happens today with enumkit-defined types. That is a fundamental requirement that I won't deviate from. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
On Thu, Nov 10, 2005 at 05:26:45PM -0500, Andrew Dunstan wrote: David Fetter wrote: On Thu, Nov 10, 2005 at 04:08:29PM -0500, Andrew Dunstan wrote: Tom Lane wrote: I'm not convinced that using bigint-equivalent space for an enum is a mortal sin... at least venial ... Heh. Would ORDER BY somehow know about enums' given ordering? ORDER BY (and all inequality operators) will reflect the defined enumeration ordering, as happens today with enumkit-defined types. That is a fundamental requirement that I won't deviate from. Great :) :) I hadn't understood how the enumkit stuff worked. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(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
Re: [HACKERS] generic builtin functions
Tom Lane said: Andrew Dunstan [EMAIL PROTECTED] writes: My idea was to have the functions that need access to the text values look up fcinfo-flinfo-fn_oid and then use that to look up the type info. But that would mean we would need pg_proc entries for these functions for each enum, even if it's the same function underneath, wouldn't it? Yeah, and you still have to have a pg_proc entry for the original underlying function, else it doesn't get into the builtins list. It's worth pointing out also that while aliasing a builtin function after-the-fact like that is possible, lookup for it is substantially slower than a normal builtin (because we can't do a binary search on OID for it). That's on top of the function-to-type-oid lookup you'll have to do within the function. I'm not convinced that using bigint-equivalent space for an enum is a mortal sin... What about having the calling code fill in the io type oid in an extra field in the flinfo? That possibly still leaves the builtin/aliasing issue ... that deserves more thought. There's no rush on this. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] generic builtin functions
Andrew Dunstan [EMAIL PROTECTED] writes: What about having the calling code fill in the io type oid in an extra field in the flinfo? I don't think that's workable; for one thing there's the problem of manual invocation of the I/O functions, which is not going to provide any such special hack. It also turns the enum proposal into a seriously invasive patch (hitting all PLs both inside and outside the core, for instance), at which point you'll start encountering some significant push-back. BTW, you might want to think about what'd be involved in supporting arrays and domains over enums ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?
Merlin Moncure [EMAIL PROTECTED] writes: When the dump gets to the point where the indexes/keys are built, the primary key fails to build due to duplicate key constraint failure. However, after dump is complete, I can create the p-key without any modification to the table and everything is fine. That's pretty bizarre. What's the datatype of the key column(s)? Can you reduce it to a smaller test case, or perhaps send me the full dump off-list? (270m is a bit much for email, but web or ftp would work ... also, presumably only the pkey column is needed to generate the error ...) regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Module incompatibility detection between 8.0 and 8.1
I just make postgresql 8.1 rpm for mandriva and I was making basic test. I made in pgfoundry the module pgrpm (rpm function in postgres). However after installing postgresql 8.1 I have: ERREUR: unable to load library «/usr/lib64/pgsql/pgrpm.so»: /usr/lib64/pgsql/pgrpm.so: undefined symbol: MemoryContextSwitchTo Well the problem here is the module was build with postgresql 8.0. I will rebuild the module ASAP, this is not a problem. The problem is rpm has no way to detect this kind of issue: $ rpm -q --requires pgrpm rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) librpm-4.4.so()(64bit) Does anyone allready think to add marker into module, and maybe into postgres and giving a way to rpm or other packaging tools to detect broken linkage ? To fix the issue, I will add a provide into postgresql-server package, something like postgresql-ABI = 8.1, add equivalent requires into modules. pgpbegVvz6u7J.pgp Description: PGP signature
Re: [HACKERS] Comments from a Firebird user via Borland
On Thu, Nov 10, 2005 at 12:00:12 -0600, Kevin Grittner [EMAIL PROTECTED] wrote: Hi Tony, As the referenced documentation states, the PostgreSQL SERIALIZABLE transaction isolation level complies with the ANSI/ISO requirements, but not with a mathematically pure interpretation of the term. (The only quibble I have with that documentation is that you have to be averting your eyes to not find several commercial products which do enforce the stricter interpretation.) For cases where you really need predicate locking, you can use full table locks. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?
On Thu, 10 Nov 2005, Tom Lane wrote: When the dump gets to the point where the indexes/keys are built, the primary key fails to build due to duplicate key constraint failure. That's pretty bizarre. What's the datatype of the key column(s)? There was one guy on IRC that had the same problem. We didn't get that much info about it and suggested that he check the original database for corruption (rebuilding indexes) to make sure it's in a proper state. Either this is the same guy or/and we might have a bigger problem. The guy on irc also had an integer PK. -- /Dennis Björklund ---(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
Re: [HACKERS] Underlying view columns?
Tom Lane wrote: Fredrik Olsson [EMAIL PROTECTED] writes: Have I misunderstood the concept of pg_depend? Can it even be used for what I intend, and if not in what direction should I be searching next? What you missed is that the per-column dependencies you are looking for go from the view's rewrite rule to the underlying table. snip There isn't anything in pg_depend that would let you associate particular columns of bar's output with particular dependencies, so I'm not sure it really will help for your problem. I don't think there's any way you could find that out except by parsing the stored rule expression, which I would strongly NOT recommend, as your code will inevitably break every time we modify expression trees (which is often). regards, tom lane Thanks for the good explanation. I resort to keep depending on name-similarities, with added exceptions for legacy objects. That and some well documented guidelines for this projects future additions solves the problem, in a way that looks good to the end user at least :). -- //Fredrik Olsson Treyst AB +46-19-362182 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
