Re: [HACKERS] Call for 7.5 feature completion
David Garamond wrote: Robert Treat wrote: Given that the cygwin version is currently labeled as not ready for production I would say you are right. The truth is that many will never declare win32 good for production simply because of the OS it runs on, but we still want to make it as solid as possible. People _do_ use postgresql+cygwin in production environments though (see the pgsql-cygwin archive). And I suspect people _will_ use 7.5 for win32 in production, despite the release notes and the website clearly saying it's not production ready. Why? 1) The version number is 7.5 and many people will presume the ports are more or less equal in quality/maturity since they have the same version number; 2) People don't read release notes. See the various reviews on the recently released Fedora Core 2, complaining about how it doesn't support MP3 or DVD playback, despite the [legal] issues having been known and documented since Red Hat 8. Strangely enough, these people (who don't read release notes) _do_ write public reviews. They will badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being much much more rock solid, etc etc. I suggest we label the win32 port as 7.5 ALPHA or 7.5 DANGEROUS :-) My concern is about the fact the fact that Postgresql rely on the OS about his ability to optimize memory access. Do we have any possibility at this stage to compare Postgresql performance on top of Win32 with other products for this platform ? I think that Postgresql with this version is going to address a specific class of final users that right now are using what ? I don't think the response is: users that now are using postgresql+cygwin. Can the first version of postgresql for Win32 compared with other products? I really hope yes, you know: there is no a *second* possibility to do a *first* good impression. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS HEAD: make install broken for vpath
Neil Conway [EMAIL PROTECTED] writes: With current sources, it appears that vpath builds (i.e. separate source and build trees) are broken. make succeeds, but make install produces: I can't take the time right now to test it, but try changing TZDATAFILES := $(TZDATA:%=data/%) to TZDATAFILES := $(TZDATA:%=$(srcdir)/data/%) in src/timezone/Makefile. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] New horology failure
I get this since Tom's commit. Chris --- ./results/horology.out Sun May 23 11:39:49 2004 *** *** 1787,1796 | Wed Mar 15 13:14:02 2000 PST | @ 34 years| Tue Mar 15 13:14:02 1966 PST | Sun Dec 31 17:32:01 2000 PST | @ 34 years| Sat Dec 31 17:32:01 1966 PST | Mon Jan 01 17:32:01 2001 PST | @ 34 years| Sun Jan 01 17:32:01 1967 PST ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years| Fri Sep 22 18:19:20 1967 PDT ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 12:00:00 1969 PDT ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri Aug 01 00:00:00 1969 PDT ! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed Oct 01 00:00:00 1969 PDT | Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon Dec 22 00:00:00 1969 PST | Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST | Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed Dec 31 19:00:00 1969 PST --- 1787,1796 | Wed Mar 15 13:14:02 2000 PST | @ 34 years| Tue Mar 15 13:14:02 1966 PST | Sun Dec 31 17:32:01 2000 PST | @ 34 years| Sat Dec 31 17:32:01 1966 PST | Mon Jan 01 17:32:01 2001 PST | @ 34 years| Sun Jan 01 17:32:01 1967 PST ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years| Fri Sep 22 18:19:20 1967 PST ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 12:00:00 1969 PST ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri Aug 01 00:00:00 1969 PST ! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed Oct 01 00:00:00 1969 PST | Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon Dec 22 00:00:00 1969 PST | Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST | Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed Dec 31 19:00:00 1969 PST ---(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] zero-column table behavior
Does the following zero-column behavior strike anyone else as being a little strange? I can take a look at fixing this, I'm just curious if there's a consensus that the status quo isn't optimal. (1) neilc=# create table zero_col (); CREATE TABLE neilc=# select * from zero_col; -- (0 rows) -- Why is there a blank line before the -- that indicates the -- end of the result set? That seems inconsistent with the way -- we present a normal empty result set: neilc=# create table abc (a int); CREATE TABLE neilc=# select * from abc; a --- (0 rows) (2) neilc=# insert into zero_col default values; INSERT 17218 1 neilc=# insert into zero_col default values; INSERT 17219 1 neilc=# select * from zero_col; -- (2 rows) -- If the result set contains two rows, ISTM the psql output -- should emit either two or three blank lines before the -- -- that indicates the end of the result set (3) neilc=# select * from zero_col order by random(); ERROR: ORDER/GROUP BY expression not found in targetlist -- ISTM that ought to work (4) neilc=# create view zero_col_view as select * from zero_col; ERROR: view must have at least one column -- ISTM that ought to work as well: if we allow zero-column tables, -- is there a good reason for disallowing zero-column views? -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Database variables when copying a database
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Anyone thought about this at all yet? It seems to me that we shouldn't copy them, but I'm having a hard time putting a finger on why exactly. I guess it goes along with the fact that we don't copy the database's owner, and any per-database variable settings seem to me to be the database owner's decision to make. Also I refer you to the point made in the manual that CREATE DATABASE is not intended to be a COPY DATABASE facility. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Database variables when copying a database
It seems to me that we shouldn't copy them, but I'm having a hard time putting a finger on why exactly. I guess it goes along with the fact that we don't copy the database's owner, and any per-database variable settings seem to me to be the database owner's decision to make. Good points. The reason I ran into this is because I basically did use it as a copy database command to make a development copy of an in-use database for a developer to mess with. However, somethings turned out to be broken as it had lost the custom search_path we had set on the database that made stuff work. It occurred to me that it was probably somethign that had not been thought of when db variables were invented, rather than somethign deliberately avoided. Chris ---(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] Latest requests from IRC
Hi guys, The latest thing we've noticed in the IRC channel and the phpPgAdmin lists is that people want to be able to grant on all objects in a database, etc: grant select on all tables to blah; or even: grant rule on all views in schema myschema to blah; This seriously is asked every other day on #postgresql, followed by us saying they have to write a stored proc to do it, followed by them saying that that's crap... The obvious trick here is what do do if you aren't a grantor for that privilege. I confess I find this an annoying omission also... Chris ---(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] Call for 7.5 feature completion
We could perhaps do something similar to the Apache 1.3 win platform notes, where they (still) say *something* like : Apache on windows is not as stable as on unix... but is being actively improved all the time This is a bit more positive than it's dangerous!. As for people not reading the release notes - we could display the platform note (or an href to it) prominently on the download page (they may still not read that...but it has become a matter of choice at that point...). regards Mark David Garamond wrote: Robert Treat wrote: Given that the cygwin version is currently labeled as not ready for production I would say you are right. The truth is that many will never declare win32 good for production simply because of the OS it runs on, but we still want to make it as solid as possible. People _do_ use postgresql+cygwin in production environments though (see the pgsql-cygwin archive). And I suspect people _will_ use 7.5 for win32 in production, despite the release notes and the website clearly saying it's not production ready. Why? 1) The version number is 7.5 and many people will presume the ports are more or less equal in quality/maturity since they have the same version number; 2) People don't read release notes. See the various reviews on the recently released Fedora Core 2, complaining about how it doesn't support MP3 or DVD playback, despite the [legal] issues having been known and documented since Red Hat 8. Strangely enough, these people (who don't read release notes) _do_ write public reviews. They will badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being much much more rock solid, etc etc. I suggest we label the win32 port as 7.5 ALPHA or 7.5 DANGEROUS :-) ---(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] Unicode upper/lower solution proposal
Hi all, Disclaimer: I'm not a C programmer and my knowledge of locales is limited. I use Python. PostgreSQL does not correctly use upper() and lower() for Unicode characters. I've read the bug reports and followups at archive.postgresql.org. I'd like to propose two ideas: 1) Python has upper() and lower() functions, and they work in Unicode perfectly. With Python being open source, could PostgreSQL developers pick Python developer's brains? Is Python using only standard C library calls to do its Unicode upper/lower conversion? Could the relevant part of Python source code serve as a starting point of implementing Unicode upper/lower in Postgres? 2) Arbitrary collation support for PostgreSQL is available at http://www.fi.muni.cz/~adelton/l10n/ and it works perfectly. Could it be used to implement Unicode upper/lower in Postgres? -- Milos Prudek ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Syntax question
Here are the two syntaxes we can use for turning off clustering: 1) ALTER TABLE / SET WITHOUT CLUSTER This will turn off clusting on any index on the table that has it enabled. It won't recurse so as to match the CLUSTER ON syntax. However, this form makes the non-standardy SET WITHOUT form more emphasised... 2) ALTER TABLE / DROP CLUSTER ON idx I like this form, however to make it work, we need to bump CLUSTER to being a reserved keyword. This form looks more like SQL standard, and is related to the CLUSTER ON form. Which one do we want? Chris ---(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] Clean-up callbacks for non-SR functions
On 05/21/04:20/5, Tom Lane wrote: Hm. I do not think you can use an expression context callback for this anyway, because the callback won't be called in the case that query execution is abandoned due to an error. What you'd need for something like that is a global data structure that is traversed at transaction commit/abort and tells you which PyObjects you are holding refcounts on. Indeed. I was planning to implement something along those lines for that case at a later point in time, just wasn't sure when the cleanup should occur, and how it was to be triggered at that time. I still have reservations about the temporary leakage, but I can't help but think that a solution to that is likely cost more than its worth. I can't imagine anything other than an explicit end of usage callback function stored in FmgrInfo that takes fn_extra as an argument, and this would still require ERROR handling... You might want to look at plpgsql's plpgsql_eoxact() function for something vaguely similar. Aye! Thanks for pointing me at EOXact! It's quite the perfect point to cleanup my fn_extra usage. I think that it is quite reasonable to specify that inter-transaction usage of the feature to be forbidden; thus further qualifying it as an appropriate cleanup point. Disqualifying my own idea: AFA free-hooks are concerned, it is clear to me now that they are BAD for my application, as it assumes FmgrInfo is allocated by Postgres's memory manager, and after a quick grep I see that FmgrInfo is statically declared/allocated is many places.. -- Regards, James William Pye pgpGrvIR3fGuo.pgp Description: PGP signature
Re: [HACKERS] zero-column table behavior
Neil Conway [EMAIL PROTECTED] writes: Does the following zero-column behavior strike anyone else as being a little strange? I can take a look at fixing this, I'm just curious if there's a consensus that the status quo isn't optimal. I think that psql's table-pretty-printing logic gets slightly confused when there are zero columns. It's never seemed high enough priority to worry about to me, but if you wanna take a look, go for it. neilc=# select * from zero_col order by random(); ERROR: ORDER/GROUP BY expression not found in targetlist -- ISTM that ought to work I agree, that's a bug (and a weird one). I will look at this one. neilc=# create view zero_col_view as select * from zero_col; ERROR: view must have at least one column -- ISTM that ought to work as well: if we allow zero-column tables, -- is there a good reason for disallowing zero-column views? I'm not sure if that error is just overzealousness or if it is protecting some implementation assumption. Try removing the error check and see if things work or not ... 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] New horology failure
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I get this since Tom's commit. On what platform? How is type time_t defined on your platform? 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] Latest requests from IRC
On Sun, May 23, 2004 at 12:00:29 +0800, Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Hi guys, The latest thing we've noticed in the IRC channel and the phpPgAdmin lists is that people want to be able to grant on all objects in a database, etc: The right way to do this is to make sure there is a group that has access to everything and just add people to the group. Of, course it might be nice if there was a contrib function that made such a group in case you have gotten pretty far without doing any grants. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Syntax question
Christopher Kings-Lynne [EMAIL PROTECTED] writes: 2) ALTER TABLE / DROP CLUSTER ON idx I like this form, however to make it work, we need to bump CLUSTER to being a reserved keyword. I do not think this form is enough better than the other to justify creating a nonstandard fully-reserved word. I'd go with SET WITHOUT. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Unicode upper/lower solution proposal
Milos Prudek [EMAIL PROTECTED] writes: PostgreSQL does not correctly use upper() and lower() for Unicode characters. This is already fixed in CVS tip. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Latest requests from IRC
Bruno Wolff III [EMAIL PROTECTED] writes: Christopher Kings-Lynne [EMAIL PROTECTED] wrote: ... people want to be able to grant on all objects in a database, etc: The right way to do this is to make sure there is a group that has access to everything and just add people to the group. Doesn't seem like that magically solves the problem, though. You still have lots of pain involved in granting privs on everything to that group. I don't have any fundamental problem with something like GRANT SELECT ON TABLE * TO foo, seeing as how we already allow grants on multiple tables. But we'd have to be very careful about how the scope of the * wildcard is defined. For instance, if a superuser does it, does it really grant privs on *all* tables? I'd hope that the system catalogs, at least, are not implicitly included in the wildcard scope. For lesser mortals there is also the question of whether to error out or just ignore tables that you don't have privileges for. Would it make sense to restrict the wildcard to a particular schema, viz GRANT SELECT ON TABLE myschema.* TO foo This would neatly solve the question of how to exclude the system catalogs, and in most scenarios where people are wishing for this, I bet they've put all the objects in one schema anyway. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Unicode upper/lower solution proposal
This is already fixed in CVS tip. Oh, cool! I know what is a CVS, but what is CVS tip? In which PostgreSQL stable release is upper() and lower() for Unicode planned to be included? Postgres version 7.5 ? -- Milos Prudek ---(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]
On Sat, 2004-05-22 at 23:44, Mark Kirkwood wrote: We could perhaps do something similar to the Apache 1.3 win platform notes, where they (still) say *something* like : Apache on windows is not as stable as on unix... but is being actively improved all the time This is a bit more positive than it's dangerous!. Yes it's more positive, but I think there is more danger associated with an untested database enviornment than an untested web server. Apache might crash, but it probably won't eat your data. As for people not reading the release notes - we could display the platform note (or an href to it) prominently on the download page (they may still not read that...but it has become a matter of choice at that point...). There will always be people who won't read the notes, or ignore the notes, as there will always be people doing all sorts of stupid things that we can't protect them from. There is only so much we can and should do to protect these types of people. I think if we just make sure we warn people in several places so that anyone who does read the release notes will find it. Matthew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fixing the Turkish problem
Hi, On Thu, 6 May 2004, Tom Lane wrote: We're sort of halfway there on coping with the Turkish-locale i-vs-I problem. I'd like to finish the job for 7.5. Cool! snip AFAICS the remaining problem is that there are a bunch of places that use strcasecmp() or strncasecmp() to match inputs against locally known keywords (such as datestyle or timezone names). We need to make a variant version of strcasecmp that uses this same style of case-folding. What I'm thinking of doing is inventing pg_strcasecmp and pg_strncasecmp that act like the above and replacing all calls of the standard library functions with these. If you can post all the patches you'd like to apply, I'd be happy to test them. (Sorry for the very late response, btw.) Regards, -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.TDMSoft.com http://www.gunduz.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS]
Matthew T. O'Connor [EMAIL PROTECTED] writes: There will always be people who won't read the notes, or ignore the notes, Does anyone want to contemplate hacking things so that the Windows port reports a different version number? 0.1 might give people the right sort of impression about what we think of that port's stability ... 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] Fixing the Turkish problem
Devrim GUNDUZ [EMAIL PROTECTED] writes: On Thu, 6 May 2004, Tom Lane wrote: What I'm thinking of doing is inventing pg_strcasecmp and pg_strncasecmp that act like the above and replacing all calls of the standard library functions with these. If you can post all the patches you'd like to apply, I'd be happy to test them. (Sorry for the very late response, btw.) The patches are in; please give CVS tip a shot and see what you think. It passed regression tests in a Turkish locale for me. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fixing the Turkish problem
Hi, On Sun, 23 May 2004, Tom Lane wrote: pg_strncasecmp that act like the above and replacing all calls of the standard library functions with these. If you can post all the patches you'd like to apply, I'd be happy to test them. (Sorry for the very late response, btw.) The patches are in; please give CVS tip a shot and see what you think. It passed regression tests in a Turkish locale for me. Yes, it solves the initdb bug #1133. Thanks. However, we still fail to sort small I (i dotless) and i. i dotless comes before i in Turkish Alphabet, but ORDER BY sorts i before i dotless. I would post a sample, but I'm not sure that anyone on the list could view it :) Regards, -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.TDMSoft.com http://www.gunduz.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] eval function
Bruno Wolff III [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
... people want to be able to grant on all objects in a
database, etc:
For things like this I use simple,
but super-powerful eval function:
CREATE OR REPLACE FUNCTION eval(text)
RETURNS int4
VOLATILE
LANGUAGE 'plpgsql'
SECURITY INVOKER
AS 'DECLARE
body ALIAS FOR $1;
result INT;
BEGIN
EXECUTE body;
GET DIAGNOSTICS result = ROW_COUNT;
RETURN result;
END;
';
Then you say something like:
SELECT eval('GRANT SELECT ON TABLE '||TABLE_NAME||' TO PUBLIC')
FROM INFORMATION_SCHEMA.TABLES
WHERE schema_name=current_schema()
AND type_type='BASE TABLE';
Also works great for other similar operations, such as
renaming, changing owners, etc... anything you can
generate with SQL, which is quite a lot, really.
Is this considered ok or extreme abuse?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Timezone fun (bugs and a request)
I'm looking at the new timezone support. First I initdb'd without TZ set. So every time I start the server I get LOG: could not recognize system timezone, defaulting to Etc/GMT-4 HINT: You can specify the correct timezone in postgresql.conf. Obviously the setup is wrong because DST doesn't work: alvherre=# select '2004-03-13 10:00:00'::timetz; timetz - 10:00:00+04 (1 fila) alvherre=# select '2004-03-14 10:00:00'::timetz; timetz - 10:00:00+04 (1 fila) alvherre=# set TimeZone to 'Chile/Continental'; SET alvherre=# select '2004-03-13 10:00:00'::timetz; timetz - 10:00:00-03 (1 fila) alvherre=# select '2004-03-14 10:00:00'::timetz; timetz - 10:00:00-04 (1 fila) Note I get +4 on the default zone and -4 on the correct zone. I think this is a bug. So I went and set it in postgresql.conf, timezone = 'Chile/Continental' After this, DST works correctly, but I continue to receive the LOG message above. I think it should be supressed. I then changed postgresql.conf to read timezone = unknown (the difference with the original setting is that the line isn't commented). The server now behaves different; the timezone is set to GMT rather than being guessed from system settings. I think they should work the same. I also want to be able to specify a non-default timezone and get a time with the correct displacement. CLT is abbreviation for Chile/Continental, and CLST is the summer timezone. alvherre=# select '10:00:00'::time at time zone 'CLT'; timezone - 10:00:00-04 (1 fila) alvherre=# select '10:00:00'::time at time zone 'CLST'; timezone - 11:00:00-03 (1 fila) alvherre=# select '10:00:00'::time at time zone 'Chile/Continental'; ERROR: el huso horario chile/continental no es reconocido I would like to get the time in the corresponding zone, without me having to know in advance whether I'm in current DST or not. Is this possible? For example I want to know what's the current time in 'Europe/Madrid'. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente ---(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] Fixing the Turkish problem
Devrim GUNDUZ [EMAIL PROTECTED] writes: However, we still fail to sort small I (i dotless) and i. i dotless comes before i in Turkish Alphabet, but ORDER BY sorts i before i dotless. For that, you have to complain to your locale's designer. We just do what strcoll tells us to. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timezone fun (bugs and a request)
Alvaro Herrera [EMAIL PROTECTED] writes: First I initdb'd without TZ set. So every time I start the server I get LOG: could not recognize system timezone, defaulting to Etc/GMT-4 HINT: You can specify the correct timezone in postgresql.conf. So what is your system timezone anyway (and what's the platform)? I then changed postgresql.conf to read timezone = unknown (the difference with the original setting is that the line isn't commented). The server now behaves different; the timezone is set to GMT rather than being guessed from system settings. I think they should work the same. Hmm, that's strange. I thought they would work the same. Will look into it. alvherre=# select '10:00:00'::time at time zone 'Chile/Continental'; ERROR: el huso horario chile/continental no es reconocido This is functionality that never has existed. We have perhaps some chance of coding it now, but it's not a trivial bug fix. The main problem is that the timezone library API is still based around a global tzset() setting. We need it to be able to deal with timezone definitions that are loaded (hopefully only once) but not selected as the program-wide default. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] I am back
I am back from camping and will be reading my email during the next few 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] relcache refcount
On Sat, May 15, 2004 at 02:08:39PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Regarding the lock mechanism, I simply added some code to LockReleaseAll so it gets the array of committed child Xids; on subtransaction abort, the whole lock struct is scanned just like it's done on main transaction abort; only those locks affiliated with one of the given Xids are released. This is naive, so if it's incorrect please comment. Another and perhaps simpler way would be to leave the release code alone, but on subtransaction commit scan through the lock structs and re-mark locks held by the subtrans as being held by the parent. I think these are isomorphic functionally. The second way feels like it would be faster (no inner loop over child XIDs). The problem is that the Xid is part of the locktag (which is the hash key) as far as I can tell, so relabeling means I have to delete the lock from the hashtable and then insert it again with the new tag. I don't think this is a good idea. (I found this out the hard way: I was getting proclock hashtable corrupted when finishing a subtransaction after relabeling the locks). On the other hand, if your current code does not require scanning the lock structures at all on subtrans commit, it's probably not a win to add such a scan. Nope, it doesn't. The lock algorithms must be able to tell when two lock requests are coming from the same backend. At present I think this relies on comparing XIDs, which is not going to work if you label subtrans locks with subtrans XIDs. How are you thinking about handling that? Nope, it doesn't compare Xids. That code actually looks up locks through the PGPROC struct (procHolders), so the current Xid does not affect it. Deadlock detection works without changing the code at all. It took me quite a while to figure this out, as this is pretty hairy code ... the hairiest I've seen in Postgres. I was surprised to learn the original Berkeley code came without deadlock detection. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) I call it GNU/Linux. Except the GNU/ is silent. (Ben Reiter) ---(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] Timezone fun (bugs and a request)
On Sun, May 23, 2004 at 04:58:29PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: First I initdb'd without TZ set. So every time I start the server I get LOG: could not recognize system timezone, defaulting to Etc/GMT-4 HINT: You can specify the correct timezone in postgresql.conf. So what is your system timezone anyway (and what's the platform)? This is Linux 2.6 with glibc 2.3.3. My timezone is America/Santiago (or Chile/Continental which is the same). The timezone is set via /etc/localtime having the content of the timezone file (not as a symlink as it used to be some time ago). The TZ variable isn't set. alvherre=# select '10:00:00'::time at time zone 'Chile/Continental'; ERROR: el huso horario chile/continental no es reconocido This is functionality that never has existed. Right, I know because I tried to use it with 7.4 some time ago. This part was more a feature request than a bug report. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) XML! Exclaimed C++. What are you doing here? You're not a programming language. Tell that to the people who use me, said XML. ---(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] Timezone fun (bugs and a request)
Alvaro Herrera [EMAIL PROTECTED] writes: First I initdb'd without TZ set. So every time I start the server I get LOG: could not recognize system timezone, defaulting to Etc/GMT-4 HINT: You can specify the correct timezone in postgresql.conf. I've fixed the minor issue here, which is that the sign is backwards --- it ought to select Etc/GMT+4. The larger issue is that it's not recognizing your system timezone because the only name it can cons up for the zone is CLT4CLST, which doesn't work because it has the wrong DST rules. (I think it's just luck that it realizes that, actually :-(). Magnus and I had talked off-list about a smarter routine to recognize the system timezone without a TZ setting, but the only idea we've had is to grovel through each and every timezone file in the zic database, which doesn't seem real appealing. Note I get +4 on the default zone and -4 on the correct zone. I think this is a bug. Right, that much is fixed anyway. After this, DST works correctly, but I continue to receive the LOG message above. I think it should be supressed. Fixed. timezone = unknown The server now behaves different; the timezone is set to GMT rather than being guessed from system settings. I think they should work the same. Fixed. 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]
On Sun, 23 May 2004, Tom Lane wrote: Matthew T. O'Connor [EMAIL PROTECTED] writes: There will always be people who won't read the notes, or ignore the notes, Does anyone want to contemplate hacking things so that the Windows port reports a different version number? 0.1 might give people the right sort of impression about what we think of that port's stability ... How about a pop-up when starting up that repeatedly reinforces that this is considered a early port, and should be treated as such in a production environment. When we have it to the point we consider stable, we remove teh popup? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New horology failure
I get this since Tom's commit. On what platform? How is type time_t defined on your platform? Hmmm, I just CVS up'd and all regression tests now pass... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_autovacuum fixes
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Matthew T. O'Connor wrote: This weekend I am trying to fix up all known the pg_autovacuum issues that should be resolved for 7.4.3. I am aware of only two issues: temp table issues, and unchecked send_query() calls, if I am forgetting something, please let me know. 1) temp table issue: I was not able to reproduce the crash associated with temp tables. I spent a while creating tables doing updates and dropping them trying without success to get pg_autovacuum to crash. Since I couldn't trigger the problem, I will need someone else to test to see if I have fixed the problem. Anyway, I have modified the query to exclude temp tables from the list of tables to work with. So we should no longer be dealing with temp tables at all which should side step any temp table related problem we might have been having. 2) Unchecked send_query() function calls: As best as I can tell, this is mostly a non-issue, but I went ahead added a check to any section that did anything with the result of send_query, so if this was an issue, it should be fixed now. BTW, this might have been the cause of the temp table related crash, but that is just a guess. Matthew O'Connor [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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] pg_autovacuum fixes
Matthew T. O'Connor wrote: This weekend I am trying to fix up all known the pg_autovacuum issues that should be resolved for 7.4.3. I am aware of only two issues: temp table issues, and unchecked send_query() calls, if I am forgetting something, please let me know. 1) temp table issue: I was not able to reproduce the crash associated with temp tables. I spent a while creating tables doing updates and dropping them trying without success to get pg_autovacuum to crash. Since I couldn't trigger the problem, I will need someone else to test to see if I have fixed the problem. Anyway, I have modified the query to exclude temp tables from the list of tables to work with. So we should no longer be dealing with temp tables at all which should side step any temp table related problem we might have been having. 2) Unchecked send_query() function calls: As best as I can tell, this is mostly a non-issue, but I went ahead added a check to any section that did anything with the result of send_query, so if this was an issue, it should be fixed now. BTW, this might have been the cause of the temp table related crash, but that is just a guess. It is not a non-issue. A query could fail for thousands of reasons, and doing a core dump is never a solution. Yes, these are the only two known issues. -- 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] Unicode upper/lower solution proposal
Milos Prudek wrote: This is already fixed in CVS tip. Oh, cool! I know what is a CVS, but what is CVS tip? In which PostgreSQL stable release is upper() and lower() for Unicode planned to be included? Postgres version 7.5 ? CVS tip is jus the current version of all CVS files. It means this will be in 7.5. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Latest requests from IRC
Added to TODO: * Allow GRANT/REVOKE permissions to be given to all schema objects with one command --- Tom Lane wrote: Bruno Wolff III [EMAIL PROTECTED] writes: Christopher Kings-Lynne [EMAIL PROTECTED] wrote: ... people want to be able to grant on all objects in a database, etc: The right way to do this is to make sure there is a group that has access to everything and just add people to the group. Doesn't seem like that magically solves the problem, though. You still have lots of pain involved in granting privs on everything to that group. I don't have any fundamental problem with something like GRANT SELECT ON TABLE * TO foo, seeing as how we already allow grants on multiple tables. But we'd have to be very careful about how the scope of the * wildcard is defined. For instance, if a superuser does it, does it really grant privs on *all* tables? I'd hope that the system catalogs, at least, are not implicitly included in the wildcard scope. For lesser mortals there is also the question of whether to error out or just ignore tables that you don't have privileges for. Would it make sense to restrict the wildcard to a particular schema, viz GRANT SELECT ON TABLE myschema.* TO foo This would neatly solve the question of how to exclude the system catalogs, and in most scenarios where people are wishing for this, I bet they've put all the objects in one schema anyway. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Buffer manager (was Re: relcache refcount)
On Thu, May 13, 2004 at 09:43:42AM -0400, Tom Lane wrote: BTW, what are your plans for state saving/reversion for the lock manager and buffer manager? Ok, I have skimmed through the buffer manager code. At first I thought I'd have to set something up in shared memory for this, but then I noticed that every backend keeps a local reference count, and modifies the shared counter only when the local one raises from zero, or drops to zero. Also, the number of buffers does not change while the server is running. So I see two ways of handling this: 1. Keep an array of local refcounts for all buffers, for each subtrans. At subtrans start, a new array is allocated and filled with current local refcounts. At subtrans abort, we check if any count would go to zero while restoring; if so, decrement the shared counter. At subtrans commit, drop the saved array. The problem with this approach is that we allocate a large array which likely will be almost full of zeros. 2. Keep a more elaborate struct, where each buffer get its local count saved only if its nonzero. Thus we don't have to allocate a large amount of memory. Comments? Opinions? Which one do you think is better? Any completely different idea? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Coge la flor que hoy nace alegre, ufana. ¿Quién sabe si nacera otra mañana? ---(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
