Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus wrote:
Tom, Justin,
Um, not documenting it is probably not a good move for us, however putting
it at the end in a section marked Developer Focused or something similar
would probably have the right mix of messages. i.e. hands off + not a
performance tweak, etc.
So, proposal:
1) wal_debug and the various trace_locks options will not be included in
postgresql.conf.sample
Attached is the patch I will apply.
2) they will, however, be included in the Run Time Configuration page, under
a secion entitled Source Develoment Options
Makes sense, I guess.
--
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
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.127
diff -c -c -r1.127 guc.c
*** src/backend/utils/misc/guc.c28 May 2003 18:19:09 - 1.127
--- src/backend/utils/misc/guc.c2 Jun 2003 16:03:20 -
***
*** 689,694
--- 689,695
60, 1, 600, NULL, NULL
},
+ /* Not for general use */
{
{pre_auth_delay, PGC_SIGHUP}, PreAuthDelay,
0, 0, 60, NULL, NULL
***
*** 871,876
--- 872,878
$user,public, assign_search_path, NULL
},
+ /* Can't be set in postgresql.conf */
{
{server_encoding, PGC_INTERNAL, GUC_REPORT},
server_encoding_string,
***
*** 888,893
--- 890,896
notice, assign_log_min_messages, NULL
},
+ /* Not for general use --- used by SET SESSION AUTHORIZATION */
{
{session_authorization, PGC_USERSET, GUC_NO_SHOW_ALL |
GUC_NO_RESET_ALL},
session_authorization_string,
Index: src/backend/utils/misc/postgresql.conf.sample
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.78
diff -c -c -r1.78 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample 14 May 2003 03:26:02 -
1.78
--- src/backend/utils/misc/postgresql.conf.sample 2 Jun 2003 16:03:20 -
***
*** 182,201
#
- # Lock Tracing
- #
- #trace_notify = false
-
- # requires LOCK_DEBUG
- #trace_locks = false
- #trace_userlocks = false
- #trace_lwlocks = false
- #debug_deadlocks = false
- #trace_lock_oidmin = 16384
- #trace_lock_table = 0
-
-
- #
# Misc
#
#dynamic_library_path = '$libdir'
--- 182,187
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus wrote: Tom, Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the option that's supposed to let you turn off Inserting missing FROM clause for table ... I thought that patch was accepted 3 weeks ago? Is this just missing from postgresql.conf.sample? It is in the patch queue --- I am applying tomorrow. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
scott.marlowe wrote: On Fri, 6 Jun 2003, Bruce Momjian wrote: scott.marlowe wrote: On Fri, 6 Jun 2003, Peter Eisentraut wrote: scott.marlowe writes: If indexes on text worked right in other locales it would be no big deal. They will in version 7.4, so all these concerns about trading off locale use vs. performance will become obsolete. Oh! I thought there were still issues that couldn't be worked out on that front. In that case, heck yeah, set the locale on initdb to the current system locale. sweet. The problems go away _if_ the user knows about the new way of indexing LIKE on non-C locales. Should we have something about this mentioned in http://developer.postgresql.org/docs/postgres/install-upgrading.html for the 7.4 release? Or is there a more appropriate place? Yes, at a minimum, plus we need someone coming fresh to 7.5 to know this is an issue. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Returning to the List
I just want to drop a note to say I'm back on the list. I'm sorry to have been away for so long, but I had some personal issues that kept me from the list. I also lost all my data, so it would be great if someone could send me the latest version of the PITR patch. Thanks. -- John Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.3 COMPILE FAILURE: pg_dump (fwd)
--On Monday, June 09, 2003 23:12:27 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: cc -O -g -I../../../src/interfaces/libpq -I../../../src/include -I/usr/local/include -DBINDIR=\/usr/local/pgsql/bin\ -c -o pg_dump.o pg_dump.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:acomp: ERROR: pg_dump.c, line 192: incomplete struct/union/enum option: long_options This implies that your system has the getopt_long() subroutine (in one library or another) but getopt.h either doesn't exist or doesn't define struct option. This is not particularly hard to believe, since getopt_long() might be installed in a nonstandard place and its header file too. CVS tip attempts to support long options with or without a system copy of getopt_long(), but I fear that it will still break on platforms like yours, because there is no separate configure check to see if we need to provide a definition of struct option. Peter, what can we do to fix that? for the record, this is a change from 7.3.2 to 7.3.3 that broke here. 7.3.2 compiled just fine. Peter has an account on this box if he wants to look around. I can also make other people accounts. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
On Mon, 9 Jun 2003, Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the option that's supposed to let you turn off Inserting missing FROM clause for table ... Bruce hasn't applied that patch yet. I believe he's starting to catch up the patch backlog today, though. Are you sure about that? I seem to remember seeing the will be applied within 24 hours message a couple of weeks or so ago now. Is this a feature of the recent system problems and lost patches are having to be reapplied? As for it's name Josh, sorry, I don't have a record of my patch and the name used in the patch differs to that which I have in my source tree. -- Nigel Andrews ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] incremental backup
Hi all. I am newer to postgresql develop, so my qestion maybe too simple. I have noticed that we have discussed the incremental backup and PITR before. Frankly, I am still interested in incremental backup. I am not sure whether we can implement such function based on XLog Since there exists the unqiue LSN in XLog, if we backup the xlog content after the given LSN, when some error ocurrs, we use the parital xlog to restore the database. I am not familiar with the log mechinism in postgresql, maybe before we make incremental backup on Xlog, we should create a checkpoints in log. Very appreciate to any kind feedback. Thanks ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Function returns composite type
Hi! For some reason I wish to write C-function for SQL which returns set of composite type, but this type is defined function itself and composite type can be changed from call to call. So I can't define create type by 'CREATE TYPE' command. It's documented (34.7.8. Returning Rows (Composite Types) from C-Language Functions) there are only two ways to get TupleDesc: for a named relation and based on type OID. That ways are useless in my case. Is it possibly? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] ---(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] 7.3.3 COMPILE FAILURE: pg_dump (fwd)
Larry Rosenman [EMAIL PROTECTED] writes: for the record, this is a change from 7.3.2 to 7.3.3 that broke here. [ scratches head... ] I don't see anything in the CVS logs that could account for that. 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] Function returns composite type
Teodor Sigaev [EMAIL PROTECTED] writes: For some reason I wish to write C-function for SQL which returns set of composite type, but this type is defined function itself and composite type can be changed from call to call. So I can't define create type by 'CREATE TYPE' command. Perhaps the RECORD stuff would help you? It's poorly documented, but you could look at the code for SRFs to see how to use it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.3 COMPILE FAILURE: pg_dump (fwd)
On Tue, 10 Jun 2003, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: for the record, this is a change from 7.3.2 to 7.3.3 that broke here. [ scratches head... ] I don't see anything in the CVS logs that could account for that. It might be maintenenace related (7.1.3 UP 1 of UnixWare). I'll investigate when I get back from Houston (Fri 6/13/2003). LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] host and hostssl equivalence in pg_hba.conf
On Tue, 10 Jun 2003, Nigel J. Andrews wrote: How do people feel about changing matching for host and hostssl to be such that a plain host line in pg_hba.conf does not allow a SSL connection but requires the hostssl specifier? Nigel, We had discussed overhauling the connection settings on both client and server to cover all needs, along these lines: Date: Tue, 7 Jan 2003 16:07:58 -0500 (EST) From: Bruce Momjian [EMAIL PROTECTED] To: Peter Eisentraut [EMAIL PROTECTED] Cc: Jon Jensen [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PATCHES] Refuse SSL patchf Peter Eisentraut wrote: Bruce Momjian writes: Tom thought that having conflicting REFUSESSL and REQUIRESSL directives would be confusing, and since I dug up someone's old discussion in the list archives of the four possible modes, we could move to that. Oh. I find two params clearer than one with meaningless numbers. :-) But the numeric model provides four modes (refuse ssl, prefer no ssl, prefer ssl, require ssl) whereas the refuse/require combination only provides three modes (refuse ssl, require ssl, and one other depending on how you define it when neither is set). If you don't like numbers, make them words. OK, that works: require prevent prefer noprefer This allows us to subsume PGREQUIRE_SSL into the new variable. Do we still need additional functionality in pg_hba.conf? I am only asking if pushing these decisions out to the client makes sense? For performance reasons, it is good to push this information out to the clients so the proper connection method is used the first time. However, for easier maintenance, we could have all of this in pg_hba.conf only, and have clients try SSL first, and fall back to non-SSL if the server doesn't want SSL. It would require two new pg_hba.conf line types. We have prefer-SSL (host) and SSL-only (ssl) now. require (ssl) prevent (nossl) prefer (hostpreferssl) noprefer(host) This would change 'host' to not prefer SSL. Unfortunately, I lived with my own local patch and forgot about making the more general one these past five months. This proposal would meet your needs, wouldn't it? Jon ---(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] Returning to the List
Excellent news. I picked up your patch but have not be able to devote a large amount of time to it. I'll send you a patch based on the cvs tip as well as some pointers to proposed changes. I'll contact you offlist about various workload proposals. Cheers, Patrick J.R. Nield wrote: I just want to drop a note to say I'm back on the list. I'm sorry to have been away for so long, but I had some personal issues that kept me from the list. I also lost all my data, so it would be great if someone could send me the latest version of the PITR patch. Thanks. -- John Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] host and hostssl equivalence in pg_hba.conf
On Tue, 10 Jun 2003, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: How do people feel about changing matching for host and hostssl to be such that a plain host line in pg_hba.conf does not allow a SSL connection but requires the hostssl specifier? Then there would be no way to have a host entry that allowed both --- which, aside from being a loss of functionality, would doubtless break existing setups. Well, what I was thinking of would have allowed it, just using two entries, a host one and a hostssl one. I'd hold still for a hostnossl keyword, I guess, but I don't entirely see the use for it. Well Jon Jenson's posted something else on this which I should read when I've got my mind more in tune with it. If your real gripe is that libpq insists on trying SSL connections first, the server is the wrong end to be patching that problem at. There should be a way to control libpq's allow_ssl_try state variable from the outside. A quick read makes me think that's what Jon's post is on about. -- Nigel Andrews ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] host and hostssl equivalence in pg_hba.conf
Nigel J. Andrews [EMAIL PROTECTED] writes: On Tue, 10 Jun 2003, Tom Lane wrote: If your real gripe is that libpq insists on trying SSL connections first, the server is the wrong end to be patching that problem at. There should be a way to control libpq's allow_ssl_try state variable from the outside. A quick read makes me think that's what Jon's post is on about. Right. I had forgotten that thread, but indeed we had agreed to a definition that would allow flexible control of libpq's SSL behavior. Looks like no one got round to actually implementing what was hammered out though. Note: if you want to take a swipe at implementing that proposal, please be sure to start from CVS tip. I mangled all that code just a couple days ago to allow both old and new protocols to be supported ... so any patch based on 7.3 is not going to apply ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] security flaw
On Sat, 7 Jun 2003 [EMAIL PROTECTED] wrote: Hi all, I wonder if it's a security problem: One of my customer noticed that he could see all databases on the system with phppgadmin. not only he sees databases but tables, views, fonctions... Fortunatly he can't see any row. This customer has the ability to create databases but not users. I wonder if the super_user privilege should be separated from the priviledge of creating databases/users. I alose think that only a superuser should list databases and objects. What do you think? Since security by obscurity is presumed to be ineffective, conversely, revealing the location of an object produces no real decrease in security. Now, it might be nice from the user's perspective if they could filter out the stuff they don't have access to, in order to ensure a nice neat little view of their own data in a galaxy of information (i.e. 100 other users each with their own data set and priveldges.) Since schemas provide a simple way to limit your own view, they provide for that function. Can phppgadmin be programmed to only use certain search paths in the schema? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Function returns composite type
Perhaps the RECORD stuff would help you? It's poorly documented, but
you could look at the code for SRFs to see how to use it.
regards, tom lane
Ok, RECORD was a keyword, thank you. But I have questions:
1 What do you mean SRF? Set Return Function?
2 Some example I found in contrib/tablefunc, and so I create test function:
Datum
qqn(PG_FUNCTION_ARGS) {
int attnum = PG_NARGS();
TupleDesc tupdesc;
charattname[NAMEDATALEN];
int i;
TupleTableSlot *slot;
AttInMetadata *attinmeta;
Datum *dvalues, result;
char *nulls;
HeapTuple tuple;
/* set tupledesc */
tupdesc = CreateTemplateTupleDesc(attnum, false);
for (i = 0; i attnum; i++) {
sprintf(attname, z%d, i+1);
TupleDescInitEntry(tupdesc, i+1, attname, INT4OID, -1, 0, false);
}
slot = TupleDescGetSlot(tupdesc);
attinmeta = TupleDescGetAttInMetadata(tupdesc);
dvalues = (Datum *) palloc(attnum * sizeof(Datum));
nulls = (char *) palloc(attnum * sizeof(char));
for (i = 0; i attnum; i++) {
nulls[i] = ' ';
dvalues[i] = PG_GETARG_DATUM(i);
}
/* tupdesc = attinmeta-tupdesc */
tuple = heap_formtuple(tupdesc, dvalues, nulls);
pfree(dvalues);
pfree(nulls);
result = TupleGetDatum(slot, tuple);
PG_RETURN_DATUM(result);
}
create function qqN(int4)
returns record
AS 'MODULE_PATHNAME'
LANGUAGE 'C';
create function qqN(int4,int4)
returns record
AS 'MODULE_PATHNAME'
LANGUAGE 'C';
# select * from qqn(1) as c(qq int4);
qq
1
(1 row)
# select * from qqn(1,2) as c(qq int4, qq1 int4);
qq | qq1
+-
1 | 2
(1 row)
It works fine. But is there way not to point 'as c(qq int4, qq1 int4)'? Notice:
qqn isn't real, it's test only.
Thank you.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
---(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] Proposal to Re-Order Postgresql.Conf, part II
Nigel J. Andrews wrote: On Mon, 9 Jun 2003, Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the option that's supposed to let you turn off Inserting missing FROM clause for table ... Bruce hasn't applied that patch yet. I believe he's starting to catch up the patch backlog today, though. Are you sure about that? I seem to remember seeing the will be applied within 24 hours message a couple of weeks or so ago now. Is this a feature of the recent system problems and lost patches are having to be reapplied? As for it's name Josh, sorry, I don't have a record of my patch and the name used in the patch differs to that which I have in my source tree. Yes, it is in the queue: http://momjian.postgresql.org/cgi-bin/pgpatches Because of my Win32 work, I couldn't follow the 24/48 hours limit. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] host and hostssl equivalence in pg_hba.conf
Nigel J. Andrews wrote: How do people feel about changing matching for host and hostssl to be such that a plain host line in pg_hba.conf does not allow a SSL connection but requires the hostssl specifier? I had been going to submit a very small patch to do this but then it occurred to me this was a good candidate for a GUC along the lines of allow_host_hostssl_equivalence (just a name picked out of the air for this post). As this is a little bit more work and I can't get to anoncvs to refresh my tree I thought I'd check if it was something to persue or forget. The other problem with using GUC here is that is adds even more complexity to pg_bha.conf, where the meaning of 'host' changes depending on postgresql.conf, and as Tom pointed out, it doesn't give per-host control. I do think we need an additional host* line in pg_hba.conf for this. The real killer is that folks are getting SSL when they don't even know it just because their client binaries/server are ssl. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Justin Clift wrote: Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: wal_debug is seldom used outside of Postgresql source development or unusual system failures, and should therefore go last. BTW, it occurs to me that wal_debug is one of the hacker-only variables that probably ought not be documented at all. I cannot imagine any use for it for the average DBA. Um, not documenting it is probably not a good move for us, however putting it at the end in a section marked Developer Focused or something similar would probably have the right mix of messages. i.e. hands off + not a performance tweak, etc. No, not documenting it IS a good move. If there's a button people will press it, if there's a switch people will turn it on and if there's a slot people will stick in whatever they have ... believe it or not, I have found a Xmas cookie in the floppy drive of a consultant's notebook and a secretary once managed to get a 5.25'' floppy into an IBM PS/2 ... er ... yes, there was some kind of venting slot somewhere ... I did not try to explain the difference between a floppy drive and a venting slot to her, I converted it to the right format and the next time she came with a 5.25'' floppy directly to me :-) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Jan, No, not documenting it IS a good move. I couldn't disagree more. Undocumented options? Who are we, Microsoft? If there's a button people will press it, if there's a switch people will turn it on and if there's a slot people will stick in whatever they have ... believe it or not, I have found a Xmas cookie in the floppy drive of a consultant's notebook snip These kinds of people don't read the documentation in the first place, so we're in no danger from them. I can definitely see an argument that the developer switches should be documented on a different page of the docs from Run-Time Configuration. But the idea of having GUCs that aren't documented at all, anywhere, is a very anti-Open Source idea. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Postgresql AMD x86-64
Hi folks, We recently built a dual K8D-based Opteron box running Linux in 64-bit mode (Debian 'testing' distribution with newly compiled binutils, gcc, and various support libraries for amd64 architecture). The Postgres 7.3.3 port was simply a matter of setting the appropriate flags to take of the biarchectecture nature of the Linux port. (that is, -m64 to generate 64 bit code and either gcc -m64 or ld -melf_x86_64 for linking). There were no other issues in the compile. In the install, I had to re-init due to the incompatibility of pg_control. All the regression tests went smoothly (the one failure was in geometry and is due to round off in the least sig figs of the doubles in the Point structure or machine zero differences). I compared a simple query on local data in both 32bit mode and 64bit mode; the execute time difference was not significant but this was not a compute intensive verification (summing up column values in a table). We have some other 32-bit amd machines here; I would be happy to try a few other tests. Good job, developers!!! On Mon, 07 Apr 2003 18:34:05 +0800 Justin Clift [EMAIL PROTECTED] wrote: Hi guys, Does anyone want remote access to the upcoming AMD 64 bit architecture, to make sure PostgreSQL runs well on it? It's only via remote access at present, but the AMD guys are willing to help us out here. Regards and best wishes, Justin Clift Original Message Subject: RE: Postgresql AMD x86-64 Date: Fri, 4 Apr 2003 10:29:24 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Justin, I apologize for the delayed response. Unfortunately, at the moment I don't have a system available to send you. If I could get you access to a machine remotely, would that be useful to you? I will need to check machine availability before I can promise you anything, but I'm willing to be your sponsor in the AMD Developer Center and approve a request for access. -Original Message- From: Justin Clift [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 7:31 PM To: Andreas Jaeger Subject: Re: AMD x86-64 Hi Andreas, Have you heard anything back from the AMD guys in relation to this? We've not heard a single thing from them. :-( Regards and best wishes, Justin Clift Andreas Jaeger wrote: Justin Clift [EMAIL PROTECTED] writes: snip Yep, the aim is to allow PostgreSQL developers access to a system running x86-64 hardware as needed. Trying to get ahead of the ballgame these days. :) If you have hammer Hardware, I can provide you with a prerelease of our software, That would be cool Andreas, thanks. Now, just need to secure the hardware somehow. Personally, I feel that an email forwarded from you to the right people at AMD may help that significantly. At least, people from AMD should get in contact with us to see if something beneficial can be arranged. Ok, I forwarded your note and let's see whether they're interested (there're already a few commercial database like IBM DB2 ported). From past experience, it might be difficult to get hardware directly but let's wait for their answer. If you don't hear anything this week, feel free to ask me again, Andreas -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Martin Weinberg Phone: (413) 545-3821 Dept. of Astronomy FAX: (413) 545-4223 530 Graduate Research Tower [EMAIL PROTECTED] University of Massachusetts http://www.astro.umass.edu/~weinberg/ Amherst, MA 01003-4525 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Function returns composite type
Teodor Sigaev wrote: Ok, RECORD was a keyword, thank you. But I have questions: 1 What do you mean SRF? Set Return Function? It refers to functions returning one or more tuples. From a practical standpoint, it is a function that is (and must be) used in the FROM clause like a table (hence also known as a table function). # select * from qqn(1,2) as c(qq int4, qq1 int4); qq | qq1 +- 1 | 2 (1 row) It works fine. But is there way not to point 'as c(qq int4, qq1 int4)'? If you mean, is there a way to leave out the 'as c(qq int4, qq1 int4)', the answer is no. You need to either declare the function to return a determinate data type, or you have to specify the data type at runtime in the query string. Joe ---(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] Groups and roles
Tom Lane writes: 1. Do we want to someday allow groups to have groups as members? (Seems reasonable to me.) I agree. 2. Are there any other differences between groups and roles? (I'm not sure about this one.) One other difference I found is that roles can be enabled or disabled (as session state). According to the SQL standard, only one role can be active at once, but I think this is useless. According to the Oracle documentation, it seems that in Oracle many roles can be active (namely all of those granted to you), but they can be selectively enabled or disabled. This seems like a reasonable feature, but it's not terribly important. Another issue is that users and roles share a namespace. We might have to deal with that sometime, but it's not a problem as far as the information schema is concerned. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Groups and roles
Hans-Jürgen Schönig writes: Imagine having groups having rights on dozens of tables. If these groups were assigned to a role it would be an easy task to block numerous groups from executing SQL at once. Currently a user has all rights of all groups he belongs to so it is damn hard to say that 1000 users should not be allowed to do anything for a period of time (because of maintenance or so). If all those users (but the superuser) had a certain role, the role could be modified instead of those 1000 users/groups (eg. REVOKE login, execute_sql FROM some_role). I think you can do that with groups: Create a number of groups, say users1, users2, etc., and then, at the predermined hour, you do: BEGIN; REVOKE privilege FROM users1; GRANT privilege TO users2; COMMIT; This might be helped if groups could contain other groups, so that privilege could be a group/role name, to ease administration, but that does not create any distinction between the concepts role and group. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Character encoding
Dennis Björklund writes: When you run psql with a different language then english the strings are usually in a character set that is not pure ascii. For example to represent swedish you need either latin1 or unicode. Therefor the po file for swedish is in latin1. Yes, you need to set your client encoding to match the PO files. Maybe we should try to keep the (translated) column headers within the client, to side-step this issue. Do you want to investigate that? -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Proposal to Re-Order Postgresql.Conf, part II
Okay, separate documentation might work ;-) Jan Josh Berkus wrote: Jan, No, not documenting it IS a good move. I couldn't disagree more. Undocumented options? Who are we, Microsoft? If there's a button people will press it, if there's a switch people will turn it on and if there's a slot people will stick in whatever they have ... believe it or not, I have found a Xmas cookie in the floppy drive of a consultant's notebook snip These kinds of people don't read the documentation in the first place, so we're in no danger from them. I can definitely see an argument that the developer switches should be documented on a different page of the docs from Run-Time Configuration. But the idea of having GUCs that aren't documented at all, anywhere, is a very anti-Open Source idea. -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Postgresql AMD x86-64
Can you send us a patch? --- Martin D. Weinberg wrote: Hi folks, We recently built a dual K8D-based Opteron box running Linux in 64-bit mode (Debian 'testing' distribution with newly compiled binutils, gcc, and various support libraries for amd64 architecture). The Postgres 7.3.3 port was simply a matter of setting the appropriate flags to take of the biarchectecture nature of the Linux port. (that is, -m64 to generate 64 bit code and either gcc -m64 or ld -melf_x86_64 for linking). There were no other issues in the compile. In the install, I had to re-init due to the incompatibility of pg_control. All the regression tests went smoothly (the one failure was in geometry and is due to round off in the least sig figs of the doubles in the Point structure or machine zero differences). I compared a simple query on local data in both 32bit mode and 64bit mode; the execute time difference was not significant but this was not a compute intensive verification (summing up column values in a table). We have some other 32-bit amd machines here; I would be happy to try a few other tests. Good job, developers!!! On Mon, 07 Apr 2003 18:34:05 +0800 Justin Clift [EMAIL PROTECTED] wrote: Hi guys, Does anyone want remote access to the upcoming AMD 64 bit architecture, to make sure PostgreSQL runs well on it? It's only via remote access at present, but the AMD guys are willing to help us out here. Regards and best wishes, Justin Clift Original Message Subject: RE: Postgresql AMD x86-64 Date: Fri, 4 Apr 2003 10:29:24 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Justin, I apologize for the delayed response. Unfortunately, at the moment I don't have a system available to send you. If I could get you access to a machine remotely, would that be useful to you? I will need to check machine availability before I can promise you anything, but I'm willing to be your sponsor in the AMD Developer Center and approve a request for access. -Original Message- From: Justin Clift [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 7:31 PM To: Andreas Jaeger Subject: Re: AMD x86-64 Hi Andreas, Have you heard anything back from the AMD guys in relation to this? We've not heard a single thing from them. :-( Regards and best wishes, Justin Clift Andreas Jaeger wrote: Justin Clift [EMAIL PROTECTED] writes: snip Yep, the aim is to allow PostgreSQL developers access to a system running x86-64 hardware as needed. Trying to get ahead of the ballgame these days. :) If you have hammer Hardware, I can provide you with a prerelease of our software, That would be cool Andreas, thanks. Now, just need to secure the hardware somehow. Personally, I feel that an email forwarded from you to the right people at AMD may help that significantly. At least, people from AMD should get in contact with us to see if something beneficial can be arranged. Ok, I forwarded your note and let's see whether they're interested (there're already a few commercial database like IBM DB2 ported). From past experience, it might be difficult to get hardware directly but let's wait for their answer. If you don't hear anything this week, feel free to ask me again, Andreas -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Martin Weinberg Phone: (413) 545-3821 Dept. of Astronomy FAX: (413) 545-4223 530 Graduate Research Tower[EMAIL PROTECTED] University of Massachusettshttp://www.astro.umass.edu/~weinberg/ Amherst, MA 01003-4525 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [pgsql-advocacy] [GENERAL] Postgresql AMD x86-64
Can you send in a report for the supported platforms list?
http://developer.postgresql.org/docs/postgres/supported-platforms.html
Robert Treat
On Tue, 2003-06-10 at 13:16, Martin D. Weinberg wrote:
Hi folks,
We recently built a dual K8D-based Opteron box running Linux in 64-bit
mode (Debian 'testing' distribution with newly compiled binutils, gcc,
and various support libraries for amd64 architecture).
The Postgres 7.3.3 port was simply a matter of setting the appropriate
flags to take of the biarchectecture nature of the Linux port. (that is,
-m64 to generate 64 bit code and either gcc -m64 or ld -melf_x86_64
for linking). There were no other issues in the compile. In the
install, I had to re-init due to the incompatibility of pg_control.
All the regression tests went smoothly (the one failure was in geometry
and is due to round off in the least sig figs of the doubles in the Point
structure or machine zero differences).
I compared a simple query on local data in both 32bit mode and 64bit mode;
the execute time difference was not significant but this was not a compute
intensive verification (summing up column values in a table). We have
some other 32-bit amd machines here; I would be happy to try a few other
tests.
Good job, developers!!!
On Mon, 07 Apr 2003 18:34:05 +0800
Justin Clift [EMAIL PROTECTED] wrote:
Hi guys,
Does anyone want remote access to the upcoming AMD 64 bit architecture,
to make sure PostgreSQL runs well on it?
It's only via remote access at present, but the AMD guys are willing to
help us out here.
Regards and best wishes,
Justin Clift
Original Message
Subject: RE: Postgresql AMD x86-64
Date: Fri, 4 Apr 2003 10:29:24 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Justin,
I apologize for the delayed response. Unfortunately, at the moment I
don't have a system available to send you. If I could get you access to
a machine remotely, would that be useful to you? I will need to check
machine availability before I can promise you anything, but I'm willing
to be your sponsor in the AMD Developer Center and approve a request for
access.
-Original Message-
From: Justin Clift [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 7:31 PM
To: Andreas Jaeger
Subject: Re: AMD x86-64
Hi Andreas,
Have you heard anything back from the AMD guys in relation to this?
We've not heard a single thing from them.
:-(
Regards and best wishes,
Justin Clift
Andreas Jaeger wrote:
Justin Clift [EMAIL PROTECTED] writes:
snip
Yep, the aim is to allow PostgreSQL developers access to a system
running x86-64 hardware as needed.
Trying to get ahead of the ballgame these days. :)
If you have hammer Hardware, I can provide you with a prerelease of
our software,
That would be cool Andreas, thanks.
Now, just need to secure the hardware somehow. Personally, I feel
that an email forwarded from you to the right people at AMD may help
that significantly. At least, people from AMD should get in contact
with us to see if something beneficial can be arranged.
Ok, I forwarded your note and let's see whether they're interested
(there're already a few commercial database like IBM DB2 ported).
From past experience, it might be difficult to get hardware directly
but let's wait for their answer.
If you don't hear anything this week, feel free to ask me again,
Andreas
--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Martin Weinberg Phone: (413) 545-3821
Dept. of Astronomy FAX: (413) 545-4223
530 Graduate Research Tower[EMAIL PROTECTED]
University of Massachusettshttp://www.astro.umass.edu/~weinberg/
Amherst, MA 01003-4525
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Groups and roles
Peter Eisentraut [EMAIL PROTECTED] writes: Another issue is that users and roles share a namespace. We might have to deal with that sometime, but it's not a problem as far as the information schema is concerned. I've been thinking for awhile that the ACL code would be simplified if userids and groupids shared a numberspace, or whatever you want to call it (ie, a given ID number cannot belong to both a user and a group). I think that implementing that would require at least a partial merge of pg_shadow and pg_group --- unless you want to get into implementing cross-table unique indexes. If we agreed that they share a namespace as well, the merge could be taken further. Perhaps more usefully, the GRANT/REVOKE syntax and the display format for ACL lists could be simplified, since there'd be no need for a syntactic marker as to whether a given name is a user or a group. Not sure how many people would complain if they couldn't have a user and a group of the same name. 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] Groups and roles
It would be nice to merge them, but with Unix having separate namespaces, I am not sure it is a good idea to diverge from that. --- Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Another issue is that users and roles share a namespace. We might have to deal with that sometime, but it's not a problem as far as the information schema is concerned. I've been thinking for awhile that the ACL code would be simplified if userids and groupids shared a numberspace, or whatever you want to call it (ie, a given ID number cannot belong to both a user and a group). I think that implementing that would require at least a partial merge of pg_shadow and pg_group --- unless you want to get into implementing cross-table unique indexes. If we agreed that they share a namespace as well, the merge could be taken further. Perhaps more usefully, the GRANT/REVOKE syntax and the display format for ACL lists could be simplified, since there'd be no need for a syntactic marker as to whether a given name is a user or a group. Not sure how many people would complain if they couldn't have a user and a group of the same name. 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 -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Postgresql AMD x86-64
Bruce,
I didn't change the source tree at all. I used:
env CFLAGS='-O3 -m64' LD='/usr/bin/ld -melf_x86_64' ./configure --with-CXX
--without-zlib
with the experimental gcc and bintils from www.x86-64.org. I needed
--without-zlib because I don't have a 64 bit compile yet for zlib.
make
make install-all-headers
make check CC='gcc -m64'
The last one is needed to make sure that the shared library gets made
in the amd64 architecture.
That's it!
On Tue, 10 Jun 2003 14:14:22 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Can you send us a patch?
---
Martin D. Weinberg wrote:
Hi folks,
We recently built a dual K8D-based Opteron box running Linux in 64-bit
mode (Debian 'testing' distribution with newly compiled binutils, gcc,
and various support libraries for amd64 architecture).
The Postgres 7.3.3 port was simply a matter of setting the appropriate
flags to take of the biarchectecture nature of the Linux port. (that is,
-m64 to generate 64 bit code and either gcc -m64 or ld -melf_x86_64
for linking). There were no other issues in the compile. In the
install, I had to re-init due to the incompatibility of pg_control.
All the regression tests went smoothly (the one failure was in geometry
and is due to round off in the least sig figs of the doubles in the Point
structure or machine zero differences).
I compared a simple query on local data in both 32bit mode and 64bit mode;
the execute time difference was not significant but this was not a compute
intensive verification (summing up column values in a table). We have
some other 32-bit amd machines here; I would be happy to try a few other
tests.
Good job, developers!!!
On Mon, 07 Apr 2003 18:34:05 +0800
Justin Clift [EMAIL PROTECTED] wrote:
Hi guys,
Does anyone want remote access to the upcoming AMD 64 bit architecture,
to make sure PostgreSQL runs well on it?
It's only via remote access at present, but the AMD guys are willing to
help us out here.
Regards and best wishes,
Justin Clift
Original Message
Subject: RE: Postgresql AMD x86-64
Date: Fri, 4 Apr 2003 10:29:24 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Justin,
I apologize for the delayed response. Unfortunately, at the moment I
don't have a system available to send you. If I could get you access to
a machine remotely, would that be useful to you? I will need to check
machine availability before I can promise you anything, but I'm willing
to be your sponsor in the AMD Developer Center and approve a request for
access.
-Original Message-
From: Justin Clift [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 7:31 PM
To: Andreas Jaeger
Subject: Re: AMD x86-64
Hi Andreas,
Have you heard anything back from the AMD guys in relation to this?
We've not heard a single thing from them.
:-(
Regards and best wishes,
Justin Clift
Andreas Jaeger wrote:
Justin Clift [EMAIL PROTECTED] writes:
snip
Yep, the aim is to allow PostgreSQL developers access to a system
running x86-64 hardware as needed.
Trying to get ahead of the ballgame these days. :)
If you have hammer Hardware, I can provide you with a prerelease of
our software,
That would be cool Andreas, thanks.
Now, just need to secure the hardware somehow. Personally, I feel
that an email forwarded from you to the right people at AMD may help
that significantly. At least, people from AMD should get in contact
with us to see if something beneficial can be arranged.
Ok, I forwarded your note and let's see whether they're interested
(there're already a few commercial database like IBM DB2 ported).
From past experience, it might be difficult to get hardware directly
but let's wait for their answer.
If you don't hear anything this week, feel free to ask me again,
Andreas
--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Martin Weinberg Phone: (413) 545-3821
Dept. of Astronomy FAX: (413) 545-4223
530 Graduate Research Tower [EMAIL PROTECTED]
University of Massachusetts http://www.astro.umass.edu/~weinberg/
Amherst, MA 01003-4525
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Re: [HACKERS] Feature freeze date
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? Well it would certainly be nice if CVS was working first. I am still getting the following error: $ cvs update /projects/cvsroot: no such repository - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200306101553 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+5jgyvJuQZxSWSsgRArHRAKDl582A3ntupytI/29x4dj/r6Ue8wCg88xD 6Y8n8+m31p0y5izI2mut4Zk= =mSQQ -END PGP SIGNATURE- ---(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] Feature freeze date
[EMAIL PROTECTED] wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? Well it would certainly be nice if CVS was working first. I am still getting the following error: $ cvs update /projects/cvsroot: no such repository Yes. I am even holding some of the patches because I am not sure if it makes sense to apply them when no one can check them. Marc says he will have it working in 6 hours. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Character encoding
On Tue, 10 Jun 2003, Peter Eisentraut wrote: we should try to keep the (translated) column headers within the client, to side-step this issue. Do you want to investigate that? That is the obvious solution, there is no real need to send the strings to the server in the first place. The problem is not just with column headers though as it's also used in the data in the table. (which of course has the same solution, examin the data when it get to the client and substitute for the translated string). I'll take a look at it and probably fix it by the weekend (if not sooner). -- /Dennis ---(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] Proposal to Re-Order Postgresql.Conf, part II
Tom, I'm noticing re-namining of a lot of GUCs. As far as I can tell, the re-naming is based on logical reasons -- for example, log_hostname is more accurate that hostname_lookup -- but was a little surprised. We'd better warn users who are upgrading -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] Proposal to Re-Order Postgresql.Conf, part II
Tom, Also, Autocommit seems to be gone from postgresql.conf.sample. Was this intentional? -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] writes: Also, Autocommit seems to be gone from postgresql.conf.sample. Was this intentional? Yes. It's toast ... didn't you see that flamewar a couple months ago? 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] Proposal to Re-Order Postgresql.Conf, part II
Tom, Yes. It's toast ... didn't you see that flamewar a couple months ago? Nope, missed it. There's enough traffic on this list that I ignore anything that I'm not working on. So are we eliminating the autocommit GUC entirely, or just from postgresql.conf? (I never used the setting, myself ...) -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] [GENERAL] Postgresql AMD x86-64
Martin D. Weinberg [EMAIL PROTECTED] writes: I didn't change the source tree at all. I used: env CFLAGS='-O3 -m64' LD='/usr/bin/ld -melf_x86_64' ./configure --with-CXX --without-zlib BTW, see Jeff Baker's nearby report in pgsql-general that s_lock.h needs to be tweaked to use spinlocks on this platform. If you're using semaphores instead then you're taking a big performance hit. 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] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] writes: So are we eliminating the autocommit GUC entirely, or just from postgresql.conf? Entirely --- putting it on the server side was a bad mistake, in hindsight. The functionality is better provided on the client side. (The GUC var does still physically exist, but that's only so that commands like SET AUTOCOMMIT TO ON will be accepted from 7.3-vintage clients. If you try SET AUTOCOMMIT TO OFF you'll get an error. I'm unsure whether this needs to be in the documentation at all, but it definitely doesn't need to be in postgresql.conf.sample.) 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] Proposal to Re-Order Postgresql.Conf, part II
So are we eliminating the autocommit GUC entirely, or just from postgresql.conf? It's a client side feature now. Completely gone from the server. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [PERFORM] Re-ordering .CONF params ... questions for this list
Folks, Revised ordering of options, based on information and suggestions received here on both mailing lists. -- -Josh Berkus __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco #CONNECTIONS AND AUTHENTICATION #Connection Settings tcpip_socket max_connections superuser_reserved_connections port unix_socket_directory unix_socket_group unix_socket_permissions #Security Authentication authentication_timeout ssl krb_server_keyfile virtual_host db_user_namespace #RESOURCE USAGE (except WAL) #Memory shared_buffers sort_mem vacuum_mem #Free Space Map max_fsm_pages max_fsm_relations #Disk Resource Usage max_files_per_process preload_libraries #WRITE AHEAD LOG fsync wal_sync_method wal_buffers checkpoint_segments checkpoint_timeout checkpoint_warning commit_delay commit_siblings #QUERY TUNING #Planner Method Enabling enable_hashagg enable_hashjoin enable_indexscan enable_mergejoin enable_nestloop enable_seqscan enable_sort enable_tidscan #Planner Cost Constants effective_cache_size random_page_cost cpu_tuple_cost cpu_index_tuple_cost cpu_operator_cost default_statistics_target #Genetic Estimate Query Optimizer geqo geqo_threshold geqo_selection_bias geqo_pool_size geqo_effort geqo_generations geqo_random_seed #Other Query Modifiers explain_pretty_print from_collapse_limit join_collapse_limit max_expr_depth #LOGGING DEBUGGING #Syslog syslog syslog_facility syslog_ident #Debugging/Logging Levels server_min_messages client_min_messages log_min_error_statement debug_print_parse debug_print_rewritten debug_print_plan debug_pretty_print debug_assertions silent_mode #Additional Info to Log log_connections log_duration log_pid log_statement log_timestamp hostname_lookup show_source_port #CLIENT CONNECTION DEFAULTS #Statement Behaviour XautocommitX REMOVED! search_path default_transaction_isolation default_transaction_read_only statement_timeout #Locale and Formatting datestyle timezone australian_timezones extra_float_digits lc_messages lc_monetary lc_time lc_numeric client_encoding #Other Defaults password_encryption dynamic_library_path #STATISTICS #Statistics monitoring show_parser_stats show_planner_stats show_executor_stats show_statement_stats default_statistics_target #Query/Index Statistics Collector stats_start_collector stats_reset_on_server_start stats_command_string stats_row_level stats_block_level #LOCK MANAGEMENT deadlock_timeout max_locks_per_transaction #VERSION/PLATFORM COMPATIBILITY OPTIONS #Previous Postgres Versions enable_implicit_from regex_flavor sql_inheritance #Compatibility with Platforms Clients have_rendezvous transform_null_equals ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Subtitles in postgresql docs SGML?
Folks, Is there an idiot's guide to our SGML format somewhere? I'm new to updating the actual Postgresql docs, and new to SGML in general. I'm trying to figure out how to add a sub-title and sub-section within a section. Or something similar. -- -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] Subtitles in postgresql docs SGML?
On Tue, 2003-06-10 at 17:52, Josh Berkus wrote: Folks, Is there an idiot's guide to our SGML format somewhere? I'm new to updating the actual Postgresql docs, and new to SGML in general. I'm trying to figure out how to add a sub-title and sub-section within a section. Or something similar. Not quite what you're looking for, but these have good short examples. Official Guide to docbook (technical): http://www.docbook.org/tdg/en/html/docbook.html FreeBSD SGML (Docbook) Primer: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/sgml-markup-docbook.html Gnome Doc Project, intro to Docbook: http://developer.gnome.org/projects/gdp/handbook/gdp-handbook/ar01s04.html -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] SELECT TAKES A LOOOONG TIME
Hi, could somebody explain me please why following select SELECT docid FROM prod.guids GROUP BY docid HAVING( COUNT(docid) 1 ) taking 15 min on 2 Proc Box on 1M rows, where number of duplicates around 300K, and docid indexed and not null and char(16). May be I am doing something wrong? Thank you. ---(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] Feature freeze date
'k, someone please test ... should all be setup now and 'auto-updating' hourly ... On Tue, 10 Jun 2003, Bruce Momjian wrote: [EMAIL PROTECTED] wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? Well it would certainly be nice if CVS was working first. I am still getting the following error: $ cvs update /projects/cvsroot: no such repository Yes. I am even holding some of the patches because I am not sure if it makes sense to apply them when no one can check them. Marc says he will have it working in 6 hours. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze date
On Tue, 10 Jun 2003, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? I don't think a week of partial downtime justifies a month's slip. The July 1/15 schedule seems like it might be a good plan though. I know I'm not going to be done editing error messages by June 15 ... July 1/15 sounds good to me as well ... ---(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] Feature freeze date
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, someone please test ... should all be setup now and 'auto-updating' hourly ... Not quite there yet: $cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login Logging in to :pserver:[EMAIL PROTECTED]:2401/projects/cvsroot CVS password: cvs login: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200306102252 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+5pmwvJuQZxSWSsgRAkJ1AKCFCrFO3uSOZsapiELIRT3I/3j1cgCdFvwN +G5aCJaZg4kNMLezAsQxZm8= =t2BA -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze date
you have to give it a password ... any password, but a password non the less ... someone else asked me this also, and if I enter no passwd, I can get the same error message ... On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, someone please test ... should all be setup now and 'auto-updating' hourly ... Not quite there yet: $cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login Logging in to :pserver:[EMAIL PROTECTED]:2401/projects/cvsroot CVS password: cvs login: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200306102252 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+5pmwvJuQZxSWSsgRAkJ1AKCFCrFO3uSOZsapiELIRT3I/3j1cgCdFvwN +G5aCJaZg4kNMLezAsQxZm8= =t2BA -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze date
On Wed, 11 Jun 2003 12:10 pm, The Hermit Hacker wrote: you have to give it a password ... any password, but a password non the less ... someone else asked me this also, and if I enter no passwd, I can get the same error message ... The reason for the confusion might be because here: http://developer.postgresql.org/docs/postgres/cvs.html#ANONCVS the instructions state You will be prompted for a password; just press ENTER. which previously worked for me. For those of us using anon CVS, Marc's advice works fine: password a works for me and I can authenticate now. Philip. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] How to enumerate foreign key constraints after
Moving to -hackers. Unfortunately, having all my users run contrib/adddepend isn't an option for me. However, that script does contain a good deal of information that I may be able to use for detecting old-style foreign key constraints in my own code. I assume you're doing the database upgrade for them or providing instructions? Could this be a mandatory portion of that process? Okay, more questions: I see that adddepend detects old-style foreign key constraints by looking for groups of 3 triggers having 6 or more identical function arguments. Is that the best way to do it? It occurs to me that an alternative might be to find triggers that call RI_FKey_check_ins() and have the tgisconstraint flag set. Will either approach be safe in postgres 7.4? Perhaps a combination of the two would be best? Yes, a combination of the two would probably be better. You would need to be careful about function call names for FKeys, there are a fair number of them. Checking for 3 triggers with the function name starting with RI_FKey* would probably be better. That said, I've not heard of any issues with the current implementation of adddepend, which is also used in a few other well used programs. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [GENERAL] How to enumerate foreign key constraints after
On Tue, Jun 10, 2003 at 10:25:05PM -0400, Rod Taylor wrote: I see that adddepend detects old-style foreign key constraints by looking for groups of 3 triggers having 6 or more identical function arguments. Is that the best way to do it? That said, I've not heard of any issues with the current implementation of adddepend, which is also used in a few other well used programs. I used adddepend on a relatively complicated schema with lots of foreign key constraints and sequences it worked pretty well. It was from 7.1.3 to 7.4devel. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Investigación es lo que hago cuando no sé lo que estoy haciendo (Wernher von Braun) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Feature freeze date
OK, feature freeze July 1, beta starts July 15. --- The Hermit Hacker wrote: On Tue, 10 Jun 2003, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? I don't think a week of partial downtime justifies a month's slip. The July 1/15 schedule seems like it might be a good plan though. I know I'm not going to be done editing error messages by June 15 ... July 1/15 sounds good to me as well ... -- 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
[HACKERS] GUC --- prevent non-super user changes
Tom Lane wrote:
The recent change to make log_min_messages SUSET provokes the following
behavior:
$ export PGOPTIONS=-d 5
$ psql
psql: FATAL: 'log_min_messages': permission denied
$
Considering that I *am* superuser, this is quite unacceptable.
If you don't want to revert the change, propose another solution.
Here is a proposed fix for the new SUSET of various variables. The
solution is to create a new GUC context called PGC_USERLIMIT, which
limits changes by non-super users. For example, non-super users can
turn on logging, but can't turn it off, and log_min_* logging can have
added output, but not less output.
The first part of the patch prevent client PGOPTIONS from lowering the
debug level. The second part adds this new GUC context, then allows it
to be set properly. The tests are in two parts --- the first prevents
non-super users from changing the value inappropriately, and the second
allows postgresql.conf changes to apply to existing backends, i.e. if
postgresql.conf turns logging off via SET, turning it on via
postgresql.conf should propogate to the client, because the client can't
turn something off that the admin wants turned on --- that is the tricky
part that we have to be able to handle the settings in any order.
Peter, how does this look? Is reset_val the proper value to test?
--
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
Index: src/backend/tcop/postgres.c
===
RCS file: /cvsroot/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.346
diff -c -c -r1.346 postgres.c
*** src/backend/tcop/postgres.c 27 May 2003 17:49:46 - 1.346
--- src/backend/tcop/postgres.c 11 Jun 2003 04:29:55 -
***
*** 1921,1927
boolsecure;
int errs = 0;
int debug_flag = 0;
! GucContext ctx;
GucSource gucsource;
char *tmp;
int firstchar;
--- 1921,1927
boolsecure;
int errs = 0;
int debug_flag = 0;
! GucContext ctx, debug_context;
GucSource gucsource;
char *tmp;
int firstchar;
***
*** 1996,2002
/* all options are allowed until '-p' */
secure = true;
! ctx = PGC_POSTMASTER;
gucsource = PGC_S_ARGV; /* initial switches came from command line */
while ((flag = getopt(argc, argv, A:B:c:CD:d:Eef:FiNOPo:p:S:st:v:W:x:-:)) !=
-1)
--- 1996,2002
/* all options are allowed until '-p' */
secure = true;
! ctx = debug_context = PGC_POSTMASTER;
gucsource = PGC_S_ARGV; /* initial switches came from command line */
while ((flag = getopt(argc, argv, A:B:c:CD:d:Eef:FiNOPo:p:S:st:v:W:x:-:)) !=
-1)
***
*** 2033,2057
case 'd': /* debug level */
{
! debug_flag = atoi(optarg);
! /* Set server debugging level. */
! if (atoi(optarg) != 0)
{
! char *debugstr =
palloc(strlen(debug) + strlen(optarg) + 1);
!
! sprintf(debugstr, debug%s, optarg);
! SetConfigOption(log_min_messages,
debugstr, ctx, gucsource);
! pfree(debugstr);
!
}
- else
- /*
-* -d0 allows user to prevent
postmaster debug
-* from propagating to backend. It
would be nice
-* to set it to the postgresql.conf
value here.
-*/
- SetConfigOption(log_min_messages,
notice,
- ctx,
gucsource);
}
break;
--- 2033,2066
case 'd': /* debug level */
{
! /*
!* Client option can't decrease debug
level.
!* We have
Re: [HACKERS] GUC --- prevent non-super user changes
Sorry, I forgot --- this should have gone only to patches. --- Bruce Momjian wrote: Tom Lane wrote: The recent change to make log_min_messages SUSET provokes the following behavior: $ export PGOPTIONS=-d 5 $ psql psql: FATAL: 'log_min_messages': permission denied $ Considering that I *am* superuser, this is quite unacceptable. If you don't want to revert the change, propose another solution. Here is a proposed fix for the new SUSET of various variables. The solution is to create a new GUC context called PGC_USERLIMIT, which limits changes by non-super users. For example, non-super users can turn on logging, but can't turn it off, and log_min_* logging can have added output, but not less output. The first part of the patch prevent client PGOPTIONS from lowering the debug level. The second part adds this new GUC context, then allows it to be set properly. The tests are in two parts --- the first prevents non-super users from changing the value inappropriately, and the second allows postgresql.conf changes to apply to existing backends, i.e. if postgresql.conf turns logging off via SET, turning it on via postgresql.conf should propogate to the client, because the client can't turn something off that the admin wants turned on --- that is the tricky part that we have to be able to handle the settings in any order. Peter, how does this look? Is reset_val the proper value to test? -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] PostgreSQL under Windows
Hi, I'm new in this mailing list and in the world of PostGreSQL. I need to create a C++ application under Windows which will use a very huge database... I was thinking that PostgreSQL could help me to reduce the cost of a such software. But i would like to know what is the status of the PostGreSQL version under Windows ? I mean, i know that some of you are trying to do an installer version under Windows for PostGreSQL and i would like to know if a beta version already exist or not Because i was thinking to build one from my side, but if it already exists, it's better for me. thanks in advance, x04001 __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
