Re: [HACKERS] Dates BC.
On Thu, Dec 18, 2003 at 02:11:20PM +0100, Kurt Roeckx wrote:
I find this a little strange:
select date_part('year', '0002-01-01 BC'::date);
date_part
---
-1
It seems 1 BC and 0 are the same year.
Is there connection between formatting.c and date_part() ?
I don't think so...
In backend/utils/adt/formatting.c:
if (tmfc.bc)
{
if (tm-tm_year 0)
tm-tm_year = -(tm-tm_year - 1);
It this normal or a bug?
I think this code is OK, butg is somethere in extract (date_part) code.
test=# select to_date('0020-01-10 BC'::text, '-MM-DD BC');
to_date
---
0020-01-10 BC
(1 dka)
test=# select to_date('0020-01-10 AD'::text, '-MM-DD BC');
to_date
0020-01-10
test=# select to_char('0020-01-10 BC'::date, '-MM-DD AD');
to_char
---
0020-01-10 BC
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Dates BC.
There is no zero calendar year. The first year of Anno Domini is 1. It's ordinal,
not cardinal.
-Original Message-
From: Karel Zak [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 12:04 AM
To: Kurt Roeckx
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Dates BC.
On Thu, Dec 18, 2003 at 02:11:20PM +0100, Kurt Roeckx wrote:
I find this a little strange:
select date_part('year', '0002-01-01 BC'::date);
date_part
---
-1
It seems 1 BC and 0 are the same year.
Is there connection between formatting.c and date_part() ?
I don't think so...
In backend/utils/adt/formatting.c:
if (tmfc.bc)
{
if (tm-tm_year 0)
tm-tm_year = -(tm-tm_year - 1);
It this normal or a bug?
I think this code is OK, butg is somethere in extract
(date_part) code.
test=# select to_date('0020-01-10 BC'::text, '-MM-DD BC');
to_date
---
0020-01-10 BC
(1 dka)
test=# select to_date('0020-01-10 AD'::text, '-MM-DD BC');
to_date
0020-01-10
test=# select to_char('0020-01-10 BC'::date, '-MM-DD AD');
to_char
---
0020-01-10 BC
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
---(end of
broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Dates BC.
On Fri, Dec 19, 2003 at 01:12:08AM -0800, Dann Corbit wrote:
There is no zero calendar year. The first year of Anno Domini is 1. It's ordinal,
not cardinal.
I agree. But the follow quoted code is not use in date_part() there
Kurt found bug. It's used in to_timestamp() _only_, and it works,
because tm2timestamp() and date2j() work with zero year.
Is there connection between formatting.c and date_part() ?
I don't think so...
In backend/utils/adt/formatting.c:
if (tmfc.bc)
{
if (tm-tm_year 0)
tm-tm_year = -(tm-tm_year - 1);
... tm-tm_year = -(tm-tm_year - 1) is used for:
# select to_timestamp('0001/01/01 BC', '/MM/DD AD');
to_timestamp
0001-01-01 00:00:00 BC
and it's OK.
I think a bug is somewhere in timestamp2tm() which used in next
examples and it's shared between more functions:
# select to_char('0001-01-01 BC'::date, '/MM/DD AD');
to_char
---
/01/01 AD
# SELECT EXTRACT(YEAR from '0001-01-01 BC'::date);
date_part
---
0
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
---(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] Linking with -lc not a good idea
I noticed that pltcl.so is now always linked with -lc. That is normally not a good idea with gcc, because gcc figures out its own order of -lgcc and -lc. If you specify -lc explicitly, then you override -lgcc. I think this change http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/pl/tcl/ Makefile.diff?r1=1.39r2=1.40 needs to be reconsidered. ---(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
[HACKERS] could not found trigger %u
Hi, I have a problem with AFTER INSERT TRIGGER, and ask for your help for resolve of this problem. I want to insert one row in the table with the AFTER INSERT TRIGGER. For this I turn off the AFTER INSERT TRIGGER and do INSERT INTO table_name After that I turn on the AFTER INSERT TRIGGER. It works, but after exit from AFTER INSERT TRIGGER I received exception could not found trigger %u, and in the log file I have the next: -- /*turn off - successfully*/ 2003-12-17 13:25:48 LOG: enabled_trigger(tai_request_nomenclature, false) /*BEFORE INSERT TRIGGER fired in this table - successfully*/ 2003-12-17 13:25:48 LOG: EVENT: The trigger tbi_request BEFORE INSERT ROW fired, table = request oid = 2421194, id in table 257 CONTEXT: PL/pgSQL function tbi_request line 10 at perform PL/pgSQL function tai_request line 78 at SQL statement /*turn off - successfully*/ 2003-12-17 13:25:48 LOG: enabled_trigger(tai_request, true) /*row before leave trigger AFTER INSERT - successfully*/ 2003-12-17 13:25:48 LOG: EVENT: The trigger tai_request AFTER INSERT ROW fired, table = request oid = 2421194, id in table 256 CONTEXT: PL/pgSQL function tai_request line 92 at perform /* ? */ 2003-12-17 13:25:48 ERROR: could not find trigger 1680761888 -- I have PostgreSQL 7.4 compiled from source code on the Linux Redhat 7.3. -- -- AFTER INSERT trigger -- CREATE OR REPLACE FUNCTION tai_request() RETURNS trigger AS' DECLARE ... reserve int4; ... BEGIN ... ... ... -- disable trigger PERFORM enabled_trigger(\'tai_request\', false); raise log \'enabled_trigger(tai_request_nomenclature, false)\'; INSERT INTO request(made_request_id, num_unit) VALUES (new.made_request_id, reserve); -- enable trigger PERFORM enabled_trigger(\'tai_request\', true); raise log \'enabled_trigger(tai_request_nomenclature, true)\'; ... ... ... PERFORM sys_log(\'EVENT: The trigger % % % % fired, table = % oid = %, id in table % \', format_param(TG_NAME) || format_param(TG_WHEN) || format_param(TG_OP) || format_param(TG_LEVEL) || format_param(TG_RELNAME) || format_param(TG_RELID) || format_param(new.id)); --args(%) || format_param(TG_ARGV[])); RETURN new; END; ' LANGUAGE 'plpgsql' VOLATILE; CREATE TRIGGER tai_request AFTER INSERT ON request FOR EACH ROW EXECUTE PROCEDURE tai_request(); -- -- Body of the function enabled_trigger -- CREATE OR REPLACE FUNCTION enabled_trigger(varchar, bool) RETURNS int4 AS' DECLARE trigger_namealias FOR $1; enabled alias FOR $2; table_name varchar(63); ret_val int4; BEGIN -- -- Check trigger name and Get table_name -- SELECT relname INTO table_name FROM pg_class pgc JOIN pg_trigger pgt ON pgt.tgrelid = pgc.oid AND pgt.tgname = trigger_name; IF table_name IS NULL THEN ... -- raise exception ... END IF; UPDATE pg_trigger SET tgenabled = enabled WHERE tgname = trigger_name; UPDATE pg_class SET reltriggers = 0 WHERE relname = table_name; UPDATE pg_class SET reltriggers = (SELECT count(*) FROM pg_trigger WHERE pg_class.oid = tgrelid) WHERE relname = table_name; SELECT oid INTO ret_val FROM pg_trigger WHERE tgname = trigger_name; RETURN ret_val; END; ' LANGUAGE 'plpgsql' STABLE; -- Best regards, Vladimirmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
-Original Message- From: Tom Lane Is there any good reason for this restriction? regression=# begin; BEGIN regression=# declare c cursor for select * from tenk1 for update; ERROR: DECLARE CURSOR ... FOR UPDATE is not supported DETAIL: Cursors must be READ ONLY. Because we haven't supported updatable cursors yet. regards, Hiroshi Inoue ---(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] How can I return a NULL value from a function?
Chongbing Liu [EMAIL PROTECTED] writes: Hello, can you please tell me how to return a NULL value from a function? You can't unless you use the V1 function calling convention. See the programmer's guide. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] replace all with * in pg_hba.conf
On Fri, 19 Dec 2003, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The minimal disturbance change might be to teach the parser to distinguish between a quoted 'all' and an unquoted 'all', and forget the '*' idea. Probably we ought to go with that, on backwards-compatibility grounds. why not do both, but deprecate the use of all in the docs? say with an eventual goal of removing the use of all altogether in 2 releases? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] replace all with * in pg_hba.conf
Marc G. Fournier wrote: On Fri, 19 Dec 2003, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The minimal disturbance change might be to teach the parser to distinguish between a quoted 'all' and an unquoted 'all', and forget the '*' idea. Probably we ought to go with that, on backwards-compatibility grounds. why not do both, but deprecate the use of all in the docs? say with an eventual goal of removing the use of all altogether in 2 releases? The extra value is fairly low IMNSHO if we can distinguish between a magical and a non-magical 'all' - see the patch I just submitted. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Linking with -lc not a good idea
Peter Eisentraut [EMAIL PROTECTED] writes: I noticed that pltcl.so is now always linked with -lc. That is normally not a good idea with gcc, because gcc figures out its own order of -lgcc and -lc. Since no actual problem has been reported, either in 7.4 or in the previous releases that had -lc for many platforms, I'm disinclined to change this in the stable branches. Feel free to take out the -lc in HEAD, though, and we'll see if anyone complains. I cannot recall at the moment if -lc was actually needed on Darwin; if so we could consider adding SHLIB_LINK += -lc in Makefile.shlib's darwin case, as is already done for some other platforms. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] replace all with * in pg_hba.conf
Andrew Dunstan [EMAIL PROTECTED] writes: Marc G. Fournier wrote: why not do both, but deprecate the use of all in the docs? say with an eventual goal of removing the use of all altogether in 2 releases? The extra value is fairly low IMNSHO if we can distinguish between a magical and a non-magical 'all' - see the patch I just submitted. Also, your point about the special sameuser and samegroup keywords is a good one. We should make those all work consistently (ie, quoting makes it not a keyword). Going in the * direction would only make sense if that were the only special case --- but it isn't. I don't think we want to start choosing random symbols for sameuser, samegroup, and other stuff we might think of in future. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] replace all with * in pg_hba.conf
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Marc G. Fournier wrote: why not do both, but deprecate the use of all in the docs? say with an eventual goal of removing the use of all altogether in 2 releases? The extra value is fairly low IMNSHO if we can distinguish between a magical and a non-magical 'all' - see the patch I just submitted. Also, your point about the special sameuser and samegroup keywords is a good one. We should make those all work consistently (ie, quoting makes it not a keyword). Going in the * direction would only make sense if that were the only special case --- but it isn't. I don't think we want to start choosing random symbols for sameuser, samegroup, and other stuff we might think of in future. Right. Revised patch sent to patches list. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposed Query Planner TODO items
Tom, Could we see the actual present query plans for both the TPC-R query and the UNION version? (I'll settle for explain on the slow version, but explain analyze on the other, please.) I'm not going to be able to set this up. I just had to put my server into cold storage due to dismantling my office, and running the TPC stuff on my laptop is a joke. I'll contact the OSDL folks to see if they can run it. -- 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])
[HACKERS] Issue with Linux+Pentium SMP Context Switching
Folks, I brought up this issue a couple of weeks ago on the Performance list. Since then, I've gotten e-mail confirmation from a few other users seeing this problem. Here's the shape of the problem, we just don't know what causes it. I've been trying to do some profiling, but since I only have production systems to work with it's been really slow -- I have to wait for weekly downtime for each test.I'm hoping that someone with a greater knowledge of Linux Kernel internals and a good test machine can help out. Linux Versions Reported: RH and Gentoo reported, Kernels 2.4.18 to 2.4.22 Not tested on other distros/kernels. Kernels are SMP-enabled. Hardware: Intel Pentium III and 4 dual-processor systems. 5 of the 6 reported machines are made by Dell; the other is a home-build. Demonstrated on both hyper-threaded and non-hyperthreaded Xeons; Cannot be reproduced on Athalons. Description of the Problem: When a query is made against a table with millions of rows that requires a seq scan, large hash join, per-row calculations or other intensive operation, the system climbs to tens or hundreds of thousands of context switches per second (contrast with, for example, 5000cs/second on AthalonMP). This hurts performance significantly, possibly up to doubling query execution time. Initial debug logging of a test on one Xeon system demonstrating this issue showed a very large number of unattributed semop() calls. We are still following up on this. In discussions with Linux kernel hackers online, they blame the way that PostgreSQL uses shared memory. Whether or not they are correct, the effect of the issue is to harm PostgreSQL's performance and make us look bad on one of the major enterprise systems of choice: the multi-processor Xeon system. Ideas, anyone? -- 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] Issue with Linux+Pentium SMP Context Switching
On Fri, Dec 19, 2003 at 10:30:13AM -0800, Josh Berkus wrote: Linux Versions Reported: RH and Gentoo reported, Kernels 2.4.18 to 2.4.22 Not tested on other distros/kernels. Kernels are SMP-enabled. Does the same problem show with an SMP kernel on an UP system? When a query is made against a table with millions of rows that requires a seq scan, large hash join, per-row calculations or other intensive operation, the system climbs to tens or hundreds of thousands of context switches per second (contrast with, for example, 5000cs/second on AthalonMP). This is without any other query running, right? I even find 5000 cs/s rather large if there isn't any other process that wants some CPU. In discussions with Linux kernel hackers online, they blame the way that PostgreSQL uses shared memory. To me this can only make sense in case there is an other backend trying to use the same memory, and it needs to be moved from 1 CPU to an other. Kurt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] *sigh*
Christopher Browne [EMAIL PROTECTED] wrote in
comp.databases.postgresql.hackers:
Martha Stewart called it a Good Thing when Randolf Richardson [EMAIL PROTECTED]
wrote:
[sNip]
What about queueing all these updates for a separate
low-priority thread? The thread would be the only one with access
to update this field.
If updates are queued, then how do you get to use them if the
update thread isn't running because it's not high enough in
priority?
That would be an administration issue. This background process would
need to have enough priority in order for this to be functional, yet could
also be completely disabled by administrators who know their systems don't
need to use count(*) at all.
Also, if the thread was well-designed, then it could combine all the
queued entries for a single table first in order to reduce disk I/O when
updating each table.
I am not being facetious.
Oh, I see that. Don't worry, I know better than to take things
personally on newsgroups -- go ahead and be blunt if you like. =D
The one way that is expected to be successful would be to have a
trigger that, upon seeing an insert of 5 rows to table ABC, puts,
into table count_detail, something like:
insert into count_detail (table, value) values ('ABC', 5);
You then replace
select count(*) from abc;
with
select sum(value) from count_detail where table = 'ABC';
The low priority thread would be a process that does something akin
to vacuuming, where it would replace the contents of the table every
so often...
for curr_table in (select table from count_detail) do
new_total = select sum(value) from count_detail
where table = curr_table;
delete from count_detail where table = curr_table;
insert into count_detail (table, value) values (curr_table,
new_total);
done
The point of this being to try to keep the number of rows to 1 per
table.
Interesting. A different way of solving the same problem, but
wouldn't it require more disk I/O on the table being updated then a
separate tracker would?
Note that this gets _real_ expensive for tables that see lots of
single row inserts and deletes. There isn't a cheaper way that will
actually account for the true numbers of records that have been
committed.
For a small table, it will be cheaper to walk through and calculate
count(*) directly from the tuples themselves.
The situation where it may be worthwhile to do this is a table which
is rather large (thus count(*) is expensive) where there is some
special reason to truly care how many rows there are in the table.
For _most_ tables, it seems unlikely that this will be true. For
_most_ tables, it is absolutely not worth the cost of tracking the
information.
Ah, but that's the point -- do we truly care how many rows are in the
table, or is the purpose of count(*) to just give us a general idea?
This statistic would be delayed because it's being updated by a
background process, thus count won't always be accurate, but at least it
won't be slow -- it could be the fastest count in the industry! =)
--
Randolf Richardson - [EMAIL PROTECTED]
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What's the difference between int2 and int16?
William ZHANG [EMAIL PROTECTED] wrote in comp.databases.postgresql.hackers: I found the uses of int2, int16 and other similiar types misleading in PostgreSQL's source code. Sometime it is difficult to figure out which should be prefered. Maybe int2, int4, and int8 refer to database types, while int16, int32 and int64 refer to C data types. If this is the convention, maintenance may be easier. There's no difference: smallint = int2 = int16 integer = int4 = int32 largeint = int8 = int64 The single-digit types represent the number of bytes used to store the data, while the double-digit types represne the number if bits. -- Randolf Richardson - [EMAIL PROTECTED] Vancouver, British Columbia, Canada Please do not eMail me directly when responding to my postings in the newsgroups. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] *sigh*
[EMAIL PROTECTED] (Mark Kirkwood) wrote in comp.databases.postgresql.hackers: [sNip] How about: Implement a function estimated_count that can be used instead of count. It could use something like the algorithm in src/backend/commands/analyze.c to get a reasonably accurate psuedo count quickly. The advantage of this approach is that count still means (exact)count (for your xact snapshot anyway). Then the situation becomes: Want a fast count? - use estimated_count(*) Want an exact count - use count(*) I think this is an excellent solution. -- Randolf Richardson - [EMAIL PROTECTED] Vancouver, British Columbia, Canada Please do not eMail me directly when responding to my postings in the newsgroups. ---(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] Issue with Linux+Pentium SMP Context Switching
Kurt, This is without any other query running, right? I even find 5000 cs/s rather large if there isn't any other process that wants some CPU. Sorry! Darn! Important fact left out of the problem description: The issue happens when *two or more* intensive queries are running simultaneosly. To me this can only make sense in case there is an other backend trying to use the same memory, and it needs to be moved from 1 CPU to an other. Yes. See above. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] How can I return a pointer to a use structure from a function
Thank you very much for your help. In V1 function calling convention, there are micros like PG_RETURN_TEXT_P and so on. Most of them are used to return values of the built-in datatypes. If I want the XXX_in function (for my own data type) to return a pointer to a particular structure, what micro should I use? i.e., how should I organize the return value? Thank you and wish you and everybody a merry Christmas. Chongbing On Fri, 19 Dec 2003, Tom Lane wrote: Chongbing Liu [EMAIL PROTECTED] writes: Hello, can you please tell me how to return a NULL value from a function? You can't unless you use the V1 function calling convention. See the programmer's guide. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Issue with Linux+Pentium SMP Context Switching
Josh Berkus wrote: Initial debug logging of a test on one Xeon system demonstrating this issue showed a very large number of unattributed semop() calls. We are still following up on this. Postgres has it's own user space spinlock and semaphore implementation. Both fall back to semop if there is contention. Hmm. You wrote that the problem is Xeon specific, and that AthlonMP are unaffected. Perhaps Xeon cpus do not like the s_lock implementation? It doesn't follow Intel's recommentations: - no pause instructions. - always TAS. The recommended approach is nonatomic tests until the value is 0, then an atomic TAS. Attached is a gross hack that adds pause instructions. If this doesn't magically fix your problem, then we must figure out what causes the semop calls, and avoid them. Could you ask your Linux hackers why they blame the shared memory implementation in postgres? I don't see any link between shared memory and lock contention. -- Manfred Index: backend/storage/lmgr/s_lock.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/lmgr/s_lock.c,v retrieving revision 1.16 diff -c -r1.16 s_lock.c *** backend/storage/lmgr/s_lock.c 8 Aug 2003 21:42:00 - 1.16 --- backend/storage/lmgr/s_lock.c 19 Dec 2003 20:01:33 - *** *** 111,116 --- 111,117 spins = 0; } + __asm__ __volatile__(rep;nop\n: : : memory); } } ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] How can I return a pointer to a use structure from a function
Chongbing Liu [EMAIL PROTECTED] writes: If I want the XXX_in function (for my own data type) to return a pointer to a particular structure, what micro should I use? You can just use PG_RETURN_POINTER if you're feeling lazy. PG_RETURN_TEXT_P and other wrappers around PG_RETURN_POINTER exist mainly as a simple form of documentation. If you like that kind of documentation you can define your own GET and RETURN macros for your own datatype (look in fmgr.h for examples). If you don't, don't bother. 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] Proposed Query Planner TODO items
I'm not going to be able to set this up. I just had to put my server into cold storage due to dismantling my office, and running the TPC stuff on my laptop is a joke. I'll contact the OSDL folks to see if they can run it. We can... depending on what you need for a server. J -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [BUGS] pg_service.conf ignores dbname parameter
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Regardless of this particular issue, I think it would be useful if, under some conditions to be identified, some service were taken as default if nothing is specied in libpq. That would eliminate the need to set environment variables, which is undesirable in many situations. That's a thought. Maybe if pg_service.conf exists and contains a section named default, we use whatever settings are present there? (Obviously we'd not want the dbname to be forced by this, but I think we've already agreed to get rid of that behavior.) About the only downside I can see to this is that every connection would incur the overhead of an attempted file opening. That might be thought to be too much overhead, at least by people who have no use for the feature. But in comparison to what will happen on the server side during backend startup, it's probably pretty negligible. BTW, why is it that pg_service.conf is system-wide? Personally I'd think it more useful to seek settings in ~/.pg_service.conf. Perhaps the solution is to allow an environment variable to point to the services file. That way, you only look for the file if that variable exists. This would also have to be defined for any service file usage, so maybe this is bad. -- 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] [BUGS] pg_service.conf ignores dbname parameter
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: BTW, why is it that pg_service.conf is system-wide? Personally I'd think it more useful to seek settings in ~/.pg_service.conf. Perhaps the solution is to allow an environment variable to point to the services file. Peter was after a no-environment-variable solution, so I don't think he'll like that one. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ecpg tests compile failure
I have applied the following patches to CVS HEAD and 7.4.X to suppress the ecpg thread test if they didn't enable threads via configure. I also cleaned up the tools/thread test because this is to be used before you have your OS running threads via configure. --- Dave Cramer wrote: Bruce, You are correct. I did not configure with --enable-thread-safety Dave On Thu, 2003-12-18 at 08:40, Bruce Momjian wrote: Dave Cramer wrote: Shridhar, Obviously not, but I just did make inside the test directory, so I assume the Makefile needs to be fixed. Thanks, Dave On Thu, 2003-12-18 at 07:21, Shridhar Daithankar wrote: On Thursday 18 December 2003 17:37, Dave Cramer wrote: test_thread.pgc:51: undefined reference to `pthread_create' undefined reference to `pthread_join' It is not linking against pthreads library. Do you have -lpthread cause in your compilation/linking command? The ecpg/test/Makefile has: override CPPFLAGS := -I$(srcdir)/../include -I$(libpq_srcdir) $(CPPFLAGS) $(THREAD_CPPFLAGS) and %: %.o $(CC) $(CFLAGS) $(LDFLAGS) -L../ecpglib -L ../pgtypeslib -L../../libpq $^ $(LIBS) -lpgtypes -lecpg -lpq $(THREAD_LIBS) -o $@ so I see the thread compile and link flags mentioned in the Makefile. My guess is that you didn't compile the backend with --enable-thread-safety. I wonder if I should disable the thread ecpg test program when this compile option is not used. Is that correct? ---(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 Index: src/Makefile.global.in === RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v retrieving revision 1.171 diff -c -c -r1.171 Makefile.global.in *** src/Makefile.global.in 29 Nov 2003 19:51:39 - 1.171 --- src/Makefile.global.in 19 Dec 2003 23:21:45 - *** *** 121,127 # # Records the choice of the various --enable-xxx and --with-xxx options. - with_threads = @with_threads@ with_java = @with_java@ with_perl = @with_perl@ with_python = @with_python@ --- 121,126 *** *** 131,136 --- 130,136 enable_rpath = @enable_rpath@ enable_nls= @enable_nls@ enable_debug = @enable_debug@ + enable_thread_safety = @enable_thread_safety@ python_includespec= @python_includespec@ python_libspec= @python_libspec@ Index: src/interfaces/ecpg/test/Makefile === RCS file: /cvsroot/pgsql-server/src/interfaces/ecpg/test/Makefile,v retrieving revision 1.42 diff -c -c -r1.42 Makefile *** src/interfaces/ecpg/test/Makefile 29 Nov 2003 19:52:09 - 1.42 --- src/interfaces/ecpg/test/Makefile 19 Dec 2003 23:21:46 - *** *** 8,14 ECPG = ../preproc/ecpg -I$(srcdir)/../include ! TESTS = test1 test2 test3 test4 perftest dyntest dyntest2 test_notice test_code100 test_init testdynalloc num_test dt_test test_informix test_thread all: $(TESTS) --- 8,17 ECPG = ../preproc/ecpg -I$(srcdir)/../include ! TESTS = test1 test2 test3 test4 perftest dyntest dyntest2 test_notice test_code100 test_init testdynalloc num_test dt_test test_informix ! ifeq ($(enable_thread_safety), yes) ! TESTS += test_thread ! endif all: $(TESTS) Index: src/tools/thread/thread_test.c === RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v retrieving revision 1.5 diff -c -c -r1.5 thread_test.c *** src/tools/thread/thread_test.c 29 Nov 2003 19:52:14 - 1.5 --- src/tools/thread/thread_test.c 19 Dec 2003 23:21:47 - *** *** 20,29 *- */ - - #ifdef ENABLE_THREAD_SAFETY #include pthread.h - #endif #include unistd.h #include stdio.h #include stdlib.h --- 20,26 ---(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] [BUGS] pg_service.conf ignores dbname parameter
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: BTW, why is it that pg_service.conf is system-wide? Personally I'd think it more useful to seek settings in ~/.pg_service.conf. Perhaps the solution is to allow an environment variable to point to the services file. Peter was after a no-environment-variable solution, so I don't think he'll like that one. I thought he was more concerned about removing envirnment variables that have to be tuned for each user. Let's see how he responds. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Project status pages
Robert Treat wrote: Wasn't there a patch posted many months ago for PITR. IIRC it wasn't complete, but would be a good starting point for those interested in helping out. If it's in the archives it would be nice to add a link to it on the project page... which brings up the question on whats the process for updating these pages? Perhaps they should be moved into the wiki framework up on techdocs? They are just web pages. If someone want to set up wiki and pull the content, I can remove my versions. -- 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] Issue with Linux+Pentium SMP Context Switching
On Fri, Dec 19, 2003 at 11:17:31AM -0800, Josh Berkus wrote: Important fact left out of the problem description: The issue happens when *two or more* intensive queries are running simultaneosly. So two queries are enough to get this problem? I assume the tables are so big that they don't fit in shared memory and it needs to go read in the data? So that the problem only shows itself when it needs to replace buffers? If it doesn't have to go read, do you still have the problem? Kurt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Issue with Linux+Pentium SMP Context Switching
On Saturday 20 December 2003 00:00, Josh Berkus wrote: In discussions with Linux kernel hackers online, they blame the way that PostgreSQL uses shared memory. Whether or not they are correct, the effect of the issue is to harm PostgreSQL's performance and make us look bad on one of the major enterprise systems of choice: the multi-processor Xeon system. Two suggestions.. 1. Patch linux kernel for HT aware scheduler. 2. Try running Xeons in HTdisabled modes. See if that helps. I would say using 2.6 on it is recommended anyways.. If possible of course.. Shridhar ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
