Re: VACUUM/t_ctid bug (was Re: [HACKERS] GiST concurrency commited)
On Sat, 20 Aug 2005, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: I've written some quick scripts. One just vacuums constantly (999 vacuums to 1 vacuum full) while three other scripts three randomly insert into, update and delete from 3 tables. There's a mix of small and large transactions. The tables have a single int column. It is set up to run 3 million transactions across the 3 scripts. Note that since the issues have mainly to do with update chains, it'd be good to stress cases where a row is updated multiple times before being deleted. And use at least one long-running transaction, so that VACUUM can't just throw away the update chain. Right. I modified the test so have multiple updates of a given row mixed with concurrent long running read transactions. Vacuum was running repeatedly in a concurrent session. I did not encounter any problems. However, the results are inconclusive since I ran the same test against HEAD from 10 days ago and didn't manage to trigger the problem Teodor's script did. I'll take a better look tomorrow. Gavin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pre-allocated free space for row updating (like PCTFREE)
Jim C. Nasby wrote: It should be possible to see what the crossover point is in terms of benefit using dbt2 and tweaking the transactions that are run, something I can do if there's interest. But I agree with Satoshi; if there are people who will benefit from this option (which doesn't hurt those who choose not to use it), why not put it in? ISTM that this patch could be beneficial for the 'web session table' type workload (i.e. huge number of updates on relatively few rows), that is (well - last time I tried anyway) a bit of a challenge to reign in. There was a thread about this a while ago (late 2004), so in some sense it is a 'real world' scenario: http://archives.postgresql.org/pgsql-hackers/2004-06/msg00282.php regards Mark ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: Missing CONCURRENT VACUUM (Was: [HACKERS] Release notes for
On E, 2005-08-22 at 23:17 +0300, Hannu Krosing wrote: On E, 2005-08-22 at 14:05 -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: But I could not find the breakage (from your Aug 17 email) with You missed vac_truncate_clog, though. That was fixed (and documented), along with some other problems, in the modified patch I sent back to you: http://archives.postgresql.org/pgsql-patches/2005-08/msg00260.php AFAICT you ignored that ... I must make a serious inquiry into my mailhost to see what is going on. Again I answered too quickly. I see it now. Your answer was to pgsql-patches list and to my terminally spam-infested old address [EMAIL PROTECTED], whereas I expected it for some reason as a reply to my [EMAIL PROTECTED] address and/or pgsql-hackers list from/to which the last mails were sent Sorry, must look more aggressively in future :) -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.1 release notes
Bruce, I think I took part in GiST concurrency and recovery project. Oleg On Mon, 22 Aug 2005, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 release notes
JFYI: Allow indexes to be used for MIN/MAX (Tom) In previous releases, the only way to use index for MIN/MAX was to rewrite the query as SELECT col FROM tab ORDER BY col LIMIT 1. This not happens automatically. I guess this should read This now happens automatically Regards, Mario Weilguni -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Bartunov Sent: Tuesday, August 23, 2005 9:04 AM To: Bruce Momjian Cc: PostgreSQL-development Subject: Re: [HACKERS] 8.1 release notes Bruce, I think I took part in GiST concurrency and recovery project. Oleg On Mon, 22 Aug 2005, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE- 8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 release notes
Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. I think this is an understatement and does not really say what was done: Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. I would include something like Implement SQL-compliant ROLE support I believe Make default_with_oids default to false and Change add_missing_from to 'false' should be mentioned in the Migration section. This section should say Migration to version 8.1 instead of Migration to version 8.0. This caused CREATE DATABASE to sometimes fail because a new database can not be created if anyone else is in the template database. Shouldn't this read: This caused CREATE DATABASE to sometimes fail because a new database could not be created if anyone else was in the template database. With this change, the default connection database is now 'postgres', meaning is is much less likely someone will be using template1 during CREATE DATABASE. ... meaning it is much less likely ... There are some items that are appended to the last one. E.g. Fix interval division and multiplication (Bruce) Other times, the additional comments have their own bullet. These I don't really understand: - Improve rtree index capabilities and performance (Neil) - Replace rtree index code with code from /contrib/rtree_gist (Tom) So first Neil improved the performance for rtree, then rtree was replaced with rtree_gist? So Neil's optimizations are gone? What file should I send patches against next time? ;-) Best Regards, Michael Paesold ---(end of broadcast)--- TIP 1: 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] 8.1 release notes
On Aug 23, 2005, at 6:07 PM, Michael Paesold wrote: This caused CREATE DATABASE to sometimes fail because a new database can not be created if anyone else is in the template database. Shouldn't this read: This caused CREATE DATABASE to sometimes fail because a new database could not be created if anyone else was in the template database. iiuc, It's *always* the case that a new database can not be created if anyone is connected to template1, so *can not be* is more appropriate than *could not be*. It's still the case that if someone is connected to template1 when a CREATE DATABASE is issued, the command will fail. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 1: 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] Win32 unicode vs ICU
.. back home again after a couple of days .. snip I am unsure of how to proceed. As I see it there are three paths: 1) Use native win32 functionality only on win32 2) Use ICU functionality only on win32 3) Allow both ICU and native functionality, compile time switch --with-icu (same as unix with the ICU patch) snip I feel it makes sense to apply the smaller patch in any case, so that there's a Win32 solution not requiring ICU (ie, I can't see an argument for doing (2) rather than (3)). Comments? Sounds reasonable to me - couldn't really find a reasonable argument for (2), but it was an option :-) Though as it seems to be needed on FreeBSD as well, we should definitly look at (3) as a long-term option. Considering Palle has been running it in production for quite a while now IIRC, the ICU part should be fairly stable. but see below... And anohter question - my native patch touches the same functions as the ICU patch. Can somebody who knows the internals confirm or deny that these are all the required locations, or do we need to modify more? There is a strxfrm() call in src/backend/utils/adt/selfuncs.c, which probably needs to be looked at too. Ok. Will look into that. Do you have a hint as to how to test that? Considering I've been unable to show incorrect function without donig it, and apparantly so has Palle (with the ICU patch) running it in production for a long time, I clearly don't know how to provoke a failure with the current code. Which brings up another point - there are clearly no regression tests for this (considering we missed the unicode stuff early in the 8.0 cycle). Is there a reasonable way to add something along this line that could be used, or will that be too complex? (I guess we can never test completely as it depends on the OS locale handling, but some?) I'm thinking it might be too complex as we'd need a new initdb with a different encoding, but perhaps it's worth it anyway? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: VACUUM/t_ctid bug (was Re: [HACKERS] GiST concurrency commited)
I have committed changes that I believe fix this problem: http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php But it needs more testing. Would you update to CVS tip and see if you still see the failure? It seems, patch works correctly. My tests is passed with approximatly 1e8 SQL statements without any failure. Tests runs on two boxes: PIII/1133MHz adn Quad Xeon/500MHz and works with four threads. Further I'm going to increase concurrency up to 12 parallel threads. PS GiST passed this tests too. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 release notes
Fixed. --- Mario Weilguni wrote: JFYI: Allow indexes to be used for MIN/MAX (Tom) In previous releases, the only way to use index for MIN/MAX was to rewrite the query as SELECT col FROM tab ORDER BY col LIMIT 1. This not happens automatically. I guess this should read This now happens automatically Regards, Mario Weilguni -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Bartunov Sent: Tuesday, August 23, 2005 9:04 AM To: Bruce Momjian Cc: PostgreSQL-development Subject: Re: [HACKERS] 8.1 release notes Bruce, I think I took part in GiST concurrency and recovery project. Oleg On Mon, 22 Aug 2005, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE- 8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Thanks, added. --- Oleg Bartunov wrote: Bruce, I think I took part in GiST concurrency and recovery project. Oleg On Mon, 22 Aug 2005, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
Fixed.
---
Bruno Wolff III wrote:
On Mon, Aug 22, 2005 at 23:16:14 -0400,
Bruce Momjian pgman@candle.pha.pa.us wrote:
I have compiled the 8.1 release notes and converted them to SGML at:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1
I still need to add markup and cleanup, but it is good enough for
review and for beta1. I will work on it more tomorrow.
I spotted a couple of typos:
I think that 'not' should be 'now' in the following:
In previous releases, the only way to use index for MIN/MAX was to rewrite
the query as SELECT col FROM tab ORDER BY col LIMIT 1. This not happens
automatically.
I think that 'of' should be 'off' in the following:
To prevent partial disk writes from corrupting the database, PostgreSQL
writes a complete copy of each database disk page to WAL the first time it is
modified after a checkpoint. This turns of that functionality for users with
battery-backed disk caches where partial page writes can not happen.
I don't think you want a double negative ('not' and 'INconsistant') in the
following:
In release 8.0, carriage returns and line feeds in CSV COPY TO were not
processed in a inconsitent manner. (This was documented on the TODO list.)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE USER and pg_user
Jim Nasby [EMAIL PROTECTED] write Yes, but it doesn't really specify if you have to have a privilege in order to grant it, although reading one of the notes[1] tends to indicate that you must have a role in order to grant it. Unless I'm overlooking some part of the docs? I am confused by the combination of USER and ROLE in 8.1 at first glance. In my memory, USER is a representation of somebody using the database, just as USER in OS. USER can also always login into the system, except the Admin prohibit it. ROLE is a collection of some priviledges. A USER can act as multiple ROLEs, but in real life, it cannot act as multiple ROLEs are the same time. That's why some system define that a USER can only act as one ROLE at a moment, but she can change her ROLE with SET SESSION ROLE TO anotherRole. Maybe I will read more about SQL:2003, pgsql-8.1 doc and RBAC (Role Based Access Control, http://csrc.nist.gov/rbac/rbac-stds-roadmap.html) to understand it correctly. Regards, William ZHANG ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 release notes
Hi Bruce, Andreas did the initial version of the dbsize integration patch so should be included in the credit for that item. Regards, Dave -Original Message- From: Bruce Momjianpgman@candle.pha.pa.us Sent: 23/08/05 04:19:19 To: PostgreSQL-developmentpgsql-hackers@postgresql.org Subject: [HACKERS] 8.1 release notes I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster -Unmodified Original Message- I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Thanks, added. --- Dave Page wrote: Hi Bruce, Andreas did the initial version of the dbsize integration patch so should be included in the credit for that item. Regards, Dave -Original Message- From: Bruce Momjianpgman@candle.pha.pa.us Sent: 23/08/05 04:19:19 To: PostgreSQL-developmentpgsql-hackers@postgresql.org Subject: [HACKERS] 8.1 release notes I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster -Unmodified Original Message- I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: explain analyze is your friend
Re: [HACKERS] [pgsql-www] New web page for release status
I have put together a new web page to show all the PostgreSQL status pages I maintain, and I have added a bugs to be fixed in 8.1 page that will track must-fix bugs for this release. It is at: http://momjian.postgresql.org/pgrelease I think this should be added to the developers page somewhere. I think it would be better if the page itself was moved to the developer page, and just the stuff that it points to stays on the different site. Actually, I think the best would be to move even more of it to the actual developer page (I realise we can't do that for the patches lists that are built from mail folders. I still think that those should be moved to some kind of patch tracker both to make them easier to access and to make it easier for people to fill in for you when you are out of town etc, but that's a completely different thing). AFAICS the Open Items is just a webpage, could it be moved to the main website? (Doing static webpages on the main website is really easy once you have the template in place - and doing the template for something like this is also very very easy as it's just a webpage with a title. The actual updating is just a normal case of editing standard HTML) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Bruce, I have also noticed a small error: a.. Remove old *.backup files when we do pg_stop_backup() (Bruce) a.. This prevents a large number of *.backup files from existing in pg_xlog/. I think there should not be a point on the left of the second line because it's the details of the first line. Best Regards, Otto - Original Message - From: Bruce Momjian pgman@candle.pha.pa.us To: PostgreSQL-development pgsql-hackers@postgreSQL.org Sent: Tuesday, August 23, 2005 5:16 AM Subject: [HACKERS] 8.1 release notes I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 release notes
Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. A couple of (other) items I have been involved with that might deserve a mention: . pl/perl support for strict mode . improved regression framework, - separate db names for separate suites (standard regression, PL, contrib), loadable languages, standardised framework for PLs. (We're still working in strict mode but we'll get it fixed in the next few days) And I am not sure if this counts as a bug fix or a feature :-) : . pl/perl logging of non-fatal warnings cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
Michael Paesold wrote: Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. I think this is an understatement and does not really say what was done: Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. I would include something like Implement SQL-compliant ROLE support Yes, I still need to add text for some of the items. I believe Make default_with_oids default to false and Change add_missing_from to 'false' should be mentioned in the Migration section. This section should say Migration to version 8.1 instead of Migration to version 8.0. This caused CREATE DATABASE to sometimes fail because a new database can not be created if anyone else is in the template database. Shouldn't this read: This caused CREATE DATABASE to sometimes fail because a new database could not be created if anyone else was in the template database. With this change, the default connection database is now 'postgres', meaning is is much less likely someone will be using template1 during CREATE DATABASE. ... meaning it is much less likely ... There are some items that are appended to the last one. E.g. Fix interval division and multiplication (Bruce) Other times, the additional comments have their own bullet. Above fixed. These I don't really understand: - Improve rtree index capabilities and performance (Neil) - Replace rtree index code with code from /contrib/rtree_gist (Tom) So first Neil improved the performance for rtree, then rtree was replaced with rtree_gist? So Neil's optimizations are gone? I was wondering about this too. I will add a ? to the item. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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] 8.1 release notes
Fixed. --- Havasv?lgyi Ott? wrote: Bruce, I have also noticed a small error: a.. Remove old *.backup files when we do pg_stop_backup() (Bruce) a.. This prevents a large number of *.backup files from existing in pg_xlog/. I think there should not be a point on the left of the second line because it's the details of the first line. Best Regards, Otto - Original Message - From: Bruce Momjian pgman@candle.pha.pa.us To: PostgreSQL-development pgsql-hackers@postgreSQL.org Sent: Tuesday, August 23, 2005 5:16 AM Subject: [HACKERS] 8.1 release notes I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Win32 unicode vs ICU
Magnus Hagander [EMAIL PROTECTED] writes: There is a strxfrm() call in src/backend/utils/adt/selfuncs.c, which probably needs to be looked at too. Ok. Will look into that. Do you have a hint as to how to test that? Any problems would manifest as a bogus interpolation between histogram elements for a scalar-inequality selectivity estimate in a text column. For instance, if you insert all 676 2-letter combinations AA, AB, AC, ..., ZY, ZZ into a text column, ANALYZE, and then try cases like EXPLAIN SELECT * FROM tab WHERE col 'QW', ideally the row estimate should be pretty nearly dead on. Being pure-ASCII this test would probably still work in a broken Unicode context, but if you did a similar experiment with 26 non-ASCII characters it would be likely to come out with silly results. You could increase the obviousness of the bad result by reducing the statistics target, since the silliness will be bounded by the histogram bin size. (Just looking at it again, the code in convert_string_to_scalar is pretty bogus for multibyte encodings in any case. Possibly we need to rethink the whole approach.) Which brings up another point - there are clearly no regression tests for this (considering we missed the unicode stuff early in the 8.0 cycle). src/test/locale? src/test/mb? I've never used either, but they're there ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
OK, updated. When I read migrate I thought move. --- Tom Lane wrote: Michael Paesold [EMAIL PROTECTED] writes: These I don't really understand: - Improve rtree index capabilities and performance (Neil) - Replace rtree index code with code from /contrib/rtree_gist (Tom) Not sure how Bruce got the latter out of this commit message: Migrate rtree_gist functionality into the core system, and add some basic regression tests for GiST to the standard regression tests. All that's really happened is that GiST actually has a couple of opclasses in the core system now, whereas previously they were all contrib (meaning that GiST was dead weight in a standard installation). It's also now true that everything you can do with the standard rtree opclasses, you can do with standard GiST opclasses. There was some talk of obsoleting rtree further down the road, but it isn't happening in 8.1. If no serious bugs crop up in all the new GiST work Teodor and Oleg did, we might consider obsoleting rtree in 8.2. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: explain analyze is your friend
Re: [HACKERS] 8.1 release notes
Michael Paesold [EMAIL PROTECTED] writes: These I don't really understand: - Improve rtree index capabilities and performance (Neil) - Replace rtree index code with code from /contrib/rtree_gist (Tom) Not sure how Bruce got the latter out of this commit message: Migrate rtree_gist functionality into the core system, and add some basic regression tests for GiST to the standard regression tests. All that's really happened is that GiST actually has a couple of opclasses in the core system now, whereas previously they were all contrib (meaning that GiST was dead weight in a standard installation). It's also now true that everything you can do with the standard rtree opclasses, you can do with standard GiST opclasses. There was some talk of obsoleting rtree further down the road, but it isn't happening in 8.1. If no serious bugs crop up in all the new GiST work Teodor and Oleg did, we might consider obsoleting rtree in 8.2. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 release notes
Added. Thanks. --- Andrew Dunstan wrote: Bruce Momjian wrote: . pl/perl support for strict mode That was completed after I pulled CVS, I think. It will be updated later. Actually, it snuck in with one of Abhijit's patches. And I am not sure if this counts as a bug fix or a feature :-) : . pl/perl logging of non-fatal warnings Uh, not really. I saw the commit message but what does it mean? Before this patch, any non-fatal perl warning, either generated by perl itself of by the user calling the builtin function warn(), was dropped in the bit bucket. Now it is logged at NOTICE level. cheers andrew -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Pre-allocated free space for row updating (like PCTFREE)
Jim, Satoshi, It should be possible to see what the crossover point is in terms of benefit using dbt2 and tweaking the transactions that are run, something I can do if there's interest. But I agree with Satoshi; if there are people who will benefit from this option (which doesn't hurt those who choose not to use it), why not put it in? Because your predicate is still disputed? That is, we don't know that people will benefit yet -- pgbench is a pretty useless benchmark for real performance comparisons. Satoshi, if you can package up a patch on current CVS, I'll throw it at DBT2. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.1 release notes
Bruce Momjian wrote: . pl/perl support for strict mode That was completed after I pulled CVS, I think. It will be updated later. Actually, it snuck in with one of Abhijit's patches. And I am not sure if this counts as a bug fix or a feature :-) : . pl/perl logging of non-fatal warnings Uh, not really. I saw the commit message but what does it mean? Before this patch, any non-fatal perl warning, either generated by perl itself of by the user calling the builtin function warn(), was dropped in the bit bucket. Now it is logged at NOTICE level. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Let's drop some GUCs (bgwriter)
Jim, But have you looked at how this affects response time, especially around checkpoints? Testing I've done shows that changing the variables in 8.0.3 can markedly reduce the impact of checkpoints. In many applications, maintaining low response times is more important than overall throughput, and that's where bgwriter tuning currently comes into play. Depending on hardware it may not be possible to simplify all these into a single number, either. Hmmm ... can you give me the settings you used? I'd like to check the response times. --Josh -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Win32 unicode vs ICU
I wrote: (Just looking at it again, the code in convert_string_to_scalar is pretty bogus for multibyte encodings in any case. Possibly we need to rethink the whole approach.) After studying this some more, I think the code is really so bogus for any non-ASCII situation that it's probably not worth worrying about too much. It's effectively assuming that the output of strxfrm() is still in an ASCII-superset encoding ... but I don't see anything in strxfrm's API that guarantees any such thing. As long as strxfrm() doesn't fail completely for Windows Unicode, I'd recommend just leaving this alone. As previously noted, the worst that can happen is an estimation error that's bounded by the histogram bin size anyhow. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
Andrew Dunstan wrote: Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. A couple of (other) items I have been involved with that might deserve a mention: . pl/perl support for strict mode That was completed after I pulled CVS, I think. It will be updated later. . improved regression framework, - separate db names for separate suites (standard regression, PL, contrib), loadable languages, standardised framework for PLs. That isn't something we usually mention in the release notes, but I can under source code. (We're still working in strict mode but we'll get it fixed in the next few days) And I am not sure if this counts as a bug fix or a feature :-) : . pl/perl logging of non-fatal warnings Uh, not really. I saw the commit message but what does it mean? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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] Inconsistencies with create role
The documentation already says prominently that roles and users are the same thing. If you're fooling with CREATE ROLE without having read any of that, I'm not sure that an error message will help. I am talking about consistency here. Most people are not going to think a role is a user, at least not initially since it is a new feature. All I was saying was that the error message was a little confusing. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CREATE USER and pg_user
On Mon, Aug 22, 2005 at 10:42:15PM -0400, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: My original point was that if you don't have permission to do something, you shouldn't be able to grant permissions to do it. This applies to all snip I'm not convinced. It seems reasonable to say that you can't grant CREATEDB if you don't have it, but that's only because it's hard to imagine why anyone would make a role that's CREATEROLE and not CREATEDB. I don't think it's unreasonable that an admin would want to allow someone to be able to grant permissions to others, but not create databases. Regardless, the real issue comes in when more privleges are added in the future. We can either cross that bridge when we come to it or we can look at it now. My argument is that we should look at it now. But, for example, we allow a CREATEROLE role to grant and revoke role memberships without itself being an admin of those roles. Which is arguably not good... Basically the point of CREATEROLE is to be a safer kind of superuser: you can do what you like with respect to creating and dropping and altering users and groups (other than superusers), but you don't have permission to, say, DELETE FROM pg_proc. If we restrict CREATEROLE to not have any privileges that an ordinary user wouldn't have except the ability to create users, then we'll be back at square one in the sense that lots of common administrative situations will require superuser privilege. I definately don't think we should restrict CREATEROLE to the point where it's just another user, but I also don't think it should be given full reign, either. To an extent we've already addressed that with the special condition of SUPERUSER. My point is that instead of treating SUPERUSER as a special case, why not just restrict all privileges the same way? An alternative would be a second set of privileges that determine what privileges a role can assign, but that seems like overkill and a potential foot-gun. It's quite likely that we don't have CREATEROLE fully done yet, and that it still needs some more tweaks that we haven't thought of. But I don't think I buy the premise that it ought to be confined to creating users with no other special privileges. If we do that, we'll just have to re-invent the limited-superuser facility under a different name, because there's a serious need for that. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CREATE USER and pg_user
On Tue, Aug 23, 2005 at 09:26:07AM +0800, William ZHANG wrote: Jim Nasby [EMAIL PROTECTED] write Yes, but it doesn't really specify if you have to have a privilege in order to grant it, although reading one of the notes[1] tends to indicate that you must have a role in order to grant it. Unless I'm overlooking some part of the docs? I am confused by the combination of USER and ROLE in 8.1 at first glance. In my memory, USER is a representation of somebody using the database, just as USER in OS. USER can also always login into the system, except the Admin prohibit it. ROLE is a collection of some priviledges. A USER can act as multiple ROLEs, but in real life, it cannot act as multiple ROLEs are the same time. That's why some system define that a USER can only act as one ROLE at a moment, but she can change her ROLE with SET SESSION ROLE TO anotherRole. Maybe I will read more about SQL:2003, pgsql-8.1 doc and RBAC (Role Based Access Control, http://csrc.nist.gov/rbac/rbac-stds-roadmap.html) to understand it correctly. You should take a look at http://lnk.nu/developer.postgresql.org/3mi.html, both 17.1 and 17.2. In particular: CREATE USER is equivalent to CREATE ROLE except that CREATE USER assumes LOGIN by default, while CREATE ROLE does not. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pre-allocated free space for row updating (like PCTFREE)
On Mon, Aug 22, 2005 at 10:18:25PM -0400, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: ... But I agree with Satoshi; if there are people who will benefit from this option (which doesn't hurt those who choose not to use it), why not put it in? Because there's no such thing as a free lunch. Every option we support costs us in initial implementation time, documentation effort, and ongoing maintenance. Plus it confuses users who don't know what to do with it. (Note Josh's nearby lobbying to remove some GUC parameters. While I opposed him on that particular item, I sympathize with his point in general.) Oracle's approach of offer every knob you can think of is not one that I care to emulate. We have to strike a balance between flexibility and not having a database that's too complex to administer for anyone except an expert. The problem is that unless you're going to put a lot of AI in the database[1] (something Oracle is now doing...), you're going to end up limiting yourself. As the PostgreSQL code continues to improve performance-wise, we're going to run into more and more situations where the way to get more performance means adding more tunables. Look at the knobs that have been added for bgwriter and delayed vacuum for example. These were added because the code had gotten to a point where the problems they solve had become bigger and bigger bottlenecks. I know there's hope that eventually these can be turned into simple 1-10 knobs or something, but I'm doubtful that something that simple will suffice for all situations. I do understand the issue of having 100s of knobs, though. I don't think we should go adding knobs willy-nilly (Josh made the good point that there's currently no testing to validate the usefullness of this free space knob, for example). But I also think that the way to control 'knob-bloat' isn't to do everything possible not to add knobs, but to look at how to limit their exposure to people who don't need to know about them. For example, there's less than a half dozen knobs that people always ask about when people post performance questions: shared_buffers, work_mem, effective_cache_size, etc. These are knobs that almost every user needs to know about. Call them 'level 1' knobs. Level 2 might be things like vacuum_cost_delay, maintenance_work_mem, max_fsm_pages, and max_connections. And so on. By grouping in this fashion we can limit exposure to things that most users won't need to mess with, but give users who have need to change these things the ability to do so. [1]: I'm all in favor of making things self-tuning wherever possible, but that's generally a lot more work than just exposing a GUC, so I suspect it will be some time before we get to that point. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] 8.1 release notes
I have finished working on the release notes for the moment: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I will update them just before we put out the beta. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
On Mon, Aug 22, 2005 at 11:16:14PM -0400, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Is a dump/restore required for upgrading from 8.0.x? It might be nice to note what features require this (2PC?). -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Jim C. Nasby wrote: On Mon, Aug 22, 2005 at 11:16:14PM -0400, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Is a dump/restore required for upgrading from 8.0.x? It might be nice to note what features require this (2PC?). Major releases always require a dump/reload because of regular system catalog and heap/index changes during development. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] New web page for release status
It'd also be good to add http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 to the page. On Tue, Aug 23, 2005 at 01:38:53PM +0200, Magnus Hagander wrote: I have put together a new web page to show all the PostgreSQL status pages I maintain, and I have added a bugs to be fixed in 8.1 page that will track must-fix bugs for this release. It is at: http://momjian.postgresql.org/pgrelease I think this should be added to the developers page somewhere. I think it would be better if the page itself was moved to the developer page, and just the stuff that it points to stays on the different site. Actually, I think the best would be to move even more of it to the actual developer page (I realise we can't do that for the patches lists that are built from mail folders. I still think that those should be moved to some kind of patch tracker both to make them easier to access and to make it easier for people to fill in for you when you are out of town etc, but that's a completely different thing). AFAICS the Open Items is just a webpage, could it be moved to the main website? (Doing static webpages on the main website is really easy once you have the template in place - and doing the template for something like this is also very very easy as it's just a webpage with a title. The actual updating is just a normal case of editing standard HTML) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 release notes
On Tue, Aug 23, 2005 at 03:57:52PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: On Mon, Aug 22, 2005 at 11:16:14PM -0400, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Is a dump/restore required for upgrading from 8.0.x? It might be nice to note what features require this (2PC?). Major releases always require a dump/reload because of regular system catalog and heap/index changes during development. Duh, I was equating major version number to requiring pg_dump... it's just been too long since 7.3-7.4. Sorry. :) -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.1 release notes
Just so this doesn't get lost (and I don't forget): Is the intention that standard_conforming_strings will always be read-only? ISTM it would be very useful if it was used to control the behavior of strings that weren't E quoted while people are transitioning. Or is that too difficult to do? (Unfortunately I couldn't find the answer to this in the hackers archives...) In any case, it would be good if the release notes linked to a page that described the plan for this in more detail. Actually, it would be great if all the items linked to pages that had more detailed info, even if it was just the relevant page in the docs or a thread on the mailling list. If the source sgml is available I can take a stab at this. On Tue, Aug 23, 2005 at 03:51:35PM -0400, Bruce Momjian wrote: I have finished working on the release notes for the moment: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I will update them just before we put out the beta. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: don't forget to increase your free space map settings -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.1 release notes
* Bruce Momjian (pgman@candle.pha.pa.us) wrote: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 Regarding E.1.3.4 (Object Manipulation Changes): - Allow ALTER OWNER commands to be performed by the object owner as well as the superuser (Stephen Frost) Prior releases only allowed super-user to change object owners, even if the current owner was executing the command and the new owner have permission to create objects of that type. - This isn't *quite* right and implies an ability some might frown upon (giving away objects) that isn't actually allowed by my changes. How about: - Allow ALTER OWNER commands to be performed by the object owner (Stephen Frost) Prior releases only allowed a single user to own an object. With the addition of role support (where a role can own an object and that role can have members) it's now possible for multiple users to have ownership rights on a given object. ALTER OWNER has been updated to allow changing the ownership of an object when the user has ownership rights on the object, is in the new owner role, and the new owner role has the right to create the object. - Unfortunately, though there was some discussion on it, it seems that the new owner role must have rights to create the object even if the user doing the ALTER OWNER owns the schema/db in question. This means a user would have to first grant create privileges to the unpriviledged role, change the ownership to that role, and then reokve the create privileges. This also means that a number of explicit 'superuser()' checks were added after I had worked to minimize them. I'd still like to see the explicit superuser() checks removed in favor of checking schema ownership but I'm guessing it's too late for that now. Perhaps after 8.1 is released we'll get some conversation regarding these kinds of things which goes beyond just Tom and I. I don't mind discussing it with Tom but it'd be nice to get some fresh viewpoints on the subject and eventually I think it's better, I don't like it gets kind of boring and can be difficult to work past (well, except he has commit access and I don't... ;). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.1 release notes
On Tue, Aug 23, 2005 at 03:51:35PM -0400, Bruce Momjian wrote: I have finished working on the release notes for the moment: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I will update them just before we put out the beta. Here's bit clarified pgcrypto summary: - Implemention of OpenPGP symmetric- and public-key encryption. Supported are both RSA and Elgamal public-key algorithms. - Standalone build: include SHA256/384/512 hashes, Fortuna PRNG. - OpenSSL build: support 3DES, use internal AES with OpenSSL 0.9.7. - Take build parameters (OpenSSL, zlib) from ./configure result. No need to edit Makefile anymore. The mhash note can stay as-is. -- marko ---(end of broadcast)--- TIP 1: 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] 8.1 release notes
Jim C. Nasby wrote: Just so this doesn't get lost (and I don't forget): Is the intention that standard_conforming_strings will always be read-only? ISTM it would be very useful if it was used to control the behavior of strings that weren't E quoted while people are transitioning. Or is that too difficult to do? I think in 8.2 it will be read/write. (Unfortunately I couldn't find the answer to this in the hackers archives...) In any case, it would be good if the release notes linked to a page that described the plan for this in more detail. Actually, it would be great if all the items linked to pages that had more detailed info, even if it was just the relevant page in the docs or a thread on the mailling list. If the source sgml is available I can take a stab at this. You are looking in the release notes at all the information there is, so there is nothing to link to. :-) If you want more, send a patch to release.sgml and I will add it. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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] 8.1 release notes
Stephen Frost wrote: -- Start of PGP signed section. * Bruce Momjian (pgman@candle.pha.pa.us) wrote: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 Regarding E.1.3.4 (Object Manipulation Changes): - Allow ALTER OWNER commands to be performed by the object owner as well as the superuser (Stephen Frost) Prior releases only allowed super-user to change object owners, even if the current owner was executing the command and the new owner have permission to create objects of that type. - This isn't *quite* right and implies an ability some might frown upon (giving away objects) that isn't actually allowed by my changes. How about: - Allow ALTER OWNER commands to be performed by the object owner (Stephen Frost) Prior releases only allowed a single user to own an object. With the addition of role support (where a role can own an object and that role can have members) it's now possible for multiple users to have ownership rights on a given object. ALTER OWNER has been updated to allow changing the ownership of an object when the user has ownership rights on the object, is in the new owner role, and the new owner role has the right to create the object. - Unfortunately, though there was some discussion on it, it seems that the new owner role must have rights to create the object even if the user doing the ALTER OWNER owns the schema/db in question. This means a user would have to first grant create privileges to the unpriviledged role, change the ownership to that role, and then reokve the create privileges. This also means that a number of explicit 'superuser()' checks were added after I had worked to minimize them. I'd still like to see the explicit superuser() checks removed in favor of checking schema ownership but I'm guessing it's too late for that now. Good description, updated to: Allow limited commandALTER OWNER/ commands to be performed by the object owner (Stephen Frost) Prior releases allowed only the super-user to change object owners, even if the current owner was executing the command and the new owner was in the same group. With roles such transfers are now possible. Allow limited commandALTER OWNER/ commands to be performed by the object owner (Stephen Frost) Prior releases allowed only the super-user to change object owners, even if the current owner was executing the command and the new owner was in the same group. With roles such transfers are now possible. Perhaps after 8.1 is released we'll get some conversation regarding these kinds of things which goes beyond just Tom and I. I don't mind discussing it with Tom but it'd be nice to get some fresh viewpoints on the subject and eventually I think it's better, I don't like it gets kind of boring and can be difficult to work past (well, except he has commit access and I don't... ;). Most people don't know what roles are, but with them described in 8.1 release, we will have more people available to discuss in the future. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Thanks, updated. I suspected there was more than I had listed. --- Marko Kreen wrote: On Tue, Aug 23, 2005 at 03:51:35PM -0400, Bruce Momjian wrote: I have finished working on the release notes for the moment: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I will update them just before we put out the beta. Here's bit clarified pgcrypto summary: - Implemention of OpenPGP symmetric- and public-key encryption. Supported are both RSA and Elgamal public-key algorithms. - Standalone build: include SHA256/384/512 hashes, Fortuna PRNG. - OpenSSL build: support 3DES, use internal AES with OpenSSL 0.9.7. - Take build parameters (OpenSSL, zlib) from ./configure result. No need to edit Makefile anymore. The mhash note can stay as-is. -- marko -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
On Monday 22 August 2005 20:16, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. I think the not in the following should be now. (limits can not be enforced) Add per-user and per-database connection limits (Petr Jelinek) Using ALTER USER and ALTER DATABASE, limits can not be enforced on the maximum number of users who can connect as as a specific uesr or to a specific database. Setting the limit to zero disables user or database connections. -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 release notes
On Monday 22 August 2005 20:16, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. Also I think Allow TRUNCATE to truncate multiple files in a single command (Alvaro) Should read tables or relations not files. -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 release notes
On Tue, Aug 23, 2005 at 05:25:56PM -0400, Bruce Momjian wrote: Thanks, updated. I suspected there was more than I had listed. This patch tidies dots and bit more. -- marko Index: doc/src/sgml/release.sgml === RCS file: /opt/arc/cvs2/pgsql/doc/src/sgml/release.sgml,v retrieving revision 1.351 diff -u -c -r1.351 release.sgml *** doc/src/sgml/release.sgml 23 Aug 2005 21:25:56 - 1.351 --- doc/src/sgml/release.sgml 23 Aug 2005 22:09:29 - *** *** 1726,1732 listitem para ! Implemention of OpenPGP symmetric-key and public-key encryption /para para Supported are both RSA and Elgamal public-key algorithms. --- 1726,1732 listitem para ! Implemention of OpenPGP symmetric-key and public-key encryption. /para para Supported are both RSA and Elgamal public-key algorithms. *** *** 1735,1753 listitem para ! Standalone build: include SHA256/384/512 hashes, Fortuna PRNG /para /listitem listitem para ! OpenSSL build: support 3DES, use internal AES with OpenSSL 0.9.7 /para /listitem listitem para ! Take build parameters (OpenSSL, zlib) from filename/configure/. result /para para No need to edit the filenameMakefile/ anymore. --- 1735,1753 listitem para ! Standalone build: include SHA256/384/512 hashes, Fortuna PRNG. /para /listitem listitem para ! OpenSSL build: support 3DES, use internal AES with OpenSSL lt; 0.9.7. /para /listitem listitem para ! Take build parameters (OpenSSL, zlib) from filename./configure/ result. /para para No need to edit the filenameMakefile/ anymore. *** *** 1756,1762 listitem para ! Remove support for filenamelibmhash/ and filenamelibmcrypt/ (Marko Kreen) /para /listitem --- 1756,1762 listitem para ! Remove support for filenamelibmhash/ and filenamelibmcrypt/. /para /listitem ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Thanks, fixed. --- Darcy Buskermolen wrote: On Monday 22 August 2005 20:16, Bruce Momjian wrote: I have compiled the 8.1 release notes and converted them to SGML at: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1 I still need to add markup and cleanup, but it is good enough for review and for beta1. I will work on it more tomorrow. I think the not in the following should be now. (limits can not be enforced) Add per-user and per-database connection limits (Petr Jelinek) Using ALTER USER and ALTER DATABASE, limits can not be enforced on the maximum number of users who can connect as as a specific uesr or to a specific database. Setting the limit to zero disables user or database connections. -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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] 8.1 release notes
Thanks, done. --- Marko Kreen wrote: On Tue, Aug 23, 2005 at 05:25:56PM -0400, Bruce Momjian wrote: Thanks, updated. I suspected there was more than I had listed. This patch tidies dots and bit more. -- marko [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Pre-allocated free space for row updating (like PCTFREE)
Josh Berkus wrote: Satoshi, if you can package up a patch on current CVS, I'll throw it at DBT2. Ok. I'll do it. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: 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] SHOW, RESET require quotes, SET doesn't
SHOW and RESET require quoting in cases where SET doesn't: test= SHOW plperl.use_strict; ERROR: syntax error at or near . at character 12 LINE 1: SHOW plperl.use_strict; ^ test= SHOW plperl.use_strict; plperl.use_strict --- on (1 row) test= SET plperl.use_strict TO off; SET test= RESET plperl.use_strict; ERROR: syntax error at or near . at character 13 LINE 1: RESET plperl.use_strict; ^ test= RESET plperl.use_strict; RESET I see in gram.y that SHOW and RESET take a ColId but SET takes a var_name, which is ColId or var_name.ColId. Is there a reason for the inconsistency or is it just an oversight? -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 release notes
Jim C. Nasby [EMAIL PROTECTED] writes: Is the intention that standard_conforming_strings will always be read-only? For the moment it's read-only false; the long-term goal is that it will be read-only true. In between we will have a release or three where it is modifiable to some extent. I personally think it would be a *bad* idea if it were a mere USERSET variable --- we learned from the autocommit fiasco that changing fundamental semantics on a whim does not work. But there will need to be some way to alter it for testing purposes during the interregnum. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SHOW, RESET require quotes, SET doesn't
Michael Fuhr [EMAIL PROTECTED] writes: I see in gram.y that SHOW and RESET take a ColId but SET takes a var_name, which is ColId or var_name.ColId. Is there a reason for the inconsistency or is it just an oversight? Offhand it looks like the custom-variable patch missed dealing with SHOW and RESET ... that patch was a few bricks shy of a load in other ways too ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Must be owner to truncate?
Bruce Momjian schrob: Stephen Frost wrote: -- Start of PGP signed section. * Jim C. Nasby ([EMAIL PROTECTED]) wrote: On Thu, Jul 07, 2005 at 01:48:59PM -0400, Tom Lane wrote: I don't really agree with the viewpoint that truncate is just a quick DELETE, and so I do not agree that DELETE permissions should be enough to let you do a TRUNCATE. What about adding a truncate permission? I would find it useful, as it seems would others. That would be acceptable for me as well. I'd prefer it just work off delete, but as long as I can grant truncate to someone w/o giving them ownership rights on the table I'd be happy. Added to TODO: * Add TRUNCATE permission Currently only the owner can TRUNCATE a table because triggers are not called, and the table is locked in exclusive mode. Is anyone working on this yet? I looked at the code involved, and it seems there are just a couple of lines needed, some regression test and documentation updates, and most importantly, tab-completion updates. However, a question arose quickly: According to the standard, revoking INSERT, UPDATE and DELETE after GRANT ALL PRIVILEGES would leave the relation read-only, but with the TRUNCATE privilege lying around, this would no longer be true for PostgreSQL. Would this open a security hole or is it okay as far as extensions to the standard go? regards, Andreas -- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] beginning hackers (was: indexes spanning multiple
On Mon, Aug 22, 2005 at 06:48:52PM -0400, Rod Taylor wrote: Another source of items on the TODO list is the Unsupported Features portion of the SQL Conformance documentation: http://www.postgresql.org/docs/8.0/interactive/unsupported-features-sql-standard.html Maybe we should just have a generic link from TODO to that info? It doesn't seem to make sense to keep the same info in two places... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
