Re: [HACKERS] pg_get_serial_sequence is inconsistent
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> pg_get_serial_sequence() does dequoting/downcasing on its relation-name >> argument, but not on its column-name argument. > I presume the reason for that is that the first paramater can be qualified: Right. From a bare-functionality point of view there's nothing wrong with it, it just seems inconsistent and therefore likely to trip someone up in future. But it seems no one else cares, so I'll shut up about it ... 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]
--On Dienstag, Oktober 26, 2004 23:44:10 +0300 Hannu Krosing <[EMAIL PROTECTED]> wrote: Thus I think that reserved keyword is what it is meant to be in the first place ;) Yes, that was my intention, too. That's because i went straight forward and put it in the reserved keyword list and didn't spent time on playing around with it as a non-reserved keyword. I expect somebody wouldn't agree with this, since it will break things if somebody has something odd like CREATE VIEW vblabla AS SELECT * FROM FOO AS WITH; -- Bernd ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Unixware 714 pthreads
Sorry to follow up my own post. I made some more tests: create table foo (f1 int) -- for it not to be removed if if kill the process each time I do: psql template1 template1# set statement_timeout=1000; SET template1 select block_me(); it works ok if i do it a second time in the same session, blockme() never returns I wonder if handle_sig_alarm is re-armed after being used or if sleep is used anywhere in the backend. Unixware doc for setitimer (http://www.pyrenet.fr:8458/en/man/html.3C/getitimer.3C.html) says that "A sleep following a setitimer wipes out knowledge of the user signal handler" What can I do next? Regards On Wed, 27 Oct 2004 [EMAIL PROTECTED] wrote: > Date: Wed, 27 Oct 2004 13:01:45 +0200 (MET DST) > From: [EMAIL PROTECTED] > Newsgroups: comp.databases.postgresql.hackers > Subject: Re: Unixware 714 pthreads > > Dear Bruce, > > Thanks for your reply, I was desperate I did'nt get one! > > As I said, I'm quite sure there is a bug in pthread library, Before saying > this to SCO, I have to prove it. Postgresql is the way to prove it! > > What I need is to know where to start from (I'd like to put elogs where > statement_timeout is processed to see what really happens and why it > doesn't cancel the query). > > Could someone tell me where to look for? If anyone is interessed in > debugging this issue with me, I can set up an account on a test unixware > machine. > > TIA > On Tue, 26 Oct 2004, Bruce Momjian wrote: > > > Date: Tue, 26 Oct 2004 17:59:17 -0400 (EDT) > > From: Bruce Momjian <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: [HACKERS] Unixware 714 pthreads > > > > > > The only help I can be is that on Unixware (only) the backend is > > compiled with threading enabled. This might be showing some thread > > bugs. > > > > > > --- > > > > [EMAIL PROTECTED] wrote: > > > Hi every one, > > > > > > I need help to debug the problem I have on Unixware 714 and beta3. > > > postgresql make check hangs on plpgsql test when compiled with > > > --enable-thread-safty. > > > > > > It does hang on select block_me(); > > > > > > This select should be canceled by the set statement_timeout=1000, instead, > > > the backend is 100% CPU bound and only kill -9 can kill it. > > > > > > It works ok when compiled without -enable-thread-safty. > > > > > > I've tried almost every thing I could think of, but not knowing so much > > > about threads and PG source code, I request that someone can help me as to > > > find a way to debug this. It worked up until beta2, but I'm not sure > > > block_me()was there. > > > > > > I really need someone to tell me where to begin. > > > > > > TIA > > > > > > -- > > > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > > > 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) > > > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > > > FRANCE Email: [EMAIL PROTECTED] > > > -- > > > Make your life a dream, make your dream a reality. (St Exupery) > > > > > > ---(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 > > > > > > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(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] Proposed Query Planner TODO items
Hi Tatsuo, I've made a new release: http://prdownloads.sourceforge.net/osdldbt/dbt3-v1.5.tar.gz?download Let me know if there are any problems. On Tue, Oct 26, 2004 at 12:44:49PM +0900, Tatsuo Ishii wrote: > Hi, > > Thanks for the info. Would you give me the tarball? ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Unixware 714 pthreads
[EMAIL PROTECTED] writes: > if i do it a second time in the same session, blockme() never returns > I wonder if handle_sig_alarm is re-armed after being used No. Why should the signal handler need re-arming? > or if sleep is used anywhere in the backend. Nope. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Unixware 714 pthreads
Tom Lane wrote: [EMAIL PROTECTED] writes: if i do it a second time in the same session, blockme() never returns I wonder if handle_sig_alarm is re-armed after being used No. Why should the signal handler need re-arming? or if sleep is used anywhere in the backend. Nope. Actually, I just noticed that postmaster/pg_arch.c has a call to sleep() that needs to be removed ... I guess it snuck in after all that stuff was adjusted. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Beta 4 on Debian Sarge (MIPS/MIPSEL)
On October 27, 2004 05:57 pm, Jim Buttafuoco wrote: > Hackers, > > just an fyi, Beta 4 passed ALL tests on Debian Sarge for both MIPS (Indy) > and MIPSEL (Cobalt RAQ) > > I can test Debian Sarge Sparc, Alpha, PowerPC, PA-RISC and M68K if no one > else has reported on these systems yet. > > Also, with a little work I could test Solaris, Tru64 (or what ever its > called these days) and IRIX You could always make an application to pgbuildfarm.org and add those OS to the farm. > > Keep up the good work. > Jim > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Unixware 714 pthreads
On Thu, 28 Oct 2004, Tom Lane wrote: > Date: Thu, 28 Oct 2004 12:11:12 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Unixware 714 pthreads > > [EMAIL PROTECTED] writes: > > if i do it a second time in the same session, blockme() never returns > > > I wonder if handle_sig_alarm is re-armed after being used > > No. Why should the signal handler need re-arming? My impression was that once caught, signal handler for a particular signal is reset to SIG-DFL. > > > or if sleep is used anywhere in the backend. > > Nope. > > regards, tom lane > Oh well, bye bye htreads on unixware, I give up! (very disapointed) cheers -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Unixware 714 pthreads
[EMAIL PROTECTED] writes: > On Thu, 28 Oct 2004, Tom Lane wrote: >> No. Why should the signal handler need re-arming? > My impression was that once caught, signal handler for a particular signal > is reset to SIG-DFL. No. If your signal support is POSIX-compatible, it should not do that because we don't set SA_RESETHAND when calling sigaction(2). If you don't have POSIX signals, you had better have BSD-style signal(2), which doesn't reset either. If this is not happening as expected, you will have much worse problems than whether statement_timeout works :-( 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] Unixware 714 pthreads
I agree with all that you say Tom, I'm just asking for some help to debug this, Now that Larry is a litle off the list, I'm feeling really lonely on UW. SCO won't do anything until I come up with a test program that fails. All my tries did work until then. I use other threaded progs like postfix or bind that nether fail. I'm really at lost. Would you/someone help me? Best regards On Thu, 28 Oct 2004, Tom Lane wrote: > Date: Thu, 28 Oct 2004 13:55:56 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Unixware 714 pthreads > > [EMAIL PROTECTED] writes: > > On Thu, 28 Oct 2004, Tom Lane wrote: > >> No. Why should the signal handler need re-arming? > > > My impression was that once caught, signal handler for a particular signal > > is reset to SIG-DFL. > > No. If your signal support is POSIX-compatible, it should not do that > because we don't set SA_RESETHAND when calling sigaction(2). If you > don't have POSIX signals, you had better have BSD-style signal(2), > which doesn't reset either. If this is not happening as expected, > you will have much worse problems than whether statement_timeout works :-( > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(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] Beta 4 on Debian Sarge (MIPS/MIPSEL)
Darcy, I have been working on it all day. Not the fastest systems. Jusy an FYI, I have started on a Debian PKG file for the pg build system. My plan is to get ALL of the dependencies worked out and let APT fix my system. Jim -- Original Message --- From: Darcy Buskermolen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "pgsql-hackers" <[EMAIL PROTECTED]> Sent: Thu, 28 Oct 2004 10:35:04 -0700 Subject: Re: [HACKERS] Beta 4 on Debian Sarge (MIPS/MIPSEL) > On October 27, 2004 05:57 pm, Jim Buttafuoco wrote: > > Hackers, > > > > just an fyi, Beta 4 passed ALL tests on Debian Sarge for both MIPS (Indy) > > and MIPSEL (Cobalt RAQ) > > > > I can test Debian Sarge Sparc, Alpha, PowerPC, PA-RISC and M68K if no one > > else has reported on these systems yet. > > > > Also, with a little work I could test Solaris, Tru64 (or what ever its > > called these days) and IRIX > > You could always make an application to pgbuildfarm.org and add those OS to > the farm. > > > > > Keep up the good work. > > Jim > > > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > -- > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] --- End of Original Message --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] -HEAD contrib/dblink regress failure on SPARC/Solaris 8
On October 20, 2004 10:26 am, you wrote: > The buildfarm has identified yet another failure under SPARC/Solaris 8 as > outlined in. > This is an update to the build failure the log can now be seen at http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=potorooo&dt=2004-10-26%2020:30:01 and it's probably also the reason for sig 11 at: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2004-10-27%2011:17:23 (gdb) bt #0 0xff0b3218 in strlen () from /lib/libc.so.1 #1 0xff106520 in _doprnt () from /lib/libc.so.1 #2 0xff1082c8 in snprintf () from /lib/libc.so.1 #3 0xff0266c4 in getConnectionByName (name=0xffbee8a8 "") at dblink.c:2032 (gdb) -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Suggestion: additional system views
Folks, Is there any reason that we don't have pg_functions, pg_users, pg_groups and other system views?pg_tables and pg_views is really useful, but it would be good to cover the other items as well. Is there a reason not to have these other than that they're not coded? If not, I'll get working on them. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Unixware 714 pthreads
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > On Thu, 28 Oct 2004, Tom Lane wrote:
> >> No. Why should the signal handler need re-arming?
>
> > My impression was that once caught, signal handler for a particular signal
> > is reset to SIG-DFL.
>
> No. If your signal support is POSIX-compatible, it should not do that
> because we don't set SA_RESETHAND when calling sigaction(2). If you
> don't have POSIX signals, you had better have BSD-style signal(2),
> which doesn't reset either. If this is not happening as expected,
> you will have much worse problems than whether statement_timeout works :-(
SysV-style signal(2) handling does indeed require that the signal
handler be re-enabled. The attached program demonstrates this on
Solaris, and probably on Unixware as well (I don't have access to the
latter). Just run it and interrupt it with ctrl-c. It should print
something the first time around, and actually be interrupted the
second time.
So if Unixware doesn't have sigaction() or it's not being picked up by
autoconf then yeah, he'll have big problems...
--
Kevin Brown [EMAIL PROTECTED]
#include
#include
#include
void sighandler(int sig) {
printf ("Received signal %d\n", sig);
}
int main (int argc, char *argv[]) {
signal(SIGINT, sighandler);
while(1) {
sleep(1);
}
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] -HEAD contrib/dblink regress failure on SPARC/Solaris 8
Darcy Buskermolen <[EMAIL PROTECTED]> writes: > On October 20, 2004 10:26 am, you wrote: >> The buildfarm has identified yet another failure under SPARC/Solaris 8 as >> outlined in. Most likely this is fixed by Kris Jurka's just-applied patch. 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] pg_get_serial_sequence is inconsistent
Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > >> pg_get_serial_sequence() does dequoting/downcasing on its relation-name > >> argument, but not on its column-name argument. > > > I presume the reason for that is that the first paramater can be qualified: > > Right. From a bare-functionality point of view there's nothing wrong > with it, it just seems inconsistent and therefore likely to trip someone > up in future. > > But it seems no one else cares, so I'll shut up about it ... That behavior does seem strange to me. Would make it consistent have any downsides? If not, we should do it. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Unixware 714 pthreads
[EMAIL PROTECTED] wrote: > I agree with all that you say Tom, I'm just asking for some help to debug > this, Now that Larry is a litle off the list, I'm feeling really lonely on > UW. > SCO won't do anything until I come up with a test program that fails. All > my tries did work until then. > > I use other threaded progs like postfix or bind that nether fail. > > I'm really at lost. Would you/someone help me? The problem is that we are then spending our time debugging Unixware problems rather than focusing on our database software. I think this is why few have offered assistance. -- 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 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] Shared dependencies
On Thu, Oct 28, 2004 at 01:30:31AM -0300, Alvaro Herrera wrote: Hi, > So the first obvious question: should I create two separate catalogs, > one for users and other for tablespaces? Ok, so no opinions? Nobody objects to me creating two new shared catalogs to keep track of dependency on global objects, one for user/groups and other for tablespaces? -- Alvaro Herrera () Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] -HEAD contrib/dblink regress failure on SPARC/Solaris 8
On October 28, 2004 03:32 pm, Tom Lane wrote: > Darcy Buskermolen <[EMAIL PROTECTED]> writes: > > On October 20, 2004 10:26 am, you wrote: > >> The buildfarm has identified yet another failure under SPARC/Solaris 8 > >> as outlined in. > > Most likely this is fixed by Kris Jurka's just-applied patch. Yes it is. -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Shared dependencies
On Thu, 28 Oct 2004, Alvaro Herrera wrote: > On Thu, Oct 28, 2004 at 01:30:31AM -0300, Alvaro Herrera wrote: > > Hi, > > > So the first obvious question: should I create two separate catalogs, > > one for users and other for tablespaces? > > Ok, so no opinions? Nobody objects to me creating two new shared > catalogs to keep track of dependency on global objects, one for > user/groups and other for tablespaces? Perhaps we could (gulp) reenable OIDs on pg_shadow and pg_group and then we could just identify by OID. Gavin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposed Query Planner TODO items
> Hi Tatsuo, > > I've made a new release: > http://prdownloads.sourceforge.net/osdldbt/dbt3-v1.5.tar.gz?download > > Let me know if there are any problems. Thanks! > On Tue, Oct 26, 2004 at 12:44:49PM +0900, Tatsuo Ishii wrote: > > Hi, > > > > Thanks for the info. Would you give me the tarball? > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Suggestion: additional system views
On Fri, 2004-10-29 at 07:35, Josh Berkus wrote: > Is there any reason that we don't have pg_functions, pg_users, pg_groups and > other system views?pg_tables and pg_views is really useful, but it would > be good to cover the other items as well. pg_functions might be useful, but what would pg_users offer that pg_user does not already do? A pg_sequences view might also be handy. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_serial_sequence is inconsistent
Right. From a bare-functionality point of view there's nothing wrong with it, it just seems inconsistent and therefore likely to trip someone up in future. But it seems no one else cares, so I'll shut up about it ... I'm happy to have it fixed or changed :) I was just pointing out why it was like it is. It uses two different parsing functions. Chris ---(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] psql and schemas
psql's slash commands for schemas seem a little weird to me. For example: neilc=# \d nonexistent Did not find any relation named "nonexistent". neilc=# \dt nonexistent No matching relations found. neilc=# \dn nonexistent List of schemas Name | Owner --+--- (0 rows) -- Is there a good reason for this inconsistency? neilc=# create schema foo_schema; CREATE SCHEMA neilc=# \dn foo_schema List of schemas Name| Owner +--- foo_schema | neilc (1 row) neilc=# \dn foo_schema. List of schemas Name| Owner +--- foo_schema | neilc information_schema | neilc pg_catalog | neilc pg_toast | neilc public | neilc (5 rows) -- Why? (The same applies to "\dn nonexistent.") neilc=# \d No relations found. neilc=# \d foo_schema.* Did not find any relation named "foo_schema.*". -- Why the difference in behavior? In any case, the error message is confusing -- it suggests psql was looking for a relation with the name "foo_schema.*", where it obviously was not: neilc=# create table "foo_schema.*" (a int, b int); CREATE TABLE neilc=# \d foo_schema.* Did not find any relation named "foo_schema.*". neilc=# \d List of relations Schema | Name | Type | Owner +--+---+--- public | foo_schema.* | table | neilc (1 row) -- When you do \d schema.*, you get the definitions of _all_ the objects in the schema. I can see why we support this, although I can't see it being used very often. On the other hand, I think a much more common case would be trying to get a list of all the objects in a schema -- is there any way to do that? \dt schema.* lists the tables in a schema, for example, but not the other types of objects (in a similar fashion to how "\d" displays the objects in the search path). That's all for now :-) -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Suggestion: additional system views
Neil, > pg_functions might be useful, but what would pg_users offer that pg_user > does not already do? Show a list of groups that the user belongs to? Same thing with pg_groups; showing the list of users in the group. > A pg_sequences view might also be handy. Yes. Anything else? So far I have: pg_users pg_groups pg_functions pg_sequences hmmm ... pg_schemas pg_tablespaces ... as well, just for completeness. This is obviously and 8.1 thing, so I'll put it on my task list for after 8.0 PR is done. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Shared dependencies
Gavin Sherry <[EMAIL PROTECTED]> writes: > On Thu, 28 Oct 2004, Alvaro Herrera wrote: >> Ok, so no opinions? Nobody objects to me creating two new shared >> catalogs to keep track of dependency on global objects, one for >> user/groups and other for tablespaces? > Perhaps we could (gulp) reenable OIDs on pg_shadow and pg_group and then > we could just identify by OID. Or better, just equate AclId with OID. It's silly to create two tables where one will do. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] tablespaces for temporary files
I'd like to provide a way for DBAs to specify that the temporary files needed to for sorting, holdable cursors and similar operations should be created in a particular tablespace. (Right now these files are created in the tablespace associated with the current database.) Two ways to do this come to mind: via a GUC variable, or by setting a property of CREATE DATABASE (that could be altered via ALTER DATABASE). I think using a GUC variable is probably the better bet: it is more flexible, since ALTER DATABASE ... SET and ALTER USER ... SET can be used to define the GUC variable automatically for particular users and databases. So I'd like to add a GUC variable called something like "scratch_tablespace". If undefined (the default), temporary files for sorting/etc. will be created in the current database's tablespace. If set to the name of an existent tablespace, that tablespace will be used for temporary storage. If set to a nonexistent tablespace, a warning will be printed and we'll fallback to using the current database's tablespace. Regarding naming, I considered calling the GUC variable "temporary_tablespace" or something similar, but it seems to me that this might cause confusion with temporary tables -- furthermore, it might be an interesting feature to define a "temporary table tablespace" in the future, leading to yet more confusion. I think "scratch tablespace" is a pretty decent name for this concept, but I'm open to suggestions. Comments? -Neil ---(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] tablespaces for temporary files
So I'd like to add a GUC variable called something like "scratch_tablespace". If undefined (the default), temporary files for Should be called 'work_tablesapce' to match 'work_mem' :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
