Re: [HACKERS] Using Threads?
spinlocks rewritten to mutex_ locktable uses sema_ some cond_ in bufmgr.c Myron Karel Zak wrote: > On Mon, 1 Jan 2001, Myron Scott wrote: > > >> For anyone interested, >> >> I have posted my multi-threaded version of PostgreSQL here. >> >> http://www.sacadia.com/mtpg.html > > > How you solve locks? Via original IPC or you rewrite it to mutex (etc). > > Karel
Re: [HACKERS] Assuming that TAS() will succeed the first time is verboten
* Bruce Momjian <[EMAIL PROTECTED]> [010101 23:59] wrote: > > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > One trick that may help is calling sched_yield(2) on a lock miss, > > > it's a POSIX call and quite new so you'd need a 'configure' test > > > for it. > > > > The author of the current s_lock code seems to have thought that > > select() with a zero delay would do the equivalent of sched_yield(). > > I'm not sure if that's true on very many kernels, if indeed any... > > > > I doubt we could buy much by depending on sched_yield(); if you want > > to assume POSIX facilities, ISTM you might as well go for user-space > > semaphores and forget the whole TAS mechanism. > > > Another issue is that sched_yield brings in the pthreads library/hooks > on some OS's, which we certainly want to avoid. I know it's a major undertaking, but since the work is sort of done, have you guys considered the port to solaris threads and seeing about making a pthreads port of that? I know it would probably get you considerable gains under Windows at the expense of dropping some really really legacy system. Or you could do what apache (is rumored) does and have it do either threads or processes or both... -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] Ignored PostgreSQL SET command
"Patrick Dunford" wrote: >I have a line in a PHP script that looks like this: > > $set=pg_exec($dbconn, "SET DATESTYLE TO 'European'"); //Set date format > >Since my ISP updated their server, this appears to be ignored as pgsql >always returns dates in ISO format. > >1. What is the default format of dates returned that I can ALWAYS rely on? >From release 7, the default format is ISO: -mm-dd >2. Why is the command ignored? European has no meaning with the ISO datestyle. To get normal European dates, do this SET command: SET DATESTYLE TO 'Postgres,European' -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Verily, verily, I say unto you, He that heareth my word, and believeth on him that sent me, hath everlasting life, and shall not come into condemnation; but is passed from death unto life." John 5:24
Re: [HACKERS] Assuming that TAS() will succeed the first time is verboten
> Alfred Perlstein <[EMAIL PROTECTED]> writes: > > One trick that may help is calling sched_yield(2) on a lock miss, > > it's a POSIX call and quite new so you'd need a 'configure' test > > for it. > > The author of the current s_lock code seems to have thought that > select() with a zero delay would do the equivalent of sched_yield(). > I'm not sure if that's true on very many kernels, if indeed any... > > I doubt we could buy much by depending on sched_yield(); if you want > to assume POSIX facilities, ISTM you might as well go for user-space > semaphores and forget the whole TAS mechanism. Another issue is that sched_yield brings in the pthreads library/hooks on some OS's, which we certainly want to avoid. -- 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] Using Threads?
On Mon, 1 Jan 2001, Myron Scott wrote: > For anyone interested, > > I have posted my multi-threaded version of PostgreSQL here. > > http://www.sacadia.com/mtpg.html How you solve locks? Via original IPC or you rewrite it to mutex (etc). Karel
Re: [HACKERS] Ignored PostgreSQL SET command
> I have a line in a PHP script that looks like this: > $set=pg_exec($dbconn, "SET DATESTYLE TO 'European'"); //Set date format > Since my ISP updated their server, this appears to be ignored as pgsql > always returns dates in ISO format. > 1. What is the default format of dates returned that I can ALWAYS rely on? ISO. Or you can start up the backend with a different default. > 2. Why is the command ignored? It is not (or, is probably not). The variant "European" affects month and day ordering when specifying a date or when formatting a date with the "Postgres" or "SQL" format. You probably want SET DATESTYLE TO 'SQL,European' but ymmv. Check out the docs for more complete info, specifically the chapter on data types. - Thomas
Re: [INTERFACES] Re: [HACKERS] PHP and PostgreSQL
Does this requested chagne have to do with Apache or PostgreSQL? w wrote: > > > > I have been asked by the major PHP developer Rasmus Lerdorf to see > > if > > the PostgreSQL/PHP interface needs any improvements. > > > > Is the current PostgreSQL interface module in PHP adequate? Does it > > support all the current libpq features? > > > > The only problem we have run into (and I have heard of others having this > > problem also) is with persistent connections. I have seen discussion on > > persistent connection problems but I'm not sure the problem was ever > > resolved. The problem we have seen is that when using persistent > > connections the web server doesn't seen to reuse the connections or somthing > > to that effect. The result being that we eventually use up our postgres > > limit of 48 connections and nothing can connect to postgre anymore. It is > > possible that this is a configuration problem that we haven't sufficiently > > investigated, but I meniton it because I have heard other talk of this. > > Anyone have more information? > > Persistent connections behave exactly as advertised. Each apache process > sets up and maintains persistent connections as needed. The problem is > that for a typical web server, there are so many subprocesses that > persistent connections are probably consume more resources than they > save, unless they are combined with connection pooling across ALL the > apache processes. > > Implementation of connection pooling is by far the most serious > shortcoming of the current implementation, IMHO. > > I would dearly love to see this addressed as our postgresql database > sees connections from about 300 servers for 6 databases. Since our > postgresql server cannot support 1800 simultaneous active backends, > persistent connections are useless without pooling. So instead we > initiate 10 or more backends every second for generally very simple > queries. Most of the queries are pretty simple, so I would not be at all > surprised if we sent more system resources opening connections than we > do actually answering queries > > -- > Karl DeBisschop [EMAIL PROTECTED] > Learning Network/Information Please http://www.infoplease.com > Netsaint Plugin Developer[EMAIL PROTECTED] > -- 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] Re: [DOCS] Inheritance docs error.
> I am strongly inclined to rip out the pseudo-UNDER clause and support > only the old-style INHERITS syntax for 7.1. UNDER is adding no > functionality and I think we will eventually regret using an SQL keyword > for non-SQL semantics. I agree with you, Hannu, et al. If it isn't making a good effort in truely supporting SQL9x, then it isn't yet worth having in the parser. - Thomas
Re: [HACKERS] Re: [DOCS] Inheritance docs error.
I thought about this UNDER/INHERITS stuff months ago and wrote this file: http://www.comptechnews.com/~reaster/pgoo.html It might have something of value to someone. I'm not sure everything in the file is correct though. I remember the idea of UNDER is to be compatible with storing data from a Java program, which only does single inheritance of classes and multiple for interface types. UNDER and INHERIT are different enough to be completely separate and coexisting. It's an interesting subject, but I don't have anything much else to say about this topic since I have no plans to implement it! I'd have to study postgres for another year probably first! :) On Sunday 31 December 2000 22:57, Hannu Krosing wrote: > Tom Lane wrote: > > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > They are all correct: UNDER is the new SQL99 syntax, INHERITS is > > the traditional Postgres syntax. > > >> > > >> Current docs do appear to be erroneous: they claim the UNDER phrase > > >> goes where INHERIT does, which is not what the grammar thinks. I > > >> haven't looked at SQL99 to see which is right. > > > > > > The grammar appears to be correct to the extent that SQL99 wants the > > > UNDER before the column list, so I corrected the documentation at that > > > point. However, the syntax as a whole is not SQL99-compliant. > > > > Hmm. After looking at the SQL99 syntax, it seems that what we've done > > with our grammar is to take the old INHERITS functionality and plaster > > a vaguely-SQL-like syntax on it. I have to wonder whether this is a > > good idea. I think it'll get in the way when and if we want to offer > > true SQL99 UNDER behavior, which is only marginally related to INHERITS. > > (In particular, SQL99 seems to want an explicit specification of the > > structured type that's being inherited.) > > > > I am strongly inclined to rip out the pseudo-UNDER clause and support > > only the old-style INHERITS syntax for 7.1. UNDER is adding no > > functionality and I think we will eventually regret using an SQL keyword > > for non-SQL semantics. > > > > Comments? > > I'm all for it, as UNDER and INHERITS seem to offer different benefits. > > As UNDER is strictly single-inheritance, the best way to implement it > seems > to use a single file for all tables "under" the root table which will > give us > almost automatic primary keys and other constraints which are much > trickier to > implement or even to define for multimple inheritance (e.g. how do you > "inherit" > a primary key from two parents' primary keys) > > So just leave it out until we have a _real_ under implementation, or > else > someone will use it and lock us into backwards-compatibility trap. > > > -- > Hannu -- Robert B. Easter [EMAIL PROTECTED] - - CompTechNews Message Board http://www.comptechnews.com/ - - CompTechServ Tech Services http://www.comptechserv.com/ - -- http://www.comptechnews.com/~reaster/
Re: [HACKERS] Using Threads?
For anyone interested, I have posted my multi-threaded version of PostgreSQL here. http://www.sacadia.com/mtpg.html It is based on 7.0.2 and the TAO CORBA ORB which is here. http://www.cs.wustl.edu/~schmidt/TAO.html Myron Scott [EMAIL PROTECTED]
Re: [HACKERS] Current Sources/UW7.1.1
Larry Rosenman <[EMAIL PROTECTED]> writes: > * Tom Lane <[EMAIL PROTECTED]> [010101 23:16]: > [snip] > there are a couple of them that I *THINK* have more tuples on one side > or the other of the Diff. I'll try and narrow them... (or shouldn't I > bother? ) That would certainly be a bug, if so, so do look closer. An easy way to check for such a thing is to grep the regression.diffs file for differences in the "(n rows)" comments appended by psql. regards, tom lane
Re: [HACKERS] Current Sources/UW7.1.1
* Tom Lane <[EMAIL PROTECTED]> [010101 23:16]: [snip] there are a couple of them that I *THINK* have more tuples on one side or the other of the Diff. I'll try and narrow them... (or shouldn't I bother? ) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Current Sources/UW7.1.1
Larry Rosenman <[EMAIL PROTECTED]> writes: The planregress.sh tests generate errors. Attached is a tar of the planregress directory... >> >> Have you examined the diffs to see whether any represent real problems, >> as opposed to trivial changes in output tuple order? > > Is the tuple order differences ok? If so, I believe these were just > order differences, but... Yes, order differences are OK (except for queries that specify an ORDER BY, of course). Most of the regression test scripts are not so pedantic as to use an ORDER BY for every single SELECT, and so their result tuple orderings are not truly well-defined according to the letter of the SQL spec. In practice, since the regress tests start from a virgin database, the planner should choose the same plans on most or all platforms, and so we usually don't have problems with cross-platform differences in result orderings. (There are some tests in which we've had to insert explicit ORDER BY clauses just to prevent such problems, however.) planregress creates an additional source of order variation by forcing different plan types to be used, so you get some "failures" that have to be validated by inspection. We could eliminate these "failures" by adding more explicit ORDER BYs, but IMHO that would actually make planregress less useful, not more. The ORDER BY clauses would push the planner to favor ordered plans over unordered ones, and thus to some extent defeat the purpose of exercising multiple plan types. Since planregress isn't intended for general-purpose use, only as a test tool for planner hacking, I think it's most useful as-is. But you do have to know how to interpret the output. regards, tom lane
Re: [HACKERS] PHP and PostgreSQL
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Now what happens is if someone browses the phorums for a little while, and > then switches to pages that use our own db classes, you get random slowdowns > (ie. a select occurs, and then times out after 2 mins or so). > If you use psql, and perform the select you get a 'shared memory corruption' > and 'timed out waiting for lock' errors. Ugh. We would like to think that client misbehavior couldn't cause such things. Can you dig into this some more, and provide further details on what is happening and what the sequence of client requests is? regards, tom lane
[HACKERS] Ignored PostgreSQL SET command
I have a line in a PHP script that looks like this: $set=pg_exec($dbconn, "SET DATESTYLE TO 'European'"); //Set date format Since my ISP updated their server, this appears to be ignored as pgsql always returns dates in ISO format. 1. What is the default format of dates returned that I can ALWAYS rely on? 2. Why is the command ignored? === Patrick Dunford, Christchurch, NZ - http://pdunford.godzone.net.nz/ There is no wisdom, no insight, no plan that can succeed against the LORD. -- Proverbs 21:30 http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20010101 === Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
RE: [HACKERS] PHP and PostgreSQL
At my work we were happily cruising along using PHP/Postgres persistent
connections. This was all happy until we installed Phorum. Phorum has its
own database abstraction layer, quite separate to all our own database
classes.
Now what happens is if someone browses the phorums for a little while, and
then switches to pages that use our own db classes, you get random slowdowns
(ie. a select occurs, and then times out after 2 mins or so).
If you use psql, and perform the select you get a 'shared memory corruption'
and 'timed out waiting for lock' errors.
Our basic theory is that somehow locks aren't being properly released by
phorum, or the connection pooling is stuffed - although Phorum doesn't use
the LOCK or BEGIN/COMMIT commands. Actually, we did notice that Phorum
issues a COMMIT whenever it closes a connection, even tho it never issues a
BEGIN. If we avoid running any Phorum scripts - no problems occur.
In an attempt to fix the problem, we configured phplib and Phorum to use
non-persistent postgresql connections. This worked fine, until now we have
a particular script, no different to the rest, that cannot acquire a
connection - it just gets an invalid resource handle. We switched phplib
back to persistent connections, and it works fine again - nothing else was
changed!
So my advice to the PHP people is to just fix Postgres connection handling!
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Tuesday, January 02, 2001 11:58 AM
> To: Rod Taylor
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] PHP and PostgreSQL
>
>
> This is interesting. I always wondered how the persistent connection
> stuff handled this, and not I see that it doesn't.
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > The only problem we have run into (and I have heard of others
> having this
> > > problem also) is with persistent connections. I have seen
> discussion on
> > > persistent connection problems but I'm not sure the problem was ever
> > > resolved. The problem we have seen is that when using persistent
> > > connections the web server doesn't seen to reuse the connections or
> > somthing
> > > to that effect. The result being that we eventually use up
> our postgres
> > > limit of 48 connections and nothing can connect to postgre
> anymore. It is
> > > possible that this is a configuration problem that we haven't
> sufficiently
> > > investigated, but I meniton it because I have heard other
> talk of this.
> > > Anyone have more information?
> >
> > The *real* problem with persistent connections is:
> >
> > Script1: BEGIN;
> > Script1: UPDATE table set row = 'things';
> > Script2: Insert into table (id) values ('bad data');
> > Script1: COMMIT;
> >
> > Since script2 managed to do a BAD insert in the middle of script1's
> > transaction, the transaction in script1 fails. Obvious
> solution? Don't do
> > connection sharing when a transaction is enabled. The whole persistent
> > connection thing is only valid for mysql as it's the only thing
> that doesn't
> > really support transactions (and even thats partially changed).
> >
> > They need to look for stuff going through (keywords like BEGIN)
> and 'lock'
> > that connection to the single entity that opened it.
> >
> > It's much easier to write your own. I wrote a few functions like:
> >
> > get_connection('DB PARMS');
> > begin_transaction();
> >
> > commit_transaction();
> > close_connection();
> >
> > All of this is done in a class which has knowledge of all
> connections that a
> > script is currently using. Beginning a transaction locks down the
> > connection from use by any other handler, they're all bumped to
> another one.
> > Problem? It requires atleast 1 connection per page, but since they're
> > actually dropped at close it's not so bad.
> >
> >
>
>
> --
> 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] PHP and PostgreSQL
It was obviously designed with MySQL's "Nobody needs transactions for
webwork" type of situation in mind.
> This is interesting. I always wondered how the persistent connection
> stuff handled this, and not I see that it doesn't.
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > The only problem we have run into (and I have heard of others having
this
> > > problem also) is with persistent connections. I have seen discussion
on
> > > persistent connection problems but I'm not sure the problem was ever
> > > resolved. The problem we have seen is that when using persistent
> > > connections the web server doesn't seen to reuse the connections or
> > somthing
> > > to that effect. The result being that we eventually use up our
postgres
> > > limit of 48 connections and nothing can connect to postgre anymore.
It is
> > > possible that this is a configuration problem that we haven't
sufficiently
> > > investigated, but I meniton it because I have heard other talk of
this.
> > > Anyone have more information?
> >
> > The *real* problem with persistent connections is:
> >
> > Script1: BEGIN;
> > Script1: UPDATE table set row = 'things';
> > Script2: Insert into table (id) values ('bad data');
> > Script1: COMMIT;
> >
> > Since script2 managed to do a BAD insert in the middle of script1's
> > transaction, the transaction in script1 fails. Obvious solution? Don't
do
> > connection sharing when a transaction is enabled. The whole persistent
> > connection thing is only valid for mysql as it's the only thing that
doesn't
> > really support transactions (and even thats partially changed).
> >
> > They need to look for stuff going through (keywords like BEGIN) and
'lock'
> > that connection to the single entity that opened it.
> >
> > It's much easier to write your own. I wrote a few functions like:
> >
> > get_connection('DB PARMS');
> > begin_transaction();
> >
> > commit_transaction();
> > close_connection();
> >
> > All of this is done in a class which has knowledge of all connections
that a
> > script is currently using. Beginning a transaction locks down the
> > connection from use by any other handler, they're all bumped to another
one.
> > Problem? It requires atleast 1 connection per page, but since they're
> > actually dropped at close it's not so bad.
> >
> >
>
>
> --
> 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] PHP and PostgreSQL
This is interesting. I always wondered how the persistent connection
stuff handled this, and not I see that it doesn't.
[ Charset ISO-8859-1 unsupported, converting... ]
> > The only problem we have run into (and I have heard of others having this
> > problem also) is with persistent connections. I have seen discussion on
> > persistent connection problems but I'm not sure the problem was ever
> > resolved. The problem we have seen is that when using persistent
> > connections the web server doesn't seen to reuse the connections or
> somthing
> > to that effect. The result being that we eventually use up our postgres
> > limit of 48 connections and nothing can connect to postgre anymore. It is
> > possible that this is a configuration problem that we haven't sufficiently
> > investigated, but I meniton it because I have heard other talk of this.
> > Anyone have more information?
>
> The *real* problem with persistent connections is:
>
> Script1: BEGIN;
> Script1: UPDATE table set row = 'things';
> Script2: Insert into table (id) values ('bad data');
> Script1: COMMIT;
>
> Since script2 managed to do a BAD insert in the middle of script1's
> transaction, the transaction in script1 fails. Obvious solution? Don't do
> connection sharing when a transaction is enabled. The whole persistent
> connection thing is only valid for mysql as it's the only thing that doesn't
> really support transactions (and even thats partially changed).
>
> They need to look for stuff going through (keywords like BEGIN) and 'lock'
> that connection to the single entity that opened it.
>
> It's much easier to write your own. I wrote a few functions like:
>
> get_connection('DB PARMS');
> begin_transaction();
>
> commit_transaction();
> close_connection();
>
> All of this is done in a class which has knowledge of all connections that a
> script is currently using. Beginning a transaction locks down the
> connection from use by any other handler, they're all bumped to another one.
> Problem? It requires atleast 1 connection per page, but since they're
> actually dropped at close it's not so bad.
>
>
--
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] PHP and PostgreSQL
Yes, please send them over to the PHP folks. Thanks. > On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote: > > I have been asked by the major PHP developer Rasmus Lerdorf to see if > > the PostgreSQL/PHP interface needs any improvements. > > > > Is the current PostgreSQL interface module in PHP adequate? Does it > > support all the current libpq features? > > > > If not, would someone submit some patches to the PHP folks. They want > > us to work well with PHP. They are basically encouraging us to improve > > it in any way we can. > > I use PHP and Postgres together quite a bit, and find the APIs > complete enough for most things. However, just last week I implemented > > pg_lolseek($loid, $offset $whence) > and > pg_lotell($loid) > > For some stuff that we are working on. They are pretty straightforward, > and I can package them up and submit them if someone wants. > > -- > Adam Haberlach|A cat spends her life conflicted between a > [EMAIL PROTECTED] |deep, passionate, and profound desire for > http://www.newsnipple.com |fish and an equally deep, passionate, and > '88 EX500 |profound desire to avoid getting wet. > -- 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] how do i store \0 inside a text attribute?
> > See bytea, though its presentation format leaves something to be desired IMHO > > > > > how would someone be expected to store, say, a GIF image in a TOAST text? > > > > One would not. A TOASTed bytea is the appropriate column type. > > thanks -- that's EXACTLY what i needed. > bytea was not really used very much until people started asking to do this kind of think. -- 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] GNU readline and BSD license
> > >I do not believe that. In fact, I'll go further and say "Horsepucky!" > > >The GPL applies to works that "contain or are derived from" a GPL'd > > >program. Linking to a separately distributed library does not cause > > >psql either to contain or to be derived from libreadline. > > > > > > Some very highly paid lawyers disagree with you. > > > > That doesn't make them right, but keep in mind that no one has defined "derivitive >work" in a court of law. And RMS isn't a lawyer. > > > > I agree readline doesn't taint PG, but IMHO, the more distance between the GPL and >PG, the better. > OK. For the last time, here's the story about linking, as agreed upon by > almost damn everyone: > > a) dynamic linking is kosher, as of GPL2 > b) static linking is OK, but you may NOT redistribute resulting libraries. > > I hope the above will put the discussion about readline to an end, as > Postgres does not distribute statically linked binaries. I read through this large thread, and it is good to see that readline is not an issue for us. Only binary distributions that statically link in libreadline are a problem. If people feel that this is a significant restriction, we can start distributing libedit, or the binary packager can link libedit into their binary. I hesitate to add the libedit code to our already large distribution, and I think several others agreed. I am concerned about RMS's heavy-handed agenda in regards to the GPL, but it appears he is not irrational in his requirements. -- 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] Current Sources/UW7.1.1
* Tom Lane <[EMAIL PROTECTED]> [010101 13:19]: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > The planregress.sh tests generate errors. Attached is a tar of the > > planregress directory... > > Have you examined the diffs to see whether any represent real problems, > as opposed to trivial changes in output tuple order? Is the tuple order differences ok? If so, I believe these were just order differences, but... > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] pg_dumpall (7.1beta1, current CVS)
* Tom Lane <[EMAIL PROTECTED]> [010101 13:16]: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > I noticed today that pg_dumpall from current CVS does *NOT* > > dump a password assiged to the postgres user. > > > I consider this BAD, since if one has to restore from > > a pg_dumpall, one may forget to reset the password. > > I'm unconvinced. The pg_dumpall script is clearly intended to allow > restoration into a new database installation with a different superuser; > you will note that the script is careful not to assume that the old and > new superuser names are the same (an assumption your proposed patch > does make). > > In any case the new installation certainly already *has* a superuser. > I'm not sure it's the job of the restore script to change his password > for him. > > This does point up that there is some state that is not saved/restored > by pg_dumpall --- the pg_hba.conf file and other config files that > live in $PGDATA come to mind. Perhaps there should be a separate > utility that saves/restores these. (pg_dump can't do it because there's > no way to retrieve these files through a database connection.) How would you suggest doing this? A shell script that makes a SHAR or somesuch? Or what? Should it save the SuperUser password? I agree that this is a shortcoming. As to the SuperUser password thing, how do we remind the user that they had one set? Can we at least put out a comment in the pg_dumpall output that mentions it? > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] PRIMARY KEY and INHERITANCE
From: Horst Herb <[EMAIL PROTECTED]> Date: Mon, 1 Jan 2001 10:09:52 +1100 >> create table a ( >>id serial primary key, >>something text >> ); >> >> create table b ( >>morething text >> ) inherits (a); >> >> create table c ( >>trouble int references b; >> ); >> NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY >> check(s) ERROR: PRIMARY KEY for referenced table "b" not found > > >> How is possible to resolve this bug? >> How is possible to talk about a ORDBMS with this kind of error? > It is not a bug, I would call it a missing feature. I had the same problem, > and somebody from this list helped me with a private email. I think this > should be included in the FAQ and general documentation. > What happens is that the attribute "id" is inherited, but the index on "id" > is not. The workaround is: > create unique index table_b_id on b(id); > Then the index exists, and the foreign key can be referenced. Thank you Horst, I was very happy for this workaround: it could make me able to use classes during the design and it could give me a power approach, but now: \di List of relations Name| Type | Owner ---+---+--- a_pkey| index | fer table_b_id| index | fer # create table c (test int references b); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) ERROR: PRIMARY KEY for referenced table "b" not found I've also tried to build b_pkey unique index: b_pkey| index | fer The trouble still persists. May someone give me another workaround for PostgreSQL 7.0.3? Thank you in advance, \fer
RE: [HACKERS] Current Sources/UW7.1.1
No I hadn't. -- 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 -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Monday, January 01, 2001 1:19 PM To: Larry Rosenman Cc: PostgreSQL Hackers List Subject: Re: [HACKERS] Current Sources/UW7.1.1 Larry Rosenman <[EMAIL PROTECTED]> writes: > The planregress.sh tests generate errors. Attached is a tar of the > planregress directory... Have you examined the diffs to see whether any represent real problems, as opposed to trivial changes in output tuple order? regards, tom lane
Re: [HACKERS] Current Sources/UW7.1.1
Larry Rosenman <[EMAIL PROTECTED]> writes: > The planregress.sh tests generate errors. Attached is a tar of the > planregress directory... Have you examined the diffs to see whether any represent real problems, as opposed to trivial changes in output tuple order? regards, tom lane
Re: [HACKERS] pg_dumpall (7.1beta1, current CVS)
Larry Rosenman <[EMAIL PROTECTED]> writes: > I noticed today that pg_dumpall from current CVS does *NOT* > dump a password assiged to the postgres user. > I consider this BAD, since if one has to restore from > a pg_dumpall, one may forget to reset the password. I'm unconvinced. The pg_dumpall script is clearly intended to allow restoration into a new database installation with a different superuser; you will note that the script is careful not to assume that the old and new superuser names are the same (an assumption your proposed patch does make). In any case the new installation certainly already *has* a superuser. I'm not sure it's the job of the restore script to change his password for him. This does point up that there is some state that is not saved/restored by pg_dumpall --- the pg_hba.conf file and other config files that live in $PGDATA come to mind. Perhaps there should be a separate utility that saves/restores these. (pg_dump can't do it because there's no way to retrieve these files through a database connection.) regards, tom lane
Re: [HACKERS] About PQsetClientEncoding(),"SET NAMES",and "SETCLIENT_ENCODING"
On Sat, 30 Dec 2000, Tatsuo Ishii wrote: > Even if the Big5 version of README.mb could be included in our SGML > docs, I don't think sgml tools could process Big5 without any problem > due to the nature of the encoding(probably ok for EUC-TW or > UTF-8). What about placing it as doc/README.mb.big5 or whatever? IMHO, doc/README.mb.big5 is enough. -- Chih-Chang Hsieh
