Re: [BUGS] BUG #2034: Wrong time zone IST
"Neeraj Malhotra" <[EMAIL PROTECTED]> writes: > In postgreSQL IST timezone is being used for Israel Standard Time(+2:00) > which is incorrect. IST stands for Indian Standard Time(+5:30). Please > correct it because it is causing problem in our applications. Unfortunately, what's "wrong" to you is "right" to the Israelis. Eventually we'll probably fix things so that the list of known timezone abbreviations is stored in a config file and can be customized for local needs more easily. In the meantime there's not a lot we can do about this sort of conflict. If you like you can make a locally modified version with your interpretation of IST --- look at the token table in src/backend/utils/adt/datetime.c. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2034: Wrong time zone IST
On Thu, Nov 10, 2005 at 12:10:27PM +, Neeraj Malhotra wrote: > In postgreSQL IST timezone is being used for Israel Standard Time(+2:00) > which is incorrect. IST stands for Indian Standard Time(+5:30). Please > correct it because it is causing problem in our applications. IST means something different depending on whether you're in India, Israel, or Ireland. This has come up before; allowing users to customize it is on the developers' TODO list but nobody's gotten around to it. http://archives.postgresql.org/pgsql-bugs/2004-01/msg00202.php http://archives.postgresql.org/pgsql-hackers/2004-10/msg00766.php http://www.postgresql.org/docs/faqs.TODO.html In the first message above, Tom Lane suggests hacking src/backend/utils/adt/datetime.c if you want to fix your own system. -- Michael Fuhr ---(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: [BUGS] BUG #2032: grant role bug
[EMAIL PROTECTED] writes:
> here is an 'real' output of psql in our test scenario.
I tried to duplicate this example, but it still works fine for me.
> testdb1=> \du
>List of users
> User name | User ID | Attributes | Groups
> ---+-++-
> allgemein | 22584 || {g_usermgr_use}
> enduser | 24364 || {g_usermgr_use}
> postgres | 10 | superuser, create database |
> usermgr | 22583 ||
> (4 rows)
This makes me suspicious, because you are evidently using an 8.0 (or
older) psql; 8.1's \du output does not look like that. While using an
old psql with a new backend shouldn't affect the behavior of GRANT,
I wonder whether this is a symptom of pilot error at another level.
Is it possible that you are talking to an 8.0 postmaster as one user
and an 8.1 postmaster as the other user? Then the two "testdb1"
databases wouldn't be the same database at all. You can use
"select version()" and "show data_directory" to positively confirm
the identity of the postmaster you are connected to.
> testdb1=> \dp+
> Access privileges for database "testdb1"
> Schema | Name | Type | Access privileges
> +--+--+---
> (0 rows)
I believe this only shows stuff that is in your search path, which the
usermgr schema wouldn't be by default for enduser. Try
\dp usermgr.*
regards, tom lane
---(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: [BUGS] BUG #2031: Patch also required prior to ML3
Seneca Cunningham wrote: Mark Gibson wrote: AIX hasn't had any maintence levels applied yet, so oslevel -r returns: 5300-01. _SS_MAXSIZE has been set to 1025 manually, this was required for 8.0.4. But with 8.1.0 the patch for dynahash.c had to be applied before the regression tests would run. So the problem described in FAQ_AIX appears not to be specific to AIX 5.3 ML3. What do "instfix -ci | grep bos.rte.bind_cmds" and "instfix -ci | grep bos.adt.base" return? $ instfix -ci | grep bos.rte.bind_cmds IY58143:bos.rte.bind_cmds:5.3.0.1:5.3.0.10:+:Required fixes for AIX 5.3 IY59386:bos.rte.bind_cmds:5.3.0.10:5.3.0.10:=:ld -m does not produce any output IY60158:bos.rte.bind_cmds:5.3.0.10:5.3.0.10:=:RESOLVEALL LDR_CNTRL variable setting IY60696:bos.rte.bind_cmds:5.3.0.10:5.3.0.10:=:nm symbol size printing truncates IY62441:bos.rte.bind_cmds:5.3.0.10:5.3.0.10:=:FVTR_SERV: dump -t +t does not give proper output 5300-01_AIX_ML:bos.rte.bind_cmds:5.3.0.10:5.3.0.10:=:AIX 5300-01 Update $ instfix -ci | grep bos.adt.base IY58689:bos.adt.base:5.3.0.10:5.3.0.10:=:cxref with -w num option fails IY58712:bos.adt.base:5.3.0.10:5.3.0.10:=:cxref,cflow,lint fail of variable starts with dollar IY59454:bos.adt.base:5.3.0.10:5.3.0.10:=:as produces renamed symbols in object file IY60145:bos.adt.base:5.3.0.10:5.3.0.10:=:cflow outputs a warning msg. IY60146:bos.adt.base:5.3.0.10:5.3.0.10:=:lint command outputs warning message IY60681:bos.adt.base:5.3.0.10:5.3.0.10:=:make fails with more than one (.) in the source path IY61149:bos.adt.base:5.3.0.10:5.3.0.10:=:do not invoke assembler with 'cc -qarch=pwr4' 5300-01_AIX_ML:bos.adt.base:5.3.0.10:5.3.0.10:=:AIX 5300-01 Update -- Mark Gibson Web Developer & Database Admin Cromwell Tools Ltd. Leicester, England. ___ This email is intended for the named recipient. The information contained in it is confidential. You should not copy it for any purposes, nor disclose its contents to any other party. If you received this email in error, please notify the sender immediately via email, and delete it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. Registered Office: PO Box 14, Chartwell Dr, Wigston, Leicester. LE18 1AT __ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
R: [BUGS] Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited").
Title: Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited"). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cristiano AnsaloniSent: 08 November 2005 15:35To: pgsql-bugs@postgresql.orgSubject: [BUGS] Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited"). Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited"). Cache size of 0/unlimited makes no sense. The cache is only used in declare/fetch mode, so if you want to fetch all rows at once, just turn off use declare/fetch. Instead, the "Maximum rows to retrieve" option in the Tab 3 of pgAdmin options works good. pgAdmin III doesn't use ODBC, and besides, that option is not analagous to psqlODBC's cache size setting in the slightest. I would suggest reading the appropriate doc pages for each product. I have read the documentation: Use Declare/Fetch: If true, the driver automatically uses declare cursor/fetch to handle SELECT statements and keeps 100 rows in a cache. This is mostly a great advantage, especially if you are only interested in reading and not updating. It results in the driver not sucking down lots of memory to buffer the entire result set. If set to false, cursors will not be used and the driver will retrieve the entire result set. For very large tables, this is very inefficient and may use up all the Windows memory/resources. However, it may handle updates better since the tables are not kept open, as they are when using cursors. This was the style of the old podbc32 driver. However, the behavior of the memory allocation is much improved so even when not using cursors, performance should at least be better than the old podbc32. The problem is that this documentation says the opposite of true: with this option false (the default) there is the 100 rows limit, with this option true the cursor is "free". I have tested it. Moreover, this "new" default change the "old" default and so all "old configurations" odbc are wrong. Sorry for my english. Regards, Ans.
Re: [BUGS] BUG #2032: grant role bug
Hi Tom,
here is an 'real' output of psql in our test scenario.
psql-output as user : enduser
testdb1=> \du
List of users
User name | User ID | Attributes | Groups
---+-++-
allgemein | 22584 || {g_usermgr_use}
enduser | 24364 || {g_usermgr_use}
postgres | 10 | superuser, create database |
usermgr | 22583 ||
(4 rows)
psql-output as user : usermgr
testdb1=> grant usage on schema usermgr to g_usermgr_use;
GRANT
testdb1=> grant select on table usermgr.a to g_usermgr_use;
GRANT
testdb1=> grant select on table usermgr.b to g_usermgr_use;
GRANT
testdb1=> \dn+
List of schemas
Name| Owner | Access privileges|
Description
+--+--+-
-
enduser| enduser ||
information_schema | postgres | {postgres=UC/postgres,=U/postgres}|
pg_catalog | postgres | {postgres=UC/postgres,=U/postgres}|
System catalog schema
pg_toast | postgres ||
Reserved schema for TOAST tables
public | postgres | {postgres=UC/postgres,=UC/postgres}|
Standard public schema
usermgr| usermgr |
{usermgr=UC/usermgr,g_usermgr_use=U/usermgr} |
(6 rows)
testdb1=> \dp
Access privileges for database "testdb1"
Schema | Name | Type | Access privileges
-+--+---+---
usermgr | a| table |
{usermgr=arwdRxt/usermgr,g_usermgr_use=r/usermgr}
usermgr | b| table |
{usermgr=arwdRxt/usermgr,g_usermgr_use=r/usermgr}
(2 rows)
now I tried a select on table a as user enduser
testdb1=> select * from usermgr.a;
ERROR: permission denied for schema usermgr
testdb1=>
testdb1=> \dp+
Access privileges for database "testdb1"
Schema | Name | Type | Access privileges
+--+--+---
(0 rows)
Did I miss anything ? Is it neccessary to activate the role-membership or
is there any other precondition that must be fullfilled
before the right privileges can be handled ?
Thanks
Tom
Tom Lane <[EMAIL PROTECTED]>
09.11.2005 16:38
An: "Tom" <[EMAIL PROTECTED]>
Kopie: pgsql-bugs@postgresql.org
Thema: Re: [BUGS] BUG #2032: grant role bug
"Tom" <[EMAIL PROTECTED]> writes:
> GRANT usage on SCHEMA usermgr to g_usermgr_use;
> GRANT select on table a to g_usermgr;
> GRANT select on table b to g_usermgr;
Perhaps you meant to grant those select privileges to g_usermgr_use ?
Also, are you sure you were granting privileges on usermgr.a, and not
some other table named A in a different schema?
If you want us to believe this doesn't work, you'll need to send an
exact transcript of what you did (copy and paste from a terminal window
works well), not a rather handwavy description that might or might not
contain errors.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2034: Wrong time zone IST
The following bug has been logged online: Bug reference: 2034 Logged by: Neeraj Malhotra Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.2 Operating system: Fedora Core 4 Description:Wrong time zone IST Details: In postgreSQL IST timezone is being used for Israel Standard Time(+2:00) which is incorrect. IST stands for Indian Standard Time(+5:30). Please correct it because it is causing problem in our applications. Thanks & Regards ---(end of broadcast)--- TIP 6: explain analyze is your friend
