Re: [HACKERS] Performance TODO items
On Mon, 30 Jul 2001, Bruce Momjian wrote: > * Improve spinlock code, perhaps with OS semaphores, sleeper queue, or > spining to obtain lock on multi-cpu systems You may be interested in a discussion which happened over on linux-kernel a few months ago. Quite a lot of people want a lightweight userspace semaphore, and for pretty much the same reasons. Linus proposed a pretty interesting solution which has the same minimal overhead as the current spinlocks in the non- contention case, but avoids the spin where there's contention: http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg39615.html Matthew. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Returned mail: User unknown
> Grant <[EMAIL PROTECTED]> writes: > > Is it just me or is an address on the hackers list who's mail is handled > > by wmail.metro.taejon.kr not existant? > > I've had to institute a sendmail access block against that site :-( > It bounces a useless complaint for every damn posting I make. What's > worse is that it looks like it's trying to deliver extra copies to > the people named in the To:/CC: lines --- if it somehow fails to fail > to deliver those copies, it's spamming. > > Yo Marc, are you awake? These losers should be blocked from our lists > permanently (or at least till they install less-broken mail software). I already reported it to him yesterday. I have blocked them via sendmail here too, and sent mail to their postmaster. The strange part of it is that these emails arrives in my mailbox marked as "already read" which is kind of errie. I see the new mail, but it says I already read it. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] vacuumlo.
> > > > Can you see a scenario where a programmer would forget to delete the > > > > data from pg_largeobject and the database becoming very large filled > > > > with orphaned large objects? > > > > > > Sure. My point wasn't that the functionality isn't needed, it's that > > > I'm not sure vacuumlo does it well enough to be ready to promote to > > > the status of mainstream code. It needs more review and testing before > > > we can move it out of /contrib. > > > > > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > > account. I'm suspicious if vacuumlo is reliable. > > This was my round about way of asking if something to combat this issue > can be placed in the to do list. :) Added to TODO: * Improve vacuum of large objects (/contrib/vacuumlo) -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: From TODO, XML?
Bruce Momjian wrote:
>
> > > > I have managed to get several XML files into PostgreSQL by writing a parser,
> > > > and it is a huge hassle, the public parsers are too picky. I am thinking that a
> > > > fuzzy parser, combined with some intelligence and an XML DTD reader, could make
> > > > a very cool utility, one which I have not been able to find.
> > > >
> > > > Perhaps it is a two stage process? First pass creates a schema which can be
> > > > modified/corrected, the second pass loads the data.
> > >
> > > Can we accept only relational XML. Does that buy us anything? Are the
> > > other database vendors outputting heirchical XML? Are they using
> > > foreign/primary keys to do it?
> >
> > Then what's the point? Almost no one creates a non-hierarchical XML. For the
> > utility to be usefull, beyond just a different format for pg_dump, it has to
> > deal with these issues and do the right thing.
>
> Oh, seems XML will be much more complicated than I thought.
I think an XML "output" for pg_dump would be a pretty good/easy feature. It is
easy to create XML.
bla bla
foo bar
Is very easy to create. Of course a little work would be needed to take
information of the field (column) types into a DTD, but the actual XML is not
much more complicated than a printf, i.e. printf("<%s>%s", name, data,
name);
The real issues is reading XML. Postgres can make a DTD and XML file which can
be read by a strict parser, but that does not imply the inverse.
Attached is an XML file from MP3.com. For an XML import to be anything but
market/feature list candy, it should be able to import this sort of data,
because when people say XML, this is the sort of data they are thinking about.
If you take the time to examine the file, you will see it represents four or
five distinct tables in a relational database. These tables are Song, Artist,
[Cdlist,] Cd, and Genre.
Song has a number of fields, plus foreign keys: Artist, Cdlist, and Genre.
Cdlist would have to have a synthetic primary key (OID, sequence?), which
tables Cd and Song would reference. Cdlist would probably never be used in a
query.
I think it is doable as a project (which everyone will be glad to have and
complain about), but I think it is far more complicated than a one or two day
modification of pg_dump.
--
5-4-3-2-1 Thunderbirds are GO!
http://www.mohawksoft.com
1004001
121693
http://contentfeeds.mp3.com/standard_2.0/data_files/artists/121/121693.xml
AVAILABLE
conscious
http://artists.mp3s.com/artist_song/1004/1004001.html
A hard techno tune in the European style. Deep sleepers regain
consciousness. Are they awake, are they alive or is it all a dream..
e n c r y p t i o n
portal
white label
66944
http://contentfeeds.mp3.com/standard_2.0/data_files/dam_cds/66/66944.xml
N
http://images.mp3.com/mp3s/71/e_n_c_r_y_p_t_i_o_n/artificial1.jpg
Intelligent Techno
http://genres.mp3.com/music/electronic/techno/intelligent_techno
7.8
http://my.mp3.com/music?Action=sl-1004001,cm-ad,cs-pc&origin=song&origin_id=1004001&location=generic&wqx=AddToMyMP3
http://musicgreetings.mp3.com/email_song?song_id=1004001&origin=song&origin_id=1004001&location=generic&band_id=121693
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Performance TODO items
> On Mon, 30 Jul 2001, Bruce Momjian wrote: > > > * Improve spinlock code, perhaps with OS semaphores, sleeper queue, or > > spining to obtain lock on multi-cpu systems > > You may be interested in a discussion which happened over on > linux-kernel a few months ago. > > Quite a lot of people want a lightweight userspace semaphore, > and for pretty much the same reasons. > > Linus proposed a pretty interesting solution which has the > same minimal overhead as the current spinlocks in the non- > contention case, but avoids the spin where there's contention: > > http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg39615.html Yes, many OS's have user-space spinlocks, for the same performance reasons (no kernel call). -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] [Fwd: Majordomo Delivery Error]
Anyone else getting these? Are these supposed to go to list subscribers? Tim Original Message Subject: Majordomo Delivery Error Date: Tue, 31 Jul 2001 09:43:58 -0400 (EDT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] This message was created automatically by mail delivery software. A Majordomo message could not be delivered to the following addresses: [EMAIL PROTECTED]: 450 4.7.1 ... Can not check MX records for recipient host pixelenvy.ca [EMAIL PROTECTED]: 450 4.7.1 ... Can not check MX records for recipient host mail2db.circumsolutions.com [EMAIL PROTECTED]: 450 4.7.1 ... Can not check MX records for recipient host techjockey.net -- Original message omitted -- -- Timothy H. Keitt Department of Ecology and Evolution State University of New York at Stony Brook Stony Brook, New York 11794 USA Phone: 631-632-1101, FAX: 631-632-7626 http://life.bio.sunysb.edu/ee/keitt/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [Fwd: Majordomo Delivery Error]
"Timothy H. Keitt" <[EMAIL PROTECTED]> writes: > Anyone else getting these? Are these supposed to go to list subscribers? Was it a bounceback from wmail.metro.taejon.kr? They seem to have some rather broken mail delivery software in place there. Bruce and I have both asked Marc to remove that address from the PG mail lists, but Marc's not responding (might be off on vacation or some such...) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [Fwd: Majordomo Delivery Error]
On Tue, 31 Jul 2001, Tom Lane wrote: > "Timothy H. Keitt" <[EMAIL PROTECTED]> writes: > > Anyone else getting these? Are these supposed to go to list subscribers? > > Was it a bounceback from wmail.metro.taejon.kr? They seem to have some > rather broken mail delivery software in place there. Bruce and I have > both asked Marc to remove that address from the PG mail lists, but Marc's > not responding (might be off on vacation or some such...) I just got a note from him, he got it. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] LIBPQ on Windows and large Queries
Hello all, I was in a trip and just arrived, and will do it real soon. Best Regards, Steve Howe - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Hiroshi Inoue" <[EMAIL PROTECTED]> Cc: "Steve Howe" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, July 29, 2001 8:57 PM Subject: Re: [HACKERS] LIBPQ on Windows and large Queries > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Well haven't this problem solved already ? > > I'm not sure. Steve, have you tried current sources? > > regards, tom lane > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Fw: [HACKERS] Translators wanted
The same applies as to my previous post... Sorry again. S. - Original Message - From: Serguei Mokhov <[EMAIL PROTECTED]> To: Peter Eisentraut <[EMAIL PROTECTED]> Sent: Wednesday, August 01, 2001 1:50 AM Subject: Re: [HACKERS] Translators wanted > - Original Message - > From: Peter Eisentraut <[EMAIL PROTECTED]> > To: Serguei Mokhov <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, July 16, 2001 4:03 PM > > > > Serguei Mokhov writes: > > > > > Are there people working on the translation into the Russian language? > > > If yes, then what messages are you working on and what encoding are you using? > > > I can start translating the messages, just want to make sure so that we > > > don't duplicate the effort. > > > > Use the koi8-r encoding unless you have strong reasons against it. > > Well, the KOI8-R is the standard encoding, no objection. However, Win32 apps > use Windows-1251, which is pretty common on Win machines (e.g. pgAdmin tool > on Windows will have to have messages in this exactly encoding), or console > Windows apps by historical reasons (from DOS) use the 866 code page. If people > write standard Windows or console client, which rely on the messages will > get garbage most likely or will switch back to English ones. > > I can send the translated messages in the all mentioned encodings, but the > problem is how will you place those files in the tree (according to the naming > conventions ll[_RR].po one can have only one language per region per component) > and plus, backbends probably have no way to know what kind of clients are > connected to them and which encoding is more appropriate for the given client > in the same language... These problems prevent different clients with the same > language but different encoding schemes equally well display those messages to the > user unless someone is willing (and has ideas how) to find a solution to the >problems. > > Serguei ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Fw: [HACKERS] Translators wanted
Sorry for posting this messages into the list. It was intended for Peter E., but it looks like his personal mailbox is over quota... Hopefully, he will scan through the posts in the list once he's back from vacation, and the message won't get lost. Serguei - Original Message - From: Serguei Mokhov <[EMAIL PROTECTED]> To: Peter Eisentraut <[EMAIL PROTECTED]> Sent: Wednesday, August 01, 2001 1:38 AM Subject: Re: [HACKERS] Translators wanted > Hello Peter, > > There was a little typo in line 73 in the original file libpq.pot: > > #: fe-connect.c:713 > #, c-format > msgid "could not socket to non-blocking mode: %s\n" > > missing the word 'set' between 'not' & 'socket'... Despite > I'm not a native English speaker/writer, I strongly believe > it should be there: > > msgid "could not set socket to non-blocking mode: %s\n" > > I corrected the message in my translations; however, I > didn't update the sources. > > The .PO file is sent to the pgsql-patches list. > > By the time you're back from vacation, > I might have some other things translated... > > Have a good day, > Serguei > > - Original Message - > From: Peter Eisentraut <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, July 15, 2001 6:13 PM > Subject: [HACKERS] Translators wanted > > > > Those of you who wanted to help translating the messages of PostgreSQL > > programs and libraries, you can get started now. I've put up a page > > explaining things a bit, with links to pages that explain things a bit > > more, at > > > > http://www.ca.postgresql.org/~petere/nls.html > > > > Please arrange yourselves with other volunteering speakers of your > > language. Results should be sent to the pgsql-patches list. > > > > You have a few days to ask me questions about this, then I'll be off on > > vacation and looking forward to a lot of progress when I get back. ;-) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Returned mail: User unknown
Should be fixed ... meant to respond as soon as I fixed it, but got onto something else at the time :( On Tue, 31 Jul 2001, Bruce Momjian wrote: > > Grant <[EMAIL PROTECTED]> writes: > > > Is it just me or is an address on the hackers list who's mail is handled > > > by wmail.metro.taejon.kr not existant? > > > > I've had to institute a sendmail access block against that site :-( > > It bounces a useless complaint for every damn posting I make. What's > > worse is that it looks like it's trying to deliver extra copies to > > the people named in the To:/CC: lines --- if it somehow fails to fail > > to deliver those copies, it's spamming. > > > > Yo Marc, are you awake? These losers should be blocked from our lists > > permanently (or at least till they install less-broken mail software). > > I already reported it to him yesterday. I have blocked them via > sendmail here too, and sent mail to their postmaster. > > The strange part of it is that these emails arrives in my mailbox marked > as "already read" which is kind of errie. I see the new mail, but it > says I already read it. > > -- > 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 > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Update to 7.1.2 Question...
hello all I have a postgresql 7.0 and I'm trying to update to 7.1.2 using rpms but some files is missing like: libcrypto.so.0 libssl.so.0 anyone knows what package i can find this files?? thanks... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Update to 7.1.2 Question...
"gabriel" <[EMAIL PROTECTED]> writes: > hello all > I have a postgresql 7.0 > and I'm trying to update to 7.1.2 using rpms > but some files is missing > like: > libcrypto.so.0 > libssl.so.0 > > anyone knows what package i can find this files?? openssl -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linux only)
Tom Lane wrote: >[ redirected to pgsql-hackers for comment ] > >Helge Bahmann <[EMAIL PROTECTED]> writes: >> On Tue, 31 Jul 2001, Tom Lane wrote: >>> There is a more complete version of this capability in the Debian patch >>> set. I think we've been waiting for Oliver to pull it out and submit it >>> as a patch... > >> Ok found it; uses "peer" as a keyword instead of "ident" but basically >> does the same thing. I think you can discard my patch then. > >Well, we need to talk about that. I like your idea of making ident auth >"just work" on local connections better than Oliver's approach of >inventing a separate auth-type keyword. So some kind of merger of the >two patches seems attractive to me. But Oliver may feel that he has to >continue to support the "peer" keyword on Debian anyway, for backwards >compatibility. If so, do we want different ways of doing the same thing >on different distros, or should we just follow the Debian precedent to >keep things ugly-but-consistent? This change has only been made in the unstable release; so I don't mind if peer and ident are folded together. Anyone running unstable knows the world may turn upside down beneath him! So if you have a patch to do that, go ahead. -- 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 "Have not I commanded thee? Be strong and of a good courage; be not afraid, neither be thou dismayed; for the LORD thy God is with thee whithersoever thou goest."Joshua 1:9 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Update to 7.1.2 Question...
gabriel wrote: > > hello all > I have a postgresql 7.0 > and I'm trying to update to 7.1.2 using rpms > but some files is missing > like: > libcrypto.so.0 > libssl.so.0 > > anyone knows what package i can find this files?? > > thanks... > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster These should be available on RedHat's update pages. libssl.so comes from OpenSSH libcrypt comes from crypt. -- 5-4-3-2-1 Thunderbirds are GO! http://www.mohawksoft.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: From TODO, XML?
Hi, Why don't use the excellent DBIx-XML_RDB perl module ? Give it the query it will return XML output as you sample. With some hack you can do what you want... Regards Gilles DAROLD mlw wrote: > Bruce Momjian wrote: > > > > > > > I have managed to get several XML files into PostgreSQL by writing a parser, > > > > > and it is a huge hassle, the public parsers are too picky. I am thinking >that a > > > > > fuzzy parser, combined with some intelligence and an XML DTD reader, could >make > > > > > a very cool utility, one which I have not been able to find. > > > > > > > > > > Perhaps it is a two stage process? First pass creates a schema which can be > > > > > modified/corrected, the second pass loads the data. > > > > > > > > Can we accept only relational XML. Does that buy us anything? Are the > > > > other database vendors outputting heirchical XML? Are they using > > > > foreign/primary keys to do it? > > > > > > Then what's the point? Almost no one creates a non-hierarchical XML. For the > > > utility to be usefull, beyond just a different format for pg_dump, it has to > > > deal with these issues and do the right thing. > > > > Oh, seems XML will be much more complicated than I thought. > > I think an XML "output" for pg_dump would be a pretty good/easy feature. It is > easy to create XML. > > > bla bla > foo bar > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pg_hba.conf pre-parsing change
Bruce Momjian - CVS <[EMAIL PROTECTED]> writes: > Load pg_hba.conf and pg_ident.conf on startup and SIGHUP into List of > Lists, and use that for user validation. While this should be a nice speedup, it bothers me somewhat that the old behavior of reacting immediately to pg_hba.conf and pg_ident.conf updates has been changed. (And you didn't update the documentation to say so --- tsk tsk.) Would it make sense to do fstat calls on these files and reload whenever we observe that the file modification time has changed? That'd be an additional kernel call per connection attempt, so I'm not at all sure I want to do it ... but it ought to be debated. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections(Linux only)
Can you send over your version for review. We can edit the 'peer' part. > Tom Lane wrote: > >[ redirected to pgsql-hackers for comment ] > > > >Helge Bahmann <[EMAIL PROTECTED]> writes: > >> On Tue, 31 Jul 2001, Tom Lane wrote: > >>> There is a more complete version of this capability in the Debian patch > >>> set. I think we've been waiting for Oliver to pull it out and submit it > >>> as a patch... > > > >> Ok found it; uses "peer" as a keyword instead of "ident" but basically > >> does the same thing. I think you can discard my patch then. > > > >Well, we need to talk about that. I like your idea of making ident auth > >"just work" on local connections better than Oliver's approach of > >inventing a separate auth-type keyword. So some kind of merger of the > >two patches seems attractive to me. But Oliver may feel that he has to > >continue to support the "peer" keyword on Debian anyway, for backwards > >compatibility. If so, do we want different ways of doing the same thing > >on different distros, or should we just follow the Debian precedent to > >keep things ugly-but-consistent? > > This change has only been made in the unstable release; so I don't mind > if peer and ident are folded together. Anyone running unstable knows > the world may turn upside down beneath him! > > So if you have a patch to do that, go ahead. > > -- > 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 > > "Have not I commanded thee? Be strong and of a good > courage; be not afraid, neither be thou dismayed; for > the LORD thy God is with thee whithersoever thou > goest."Joshua 1:9 > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: pg_hba.conf pre-parsing change
> Bruce Momjian - CVS <[EMAIL PROTECTED]> writes: > > Load pg_hba.conf and pg_ident.conf on startup and SIGHUP into List of > > Lists, and use that for user validation. > > While this should be a nice speedup, it bothers me somewhat that the old > behavior of reacting immediately to pg_hba.conf and pg_ident.conf > updates has been changed. (And you didn't update the documentation to > say so --- tsk tsk.) Oh, I didn't realize we documented that. > Would it make sense to do fstat calls on these files and reload whenever > we observe that the file modification time has changed? That'd be an > additional kernel call per connection attempt, so I'm not at all sure > I want to do it ... but it ought to be debated. Comments anyone? We could, but we don't with postgresql.conf so it made sense to keep the behavior the same for the two files. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: pg_hba.conf pre-parsing change
Bruce Momjian <[EMAIL PROTECTED]> writes: >> Would it make sense to do fstat calls on these files and reload whenever >> we observe that the file modification time has changed? That'd be an >> additional kernel call per connection attempt, so I'm not at all sure >> I want to do it ... but it ought to be debated. Comments anyone? > We could, but we don't with postgresql.conf so it made sense to keep the > behavior the same for the two files. I'm inclined to agree --- for one thing, this allows one to edit the files in place without worrying that the postmaster will pick up a partially-edited file. But I wanted to throw the issue out to pghackers to see if anyone would be really unhappy about having to SIGHUP the postmaster after changing the authorization conf files. In any case, if we don't change the code, the change in behavior from prior releases needs to be documented... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Would it make sense to do fstat calls on these files and reload whenever > >> we observe that the file modification time has changed? That'd be an > >> additional kernel call per connection attempt, so I'm not at all sure > >> I want to do it ... but it ought to be debated. Comments anyone? > > > We could, but we don't with postgresql.conf so it made sense to keep the > > behavior the same for the two files. > > I'm inclined to agree --- for one thing, this allows one to edit the > files in place without worrying that the postmaster will pick up a > partially-edited file. But I wanted to throw the issue out to pghackers > to see if anyone would be really unhappy about having to SIGHUP the > postmaster after changing the authorization conf files. OK. > In any case, if we don't change the code, the change in behavior from > prior releases needs to be documented... You mean in the SGML or in the release highlight text? -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linux only)
BTW, while digging through my mail archives I discovered that Oliver *did* already extract his "peer" auth patch and submit it as a proposed patch --- see the pghackers archives for 3-May-2001. At the time I think we were concerned about portability issues, but as long as it's appropriately autoconf'd and documented, I see no real objection to supporting SO_PEERCRED authentication. I do still like Helge's API (use "ident") better than adding another auth keyword, though. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linuxonly)
> BTW, while digging through my mail archives I discovered that Oliver > *did* already extract his "peer" auth patch and submit it as a proposed > patch --- see the pghackers archives for 3-May-2001. At the time I > think we were concerned about portability issues, but as long as it's > appropriately autoconf'd and documented, I see no real objection to > supporting SO_PEERCRED authentication. > > I do still like Helge's API (use "ident") better than adding another > auth keyword, though. There is a Solaris API someone submitted a a month ago that was sort of rejected too. I will have to dig that one up. -- 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
On Tuesday 31 July 2001 19:20, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > We could, but we don't with postgresql.conf so it made sense to keep the > > behavior the same for the two files. > I'm inclined to agree --- for one thing, this allows one to edit the > files in place without worrying that the postmaster will pick up a > partially-edited file. But I wanted to throw the issue out to pghackers > to see if anyone would be really unhappy about having to SIGHUP the > postmaster after changing the authorization conf files. Hmmm... I much prefer having to SIGHUP postmaster -- that is semistandard daemon behavior, no? If enough people want the other behavior, add a postgresql.conf setting to activate 'modification notification' for config files. If nothing else, an 'accidental' pg_hba.conf corruption, deletion, or malicious change has to have a 'confirmation' step before a running postmaster sees the changes. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
Bruce Momjian <[EMAIL PROTECTED]> writes: >> In any case, if we don't change the code, the change in behavior from >> prior releases needs to be documented... > You mean in the SGML or in the release highlight text? Both. client_auth.sgml specifically states that editing the file is sufficient to make changes, and I think that it'd better be mentioned in the release notes too. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: pg_hba.conf pre-parsing change
> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> In any case, if we don't change the code, the change in behavior from > >> prior releases needs to be documented... > > > You mean in the SGML or in the release highlight text? > > Both. client_auth.sgml specifically states that editing the file is > sufficient to make changes, and I think that it'd better be mentioned > in the release notes too. Got it, and pg_hba.conf talked about it too. Also, I added a mention of SIGHUP to pg_ident.conf.sample. -- 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] vacuumlo.
Bruce Momjian wrote: > > > > > > Can you see a scenario where a programmer would forget to delete the > > > > > data from pg_largeobject and the database becoming very large filled > > > > > with orphaned large objects? > > > > > > > > Sure. My point wasn't that the functionality isn't needed, it's that > > > > I'm not sure vacuumlo does it well enough to be ready to promote to > > > > the status of mainstream code. It needs more review and testing before > > > > we can move it out of /contrib. > > > > > > > > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > > > account. I'm suspicious if vacuumlo is reliable. > > > > This was my round about way of asking if something to combat this issue > > can be placed in the to do list. :) > > Added to TODO: > > * Improve vacuum of large objects (/contrib/vacuumlo) > Is it possible for vacuumlo to be moved out of /contrib ? As far as I see, there's no perfect solution for vacuumlo. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] vacuumlo.
> > > > IIRC vacuumlo doesn't take the type lo(see contrib/lo) into > > > > account. I'm suspicious if vacuumlo is reliable. > > > > > > This was my round about way of asking if something to combat this issue > > > can be placed in the to do list. :) > > > > Added to TODO: > > > > * Improve vacuum of large objects (/contrib/vacuumlo) > > > > Is it possible for vacuumlo to be moved out of /contrib ? > As far as I see, there's no perfect solution for vacuumlo. Not sure myself. Let's see what others say. -- 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linux only)
[ redirected to pgsql-hackers for comment ] Helge Bahmann <[EMAIL PROTECTED]> writes: > On Tue, 31 Jul 2001, Tom Lane wrote: >> There is a more complete version of this capability in the Debian patch >> set. I think we've been waiting for Oliver to pull it out and submit it >> as a patch... > Ok found it; uses "peer" as a keyword instead of "ident" but basically > does the same thing. I think you can discard my patch then. Well, we need to talk about that. I like your idea of making ident auth "just work" on local connections better than Oliver's approach of inventing a separate auth-type keyword. So some kind of merger of the two patches seems attractive to me. But Oliver may feel that he has to continue to support the "peer" keyword on Debian anyway, for backwards compatibility. If so, do we want different ways of doing the same thing on different distros, or should we just follow the Debian precedent to keep things ugly-but-consistent? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linuxonly)
> [ redirected to pgsql-hackers for comment ] > > Helge Bahmann <[EMAIL PROTECTED]> writes: > > On Tue, 31 Jul 2001, Tom Lane wrote: > >> There is a more complete version of this capability in the Debian patch > >> set. I think we've been waiting for Oliver to pull it out and submit it > >> as a patch... > > > Ok found it; uses "peer" as a keyword instead of "ident" but basically > > does the same thing. I think you can discard my patch then. > > Well, we need to talk about that. I like your idea of making ident auth > "just work" on local connections better than Oliver's approach of > inventing a separate auth-type keyword. So some kind of merger of the > two patches seems attractive to me. But Oliver may feel that he has to > continue to support the "peer" keyword on Debian anyway, for backwards > compatibility. If so, do we want different ways of doing the same thing > on different distros, or should we just follow the Debian precedent to > keep things ugly-but-consistent? We could easily just accept peer as a synonym for ident for a few releases, because it fact our ident will become something that is used beyond the identd server. -- 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linuxonly)
> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> ... But Oliver may feel that he has to > >> continue to support the "peer" keyword on Debian anyway, for backwards > >> compatibility. If so, do we want different ways of doing the same thing > >> on different distros, or should we just follow the Debian precedent to > >> keep things ugly-but-consistent? > > > We could easily just accept peer as a synonym for ident for a few > > releases, > > Or let Oliver patch the Debian package to accept peer as a synonym for > ident. I don't see any real need to encourage the use of that keyword > by non-Debianers... Good idea. I was hoping to reduce his patching but this way he can control how long he keeps it active. However, the text is only one line in hba.c. Either way is fine. -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: From TODO, XML?
Gilles DAROLD wrote: > > Hi, > > Why don't use the excellent DBIx-XML_RDB perl module ? Give it the query > it will return XML output as you sample. With some hack you can do what you > want... > The point I was trying to make is that XML is trivial to create. It is much more difficult to read. I think pg_dump is a "better" place for the export, in that all the logic to find the fields, types, and data are already there. Were a simple option presented, --xml, it would probably be easier to add xml export to pg_dump than create a new utility, but then again, I didn't write pg_dump and therefore do not know for sure. -- 5-4-3-2-1 Thunderbirds are GO! http://www.mohawksoft.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [PATCHES] Allow IDENT authentication on local connections (Linux only)
Bruce Momjian <[EMAIL PROTECTED]> writes: >> ... But Oliver may feel that he has to >> continue to support the "peer" keyword on Debian anyway, for backwards >> compatibility. If so, do we want different ways of doing the same thing >> on different distros, or should we just follow the Debian precedent to >> keep things ugly-but-consistent? > We could easily just accept peer as a synonym for ident for a few > releases, Or let Oliver patch the Debian package to accept peer as a synonym for ident. I don't see any real need to encourage the use of that keyword by non-Debianers... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
