Re: [HACKERS] Need help in installing postgresql 8.1.2 on Windows
Hopefully your problem is solved by now; but if not, here's the link: do read the README expanded at the end of the file-list: http://www.postgresql.org/ftp/binary/v8.1.2/win32/ I could give you a long lecture on how to look for the things on your own a little bit before pestering these mailing lists; but I think I should spare you this one time. Good luck with open-source. Gurjeet. On 18/01/06, Sarvjot Kaur [EMAIL PROTECTED] wrote: Sir I am trying to install Globus Toolkit4 on Windows machine. Postgresql8.1.2 is required software for installing GT4. But i cant get installation steps from anywhere.. Please help me and do reply Thanks Sarvjot Yahoo! Photos – Showcase holiday pictures in hardcover Photo Books. You design it and we'll bind it! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] postmaster/postgres merge for testing
Peter Eisentraut [EMAIL PROTECTED] writes: Attached is a patch that merges postmaster and postgres into just a postmaster command. I had some second thoughts about this, specifically about which direction do we really want to go in. With this patch, it no longer really matters what the executable file is named, right? We were both implicitly assuming that the name should end up being postmaster, but I think there's a good case to be made that the right thing to do is to migrate in the direction of having just one executable named postgres. We've seen complaints before that having a daemon named postmaster confuses newbies into thinking it's got something to do with mail. And it's already the case that the child processes all call themselves postgres, which will become even more confusing if there is no longer any executable named postgres. If we went in this direction we'd have to keep the installed postmaster-postgres symlink for awhile to avoid breaking existing start scripts, but it could be deprecated and then removed in a few releases. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] postmaster/postgres merge for testing
On Mon, 2006-01-23 at 11:13 -0500, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Attached is a patch that merges postmaster and postgres into just a postmaster command. I had some second thoughts about this, specifically about which direction do we really want to go in. With this patch, it no longer really matters what the executable file is named, right? We were both implicitly assuming that the name should end up being postmaster, but I think there's a good case to be made that the right thing to do is to migrate in the direction of having just one executable named postgres. We've seen complaints before that having a daemon named postmaster confuses newbies into thinking it's got something to do with mail. And it's already the case that the child processes all call themselves postgres, which will become even more confusing if there is no longer any executable named postgres. If we went in this direction we'd have to keep the installed postmaster-postgres symlink for awhile to avoid breaking existing start scripts, but it could be deprecated and then removed in a few releases. Thoughts? This is clearly better, IMNSHO. I did wonder about postgresqld or postgresd or some such - many server programs end in d or .d to distinguish them from client programs. But probably just postgres is best. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] ROLLBACK triggers?
Hi, First, apologies if my question is a bit off-course. Please feel free to direct me to a different mailing list if not appropriate. I'm currently trying to embed Senna full text search engine (http://qwik.jp/senna/) into postgres. I'm trying to achieve this by using triggers (implemented in C) to cause an update to senna's index at various points. This seemed to work fine until I realized that while postgres' SQL commands could be rolled back, Senna's index remained already-changed. There are other potential issues with regards to transaction safety, but currently this seems to be a problem that I cannot fix by simply patching Senna. So I thought that if there was a rollback trigger, I could call whatever necessary to undo the changes that were made to the index. A quick scan of the docs and the source code tree seems to indicate that there is no such thing as a rollback trigger, short of hacking it. Now, I'm wondering: 1. Is there a rollback/commit trigger? If not, is it planned to be implemented at all? 2. Is there a way to undo changes to data external to postgres when a rollback occurs, OR, only update that external data when a commit occurs? Thanks in advance, --d ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] postmaster/postgres merge for testing
On Mon, Jan 23, 2006 at 11:51:36AM -0500, Andrew Dunstan wrote: This is clearly better, IMNSHO. I did wonder about postgresqld or postgresd or some such - many server programs end in d or .d to distinguish them from client programs. But probably just postgres is best. Or postgresql if we want to be consistent... /nitpick -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ROLLBACK triggers?
Daisuke,A patch was done for replication hooks which implements global database-level triggers for connection startup and shutdown, and transaction begin, commit, and rollback; they may help you out in this situation. http://gorda.di.uminho.pt/community/pgsqlhooks/-Jonah On 1/23/06, Daisuke Maki [EMAIL PROTECTED] wrote: Hi,First, apologies if my question is a bit off-course. Please feel free todirect me to a different mailing list if not appropriate.I'm currently trying to embed Senna full text search engine( http://qwik.jp/senna/) into postgres. I'm trying to achieve this byusing triggers (implemented in C) to cause an update to senna's index atvarious points.This seemed to work fine until I realized that while postgres' SQL commands could be rolled back, Senna's index remained already-changed.There are other potential issues with regards to transaction safety, butcurrently this seems to be a problem that I cannot fix by simply patching Senna. So I thought that if there was a rollback trigger, Icould call whatever necessary to undo the changes that were made to theindex.A quick scan of the docs and the source code tree seems to indicate that there is no such thing as a rollback trigger, short of hacking it.Now, I'm wondering:1. Is there a rollback/commit trigger? If not, is it planned to be implemented at all?2. Is there a way to undo changes to data external to postgres when a rollback occurs, OR, only update that external data when a commit occurs?Thanks in advance,--d---(end of broadcast)---TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ROLLBACK triggers?
On Mon, Jan 23, 2006 at 06:35:18PM +0900, Daisuke Maki wrote: A quick scan of the docs and the source code tree seems to indicate that there is no such thing as a rollback trigger, short of hacking it. Now, I'm wondering: 1. Is there a rollback/commit trigger? If not, is it planned to be implemented at all? 2. Is there a way to undo changes to data external to postgres when a rollback occurs, OR, only update that external data when a commit occurs? Actually, this is something that often comes up in terms of LISTEN/NOTIFY and doing external non-transactional stuff like sending emails. AFAIK there's no plans to add support for anything like a rollback trigger. Your best bet (short of hacking the backend) is to have your triggers (or maybe this would mean you could just do this with rules, which could be faster) record the relevant information in a staging table. After the transaction commits, you can then pull the info out of the staging table and use it to update your index. You could also use LISTEN/NOTIFY to speed this process up. Of course that means there will be a period of time where the index is out-of-date, so perhaps there is some argument to be made for a ROLLBACK trigger. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ROLLBACK triggers?
Hello Jonah, Sorry for hi-jacking the thread (not my intent, I assure you) however, is there any chance Jonah of expanding your work to include 'on user login/logout' ? As an aside, a trigger on rollback seems... unlikely (at least to my mind). What is the functionality if your rollback trigger fails ? Ugh. Down that road I can see madness looming, however, this -is- monday so ... :) Regards Stef Jonah H. Harris wrote: Daisuke, A patch was done for replication hooks which implements global database-level triggers for connection startup and shutdown, and transaction begin, commit, and rollback; they may help you out in this situation. http://gorda.di.uminho.pt/community/pgsqlhooks/ -Jonah On 1/23/06, Daisuke Maki [EMAIL PROTECTED] wrote: Hi, First, apologies if my question is a bit off-course. Please feel free to direct me to a different mailing list if not appropriate. I'm currently trying to embed Senna full text search engine ( http://qwik.jp/senna/) into postgres. I'm trying to achieve this by using triggers (implemented in C) to cause an update to senna's index at various points. This seemed to work fine until I realized that while postgres' SQL commands could be rolled back, Senna's index remained already-changed. There are other potential issues with regards to transaction safety, but currently this seems to be a problem that I cannot fix by simply patching Senna. So I thought that if there was a rollback trigger, I could call whatever necessary to undo the changes that were made to the index. A quick scan of the docs and the source code tree seems to indicate that there is no such thing as a rollback trigger, short of hacking it. Now, I'm wondering: 1. Is there a rollback/commit trigger? If not, is it planned to be implemented at all? 2. Is there a way to undo changes to data external to postgres when a rollback occurs, OR, only update that external data when a commit occurs? Thanks in advance, --d ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://wwwpostgresql.org/docs/faq .
Re: [HACKERS] ROLLBACK triggers?
Hey Stef,It's not my patch, it's Alfrânio Correia Júnior's. I don't think it would be too difficult to add a hook for authentication, but that is off-topic. If you would like to discuss it further, please create a new topic for it. As for a rollback trigger, I don't really see too much of a use for it aside from when you would need to notify an external application/database server of commit/rollback such as what Daisuke would use it for or something which could be extended by contrib modules (such as dblink, dblink_tds, ...). Of course, people could always write bad transactional application code that relies on this commit/rollback trigger, but that isn't the use case. -JonahOn 1/23/06, Stef T [EMAIL PROTECTED] wrote: Hello Jonah, Sorry for hi-jacking the thread (not my intent, I assure you) however, is there any chance Jonah of expanding your work to include 'on user login/logout' ? As an aside, a trigger on rollback seems... unlikely (at least to my mind). What is the functionality if your rollback trigger fails ? Ugh. Down that road I can see madness looming, however, this -is- monday so ... :) Regards Stef Jonah H. Harris wrote: Daisuke, A patch was done for replication hooks which implements global database-level triggers for connection startup and shutdown, and transaction begin, commit, and rollback; they may help you out in this situation. http://gorda.di.uminho.pt/community/pgsqlhooks/ -Jonah On 1/23/06, Daisuke Maki [EMAIL PROTECTED] wrote: Hi, First, apologies if my question is a bit off-course. Please feel free to direct me to a different mailing list if not appropriate. I'm currently trying to embed Senna full text search engine ( http://qwik.jp/senna/) into postgres. I'm trying to achieve this by using triggers (implemented in C) to cause an update to senna's index at various points. This seemed to work fine until I realized that while postgres' SQL commands could be rolled back, Senna's index remained already-changed. There are other potential issues with regards to transaction safety, but currently this seems to be a problem that I cannot fix by simply patching Senna. So I thought that if there was a rollback trigger, I could call whatever necessary to undo the changes that were made to the index. A quick scan of the docs and the source code tree seems to indicate that there is no such thing as a rollback trigger, short of hacking it. Now, I'm wondering: 1. Is there a rollback/commit trigger? If not, is it planned to be implemented at all? 2. Is there a way to undo changes to data external to postgres when a rollback occurs, OR, only update that external data when a commit occurs? Thanks in advance, --d ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://wwwpostgresql.org/docs/faq .
Re: [HACKERS] ROLLBACK triggers?
Jim C. Nasby [EMAIL PROTECTED] writes: On Mon, Jan 23, 2006 at 06:35:18PM +0900, Daisuke Maki wrote: A quick scan of the docs and the source code tree seems to indicate that there is no such thing as a rollback trigger, short of hacking it. Now, I'm wondering: 1. Is there a rollback/commit trigger? If not, is it planned to be implemented at all? 2. Is there a way to undo changes to data external to postgres when a rollback occurs, OR, only update that external data when a commit occurs? Actually, this is something that often comes up in terms of LISTEN/NOTIFY and doing external non-transactional stuff like sending emails. AFAIK there's no plans to add support for anything like a rollback trigger. Well, note that in the case of LISTEN/NOTIFY the receiving side doesn't see the message until the sender commits. Precisely to maintain transactional integrity. If the external work can never fail then it seems like just postponing the processing of it until transaction commit time like deferred constraints would be better. I'm not sure you can really do that currently though. -- greg ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Libpq COPY optimization
Can I get an updated patch for this? --- Tom Lane wrote: Alon Goldshuv [EMAIL PROTECTED] writes: Please help me understand this better. It appears to me that when the client-backend pipe fills up, pqSendSome() consumes any incoming NOTICE/WARNING messages before waiting, which should prevent deadlock. Hm, I had forgotten that the low-level pqSendSome routine does that. That makes the PQconsumeInput call in PQputCopyData redundant (or almost; see below). The parseInput call is still needed, because it's there to pull NOTICE messages out of the input buffer and get rid of them, rather than possibly having the input buffer grow to exceed memory. But when there's nothing for it to do, parseInput is cheap enough that there's no real need to bypass it. In short, if you just remove the PQconsumeInput call I think you'll find that it does what you want. The only case where it's helpful to have it there is if there's a incomplete message in the input buffer, as parseInput isn't quite so fast if it has to determine that the message is incomplete. Without the PQconsumeInput call, the incomplete-message state could persist for a long time, and you'd pay the parseInput overhead each time through PQputCopyData. However, that's certainly not the normal situation, so I think we could leave that case slightly pessimal. It's certainly true that that path in parseInput is a lot faster than a kernel call, so it'd still be better than it is now. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] unsubscribe
unsubscribe
Re: [HACKERS] ROLLBACK triggers?
On Mon, January 23, 2006 16:35, Daisuke Maki wrote: I'm currently trying to embed Senna full text search engine (http://qwik.jp/senna/) into postgres. I'm trying to achieve this by using triggers (implemented in C) to cause an update to senna's index at various points. This seemed to work fine until I realized that while postgres' SQL commands could be rolled back, Senna's index remained already-changed. There are other potential issues with regards to transaction safety, but currently this seems to be a problem that I cannot fix by simply patching Senna. So I thought that if there was a rollback trigger, I could call whatever necessary to undo the changes that were made to the index. I may just be being stupid here (haven't had my coffee yet) but are you sure that: I. The triggers really do arrive even when the modifications are aborted? AFAIK triggers that were, er, triggered during a transaction only really get notified once the transaction commits. In psql: = LISTEN x; LISTEN = BEGIN; BEGIN = NOTIFY x; NOTIFY = ABORT; ROLLBACK = BEGIN; BEGIN = NOTIFY x; NOTIFY = COMMIT; COMMIT Asynchronous notification x received from server process with PID 42. As you can see, the ABORT also rolled back the NOTIFY, so it never arrived. This may be exactly what you want. Well, actually it raises another question: is it alright for the ongoing transaction not to see any changes it makes reflected in your index? II. Is there any chance of wrapping your work in a function, so you can then create an index on the result of that function? I've never tried this but presumably the server would then do all the work to keep your index updated, without any need for triggers and such. This is no different from what you'd do if you wanted, say, an index on an upper-cased version of a text field to speed up case-insensitive searches. You create an index on TOUPPER(name) or whatever it is, and then when you select on WHERE TOUPPER(name)=TOUPPER(searchstring) you get full use of the index, which you wouldn't get from a regular index on name. Jeroen ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Libpq COPY optimization
I'll send it to -patches shortly Alon. On 1/23/06 10:20 PM, Bruce Momjian pgman@candle.pha.pa.us wrote: Can I get an updated patch for this? --- Tom Lane wrote: Alon Goldshuv [EMAIL PROTECTED] writes: Please help me understand this better. It appears to me that when the client-backend pipe fills up, pqSendSome() consumes any incoming NOTICE/WARNING messages before waiting, which should prevent deadlock. Hm, I had forgotten that the low-level pqSendSome routine does that. That makes the PQconsumeInput call in PQputCopyData redundant (or almost; see below). The parseInput call is still needed, because it's there to pull NOTICE messages out of the input buffer and get rid of them, rather than possibly having the input buffer grow to exceed memory. But when there's nothing for it to do, parseInput is cheap enough that there's no real need to bypass it. In short, if you just remove the PQconsumeInput call I think you'll find that it does what you want. The only case where it's helpful to have it there is if there's a incomplete message in the input buffer, as parseInput isn't quite so fast if it has to determine that the message is incomplete. Without the PQconsumeInput call, the incomplete-message state could persist for a long time, and you'd pay the parseInput overhead each time through PQputCopyData. However, that's certainly not the normal situation, so I think we could leave that case slightly pessimal. It's certainly true that that path in parseInput is a lot faster than a kernel call, so it'd still be better than it is now. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Offer for PG Developers/Hackers
Hi, I want to give something back(I would give a donation but sales are poor :-( ,so I am offering to any verified Postgresql developer(by verified I mean your name shows up on this list a LOT ) a free copy of PG Lightning Admin. I know most of you guys don't use windows, but if you do your welcome to a copy. There are no strings attached and you don't have to do anything other than keeping the setup password to yourself. Just let me know via email. Thanks, -- Tony Caduto AM Software Design Home of PG Lightning Admin for Postgresql http://www.amsoftwaredesign.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
