Re: [HACKERS] Mailing list archives available?
http://www.postgresql.org/mhonarc has them all listed .. not sure how to
get there from the Web site ... Vince?
On Mon, 23 Oct 2000, Krzysztof Kowalczyk wrote:
> Are mailing list archives of various postgresql mailing list available
> anywhere?
>
> I know they were some time ago but I couldn't find any link on
> www.postgresql.org now. I subscribed to a list mainly because I want to
> monitor the progress but the amount of messages kills my inbox. It would
> be really convenient for me if I could just browse the archives on web
> once in a while.
>
> Krzysztof Kowalczyk
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
[HACKERS] Mailing list archives available?
Are mailing list archives of various postgresql mailing list available anywhere? I know they were some time ago but I couldn't find any link on www.postgresql.org now. I subscribed to a list mainly because I want to monitor the progress but the amount of messages kills my inbox. It would be really convenient for me if I could just browse the archives on web once in a while. Krzysztof Kowalczyk
[HACKERS] libpq needs -lsocket on UnixWare
Is there any way to get libpq built with -lsocket on the unixware (and probably other SVR4's) to get the network stuff required ? (other SVR4's prolly need -lsocket -lnsl) Larry -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 PGP signature
Re: [HACKERS] relation ### modified while in use
"Mikheev, Vadim" wrote: > > > > I've wondered why AccessShareLock is a short term lock. > > > > > > MUST BE. AccessShare-/Exclusive-Locks are *data* locks. > > > If one want to protect schema then new schema share/excl locks > > > must be inroduced. There is no conflict between data and > > > schema locks - they are orthogonal. > > > > > > > Oracle doesn't have Access...Lock locks. > > Oracle has no vacuum. We need in AccessExclusiveLock to > support vacuum - to stop any concurrent scans over table. > > But maybe I try to make things more complex without > good reason - long term AccessShareLock would just > block vacuum till transaction end (in addition to blocked > concurrent DDL statements we discuss now) - not big > inconvenience probably. > So ok, I have no strong objection against using > Access...Locks as schema locks. > > > In my understanding,locking levels you provided contains > > an implicit share/exclusive lock on the corrsponding > > pg_class tuple i.e. AccessExclusive Lock acquires an > > exclusive lock on the corresping pg_class tuple and > > other locks acquire a share lock, Is it right ? > > No. Access...Locks are acquired over target table > (table' oid is used as key for lmgr hash table), > not over corresponding pg_class tuple, in what case > we would use pg_clas' oid + table' oid as key > (possibility I've described below). > Yes,I know that "lock table" doesn't touch the correpon ding pg_class tuple at all. However isn't it equivalent ? At least > > > > > If we have a mechanism to acquire a share lock on a tuple,we > need Access(Share/Exclusive)Lock ? > ... > > > - we could add oid to union above and lock tables by acquiring lock > > > on pg_class with objId.oid = table' oid. Same way we could > > > lock indices and whatever we want... if we want -:) > > > > As you know well,this implemenation has a flaw that we have > > to be anxious about the shortage of shared memory. > > Didn't you asked about share lock on a tuple? > Share locks may be kept in memory only. > I've just pointed that we have such mechanism -:) Hmm,I remember you refered to SHARE lock on tuples once. I wasn't able to suppose how you would implement it then. I've also thought the enhancement of current locking machanism which had been used for page level locking but have always been discouraged by the shmem shortage flaw. Regards. Hiroshi Inoue
[HACKERS] TODO updates
I believe these TODO items can now be marked "done": * SELECT foo UNION SELECT foo is incorrectly simplified to SELECT foo * Be smarter about promoting types when UNION merges different data types [ actually UNION is now exactly as smart as CASE, which is still not good enough, but it's no longer a UNION problem --- the issue is how much knowledge we have of type promotion ] * redesign INSERT ... SELECT to have two levels of target list * have INTERSECT/EXCEPT prevent duplicates unless ALL is specified * Views containing aggregates sometimes fail(Jan) * SELECT ... UNION ... ORDER BY fails when sort expr not in result list [ this is now disallowed, rather than misbehaving ] * SELECT ... UNION ... GROUP BY fails if column types disagree, no type promotion occurs * Allow long tuples by chaining or auto-storing outside db (TOAST)(Jan) * Allow compression of large fields or a compressed field type * Large objects o Fix large object mapping scheme, own typeid or reltype(Peter) o Not to stuff everything as files in a single directory, hash dirs o Allow large object vacuuming o Tables that start with xinv confused to be large objects * Allow DISTINCT on views * Allow views of aggregate columns * Allow views with subselects * Support UNION/INTERSECT/EXCEPT in sub-selects * Redesign the function call interface to handle NULLs better[function](Tom) * redesign UNION structures to have separarate target lists * Allow multi-level query trees for INSERT INTO ... SELECT * use fmgr_info()/fmgr_faddr() instead of fmgr() calls in high-traffic places, like GROUP BY, UNIQUE, index processing, etc. * In WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3 * Remove ANALYZE from VACUUM so it can be run separately without locks Also, this is no longer relevant for large objects, though perhaps still of interest for sort files: * Put sort files, large objects in their own directory regards, tom lane
[HACKERS] JDBC now needs updates for large objects
Peter, As of current sources, large objects no longer occupy tables named 'xinv' nor indexes named 'xinx'. Therefore, it'd be appropriate to remove the special tests that exclude tables/indices named that way from the tests in DatabaseMetaData.java. I have not done this because I'm not in a position to test changes to the JDBC driver; would you please add it to your todo list? regards, tom lane
[HACKERS] Re: TODO updates
Thanks. Changes made. That's a lot of stuff. > I believe these TODO items can now be marked "done": > > * SELECT foo UNION SELECT foo is incorrectly simplified to SELECT foo > * Be smarter about promoting types when UNION merges different data types > > [ actually UNION is now exactly as smart as CASE, which is still > not good enough, but it's no longer a UNION problem --- the > issue is how much knowledge we have of type promotion ] > > * redesign INSERT ... SELECT to have two levels of target list > * have INTERSECT/EXCEPT prevent duplicates unless ALL is specified > > * Views containing aggregates sometimes fail(Jan) > > * SELECT ... UNION ... ORDER BY fails when sort expr not in result list > > [ this is now disallowed, rather than misbehaving ] > > * SELECT ... UNION ... GROUP BY fails if column types disagree, no type > promotion occurs > > * Allow long tuples by chaining or auto-storing outside db (TOAST)(Jan) > > * Allow compression of large fields or a compressed field type > * Large objects > o Fix large object mapping scheme, own typeid or reltype(Peter) > o Not to stuff everything as files in a single directory, hash dirs > o Allow large object vacuuming > o Tables that start with xinv confused to be large objects > > * Allow DISTINCT on views > * Allow views of aggregate columns > * Allow views with subselects > > * Support UNION/INTERSECT/EXCEPT in sub-selects > > * Redesign the function call interface to handle NULLs better[function](Tom) > > * redesign UNION structures to have separarate target lists > * Allow multi-level query trees for INSERT INTO ... SELECT > > * use fmgr_info()/fmgr_faddr() instead of fmgr() calls in high-traffic > places, like GROUP BY, UNIQUE, index processing, etc. > > * In WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3 > > * Remove ANALYZE from VACUUM so it can be run separately without locks > > > Also, this is no longer relevant for large objects, though perhaps still > of interest for sort files: > > * Put sort files, large objects in their own directory > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
RE: [HACKERS] relation ### modified while in use
> > > I've wondered why AccessShareLock is a short term lock. > > > > MUST BE. AccessShare-/Exclusive-Locks are *data* locks. > > If one want to protect schema then new schema share/excl locks > > must be inroduced. There is no conflict between data and > > schema locks - they are orthogonal. > > > > Oracle doesn't have Access...Lock locks. Oracle has no vacuum. We need in AccessExclusiveLock to support vacuum - to stop any concurrent scans over table. But maybe I try to make things more complex without good reason - long term AccessShareLock would just block vacuum till transaction end (in addition to blocked concurrent DDL statements we discuss now) - not big inconvenience probably. So ok, I have no strong objection against using Access...Locks as schema locks. > In my understanding,locking levels you provided contains > an implicit share/exclusive lock on the corrsponding > pg_class tuple i.e. AccessExclusive Lock acquires an > exclusive lock on the corresping pg_class tuple and > other locks acquire a share lock, Is it right ? No. Access...Locks are acquired over target table (table' oid is used as key for lmgr hash table), not over corresponding pg_class tuple, in what case we would use pg_clas' oid + table' oid as key (possibility I've described below). > > > If we have a mechanism to acquire a share lock on a tuple,we ^ > > > could use it for managing system info generally. However the > > > only allowed lock on a tuple is exclusive. > > > Access(Share/Exclusive) > > ... > > - we could add oid to union above and lock tables by acquiring lock > > on pg_class with objId.oid = table' oid. Same way we could > > lock indices and whatever we want... if we want -:) > > As you know well,this implemenation has a flaw that we have > to be anxious about the shortage of shared memory. Didn't you asked about share lock on a tuple? Share locks may be kept in memory only. I've just pointed that we have such mechanism -:) Another possible answer is - Shared Catalog Cache. Vadim
Re: [HACKERS] relation ### modified while in use
Vadim Mikheev wrote:
> > > in general. What I'm proposing is that once an xact has touched a
> > > table, other xacts should not be able to apply schema updates to that
> > > table until the first xact commits.
> > >
> >
> > I agree with you.
>
> I don't know. We discussed this issue just after 6.5 and decided to
> allow concurrent schema modifications.
> Oracle has disctionary locks but run each DDL statement in separate
> xaction, so - no deadlock condition here. OTOH, I wouldn't worry
> about deadlock - one just had to follow common anti-deadlock rules.
>
> > I've wondered why AccessShareLock is a short term lock.
>
> MUST BE. AccessShare-/Exclusive-Locks are *data* locks.
> If one want to protect schema then new schema share/excl locks
> must be inroduced. There is no conflict between data and
> schema locks - they are orthogonal.
>
Oracle doesn't have Access...Lock locks.
In my understanding,locking levels you provided contains
an implicit share/exclusive lock on the corrsponding
pg_class tuple i.e. AccessExclusive Lock acquires an
exclusive lock on the corresping pg_class tuple and
other locks acquire a share lock, Is it right ?
>
> We use AccessShare-/Exclusive-Locks for schema because of...
> we allow concurrent schema modifications and no true schema
> locks were required.
>
> > If we have a mechanism to acquire a share lock on a tuple,we
> > could use it for managing system info generally. However the
> > only allowed lock on a tuple is exclusive. Access(Share/Exclusive)
>
> Actually, just look at lock.h:LTAG structure - lock manager supports
> locking of "some objects" inside tables:
>
> typedef struct LTAG
> {
> OidrelId;
> OiddbId;
> union
> {
> BlockNumberblkno;
> Transactionxid;
> } objId;
> ...
> - we could add oid to union above and lock tables by acquiring lock
> on pg_class with objId.oid = table' oid. Same way we could lock indices
> and whatever we want... if we want -:)
>
As you know well,this implemenation has a flaw that we have
to be anxious about the shortage of shared memory.
> > Lock on tables would give us a restricted solution about pg_class
> > tuples.
> >
> > Thers'a possibility of deadlock in any case but there are few
> > cases when AccessExclusiveLock is really needed and we could
> > acquire an AccessExclusiveLock manually from the first if
> > necessary.
> >
> > I'm not sure about the use of AccessShareLock in parse-analyze-
> > optimize phase however.
>
> There is notion about breakable (parser) locks in Oracle documentation -:)
>
I've known it also but don't know how to realize the similar
concept in PostgreSQL.
Regards.
Hiroshi Inoue
BLERe: AW: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB wrote: > > > > What I'm proposing is that once an xact has touched a > > > > table, other xacts should not be able to apply schema updates to that > > > > table until the first xact commits. > > > > > > No, this would mean too many locks, and would leave the dba with hardly a > > > chance to alter a table. > > > > > > > Are there many applications which have many SELECT statements(without > > FOR UPDATE) in one tx ? > > Why not ? > It seems to me that multiple SELECT statements in a tx has little meaning unless the tx is executed in SERIALIZABLE isolation level. > > > As for locks,weak locks doesn't pass intensive locks. Dba > > seems to be able to alter a table at any time. > > Sorry, I don't understand this sentence. Tom suggested placing a shared lock on > any table that is accessed until end of tx. Noone can alter table until all users >have > closed their txns and not accessed tables again. Remember that this would include > creating an index ... > What I meant is the following though I may be misunderstanding your point. Session-1. # begin; # declare myc cursor for select * from t1; Session-2. # begin; # lock table t1; [blocked] Session-3. # begin; # select * from t1; [blocked] Session-1. # abort; Then Session-2. LOCK TABLE # but Session-3. [still blocked] Regards. Hiroshi Inoue
Re: [HACKERS] relation ### modified while in use
Philip Warner wrote: > At 15:29 23/10/00 +0900, Hiroshi Inoue wrote: > > > >If we have a mechanism to acquire a share lock on a tuple,we > >could use it for managing system info generally. However the > >only allowed lock on a tuple is exclusive. Access(Share/Exclusive) > >Lock on tables would give us a restricted solution about pg_class > >tuples. > > > > Don't we have this ability? What about taking a RowShare lock on the > pg_class tuple whenever you read from the table; then requiring schema > updates take a RowExclusive lock on the pg_class tuple? > Both RowShare and RowExclusive lock are table level locking. The implementation of tuple level locking is quite different from that of table level locking. The information of table level locking is held in shared memory. OTOH the information of tuple level locking is held in the tuple itself i.e. a transaction(t_xmax) is updating/deleting/selecting for update the tuple If other backends are about to update/delete/select for update a tuple,they check the information of the tuple and if the tuple is being updated/... they wait until the end of the transaction(t_xmax). Regards. Hiroshi Inoue
Re: [HACKERS] [ANNC][RFC] crypto hashes for PostgreSQL 7.0, 7.1
> Btw, the concept of checksumming rows is kinda new to me. > I needed this to store passwords on a table, so sorry if I > cant be more help. But I am a litte bit curious, why is it > needed? Simple checksumming (crc32/md5) does not help malicious > changing of data, only hardware failures, but today's hardware > has itself checksumming builtin... It probably would be a > more point if you do some pgp/gpg style signing so you would > get some authenticy too, but this is hard to implement right. 1.) checksumming a row will alert you when glitches have changed data. Happened twice in 3 years to me with my previous system (with top end hardware!). This is probably due to file system or hardware failures. There is no other way to find out whether such a glitch has happened other than regularly checking the checksums. Despite all progress in hardware, these errors still happen and I have these happenings well documented. Most of the people never will notice as they do not use such a checking. 2.) We had problems before with tunneled IP connections and corrupted data. These errors are very rare, but again, they can happen - the more complex your network setup is, the more likely you might get a glitch or two per year. I never fou d out what to blame: the protocol implementation, the server, the client ... With large packet sizes, the checksumming the network protocols use is not as collision proof as one might wish. The same crc works more reliable with small amounts of data than with larger amounts. 3.) This checksumming helps to check whether a complex database setup with lots of triggers and interdependencies really stores the data the way it is supposed to as you can do the same calculation on the client and compare after commitment. Helps a lot while testing such a setup Horst
Re: [HACKERS] foreign key introduces unnecessary locking ?
> Using Dirty transaction removing/updating PK could see that concurrent > xaction attempts to update/insert FK and so would wait for its commit/abort. Of course this will require some function that would take tid as one of arguments, fetch row and check if someone is updating it. > Just like now same row writers wait for each other. Vadim
Re: [HACKERS] Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > Speaking of error messages, one idea for 7.2 might be to prepended > > numbers to the error messages. > > Isn't that long since on the TODO list? I know we've had long > discussions about a thoroughgoing revision of error reporting. Yes, yes, yes! We need in numbers especially because of we hopefully will have savepoints in 7.2 and so we would get powerful error handling by *applications* not by *human* only. Vadim
[HACKERS] Re: [GENERAL] Great Bridge is hiring!
On Mon, 23 Oct 2000, Ned Lilly wrote: > Date: Mon, 23 Oct 2000 10:53:48 -0400 > From: Ned Lilly <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: [GENERAL] Great Bridge is hiring! But for what? :) -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
[HACKERS] Great Bridge is hiring!
All, Apologies for the nature of this post - I think/hope this will be of general interest to the PostgreSQL community: Great Bridge is hiring. Big time. We're particularly interested in what we're calling "knowledge engineers" - the people who will work with paying Great Bridge customers to troubleshoot technical issues with PostgreSQL and other open source technologies, work on the fix themselves, and get paid to hack on PostgreSQL and other projects in their "down" time. Here's the position description from our website: -- This highly specialized engineer will be the front line of Great Bridge's professional support services, working to troubleshoot and resolve customers' technical issues. You will communicate with customers (email, live chat, phone) to troubleshoot and resolve problems; work closely with engineering staff on identifying bugs and scheduling fixes and hack at Great Bridge supported open source projects as available. Experience desired is 7-10 years of database programming or administration and deep expertise in at least one major RDBMS (PostgreSQL, Oracle, DB2, Microsoft SQL Server, Sybase, Informix). Unix orientation is critical, as well as experience in 2 - 3 of the following programming languages: C, C++, Perl, PHP, Python and Tcl/Tk. A demonstrated ability to work in small teams in a cooperative environment with strong customer service skills is required. -- Great Bridge is headquartered in Norfolk, Virginia - which boasts a mild climate, moderate cost of living, and easy access to lots of water, including the Atlantic Ocean, the Chesapeake Bay, and lots of rivers and inlets. For more info on the region, see www.hamptonroads.com. Great Bridge currently has 32 full-time employees and is growing fast. The knowledge engineer positions are located in Norfolk, and offer very competitive salaries, stock options, and comprehensive benefits. If you love PostgreSQL and open source, and want to get in on the ground floor of a leading open source software company, please contact me off-list and let's talk. Thanks, Ned -- Ned Lilly e: [EMAIL PROTECTED] Vice Presidentw: www.greatbridge.com Evangelism / Hacker Relationsv: 757.233.5523 Great Bridge, LLCf: 757.233.
[HACKERS] Re: Navigating time-warps in the CVS tree (was re the rule system)
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes: > pg_backup_custom.c: In function `_DoDeflate': > pg_backup_custom.c:846: `z_streamp' undeclared (first use in this function) > pg_backup_custom.c:846: parse error before `zp' > pg_backup_custom.c:849: `ctx' undeclared (first use in this function) > pg_backup_custom.c:852: `AH' undeclared (first use in this function) > pg_backup_custom.c:854: `zp' undeclared (first use in this function) > pg_backup_custom.c:854: `flush' undeclared (first use in this function) > pg_backup_custom.c: In function `_EndDataCompressor': > pg_backup_custom.c:912: `ctx' undeclared (first use in this function) > pg_backup_custom.c:912: parse error before `)' > pg_backup_custom.c:913: `z_streamp' undeclared (first use in this function) > pg_backup_custom.c:918: `zp' undeclared (first use in this function) Hmm. Looks like Philip neglected to see to it that pg_dump will compile when libz is not present --- the "#include " is properly ifdef'd out, but the code isn't. Over to you, Philip ... regards, tom lane
Re: [HACKERS] INHERITS doesn't offer enough functionality
Marten Feldtmann wrote: > > You'll still have to do 6 queries in postgres because it does not return > > fields in sub-classes. > > Practically this is not such a big problem as one might think. > WHEN you have a persistance framework you tell your framework, > that every attribut is located (mapped or stored or however you > may see it) in the superclass and then your top class (table) > helds all attributes your "lowest" subclass has. I don't understand what you're saying. There is no query which will bring back a set of objects of different types without truncating the sub-class fields. Therefore it's a big problem for persistance frameworks that use inheritance. > I can only tell you, what will be an improvement for me as > a persistance framework programmer and will not help me. > > What will not help me: > > * that the database generates OID > > * that the database generates "clsss" OID (one may want to >have that, because to recognize which table the data >comes from..) You don't seem to be thinking much in terms of an Object Data Management Group style persistence framework. That's a shame since it's becoming increasingly important. Sun seems to be endorsing it for Java in some way too. > > * special features to solve very special problems > > What will help me: > > * all the stuff to reduce the number (!) of queries send >to database to get my data > > * a way to insert VERY quickly a larger amount of data >into a table. > > * a good, speedy database > > Marten
Re: [HACKERS] foreign key introduces unnecessary locking ?
> > though constraint triggers should use SnapshotDirty instead of > > SELECT FOR UPDATE anyway. > > > > Did you consider this, Jan? > > Whenever the checks are done, the transaction inserting a new > reference to the key must ensure that this key cannot get > deleted until it is done and it's newly inserted reference is > visible to others.Otherwise a referential action, > preventing referenced key deletion (or other action) wouldn't > see those and it would be possible to violate the constraint. > > I don't see any other way doing it than obtaining a lock. > Using SnapshotDirty would mean, that one transaction could > DELETE a reference, then another transaction removes the > primary key (because using Dirty the DELETE is already > visible), but now the first transaction rolls back. Voila, > constraint violated. Using Dirty transaction removing/updating PK could see that concurrent xaction attempts to update/insert FK and so would wait for its commit/abort. Just like now same row writers wait for each other. Having this, we could insert FK without holding locks over PK. At the moment of constarint check we would see and wait concurrent PK deletion. If two xactons will wait for each other then one of them will be aborted. This behaviour is more natural for MVCC system postulated that only same-row-writers wait for each other. Why two same FK inserters should wait for each other if we can avoid this? Also, is there any way to get deferrable PK/UK constraints? I wonder why unique index is used for them. Vadim
Re: [HACKERS] INHERITS doesn't offer enough functionality
Chris schrieb: > > > The point is: this is classic, but noone does it > > like this if your really have a larger hierarchy of > > classes. You'll not get any good performance, when > > solving an association in your oo > > program, because the framework has to query against > > each table: 6 tables - 6 queries !!! :-( > > > > With the PostgreSQL approach one can send ONE query > > against the tables and one would get one result ... > > which will be much faster (I hope so ... that has to > > be prooved ..).= > > You'll still have to do 6 queries in postgres because it does not return > fields in sub-classes. Practically this is not such a big problem as one might think. WHEN you have a persistance framework you tell your framework, that every attribut is located (mapped or stored or however you may see it) in the superclass and then your top class (table) helds all attributes your "lowest" subclass has. But that puts another question to be answered: are the defined contrained also inheritate ??? Actually I would say: no and therefore we have the same handling as with indices. Most of the attributes may have NULL, but who cares ? The framework actually has to interpret the data coming from the database and will throw him away. Therefore I can get around the limitations of PostgreSQL in this case. If PostgreSQL can handle this in addition this would be very nice ... but before the basic stuff has to be fixed and it has to be very solid. But I have to admit: my point is a viewpoint from a programmer using an object oriented language and I only want to store my objects into a database. People using PHP, pearl or other "low-level" languages may have a different view or need, because they do not have a framework doing the work for them. I can only tell you, what will be an improvement for me as a persistance framework programmer and will not help me. What will not help me: * that the database generates OID * that the database generates "clsss" OID (one may want to have that, because to recognize which table the data comes from..) * special features to solve very special problems What will help me: * all the stuff to reduce the number (!) of queries send to database to get my data * a way to insert VERY quickly a larger amount of data into a table. * a good, speedy database Marten
Re: [HACKERS] UnixWare 7.1.1b FS
OK, removing the second --with-CXX got us past configure, and gmake ran a long while, but MAXBUFSIZE didn't get defined such that fe-connect.c died: gmake -C doc all gmake[1]: Entering directory `/home/ler/pg-dev/pgsql-snap/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-snap/doc' gmake -C src all gmake[1]: Entering directory `/home/ler/pg-dev/pgsql-snap/src' gmake -C backend all gmake[2]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend' prereqdir=`cd parser/ && pwd` && \ cd ../../src/include/parser/ && rm -f parse.h && \ ln -s $prereqdir/parse.h . gmake -C utils fmgroids.h gmake[3]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend/utils' CPP='cc -E' AWK='gawk' /bin/sh Gen_fmgrtab.sh ../../../src/include/catalog/pg_proc.h gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-snap/src/backend/utils' cd ../../src/include/utils/ && rm -f fmgroids.h && \ ln -s ../../../src/backend/utils/fmgroids.h . gmake -C access all gmake[3]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend/access' gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/common' cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o heaptuple.o heaptuple.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o indextuple.o indextuple.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o indexvalid.o indexvalid.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o printtup.o printtup.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o scankey.o scankey.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o tupdesc.o tupdesc.c /usr/bin/ld -r -o SUBSYS.o heaptuple.o indextuple.o indexvalid.o printtup.o scankey.o tupdesc.o gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/common' gmake -C gist SUBSYS.o gmake[4]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/gist' cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o gist.o gist.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o gistget.o gistget.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o gistscan.o gistscan.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o giststrat.o giststrat.c /usr/bin/ld -r -o SUBSYS.o gist.o gistget.o gistscan.o giststrat.o gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/gist' gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/hash' cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hash.o hash.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashfunc.o hashfunc.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashinsert.o hashinsert.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashovfl.o hashovfl.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashpage.o hashpage.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashscan.o hashscan.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashsearch.o hashsearch.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashstrat.o hashstrat.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hashutil.o hashutil.c /usr/bin/ld -r -o SUBSYS.o hash.o hashfunc.o hashinsert.o hashovfl.o hashpage.o hashscan.o hashsearch.o hashstrat.o hashutil.o gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/hash' gmake -C heap SUBSYS.o gmake[4]: Entering directory `/home/ler/pg-dev/pgsql-snap/src/backend/access/heap' cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o heapam.o heapam.c cc -c -I/usr/local/include -I/opt/include -I../../../../src/include -O -K host,inline,loop_unroll,alloca -Dsvr4 -o hio.o hio.c cc -c -I/usr/local/include -I/opt/include -I../../../../sr
[HACKERS] Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.outforeign_key.out errors.out)
> Bruce Momjian writes: > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > Speaking of error messages, one idea for 7.2 might be to prepended > > > > numbers to the error messages. > > > > > > Isn't that long since on the TODO list? I know we've had long > > > discussions about a thoroughgoing revision of error reporting. > > > > Yes. We have: > > > > * Allow elog() to return error codes, not just messages > > * Allow international error message support and add error codes > > > > I just thought I would mention it is on my radar screen now. > > Yeah, it's on mine too. The only thing I'm still unsure about the > "international" part. Does anyone know of a gettext-ish thing that has an > acceptable license? Yes, they must exist. I want a solution that doesn't make it difficult for people add error messages. Having codes in the C files and error messages in another file is quite a pain. My idea would enable us to number the error messages, keep the English text for the message in the same file next to the code, then allow international support by creating a utility that can dump out all the codes with the Engligh text to allow translators to make non-English versions. The translated file can then be used by the backend to generate messages in other languagues using a SET command. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Errors on restoring a dumpall
When I migrated to the 7.1 tree, I brought with me my 7.0.2 database.
It's fair sized (6GB) but the problems I had seem to be in the
system stuff.
I'm not even sure if the database is correctly loaded now, and that's
gotta be something no DBA would like. I'm not even all that happy
about the one NOTICE that I recieved.
The NOTICE is:
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'teach_pkey' for
table 'teach'
Provoked by:
CREATE TABLE "teach" (
"prof" character varying(5) NOT NULL,
"class" character varying(5),
PRIMARY KEY ("prof")
);
This seems like too much feedback to me.
The more serious message is 6 copies of
CHANGE
ERROR: aclinsert3: insertion before world ACL??
Provoked by things like:
REVOKE ALL on "pga_queries" from PUBLIC;
GRANT ALL on "pga_queries" to
PUBLIC;
And I have three problems with this:
1) Why is pg_dumpall producing something that provokes errors at all?
2) Why doesn't the error message give more info about the table involved?
It's kinda hard to pick out the culprit from a 3GB script.
3) I'm confused: is "PUBLIC" different from "world"?
I'm sorry I can't dive in and show how to fix these things;
it's my intention to get that good, but I'm not there yet.
++ kevin
--
Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED]
Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED]
At school: mailto:[EMAIL PROTECTED]
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html
"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change"
-- Alfred North Whitehead
[HACKERS] Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.outforeign_key.out errors.out)
Bruce Momjian writes: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Speaking of error messages, one idea for 7.2 might be to prepended > > > numbers to the error messages. > > > > Isn't that long since on the TODO list? I know we've had long > > discussions about a thoroughgoing revision of error reporting. > > Yes. We have: > > * Allow elog() to return error codes, not just messages > * Allow international error message support and add error codes > > I just thought I would mention it is on my radar screen now. Yeah, it's on mine too. The only thing I'm still unsure about the "international" part. Does anyone know of a gettext-ish thing that has an acceptable license? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] question about new fmgr in 7.1 snapshots
Tom Lane wrote: > Jeff Hoffmann <[EMAIL PROTECTED]> writes: > > my question is whether i should change the function to use the new fmgr > > type of definition or if it's only for internal functions. > > Up to you. If you need any of the new features (like clean handling > of NULLs) then convert. If you were happy with the old way, no need. > > A new-style dynamically loaded function must be defined as using > language "newC" not "C"; this cues fmgr which way to call it. > Are you sure on that? Doesn't TOAST mean that any user defined function recieving variable size attributes must expect them now to be compressed or stored external and change it's access to them going through the untoasting? Or do you do that for old style 'C' functions all the time in the fmgr now? > Gotta start updating the documentation soon ;-) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: AW: [HACKERS] to_char() dumps core
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > For pass by reference datatypes setting the reference to a null pointer > for a NULL value imho would be a fine thing in addition to the indicator, > no ? At the moment it generally will be, but that's not certain to be true forever. I believe we've had discussions in the past about supporting multiple kinds of NULL. (I had the idea this was actually required by SQL99, in fact, though I can't find anything about it at the moment.) The obvious way to do that is to commandeer the otherwise unused contents of a Datum when the associated null-flag is true. At that point checking the null-flag will be the only valid way to check for NULL. Assuming that the null-kind values are small integers, attempts to dereference them will still SEGV on reasonable systems, so I don't think any error checking is lost. Just don't do "if (datum == NULL)". regards, tom lane
[HACKERS] Re: Add support for
>> Actually, given your description of the problem, I'm half inclined >> to revert the whole patch and instead make configure's test for >> availability of first include , so >> that that configure test will succeed on IRIX etc. Pete, After looking at this I'm confused again. The configure test consists of seeing whether cpp will process #include without complaint. I can well believe that the full C compilation process will generate errors if is included without also including , but it's a little harder to believe that cpp alone will complain. Could you double-check this? It would be useful to look at the config.log file generated by the configure run that's reporting tcp.h isn't found. It should contain the error messages generated by failed tests. regards, tom lane
Re: [HACKERS] question about new fmgr in 7.1 snapshots
Jan Wieck <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Jeff Hoffmann <[EMAIL PROTECTED]> writes: my question is whether i should change the function to use the new fmgr type of definition or if it's only for internal functions. >> >> Up to you. If you need any of the new features (like clean handling >> of NULLs) then convert. If you were happy with the old way, no need. > Are you sure on that? Doesn't TOAST mean that any user > defined function recieving variable size attributes must > expect them now to be compressed or stored external and > change it's access to them going through the untoasting? If you have a user-defined function that takes a potentially-toasted argument, you'll have to fix it to detoast its argument. I don't think it's appropriate to saddle fmgr with that responsibility. At least in theory, you could detoast the argument without also buying into the new fmgr notation, but I agree that converting is easier ;-) regards, tom lane
[HACKERS] UDK....
One thing my testing gave SCO was the fact that cc needs to know about the -R option to ld. It will change before release to know that -R takes an argument. Just keep that in mind -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] relation ### modified while in use
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > I'm not sure about the use of AccessShareLock in parse-analyze- > optimize phase however. That's something we'll have to clean up while fixing this. Currently the system may acquire and release AccessShareLock multiple times while parsing/rewriting/planning. We need to make sure that an appropriate lock is grabbed at *first* use and then held. Should save a few cycles as well as being more correct ... regards, tom lane
[HACKERS] Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
> > Modified Files: > ... > > Some small polishing of Mark Hollomon's cleanup of DROP command: might > > as well allow DROP multiple INDEX, RULE, TYPE as well. Add missing > > CommandCounterIncrement to DROP loop, which could cause trouble otherwise > > with multiple DROP of items affecting same catalog entries. Try to > > bring a little consistency to various error messages using 'does not exist', > > 'nonexistent', etc --- I standardized on 'does not exist' since that's > > what the vast majority of the existing uses seem to be. > > Good idea(s). Thanks for cleaning up the error messages... Speaking of error messages, one idea for 7.2 might be to prepended numbers to the error messages. That way, people could look up a more detailed description of the error and possible causes. Now, none of us have the time to do that, but the new companies may, and they will need those numbers to help with technical support anyway. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: Navigating time-warps in the CVS tree (was re the rule system)
Tom Lane wrote: > > "Kevin O'Gorman" <[EMAIL PROTECTED]> writes: > > It's odd. I had already tried "8 Oct 2000 10:00:00 PDT" on one system > > (RedHat Linux 6.1), and it had worked. Today I'm building on a > > Caldera 2.3 system, and both the 00:00 and 10:00 builds fail. > > Hm. Portability bug maybe? But I can't tell with no info. > > > I've attached the output of the make. > > Uh, it looked more like an amazon.com search from here... > > regards, tom lane Uh, so it does. How embarassing. I've been having MORE trouble with Netscape... Anyway, here it is again. In the meantime, I did a diff with the version on a system that made okay, and there are no source differences in the pg_backup_custom.c file. If we get browser junk again, here is the tail of the file via cut-and-paste; there are about 100 lines of error output total: pg_backup_custom.c: In function `_DoDeflate': pg_backup_custom.c:846: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:846: parse error before `zp' pg_backup_custom.c:849: `ctx' undeclared (first use in this function) pg_backup_custom.c:852: `AH' undeclared (first use in this function) pg_backup_custom.c:854: `zp' undeclared (first use in this function) pg_backup_custom.c:854: `flush' undeclared (first use in this function) pg_backup_custom.c: In function `_EndDataCompressor': pg_backup_custom.c:912: `ctx' undeclared (first use in this function) pg_backup_custom.c:912: parse error before `)' pg_backup_custom.c:913: `z_streamp' undeclared (first use in this function) pg_backup_custom.c:918: `zp' undeclared (first use in this function) make[3]: *** [pg_backup_custom.o] Error 1 make[3]: Leaving directory `/usr/local/src/pgsql/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/pgsql/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/pgsql/src' make: *** [all] Error 2 [kevin@trixie pgsql]$ exit Script done, file is typescript ++ kevin -- Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED] Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED] At school: mailto:[EMAIL PROTECTED] Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead Script started on Sun Oct 22 21:33:56 2000 /home/kevin/.bashrc /home/kevin/.bashrc-private [kevin@trixie pgsql]$ make make -C doc all make[1]: Entering directory `/usr/local/src/pgsql/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/pgsql/doc' make -C src all make[1]: Entering directory `/usr/local/src/pgsql/src' make -C backend all make[2]: Entering directory `/usr/local/src/pgsql/src/backend' make -C access all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/access' make -C common SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/common' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/common' make -C gist SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/gist' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/gist' make -C hash SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/hash' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/hash' make -C heap SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/heap' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/heap' make -C index SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/index' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/index' make -C nbtree SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/nbtree' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/nbtree' make -C rtree SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/rtree' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/rtree' make -C transam SUBSYS.o make[4]: Entering directory `/usr/local/src/pgsql/src/backend/access/transam' make[4]: `SUBSYS.o' is up to date. make[4]: Leaving directory `/usr/local/src/pgsql/src/backend/access/transam' make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/access' make -C bootstrap all make[3]: Entering directory `/usr/local/src/pgsql/src/backend/bootstrap' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/pgsql/src/backend/bootstrap' make -C catalog all make[3]: Entering directory `/
Re: [HACKERS] testing my connection to list.
* Tom Lane <[EMAIL PROTECTED]> [001023 09:15]: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > Ok, so why didn't my regression outputs post? > > Marc? > > How big were they? I think the default configuration for majordomo > is that posts over 50K or so don't go through until hand-approved by > moderator. Marc tends to clean out that inbox every few days... 63K. But I thought some of my others were larger. Maybe that limit needs to be bigger? > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: AW: AW: [HACKERS] relation ### modified while in use
At 10:10 23/10/00 -0400, Tom Lane wrote: > >I consider that behavior *far* safer than allowing schema changes to >be seen mid-transaction. Consider the following example: > > Session 1 Session 2 > > begin; > > INSERT INTO foo ...; > > ALTER foo ADD constraint; > > INSERT INTO foo ...; > > end; > >Which, if any, of session 1's insertions will be subject to the >constraint? What are the odds that the dba will like the result? > In this case, wouldn't the answer depend on the isolation level of session 1? For serializable TX, then constraint would not apply; 'read committed' would mean the constraint was visible on the second insert and at the commit. I would err on the side of insisting all metadata changes occur in serializable transactions to make life a little easier. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: AW: [HACKERS] relation ### modified while in use
> > As for locks,weak locks doesn't pass intensive locks. Dba > > seems to be able to alter a table at any time. > > Sorry, I don't understand this sentence. Tom suggested placing a shared lock on > any table that is accessed until end of tx. Noone can alter table until all users have > closed their txns and not accessed tables again. More of that - while one xaction will wait to alter a table no new xaction will be allowed to access this table too. > Remember that this would include creating an index ... I don't think so. Index creation requires 1. share lock on schema 2. share lock on data Vadim
Re: AW: AW: [HACKERS] relation ### modified while in use
Philip Warner <[EMAIL PROTECTED]> writes: > In this case, wouldn't the answer depend on the isolation level of session > 1? For serializable TX, then constraint would not apply; 'read committed' > would mean the constraint was visible on the second insert and at the commit. The important issue here is that all schema changes have to be read on a read-committed basis, even if your transaction is otherwise serializable. Consider for example the possibility that the schema change you're ignoring consists of a DROP INDEX or some such --- you'll fail if you proceed as though the index is still there. This is the point Vadim was making a few days ago (but I didn't understand at the time). I believe we can work out a consistent set of behavior such that user data accesses (SELECT/UPDATE/etc) follow MVCC rules but system accesses to schema data always follow read-committed semantics. One of the components of this has to be an agreement on how to handle locking. AFAICS, we have to adopt hold-some-kind-of-lock-till-end-of-xact, or we will have consistency problems between the user and system views of the world. regards, tom lane
Re: [HACKERS] relation ### modified while in use
Philip Warner <[EMAIL PROTECTED]> writes: > Only slightly; one interpretation of a table lock is that it locks all of > the data in the table; and a lock on the pg_class row locks the metadata. I > must admit that I am having a little difficulty thinking of a case where > the distinction would be useful... I can't see any value in locking the data without locking the metadata. Given that, the other way round is sort of moot... > So where do > SELECT FOR UPDATE IN ROW SHARE MODE We don't support that (never heard of it before, in fact) > and > LOCK TABLE IN ROW EXCLUSIVE MODE statements. > fit in? That one is just a table lock (RowExclusiveLock). All the variants of LOCK TABLE are table-level locks. regards, tom lane
Re: AW: AW: AW: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > Yes, and holding a row exclusive lock must imho at least grab a shared > table lock As indeed it does. Our disagreement seems to be just on the point of whether it's safe to allow a read-only transaction to release its AccessShareLock locks partway through. My opinion about that is colored by the known bugs that we have because the parser/rewriter/planner currently do just that. You can cause the system to become mighty confused if the report of a table schema change arrives partway through the parse/plan process, because decisions already made are no longer valid. While we can probably patch the holes in this area by holding a lock throughout processing of one statement, I think that will just push the problem up to the application level. How many apps are likely to be coded in a way that will be robust against intra-transaction schema changes? regards, tom lane
Re: [HACKERS] foreign key introduces unnecessary locking ?
Mikheev, Vadim wrote: > Try this for both FK tables: > > create table tmp2(idx2 int4, col2 int4, constraint > tmpcon2 foreign key(col2) references tmp1(idx) INITIALLY DEFERRED); > > This will defer constraint checks till transaction commit... > though constraint triggers should use SnapshotDirty instead of > SELECT FOR UPDATE anyway. > > Did you consider this, Jan? > > Vadim Whenever the checks are done, the transaction inserting a new reference to the key must ensure that this key cannot get deleted until it is done and it's newly inserted reference is visible to others.Otherwise a referential action, preventing referenced key deletion (or other action) wouldn't see those and it would be possible to violate the constraint. I don't see any other way doing it than obtaining a lock. Using SnapshotDirty would mean, that one transaction could DELETE a reference, then another transaction removes the primary key (because using Dirty the DELETE is already visible), but now the first transaction rolls back. Voila, constraint violated. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
[HACKERS] Re: Navigating time-warps in the CVS tree (was re the rule system)
Tom Lane wrote: > > "Kevin O'Gorman" <[EMAIL PROTECTED]> writes: > > so I tried going back to '7 Oct 2000 10:00:00 PST' and it's better, > > but regression tests fail on the rule system. It makes the server > > die. Since rules are what I want, this won't do. > > Details? AFAIK, the system was operational on 7-Oct; I did not pick > that date out of the air. There was a broken version of the > expected/rules.out file in place right around then --- see > http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/test/regress/expected/rules.out > But that'd just have caused a bogus comparison failure, not a server > crash. (What was *in the expected file* was a report of a server > crash :-(, so if you didn't look carefully at the diff you might've > gotten confused...) > > If you want a more exact timestamp, try 7-Oct-2000 00:00 PDT which > predates the BEOS patch breakage, or 8-Oct-2000 00:00 PDT which follows > cleanup. If either of those fail on your system it'd be useful to know > about. > > regards, tom lane It's odd. I had already tried "8 Oct 2000 10:00:00 PDT" on one system (RedHat Linux 6.1), and it had worked. Today I'm building on a Caldera 2.3 system, and both the 00:00 and 10:00 builds fail. I've attached the output of the make. Could I have a bad copy of this source file? How could I tell (not knowing much about CVS, I'm disinclined to perform random experiments). ++ kevin -- Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED] Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED] At school: mailto:[EMAIL PROTECTED] Web: http://www.cs.ucsb.edu/~kogorman/index.html Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html "There is a freedom lying beyond circumstance, derived from the direct intuition that life can be grounded upon its absorption in what is changeless amid change" -- Alfred North Whitehead Title: 302 Found Script started on Thu May 25 19:22:16 2000 /home/kevin/.bashrc /home/kevin/.bashrc-private [kevin@trixie nsmail]$ telnet www.amazon.com 80 Trying 208.216.181.15... Connected to www.amazon.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 302 Found Date: Fri, 26 May 2000 02:22:44 GMT Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) Location: http://www.amazon.com:80/exec/obidos/subst/home/home.html Connection: close Content-Type: text/html; charset=iso-8859-1 Hello. Already a customer? Sign in to get recommendations. Hot in zShops: sunglasses, board shorts All Products Books Popular Music Classical Music DVD & Video Toys & Games Electronics Software Tools & Hardware Lawn & Patio Kitchen Auctions zShops sothebys.amazon Search of the Day: computers • Books • Music • DVD & Video • Electronics • Software • Toys • Video Games • Tools & Hardware • Lawn & Patio • Kitchen • Health & Beauty • Home Living • Auctions • sothebys. amazon.com • zShops • Gift Ideas • Free e-Cards Shopping Services • Buy or redeem a gift certificate. • Get e-mail recommendations from our editors. • Apply for the Amazon.com NextCard Visa. Special Features • Earn Gift Certificates • Purchase Circles • Friends & Favorites • Amazon.com Anywhere • Help a Charity Associates Sell books, music, video, and more from your Web site. Start earning today! More to Explore • Amazon.co.uk • Amazon.de • IMDb • Ashford.com • eZiba.com Thursday, May 25, 2000 Already a customer? Sign in to see what's New for You.
Re: [HACKERS] relation ### modified while in use
> > in general. What I'm proposing is that once an xact has touched a
> > table, other xacts should not be able to apply schema updates to that
> > table until the first xact commits.
> >
>
> I agree with you.
I don't know. We discussed this issue just after 6.5 and decided to
allow concurrent schema modifications.
Oracle has disctionary locks but run each DDL statement in separate
xaction, so - no deadlock condition here. OTOH, I wouldn't worry
about deadlock - one just had to follow common anti-deadlock rules.
> I've wondered why AccessShareLock is a short term lock.
MUST BE. AccessShare-/Exclusive-Locks are *data* locks.
If one want to protect schema then new schema share/excl locks
must be inroduced. There is no conflict between data and
schema locks - they are orthogonal.
We use AccessShare-/Exclusive-Locks for schema because of...
we allow concurrent schema modifications and no true schema
locks were required.
> If we have a mechanism to acquire a share lock on a tuple,we
> could use it for managing system info generally. However the
> only allowed lock on a tuple is exclusive. Access(Share/Exclusive)
Actually, just look at lock.h:LTAG structure - lock manager supports
locking of "some objects" inside tables:
typedef struct LTAG
{
OidrelId;
OiddbId;
union
{
BlockNumberblkno;
Transactionxid;
} objId;
...
- we could add oid to union above and lock tables by acquiring lock
on pg_class with objId.oid = table' oid. Same way we could lock indices
and whatever we want... if we want -:)
> Lock on tables would give us a restricted solution about pg_class
> tuples.
>
> Thers'a possibility of deadlock in any case but there are few
> cases when AccessExclusiveLock is really needed and we could
> acquire an AccessExclusiveLock manually from the first if
> necessary.
>
> I'm not sure about the use of AccessShareLock in parse-analyze-
> optimize phase however.
There is notion about breakable (parser) locks in Oracle documentation -:)
Vadim
Re: [HACKERS] testing my connection to list.
Larry Rosenman <[EMAIL PROTECTED]> writes: > Ok, so why didn't my regression outputs post? > Marc? How big were they? I think the default configuration for majordomo is that posts over 50K or so don't go through until hand-approved by moderator. Marc tends to clean out that inbox every few days... regards, tom lane
[HACKERS] Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.outforeign_key.out errors.out)
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > Speaking of error messages, one idea for 7.2 might be to prepended > > numbers to the error messages. > > Isn't that long since on the TODO list? I know we've had long > discussions about a thoroughgoing revision of error reporting. Yes. We have: * Allow elog() to return error codes, not just messages * Allow international error message support and add error codes I just thought I would mention it is on my radar screen now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
AW: AW: AW: AW: [HACKERS] relation ### modified while in use
> > You were talking about the "select only" case (and no for update eighter). > > I think that select statements need a shared lock for the duration of their > > execution only. > > You seem to think that locks on individual tuples conflict with > table-wide locks. Yes, very much so. Any other way would be subject to the same quirks you would like to avoid, no ? > AFAIK that's not true. well, imho room for improvement. > The only way to prevent > another xact from gaining AccessExclusiveLock on a table is to be > holding some lock *on the table*. Yes, and holding a row exclusive lock must imho at least grab a shared table lock (to avoid several problems, like missing an index update, inserting a null into a newly added not null column ...). Alternately the table exclusive lock could honour row locks (probably not possible, since we don't track those do we ?). > As for your claim that read-only xacts don't need to worry about > preventing schema updates, what of adding/deleting ON SELECT rules? Well, depends on what that rule does, you mean a new rule ? Ad hoc I don't see a problem based on the idea that all modification gets appropriate locks. Andreas
[HACKERS] regress issues: UW7.1.1/PG7.1dev/GCC
Here is some regression stuff. CVS as of about an hour or so ago (right after Tom answered my note...) === Notes... = postmaster must already be running for the regression tests to succeed. The time zone is set to PST8PDT for these tests by the client frontend. Please report any apparent problems to [EMAIL PROTECTED] See regress/README for more information. === dropping old regression database... = ERROR: DROP DATABASE: Database "regression" does not exist dropdb: database removal failed === creating new regression database... = CREATE DATABASE === installing languages... = installing PL/pgSQL .. ok === running regression queries... = boolean .. ok char .. ok name .. ok varchar .. ok text .. ok int2 .. ok int4 .. ok int8 .. ok oid .. ok float4 .. ok float8 .. ok numeric .. ok strings .. ok numerology .. ok point .. ok lseg .. ok box .. ok path .. ok polygon .. ok circle .. ok date .. ok time .. ok timestamp .. ok interval .. ok abstime .. ok reltime .. ok tinterval .. ok inet .. ok comments .. failed oidjoins .. ok type_sanity .. ok opr_sanity .. ok geometry .. failed horology .. ok create_function_1 .. ok create_type .. ok create_table .. ok create_function_2 .. ok copy .. ok constraints .. ok triggers .. ok create_misc .. ok create_aggregate .. ok create_operator .. ok create_index .. ok inherit .. ok create_view .. ok sanity_check .. ok errors .. ok select .. ok select_into .. ok select_distinct .. ok select_distinct_on .. ok select_implicit .. ok select_having .. ok subselect .. ok union .. ok case .. ok join .. ok aggregates .. ok transactions .. ok random .. ok portals .. ok arrays .. ok btree_index .. ok hash_index .. ok misc .. ok select_views .. ok alter_table .. ok portals_p2 .. ok rules .. ok foreign_key .. ok limit .. ok plpgsql .. failed temp .. ok *** expected/comments.out Fri Jul 14 10:43:55 2000 --- results/comments.outSun Oct 22 19:38:45 2000 *** *** 42,47 --- 42,48 */ /* This block comment surrounds a query which itself has a block comment... SELECT /* embedded single line */ 'embedded' AS x2; + ERROR: Unterminated /* comment */ SELECT -- continued after the following block comments... /* Deeply nested comment. *** *** 57,65 Now just one deep... */ 'deeply nested example' AS sixth; - sixth - --- - deeply nested example - (1 row) - /* and this is the end of the file */ --- 58,62 Now just one deep... */ 'deeply nested example' AS sixth; /* and this is the end of the file */ + ERROR: parser: parse error at or near "*/" -- *** expected/geometry.out Tue Sep 12 16:07:16 2000 --- results/geometry.outSun Oct 22 19:38:49 2000 *** *** 443,454 FROM CIRCLE_TBL; six | polygon -+- ! | ((-3,0),(-2.59807621135076,1.500442),(-1.499116,2.59807621135842),(1.53102359078377e-11,3),(1.501768,2.59807621134311),(2.59807621136607,1.49779),(3,-3.06204718156754e-11),(2.59807621133545,-1.503094),(1.496464,-2.59807621137373),(-4.59307077235131e-11,-3),(-1.50442,-2.5980762113278),(-2.59807621138138,-1.495138)) ! | ((-99,2),(-85.6025403783588,52.01473),(-48.97054,88.602540378614),(1.051034,102),(51.05893,88.6025403781036),(87.6025403788692,51.92634),(101,1.897932),(87.6025403778485,-48.10313),(50.88214,-84.6025403791243),(0.8468976,-98),(-49.14732,-84.6025403775933),(-85.6025403793795,-47.83795)) | ((-4,3),(-3.33012701891794,5.500737),(-1.498527,7.3301270189307),(1.002552,8),(3.502946,7.33012701890518),(5.33012701894346,5.496317),(6,2.994897),(5.33012701889242,0.4948437),(3.494107,-1.33012701895622),(0.9923449,-2),(-1.507366,-1.33012701887966),(-3.33012701896897,
[HACKERS] Re: Add support for
xti.h portion of patch has been backed out. > Pete Forman <[EMAIL PROTECTED]> writes: > > I've done bit more research. was the correct place to find > > TCP_NODELAY in UNIX98/SUSv2. However in the Austin Group draft of the > > next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and > > officially included. > > OK, thanks for following up on that. > > >> to revert the whole patch and instead make configure's test for > >> availability of first include , so > >> that that configure test will succeed on IRIX etc. > > > I agree with this. Back out the patch and update configure.in. > > Will do. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: [COMMITTERS] pgsql/src/pl/plpgsql/test (runtest triggers.sql mklang.sql)
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> plpgsql regress tests seem a tad out of date ... repair bit rot. > What's the relation of this test suite to the "plpgsql" test in the > regression tests? From the comments surrounding it it seems they're > related. I think it may be an ancestor of the standard regress test. Could well be that that whole directory is now redundant and ought to be removed, but until Jan is back online and I can ask him, I wasn't going to go that far ... regards, tom lane
[HACKERS] Re: [COMMITTERS] pgsql/src/pl/plpgsql/test (runtest triggers.sqlmklang.sql)
Tom Lane writes: > plpgsql regress tests seem a tad out of date ... repair bit rot. What's the relation of this test suite to the "plpgsql" test in the regression tests? From the comments surrounding it it seems they're related. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [GENERAL] Re: [HACKERS] My new job
Peter Eisentraut wrote: > Bruce Momjian writes: > > > After careful consideration, I have decided to accept a job with Great > > Bridge. > > Whatever happened to this: > > Date: Tue, 09 May 2000 15:19:48 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Ross J. Reedstrom <[EMAIL PROTECTED]> > Cc: PostgreSQL-general <[EMAIL PROTECTED]> > Subject: Re: [GENERAL] Steering committee responce to Great Bridge LLC > > : One thing we have agreed to is that there must not be an unseemly fraction > : of core members working for the same company. With six people on core, > : probably about two working at the same company would be a reasonable > : limit. Been in Poland for a week, so pardon for the delay. Initially it was (if I recall correct) Vadim's and my idea. The main reason behind it wasn't to avoid influence from commercial entities into core. We've all been working together for years as a group with great honour and trusting, so the aims of all core members where never questioned. We just decided this "fraction" to avoid any hireing to look like a takeover. This world is spinning a little fast at the moment. Let me repeat what I said to a person I met last week in Poland, during a PosrgreSQL conference in Wierzba. We have a BSD license and now I know a good reason why we kept it all the time. With that license in place, there's absolutely no reason to panic right now. Nothing can be taken away, and if things go wrong in the future, those left in the "OpenSource" corner can start from our last official release again - be sure I'll be somewhere in that corner, even if it might take some time before I can surface again. And I'm sure I'll meet all those I loved to work with together in that corner again. Never underestimate the power of Open Source. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [HACKERS] relation ### modified while in use
At 10:45 23/10/00 -0400, Tom Lane wrote: >Philip Warner <[EMAIL PROTECTED]> writes: >> Don't we have this ability? What about taking a RowShare lock on the >> pg_class tuple whenever you read from the table; then requiring schema >> updates take a RowExclusive lock on the pg_class tuple? > >How is that different from taking locks on the table itself? Only slightly; one interpretation of a table lock is that it locks all of the data in the table; and a lock on the pg_class row locks the metadata. I must admit that I am having a little difficulty thinking of a case where the distinction would be useful... >In any case, we don't have the ability to hold multiple classes of locks >on individual tuples, AFAIK. UPDATE and SELECT FOR UPDATE use a >different mechanism that involves setting fields in the header of the >affected tuple. There's no room there for more than one kind of lock; >what's worse, checking and waiting for that lock is far slower than >normal lock-manager operations. So where do SELECT FOR UPDATE IN ROW SHARE MODE and LOCK TABLE IN ROW EXCLUSIVE MODE statements. fit in? They *seem* to provide differing levels of row locking. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] relation ### modified while in use
Philip Warner <[EMAIL PROTECTED]> writes: > Don't we have this ability? What about taking a RowShare lock on the > pg_class tuple whenever you read from the table; then requiring schema > updates take a RowExclusive lock on the pg_class tuple? How is that different from taking locks on the table itself? In any case, we don't have the ability to hold multiple classes of locks on individual tuples, AFAIK. UPDATE and SELECT FOR UPDATE use a different mechanism that involves setting fields in the header of the affected tuple. There's no room there for more than one kind of lock; what's worse, checking and waiting for that lock is far slower than normal lock-manager operations. (But on the plus side, you can be holding locks on any number of tuples without risking overflowing the lock manager table, and releasing the locks at commit takes no cycles.) regards, tom lane
Re: [HACKERS] INHERITS doesn't offer enough functionality
Hiroshi Inoue schrieb: > > Chris wrote: > > > It's pretty clear to me that an inherited index should be only one > > index. There may be a case for optional non-inherited indexes (CREATE > > INDEX ON ONLY foobar), but if the index is inherited, it is just one > > index. > > > > At the end of the day though, the reason is only performance. The > > semantics should be the same no matter whether implemented as multiple > > indexes or not. Performance is much better with one index though.(*) > > > > Is it true ? > How to guarantee the uniqueness using multiple indexes ? > Sorry to say, but you all should really think about, what inheritance should mean In the classic mapping strategy (OO-rdbms mapping) it's said, that each class is mapped to ONE table ! This is the classic mapping strategy, which is mentioned in every literature. The point is: this is classic, but noone does it like this if your really have a larger hierarchy of classes. You'll not get any good performance, when solving an association in your oo program, because the framework has to query against each table: 6 tables - 6 queries !!! :-( With the PostgreSQL approach one can send ONE query against the tables and one would get one result ... which will be much faster (I hope so ... that has to be prooved ..). -- I'm not sure, that inherited indices should be really ONE index. There are very well reasons NOT to build ONE larger index. Actually one should think about: why do I really want to have inheritance in the oo-rdbms ? Actually I could put all columns (of all classes in this hierarchy into one table and that's it). I would like to have inheritance in this database system, because the tables are getting smaller and queries against special classes (eh tables) are becoming faster. Actually the inserts will be much faster also because you have several smaller indices. I've run tests here with ONE large table (5 columns and 5 indices) holding data for about 17 classes and the result is: the insert/update path is the problem and not the select-path. insert-performance is decreasing in a linear fashon ... very, very bad. Marten
Re: AW: AW: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > No, the above is not a valid example, because Session 2 won't > get the exclusive lock until Session 1 commits, since Session 1 already > holds a lock on foo (for the inserted row). > You were talking about the "select only" case (and no for update eighter). > I think that select statements need a shared lock for the duration of their > execution only. You seem to think that locks on individual tuples conflict with table-wide locks. AFAIK that's not true. The only way to prevent another xact from gaining AccessExclusiveLock on a table is to be holding some lock *on the table*. As for your claim that read-only xacts don't need to worry about preventing schema updates, what of adding/deleting ON SELECT rules? regards, tom lane
Re: AW: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: >> As for locks,weak locks doesn't pass intensive locks. Dba >> seems to be able to alter a table at any time. > Sorry, I don't understand this sentence. Tom suggested placing a > shared lock on any table that is accessed until end of tx. Noone can > alter table until all users have closed their txns and not accessed > tables again. Until existing xacts using that table have closed, yes. But I believe the lock manager has some precedence rules that will allow the pending request for AccessExclusiveLock to take precedence over new requests for lesser locks. So you're only held off for a long time if you have long-running xacts that use the target table. I consider that behavior *far* safer than allowing schema changes to be seen mid-transaction. Consider the following example: Session 1 Session 2 begin; INSERT INTO foo ...; ALTER foo ADD constraint; INSERT INTO foo ...; end; Which, if any, of session 1's insertions will be subject to the constraint? What are the odds that the dba will like the result? With my proposal, session 2's ALTER would wait for session 1 to commit, and then the ALTER's own scan to verify the constraint will check all the rows added by session 1. Under your proposal, I think the rows inserted at the beginning of session 1's xact would be committed without having been checked. regards, tom lane
Re: [HACKERS] relation ### modified while in use
At 15:29 23/10/00 +0900, Hiroshi Inoue wrote: > >If we have a mechanism to acquire a share lock on a tuple,we >could use it for managing system info generally. However the >only allowed lock on a tuple is exclusive. Access(Share/Exclusive) >Lock on tables would give us a restricted solution about pg_class >tuples. > Don't we have this ability? What about taking a RowShare lock on the pg_class tuple whenever you read from the table; then requiring schema updates take a RowExclusive lock on the pg_class tuple? As you say, it won't prevent deadlocks, but it seems like a reasonable thing to do. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[HACKERS] Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Speaking of error messages, one idea for 7.2 might be to prepended > numbers to the error messages. Isn't that long since on the TODO list? I know we've had long discussions about a thoroughgoing revision of error reporting. regards, tom lane
AW: AW: AW: [HACKERS] relation ### modified while in use
> Until existing xacts using that table have closed, yes. But I believe > the lock manager has some precedence rules that will allow the pending > request for AccessExclusiveLock to take precedence over new requests > for lesser locks. So you're only held off for a long time if you have > long-running xacts that use the target table. > > I consider that behavior *far* safer than allowing schema changes to > be seen mid-transaction. Consider the following example: > > Session 1 Session 2 > > begin; > > INSERT INTO foo ...; > > ALTER foo ADD constraint; > > INSERT INTO foo ...; > > end; > > Which, if any, of session 1's insertions will be subject to the > constraint? What are the odds that the dba will like the result? > > With my proposal, session 2's ALTER would wait for session 1 > to commit, > and then the ALTER's own scan to verify the constraint will check all > the rows added by session 1. > > Under your proposal, I think the rows inserted at the beginning of > session 1's xact would be committed without having been checked. No, the above is not a valid example, because Session 2 won't get the exclusive lock until Session 1 commits, since Session 1 already holds a lock on foo (for the inserted row). You were talking about the "select only" case (and no for update eighter). I think that select statements need a shared lock for the duration of their execution only. Andreas
Re: [HACKERS] failed runcheck
Patrick Welche <[EMAIL PROTECTED]> writes: > On Sat, Oct 21, 2000 at 01:48:39PM -0700, Vadim Mikheev wrote: >> Did you run make distclean? I've run regtests before committing changes. > Just made sure - different computer - fresh cvs update/distclean/configure/make > same coredump > #1 0x807f4be in IsSharedSystemRelationName (relname=0x0) at catalog.c:197 > ^^^ > ie. relname[0] at catalog.c:176 is dereferencing a null pointer. Interesting. Current sources pass regress tests on my machine, same as for Vadim. I think you have found a platform-specific bug. Could you dig into it a little further and try to determine where the NULL is coming from? regards, tom lane
[HACKERS] Re: Add support for
Pete Forman <[EMAIL PROTECTED]> writes: > I've done bit more research. was the correct place to find > TCP_NODELAY in UNIX98/SUSv2. However in the Austin Group draft of the > next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and > officially included. OK, thanks for following up on that. >> to revert the whole patch and instead make configure's test for >> availability of first include , so >> that that configure test will succeed on IRIX etc. > I agree with this. Back out the patch and update configure.in. Will do. regards, tom lane
Re: [HACKERS] failed runcheck
On Sat, Oct 21, 2000 at 01:48:39PM -0700, Vadim Mikheev wrote: > Did you run make distclean? I've run regtests before committing changes. Just made sure - different computer - fresh cvs update/distclean/configure/make cd src/test/regress gmake clean gmake all gmake runcheck same coredump #1 0x807f4be in IsSharedSystemRelationName (relname=0x0) at catalog.c:197 ^^^ ie. relname[0] at catalog.c:176 is dereferencing a null pointer. Cheers, Patrick
Re: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB wrote: > > What I'm proposing is that once an xact has touched a > > table, other xacts should not be able to apply schema updates to that > > table until the first xact commits. > > No, this would mean too many locks, and would leave the dba with hardly a > chance to alter a table. > Are there many applications which have many SELECT statements(without FOR UPDATE) in one tx ? As for locks,weak locks doesn't pass intensive locks. Dba seems to be able to alter a table at any time. Regards. Hiroshi Inoue
AW: AW: [HACKERS] relation ### modified while in use
> > > What I'm proposing is that once an xact has touched a > > > table, other xacts should not be able to apply schema updates to that > > > table until the first xact commits. > > > > No, this would mean too many locks, and would leave the dba with hardly a > > chance to alter a table. > > > > Are there many applications which have many SELECT statements(without > FOR UPDATE) in one tx ? Why not ? > As for locks,weak locks doesn't pass intensive locks. Dba > seems to be able to alter a table at any time. Sorry, I don't understand this sentence. Tom suggested placing a shared lock on any table that is accessed until end of tx. Noone can alter table until all users have closed their txns and not accessed tables again. Remember that this would include creating an index ... Andreas
Re: [HACKERS] testing my connection to list.
Ok, so why didn't my regression outputs post? Marc? LER * Larry Rosenman <[EMAIL PROTECTED]> [001023 04:32]: > > I posted some regression failures twice, and never saw them on the > list or in the newsgroup. This is a test. > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
[HACKERS] testing my connection to list.
I posted some regression failures twice, and never saw them on the list or in the newsgroup. This is a test. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
AW: [HACKERS] embedded sql with indicators in other DBs
> What do other DBs do with their output variables if there is > an embedded SQL > query resulting in a NULL return value? What I mean is: > > exec sql select text into :txt:ind from ... > > If text is NULL, ind will be set, but does txt change? > > I was just told Informix blanks txt. No, it gives a null string. In general Informix has a value that represents null that is 'distinct from all legal values in any given datatype'. Andreas
AW: [HACKERS] relation ### modified while in use
> What I'm proposing is that once an xact has touched a > table, other xacts should not be able to apply schema updates to that > table until the first xact commits. No, this would mean too many locks, and would leave the dba with hardly a chance to alter a table. If I recall correctly the ANSI standard mandates that schema modifications be seen immediately. Thus imho we need to refresh the relcache on first access after modification. Thus two accesses to one table inside one tx would be allowed to see two different versions (the exception beeing serializable isolation level). Imho we only need to lock out an alter table if a cursor is open on that table. Andreas
AW: [HACKERS] UnixWare 7.1.1b FS
> And the --with-CXX option is honored, but only if you don't > override it in the template file. :) Is this the precedence we want ? I would have thought that commandline is preferred over template. Andreas
AW: [HACKERS] to_char() dumps core
> (Also, if you do want to check for a NULL input in current sources, > looking for a NULL pointer is the wrong way to code it anyway; > PG_ARGISNULL(n) is the right way.) For pass by reference datatypes setting the reference to a null pointer for a NULL value imho would be a fine thing in addition to the indicator, no ? Andreas
[HACKERS] Re: Add support for
{retry of message sent Fri, 20 Oct 2000 14:04:16 +0100 (BST)]
Tom Lane writes:
> Pete Forman wrote:
> > The basic problem is that is a BSD header. The
> > correct header for TCP internals such as TCP_NODELAY on a UNIX
> > system is . By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1)
> > or later. The 2 files which conditionally include
> > need also to conditionally include .
I've done bit more research. was the correct place to find
TCP_NODELAY in UNIX98/SUSv2. However in the Austin Group draft of the
next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and
officially included.
> I have never heard of before and am rather dubious that it
> should be considered more standard than . However, if we
> are going to include it then it evidently must be *mutually
> exclusive* with including . The $64 question is, which one
> ought to be included when both are available? I'd tend to go for
> on the grounds of "don't fix what wasn't broken".
>
> Actually, given your description of the problem, I'm half inclined
> to revert the whole patch and instead make configure's test for
> availability of first include , so
> that that configure test will succeed on IRIX etc. Do you know any
> platforms where doesn't exist at all?
I agree with this. Back out the patch and update configure.in. I
might have done that myself but I do not have enough experience with
autoconf.
The only platform I know of without is Cygwin B20.1.
There is a workaround in place for that. The current Cygwin 1.1 does
have the header.
--
Pete Forman -./\.- Disclaimer: This post is originated
Western Geophysical -./\.- by myself and does not represent
[EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or
http://www.crosswinds.net/~petef -./\.- its divisions.
