Re: [HACKERS] Function to kill backend
> > In this case, SIGINT (query cancel) will not help, because > all locks > > held by the transaction will still be held. > > Wrong. Really? Please point out where I am wrong in this: SESSION A: BEGIN TRANSACTION SESSION A: LOCK TABLE foo IN ACCESS EXCLUSIVE MODE SESSION B: SELECT * FROM foo <-- blocks (expected)! not-in-session: KILL -INT (at this point, is listed as "idle in transaction") SESSION B:<-- still blcoks SESSION A: ROLLBACK SESSION B: <-- now completes If I kill it with TERM instead of INT, SESSION B is released at that point. Am I missing something very obvious here? This is on: PostgreSQL 7.4.2 on i686-pc-linux-gnu, compiled by GCC 2.95.3 //Magnus ---(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] i18n of PostgreSQL - part 1
Am Freitag, 2. April 2004 07:21 schrieb BARTKO, Zoltan: > just wanted to mention that the first part of the slovak translation of Pg > is available - the psql strings - at the following address: > > http://de.geocities.com/bartkozo/psql-sk.po.gz Installed in 7.5 branch. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Socket communication for contrib
Community, People asked me to put a simple extension for PostgreSQL Open Source. The attached package contains a simple functions whichs tells a remote TCP socket that somebody is about to modify a certain table. Why would anybody do that? Currently PostgreSQL provides a nice LISTEN / NOTIFY mechanism. However, this mechanism is obsolete when the machine which should receive a message is not connected to PostgreSQL directly. In this case it is possible to define a trigger on a table and let the database tell those machines via TCP that something interesting might have happened. In our case this package has helped us to get rid of permanent, speed consuming polling. Maybe some people might find it useful and want to see this feature in contrib. Please let us know. Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at tecwing.tgz Description: GNU Zip compressed data ---(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] Solaris initdb fails: shmmax tweak alternative?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [ raises eyebrow... ] So you're installing a test database server on a > production machine? That's not preferred admin practice anywhere that > I know of. If it's really going to be a production server, I won't have > a lot of sympathy for the performance problems that you'll doubtless > have, small database or no. Not my choice, just be glad I've managed to get Postgres involved at all. :) The development is already finished, but the development box and the production box are not the same OS. Not ideal conditions, but very much out of my control. Having to recompile initdb.c is probably not an option. I'll probably push to get shmmax bumped up. Contrary to the other writer's assertion however, Sybase and Oracle both installed properly without having to change shmmax. If anyone familiar with these can assert that a low shmmax also affects their performance, that would be helpful in my argument to bump it up for the PG install. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200404050713 -BEGIN PGP SIGNATURE- iD8DBQFAcUE6vJuQZxSWSsgRAr80AKC/SVVm4unhMOh+Z0+rhDqn8zGSigCg5hve iKhSKUt6N7qNhuq9WRO/EH4= =OuWo -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Solaris initdb fails: shmmax tweak alternative?
Greg Sabino Mullane said: > > > Having to recompile initdb.c is probably not an option. Which version of PostreSQL are you installing on this production machine? initdb is not a C program in any released version - in 7.4.2 it is a shell script which you could trivially modify. Of course, in the next release it will be a C program. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function to kill backend
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >>> In this case, SIGINT (query cancel) will not help, because >>> all locks held by the transaction will still be held. >> >> Wrong. > Really? [ experiments... ] My apologies --- you are correct about the present behavior. If a SIGINT arrives while waiting for client input, it's just dropped on the floor. The locks *will* be dropped if the SIGINT arrives during actual query processing. It strikes me that this is incorrect behavior, at least for the case where the client has a transaction block open. It'd be better to define the interrupt as "transaction cancel". regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Evening in NYC
SRA America is sponsoring an evening event with me in NYC. If folks want to go, the details are on our web site under "Events". -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Socket communication for contrib
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > People asked me to put a simple extension for PostgreSQL Open Source. > The attached package contains a simple functions whichs tells a remote > TCP socket that somebody is about to modify a certain table. Doesn't this encourage violation of the basic notion of a transaction? The message will be sent immediately, whether or not the sending transaction actually commits. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Solaris initdb fails: shmmax tweak alternative?
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: > Having to recompile initdb.c is probably not an option. initdb is just a shell script in existing releases. > Sybase and Oracle both installed properly without having to change shmmax. My bet is that they ate all available shmem, leaving none for Postgres... have you checked ipcs(1) to see what's already allocated? 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] Socket communication for contrib
"Doesn't this encourage violation of the basic notion of a transaction? The message will be sent immediately, whether or not the sending transaction actually commits." Any postgresql C coders out there that can help us out with nested transactions? This pretty much comes down to having nested transactions for this to be of real use. For example. BEGIN update table; commit; send remote message that table was updated; when ANY exception do error logic END Otherwise it doesn't really tell you anything of much value. Though I imagine in some rare/special case it could be of use as it stands. Bob Henkel 651-738-5085 Mutual Funds I/T Woodbury Hartford Life 500 Bielenberg Drive Woodbury, MN 55125 |-+--> | | Tom Lane | | | <[EMAIL PROTECTED]>| | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 04/05/2004 09:57 AM| | | | |-+--> >--| | | | To: Hans-Jürgen Schönig <[EMAIL PROTECTED]> | | cc: [EMAIL PROTECTED] | | Subject: Re: [HACKERS] Socket communication for contrib | >--| =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > People asked me to put a simple extension for PostgreSQL Open Source. > The attached package contains a simple functions whichs tells a remote > TCP socket that somebody is about to modify a certain table. Doesn't this encourage violation of the basic notion of a transaction? The message will be sent immediately, whether or not the sending transaction actually commits. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(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] Socket communication for contrib
Tom Lane wrote: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: People asked me to put a simple extension for PostgreSQL Open Source. The attached package contains a simple functions whichs tells a remote TCP socket that somebody is about to modify a certain table. Doesn't this encourage violation of the basic notion of a transaction? The message will be sent immediately, whether or not the sending transaction actually commits. regards, tom lane Yes, absolutely - it is damn hard to ROLLBACK a TCP connection. Unfortunately there are no "ON COMMIT" triggers or something like that - this would have been a better solution. I am very well aware of this problem because I share your concerns. However, sometimes it can be interesting to know if somebody ATTEMPTS to modify the database. Also, you can use it to send data in the database to somebody where. In this case there are in most cases 1-line transactions: eg. SELECT tellsomebody() WHERE id = someid; In our special case it makes sense when various clients which are NOT connected to the database (because they are somewhere else on this planet) receive some sort of database driven notification in case of some events. Depending on the return value a user can see whether a message has been delivered or not. Sending a message to many clients has always the same problem: Unfortunately TCP does not support transactions the way people would use it inside a database. Nested transactions: I don't think nested transactions will really help to resolve the core problem. Committing a subtransaction will most likely not imply that a parent transaction can be committed as well. As I said: Some people MIGHT find it useful in some special cases. If the community decides that it does not enough sense to integrate it into contrib I can live with that. Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Socket communication for contrib
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > Nested transactions: I don't think nested transactions will really help > to resolve the core problem. Committing a subtransaction will most > likely not imply that a parent transaction can be committed as well. Agreed. > As I said: Some people MIGHT find it useful in some special cases. > If the community decides that it does not enough sense to integrate it > into contrib I can live with that. I won't take a position on whether it's useful enough to put in contrib, but if people want it there, I'd just ask that the README be extended to point out the transactional risks. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Socket communication for contrib
Tom Lane wrote: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: Nested transactions: I don't think nested transactions will really help to resolve the core problem. Committing a subtransaction will most likely not imply that a parent transaction can be committed as well. Agreed. As I said: Some people MIGHT find it useful in some special cases. If the community decides that it does not enough sense to integrate it into contrib I can live with that. I won't take a position on whether it's useful enough to put in contrib, but if people want it there, I'd just ask that the README be extended to point out the transactional risks. this should not be a problem. I can intregrate all necessary information there. folks, let's do a poll ... who is for it - who is against it ... regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Socket communication for contrib
I would be FOR it if the README states the dangers Bob Henkel 651-738-5085 Mutual Funds I/T Woodbury Hartford Life 500 Bielenberg Drive Woodbury, MN 55125 |-+> | | Hans-Jürgen | | | Schönig | | | <[EMAIL PROTECTED]| | | c.at>| | || | | 04/05/2004 10:59 | | | AM | | || |-+> >--| | | | To: Tom Lane <[EMAIL PROTECTED]> | | cc: [EMAIL PROTECTED], [EMAIL PROTECTED] | | Subject: Re: [HACKERS] Socket communication for contrib | >--| Tom Lane wrote: > =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > >>Nested transactions: I don't think nested transactions will really help >>to resolve the core problem. Committing a subtransaction will most >>likely not imply that a parent transaction can be committed as well. > > > Agreed. > > >>As I said: Some people MIGHT find it useful in some special cases. >>If the community decides that it does not enough sense to integrate it >>into contrib I can live with that. > > > I won't take a position on whether it's useful enough to put in contrib, > but if people want it there, I'd just ask that the README be extended to > point out the transactional risks. this should not be a problem. I can intregrate all necessary information there. folks, let's do a poll ... who is for it - who is against it ... regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Socket communication for contrib
Hans-Jürgen Schönig wrote: > Tom Lane wrote: > > =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > > > >>Nested transactions: I don't think nested transactions will really help > >>to resolve the core problem. Committing a subtransaction will most > >>likely not imply that a parent transaction can be committed as well. > > > > > > Agreed. > > > > > >>As I said: Some people MIGHT find it useful in some special cases. > >>If the community decides that it does not enough sense to integrate it > >>into contrib I can live with that. > > > > > > I won't take a position on whether it's useful enough to put in contrib, > > but if people want it there, I'd just ask that the README be extended to > > point out the transactional risks. > > this should not be a problem. > I can intregrate all necessary information there. > > folks, let's do a poll ... > who is for it - who is against it ... Is it better in /contrib or gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Socket communication for contrib
Is it better in /contrib or gborg? I have learned (please correct me if I am wrong) that people tend to look in contrib before they look at gborg. Also, when people ask for training most of them ask for stuff in contrib. It is people's mind that contrib is somehow a source of additional, small software. Again, correct me if I am wrong. Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Socket communication for contrib
Hans-Jürgen Schönig wrote: > > > > Is it better in /contrib or gborg? > > > > > I have learned (please correct me if I am wrong) that people tend to > look in contrib before they look at gborg. > Also, when people ask for training most of them ask for stuff in > contrib. It is people's mind that contrib is somehow a source of > additional, small software. Again, correct me if I am wrong. For me, /contrib is for things closely tied to the backend code, like GIST stuff, and for key tools, like conversion programs. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [HACKERS] Socket communication for contrib
It's rumoured that Bruce Momjian once said: > > Is it better in /contrib or gborg? > Gborg imho. I thought we were trying to move all non-core code there now. Isn't that why psqlodbc etc. were moved? Regards, Dave ---(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] Socket communication for contrib
> > Is it better in /contrib or gborg? > > Gborg imho. I thought we were trying to move all non-core code there > now. Isn't that why psqlodbc etc. were moved? The argument was that it can be devopped and released independently? Features in "contrib/" have a premium over external add-ons. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Regression from 7.3 to 7.4
Dennis Bjorklund <[EMAIL PROTECTED]> writes: > This testcase works in 7.3 but not in 7.4: > create table t1 (a int); > create table t2 (b int); > select * from t1, (select b as a from t2 group by a) as foo; > ERROR: column "t2.b" must appear in the GROUP BY clause or be used in an > aggregate function > I don't know if it's supposed to work to do a group by of an alias, but > why not and it used to work. This example strikes me as a good reason why we ought to deprecate and eventually remove the capability for GROUP BY to reference output-list aliases. This is not legal per SQL spec, but we have accepted it for a few versions now (I think since about 6.5). The reason for the change in behavior is that 7.4 is trying to be helpful for some related errors. The subselect "foo" is not allowed to reference columns of t1. In 7.3 you'd get a plain "not found" error: regression=# select * from t1, (select a from t2) as foo; ERROR: Attribute "a" not found where now you get regression=# select * from t1, (select a from t2) as foo; ERROR: subquery in FROM may not refer to other relations of same query level The problem is that this check is made after parsing the subquery, so if the subquery is internally inconsistent you'll get the subquery-local error first. In your example the subquery thinks it has a "GROUP BY outer-reference" and so the check for ungrouped columns fails. This change was made partly because it seemed to yield more useful error messages, and partly in anticipation of supporting the SQL99 LATERAL feature, in which such references *are* legal. So while reverting the change is one possible answer, it doesn't seem forward-looking. Another tweak we could make is to cause findTargetlistEntry() to look only for local variable names before looking for targetlist alias matches. This would effectively change the precedence for resolving "GROUP BY x" to be (1) x as a local variable, (2) x as a targetlist alias, (3) x as an outer variable; whereas the present search order is (1), (3), (2). AFAICS this does not break compatibility with either SQL92 or SQL99 because both of them allow only case (1). However this could break existing queries that are relying on the non-aliased behavior. (Offhand I can't think of a really good reason to GROUP BY an outer reference, but maybe there is one.) Or we could bite the bullet and deprecate/remove the alias-reference feature. I think I was the one who put it in originally for GROUP BY, but in hindsight it was a terrible idea --- it's caused way more confusion than it's worth. Comments? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Socket communication for contrib
On Apr 5, 2004, at 12:35 PM, Bruce Momjian wrote: For me, /contrib is for things closely tied to the backend code, like GIST stuff, and for key tools, like conversion programs. something that would be useful (and perhaps may be part of that pgfoundry or whatever its called movement) would be making gborg's existance more clear. Maybe putting a file in doc/ or contrib/ mentioning it or including an index of things on it (Or at least the more popular items). Often when I talk to people at work about PG they ask about stuff and I say "Silly, thats on gborg!" and they look at me strangely and have no idea about it. You get less of it with contrib/ items.. just my $0.02 -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(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] Socket communication for contrib
> say "Silly, thats on gborg!" and they look at me strangely Sure. The "gborg" name does not strike as being related to postgresql. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Socket communication for contrib
Jeff wrote: On Apr 5, 2004, at 12:35 PM, Bruce Momjian wrote: For me, /contrib is for things closely tied to the backend code, like GIST stuff, and for key tools, like conversion programs. something that would be useful (and perhaps may be part of that pgfoundry or whatever its called movement) would be making gborg's existance more clear. Maybe putting a file in doc/ or contrib/ mentioning it or including an index of things on it (Or at least the more popular items). Often when I talk to people at work about PG they ask about stuff and I say "Silly, thats on gborg!" and they look at me strangely and have no idea about it. You get less of it with contrib/ items.. just my $0.02 You have hit an important point here: "What is gborg?". That's what people think. Maybe we should have a contrib package (any better ideas?) or at least a pretty obvious place inside our .tar.gz files mentioning gborg. If you want more -> gborg. Otherwise people won't use gborg too much. I have seen that too often. Maybe thinking about that makes sense about that's more an advocacy issue I think. Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] 7.5 beta version
I am having some trouble interfacing the 7.5 server built with MINGW
with tools generated using other compilers.
I suspect that the issue is one of default structure packing. In the
old version we were using, we built PostgreSQL using Intel C++ or MS
VC++ and the same for the libpq and other interfaces.
Now that I have built the server and associated tools with Mingw and a
version of the interface system with MS VC++ and Intel C++, I have
problems using (for instance) libpq.
Some character strings returned early in the struct are fine, but the
numeric fields occurring later are garbled.
Now, this issue seems like it must have happened before, since the
server might be generated on some 64 bit platform and the interface
library on some other platform.
In particular, this function:
char *PQgetvalue(const PGresult *res, int tup_num, int field_num)
{
if (!check_tuple_field_number(res, tup_num, field_num))
return NULL;
return res->tuples[tup_num][field_num].value;
}
Seems to return nonsense when I get to pointers to non-character data.
Any thoughts?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Solaris initdb fails: shmmax tweak alternative?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> Having to recompile initdb.c is probably not an option. > >initdb is just a shell script in existing releases. Yes, you are right. By sheer habit I typed in cd ~/pgsql/src/bin. > My bet is that they ate all available shmem, leaving none for > Postgres... have you checked ipcs(1) to see what's already allocated? I did that and found out that Oracle is actually installed on a different box! *sheepish grin* The good news of all this is that Oracle would probably have had the same problems (but been much more cryptic about what exactly the problem was). Thanks for the replies: I am going to push for a shmmax boost and go from there. Less pain in the long run. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200404052013 -BEGIN PGP SIGNATURE- iD8DBQFAcfbavJuQZxSWSsgRAr1SAJ0QZ9/Ur2NGmLnHJLzEqZ/grjq0kwCg3XpD hg4M9gvuq5XmwnCxPaWojJg= =vCPa -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] just a test
ignore it Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Function to kill backend
On Fri, 2004-04-02 at 16:52, Magnus Hagander wrote:
> Hi!
>
> When debugging on win32, I've created myself a little function that I
> feel should be added to the "backend proper". While it adds a lot of
> vlaue on win32, I think it adds quite a bit of value on non-win32
> platforms as well...
>
> The function is pg_kill_backend(,). superuser-only, of
> course. Which simply sends a signal to the specified backend -
> querycancel, terminate, etc.
Nice.. My new favourite command is going to be:
SELECT pg_kill_backend(procpid, 'TERM') FROM pg_stat_activity WHERE
current_query LIKE '%';
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/signature.asc
signature.asc
Description: This is a digitally signed message part
Re: [HACKERS] PITR for replication?
Oops! [EMAIL PROTECTED] ("J. Andrew Rogers") was seen spray-painting on a wall:
> I may be completely missing the point here, but it looks to me as
> though the PITR archival mechanism is also most of a native
> replication facility. Is there anyone reason this couldn't be
> extended to replication, and if so, is anyone planning on using it
> as such?
>
> My memory is fuzzy on this point, but I seem to recall that this is
> (was?) how replication is more-or-less done for many of the big
> commercial RDBMS.
What isn't clear to me at this point is whether PITR is set up to
allow the database to remain "live and accessible" while updates are
being loaded in.
If that's NOT the case, then it is in no way a meaningful replacement
for replication, vastly useful though it may be.
At those times I have seen Oracle(tm) archive logs being applied to
support PITR-related functionality, the DB hasn't been "up and
running." I suspect that may have changed by now, which would
certainly be handy for replication.
--
(format nil "[EMAIL PROTECTED]" "cbbrowne" "ntlug.org")
http://cbbrowne.com/info/multiplexor.html
As of next Tuesday, all terminal input will be line-at-a-time.
Please update your programs.
---(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] Update on PITR
[EMAIL PROTECTED] ("Marc G. Fournier") writes:
> On Thu, 1 Apr 2004, Christopher Kings-Lynne wrote:
>> > Is your timeline based on the assumption of doing all the work
>> > yourself? If so, how about farming out some of it? I'd be
>> > willing to contribute some effort to PITR. (It's been made clear
>> > to me that Red Hat really wants PITR in 7.5 ;-))
>>
>> What is RedHat's interest in PostgreSQL? Last time I heard they
>> weren't interested in their database product anymore. Why do they
>> care about the PostgreSQL project?
>
> Just speculation, but I'd go with end goal being to be able to dump
> Oracle altogether, once PostgreSQL actually has all the various
> enterprise features ...
I understood that they were using Oracle Financials and possibly
Oracle Manufacturing for their internal systems; I seriously doubt
that Oracle will be adding support for PostgreSQL in those products
:-).
That being said, I'm sure it is in their interests to be able to
promote database options that do not mandate sending one penny to any
other vendors.
That was pretty clearly a major reason behind RHAT promoting GNOME
over KDE, in that "business" use of the latter would mandate sending
more money to a little company in Europe than RHAT would receive in
selling 50 'boxed sets.'
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/wp.html
Rules of the Evil Overlord #145. "My dungeon cell decor will not
feature exposed pipes. While they add to the gloomy atmosphere, they
are good conductors of vibrations and a lot of prisoners know Morse
code."
