Re: [BUGS] BUG #5763: pg_hba.conf not honored
On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane wrote: > "Kaiting Chen" writes: >> From this pg_hba configuration as the user 'kaiting.chen' is not in role >> 'service' the second entry in the table should be skipped and he should >> authenticate via GSSAPI. However this does not happen. > > I believe the definition of "in role" we use here is "has the privileges > of role". Since kaiting.chen is a superuser, all privilege tests will > succeed for him, including that one. IOW, a superuser is automatically > a member of every role. This isn't a bug. I guess it's not a bug if we did it that way on purpose, but it seems like testing for actual group membership would be less surprising. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Documentation bug: Chapter 35.4, paragraph 4
On Tue, Nov 23, 2010 at 1:08 PM, Jonathan Pool wrote: > Chapter 35.4, paragraph 4, of the PostgreSQL 9.0.1 Documentation says: > > Any collection of commands in the SQL language can be packaged together and > defined as a function. Besides SELECT queries, the commands can include data > modification queries (INSERT, UPDATE, and DELETE), as well as other SQL > commands. (The only exception is that you cannot put BEGIN, COMMIT, ROLLBACK, > or SAVEPOINT commands into a SQL function.) > > This appears to be incorrect, in that attempting to include a VACUUM command > in a query-language function elicits the following error message: > > ERROR: VACUUM cannot be executed from a function or multi-command string > > Thus, presumably "VACUUM" should be added to the list of exceptions. I fear it's worse than that. Taking a look at the places where we call PreventTransactionChain(), they appear to include database-wide CLUSTER, DISCARD ALL, VACUUM (as you noted), COMMIT PREPARED, ROLLBACK PREPARED, CREATE TABLESPACE, DROP TABLESPACE, ALTER TYPE ADD VALUE (but the PreventTransactionChain call says ADD rather than ADD VALUE), CREATE INDEX CONCURRENTLY, CREATE DATABASE, DROP DATABASE, and REINDEX DATABASE. I'm not sure if there's some generic way we could refer to all that rather than listing them all individually. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5774: VACCUM & REINDEX kills production environement
The following bug has been logged online: Bug reference: 5774 Logged by: Bala Murugan Email address: b...@a-cti.com PostgreSQL version: 8.3.7 Operating system: openSUSE 10.3 (X86-64) - Kernel \r (\l). Description:VACCUM & REINDEX kills production environement Details: Iam running postgres 8.3 version for more than 2 yrs on Amazon EC2 Instance, in recent days Vaccum and reindex make the application down for more than 2hrs. I am not sure this because of my configuration or postgres. My hardware details : High-CPU Extra Large Instance 7 GB of memory 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each) 1690 GB of instance storage 64-bit platform conf : ## Connections port = 5432 max_connections= 1000 listen_addresses = '*' ## Memory usage shared_buffers = '1 GB' maintenance_work_mem = '448 MB' max_fsm_pages = 22 max_fsm_relations = 1000 max_prepared_transactions = 0 ## Performance checkpoint_segments= 16 effective_cache_size = '5 GB' ## To fix bad plans caused by partitioning 3/8/2010 random_page_cost = 6 ## Logging # Where and how: log_destination= 'stderr' logging_collector = on log_directory = 'pg_log' log_filename = 'postgresql-%Y-%m-%d.log' #log_line_prefix= '%t %r[%p]: [%l-1]' log_line_prefix = 'user=%u,db=%d ' # What: log_min_duration_statement = 200 log_connections= on log_disconnections = on log_duration = off log_statement = 'ddl' # Cleanup log_rotation_age = '1d' log_rotation_size = 0 log_temp_files = 0 ## Statistics #default_statistics_target = 700 default_statistics_target = 100 ## Autovacuum #autovacuum = on #autovacuum_vacuum_scale_factor = 0.1 ## Bulkloading - keep these on! fsync = on full_page_writes = on # We're partitioning the historysystem.history table constraint_exclusion = on checkpoint_completion_target = 0.9 wal_buffers = '8 MB' # Changed 3/2/2010 in response to historySystem.history queries work_mem = '44 MB' statement_timeout = 0 thanks, Bala -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
Thanks all for your help!! I am not sure that I'll get all my needed function from built-in UUID. I got the source from the below link also this works perfectly fine with 8.3 version(in my understanding). http://ring.nict.go.jp/archives/misc/db/postgresql/projects/gborg/uniqueidentifier/stable/uniqueidentifier-0.2.tar.gz I am very much excited to use UUID, please let me know if there is any link where i can download and compile all my needed functions, Also I cannot change my function on my production environment in case needed for uuid which might needed long hours of testing and hope some of our application might be in trouble. Please find the attachment for needed functions. Again,thanks for everyone who is helping me on this issue. Thanks, Bala On Sun, Nov 28, 2010 at 2:54 AM, Tom Lane wrote: > Joshua Tolley writes: > > On Sat, Nov 27, 2010 at 11:23:46AM -0500, Tom Lane wrote: > >> There used to be a project of that name on gborg. I can't find the > >> source code anymore though. > > > How about > > http://www.postgresql.org/ftp/projects/gborg/uniqueidentifier/stable/ > > Ah, thanks. > > >> The magic-block mechanism should prevent that. What I'm wondering about > >> is whether the input function is (a) careless about null input and (b) > >> not marked STRICT. > > > I think you're right: > > You're looking at the output function not the input function ... and > indeed the first thing the input function does is to invoke strlen(), > without any null check. > > > It should use PG_ARGISNULL(0), no? > > It'd be better to mark it STRICT in the SQL file (and likewise for the > output function). Or actually what he *should* do is drop the whole > thing and use the now-built-in uuid type. > > Now, this 2003-vintage tarball is obviously not what the OP is using, > since it hasn't even got a PG_MODULE_MAGIC call. But if it hasn't > been updated any more than that, this'd explain a core dump on NULL > input. What's a bit less clear is how the null got into the source > database without having triggered the same bug; but I suppose it > might've been generated via INSERT DEFAULT VALUES or some such. > >regards, tom lane > uniqueidentifier.sql Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5774: VACCUM & REINDEX kills production environement
On Sun, Nov 28, 2010 at 07:25:52AM +, Bala Murugan wrote: > > The following bug has been logged online: > > Bug reference: 5774 > Logged by: Bala Murugan > Email address: b...@a-cti.com > PostgreSQL version: 8.3.7 > Operating system: openSUSE 10.3 (X86-64) - Kernel \r (\l). > Description:VACCUM & REINDEX kills production environement > Details: > > Iam running postgres 8.3 version for more than 2 yrs on Amazon EC2 Instance, > in recent days Vaccum and reindex make the application down for more than > 2hrs. I am not sure this because of my configuration or postgres. is it normal vacuum? or are you using "vacuum full"? generally - voth vacuum full and reindex do lock tables for exclusive access. that's why you generally don't use them! vacuum full is especially frowned upon. as for reindex - if you *really* need it (are you sure? what makes you think you need it), then there are ways to do reindex without actually using "reindex" command, which are mostly transparent for users, but you should check if you really need to run reindex at all. Best regards, depesz -- Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/ jid/gtalk: dep...@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
Balamurugan Mahendran writes: > I am not sure that I'll get all my needed function from built-in UUID. I got > the source from the below link also this works perfectly fine with 8.3 > version(in my understanding). > http://ring.nict.go.jp/archives/misc/db/postgresql/projects/gborg/uniqueidentifier/stable/uniqueidentifier-0.2.tar.gz No, it doesn't work "perfectly fine" with 8.3, it's got the same bug it always had. You were just lucky enough to avoid stumbling over it before. > I am very much excited to use UUID, please let me know if there is any link > where i can download and compile all my needed functions, The core uuid type has all that stuff except newid(), which we judged not to be standardizable. You can find a few different uuid-creation functions in contrib/uuid-ossp. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5763: pg_hba.conf not honored
Robert Haas writes: > On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane wrote: >> I believe the definition of "in role" we use here is "has the privileges >> of role". Since kaiting.chen is a superuser, all privilege tests will >> succeed for him, including that one. IOW, a superuser is automatically >> a member of every role. This isn't a bug. > I guess it's not a bug if we did it that way on purpose, but it seems > like testing for actual group membership would be less surprising. Then you'd have superusers acting like they were group members for some purposes and not others. Not sure how that would be less surprising. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5763: pg_hba.conf not honored
On Sun, Nov 28, 2010 at 11:46 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane wrote: >>> I believe the definition of "in role" we use here is "has the privileges >>> of role". Since kaiting.chen is a superuser, all privilege tests will >>> succeed for him, including that one. IOW, a superuser is automatically >>> a member of every role. This isn't a bug. > >> I guess it's not a bug if we did it that way on purpose, but it seems >> like testing for actual group membership would be less surprising. > > Then you'd have superusers acting like they were group members for some > purposes and not others. Not sure how that would be less surprising. From a permissions perspective, the superuser's power ought to be defined as "bypasses all permissions checks" rather than "has privileges of every role", even though having some code that does the latter may be useful as an implementation detail. Here it seems to me roles are being used for grouping, not permissions checking. Think in particular about a reject rule for a certain group of users. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5771: C:\Program Files\PostgreSQL\8.3\Data is not accessible.
Hi Kevin, Thanks for prompt reply. I will make sure about all you have mentioned here and will let you know if find any other issue. Thanks and Regards, Shafqat -Original Message- From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov] Sent: Saturday, November 27, 2010 1:51 AM To: Shafqat Ali; pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #5771: C:\Program Files\PostgreSQL\8.3\Data is not accessible. "Shafqat Ali" wrote: > Operating system: XP Professional SP3 > Description: C:\Program Files\PostgreSQL\8.3\Data is not > accessible. From what little information you provided, this sounds more likely to be a permissions issue under Windows security than anything else. If you don't think it is, please review this page so you can provide enough information to allow others to make a more educated guess at what's happening on your machine: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
