[BUGS] BUG #3318: PostgreSQL : server process (PID 3480) was terminated by signal 5
The following bug has been logged online: Bug reference: 3318 Logged by: chee leong Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Windows XP Description:PostgreSQL : server process (PID 3480) was terminated by signal 5 Details: Dear Sir/Madam, We have 2 pc, both also install postgreSQL, but one of the pc having problem in the middle of running program call to postgreSQL, but another one no problem at all. the problem as follow : 2007-05-14 09:55:36 LOG: server process (PID 3480) was terminated by signal 5 2007-05-14 09:55:36 LOG: terminating any other active server processes 2007-05-14 09:55:36 LOG: all server processes terminated; reinitializing 2007-05-14 09:55:36 LOG: database system was interrupted at 2007-05-14 09:53:42 Malay Peninsula Standard Time 2007-05-14 09:55:36 LOG: checkpoint record is at 1/D50D3610 Many thanks and hope you can give some info/suggestion for solving this problem. Thanks and regards, Chee Leong ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3319: Superuser can't revoke grants on a schema given by aother user
The following bug has been logged online:
Bug reference: 3319
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux
Description:Superuser can't revoke grants on a schema given by
aother user
Details:
When a USAGE grant on a SCHEMA is given by an user (non-superuser in my
case), the superuser can't revoke it; instead the REVOKE statement is
silently ignored. If a SET ROLE to the grantor is issued then the REVOKE
works as expected. I have not tried with a CREATE privilege.
Here's a test case suitable for psql:
CREATE USER user1;
CREATE USER user2;
CREATE DATABASE test1;
\c test1
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT USAGE ON SCHEMA public TO user1 WITH GRANT OPTION;
SET SESSION AUTHORIZATION user1;
GRANT USAGE ON SCHEMA public TO user2;
RESET SESSION AUTHORIZATION;
REVOKE USAGE ON SCHEMA public FROM user2;
\dn+ public
-- {...,user1=U*/postgres,user2=U/user1}
-- note user2 has still usage privileges
SET ROLE user1;
REVOKE USAGE ON SCHEMA public FROM user2;
RESET ROLE;
\dn+ public
-- {...,user1=U*/postgres}
-- this is expected
---(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
[BUGS] [HACKERS] exit
I would like to leave the list ... -- Acelerador POP Acelere a sua conexão discada em até 19 x. Use o Acelerador POP. É grátis, pegue já o seu. http://www.pop.com.br/acelerador
Re: [BUGS] [HACKERS] exit
Marcos Fabrício Corso wrote: I would like to leave the list ... Not really a question worth posting several lists. If you don't know how to unsubscribe, try starting with the form linked from here. http://www.postgresql.org/community/lists/ -- Richard Huxton Archonet Ltd ---(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
[BUGS] BUG #3320: Error when using INSERT...RETURNING as a subquery
The following bug has been logged online: Bug reference: 3320 Logged by: Jan Szumiec Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Windows XP Description:Error when using INSERT...RETURNING as a subquery Details: Having: CREATE TABLE efforts ( id serial NOT NULL, effort integer ) WITHOUT OIDS; CREATE TABLE items ( id serial NOT NULL, "type" character varying(255), created_at timestamp without time zone, subject character varying(255), body text, effort integer, CONSTRAINT items_pkey PRIMARY KEY (id) ) WITHOUT OIDS; executing the following query: UPDATE items SET (type, post_id) = (INSERT INTO efforts (effort) VALUES (667) RETURNING 'Item', id) WHERE id = 1937 produces this error: ERROR: syntax error at or near "INTO" SQL state:42601 Character:44 ---(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: [BUGS] BUG #3319: Superuser can't revoke grants on a schema given by aother user
"Pedro Gimeno" <[EMAIL PROTECTED]> writes:
> When a USAGE grant on a SCHEMA is given by an user (non-superuser in my
> case), the superuser can't revoke it; instead the REVOKE statement is
> silently ignored.
This is not a bug. If you want to revoke the privilege, revoke the
GRANT OPTION you originally gave. For example:
test1=# \dn+ public
List of schemas
Name | Owner | Access privileges|
Description
+--++
public | postgres | {postgres=UC/postgres,user1=U*/postgres,user2=U/user1} |
Standard public schema
(1 row)
test1=# revoke grant option for usage on schema public from user1;
ERROR: dependent privileges exist
HINT: Use CASCADE to revoke them too.
test1=# revoke grant option for usage on schema public from user1 cascade;
REVOKE
test1=# \dn+ public
List of schemas
Name | Owner |Access privileges| Description
+--+-+
public | postgres | {postgres=UC/postgres,user1=U/postgres} | Standard public
schema
(1 row)
Alternatively, since you are superuser, you can become user1 and revoke
the privilege he gave ...
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3320: Error when using INSERT...RETURNING as a subquery
"Jan Szumiec" <[EMAIL PROTECTED]> writes: > UPDATE items SET (type, post_id) = (INSERT INTO efforts (effort) VALUES > (667) RETURNING 'Item', id) WHERE id = 1937 Sorry, RETURNING is only supported at the top level of a query. regards, tom lane ---(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: [BUGS] BUG #3318: PostgreSQL : server process (PID 3480) was terminated by signal 5
What is signal 5 in XP? I looked in the MinGW source used to build PostgreSQL 8.1.4 and there is no mention of a signal 5 there. I see signal 5 mentioned here: http://archives.postgresql.org/pgsql-bugs/2004-11/msg00175.php and it was diagnosed as an invalid memory access. I suggest you upgrade to the newest release of 8.1.X, 8.1.9. It does not require you to dump your database. This might fix it: ftp://ftp5.ca.postgresql.org/mirrors/postgresql/binary/v8.1.9/win32 --- chee leong wrote: > > The following bug has been logged online: > > Bug reference: 3318 > Logged by: chee leong > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.4 > Operating system: Windows XP > Description:PostgreSQL : server process (PID 3480) was terminated by > signal 5 > Details: > > Dear Sir/Madam, > > We have 2 pc, both also install postgreSQL, but one of the pc > having problem in the middle of running program call to postgreSQL, but > another one no problem at all. > > the problem as follow : > > 2007-05-14 09:55:36 LOG: server process (PID 3480) was terminated > by signal 5 > 2007-05-14 09:55:36 LOG: terminating any other active server > processes > 2007-05-14 09:55:36 LOG: all server processes terminated; > reinitializing > 2007-05-14 09:55:36 LOG: database system was interrupted at > 2007-05-14 09:53:42 Malay Peninsula Standard Time > 2007-05-14 09:55:36 LOG: checkpoint record is at 1/D50D3610 > > Many thanks and hope you can give some info/suggestion for solving > this problem. > > Thanks and regards, > Chee Leong > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3318: PostgreSQL : server process (PID 3480) was terminated by signal 5
Bruce Momjian wrote: > What is signal 5 in XP? I looked in the MinGW source used to build > PostgreSQL 8.1.4 and there is no mention of a signal 5 there. I see > signal 5 mentioned here: Access denied. Most often showed for accessing memory outside the mapped space, so this similar to SIGSEGV. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3320: Error when using INSERT...RETURNING as a subquery
On Tue, May 29, 2007 at 09:41:38AM -0400, Tom Lane wrote: > "Jan Szumiec" <[EMAIL PROTECTED]> writes: > > UPDATE items SET (type, post_id) = (INSERT INTO efforts (effort) VALUES > > (667) RETURNING 'Item', id) WHERE id = 1937 > > Sorry, RETURNING is only supported at the top level of a query. What would be involved with making this possible? What we have at the moment is a pretty clear POLA violation because unlike the rest of the row-returning objects (tables, views, SRFs and VALUES() clauses), only RETURNING can't be used in a subquery. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3320: Error when using INSERT...RETURNING as a subquery
"David Fetter" <[EMAIL PROTECTED]> writes: > On Tue, May 29, 2007 at 09:41:38AM -0400, Tom Lane wrote: >> "Jan Szumiec" <[EMAIL PROTECTED]> writes: >> > UPDATE items SET (type, post_id) = (INSERT INTO efforts (effort) VALUES >> > (667) RETURNING 'Item', id) WHERE id = 1937 >> >> Sorry, RETURNING is only supported at the top level of a query. > > What would be involved with making this possible? What we have at the > moment is a pretty clear POLA violation because unlike the rest of the > row-returning objects (tables, views, SRFs and VALUES() clauses), only > RETURNING can't be used in a subquery. It has the same problem that SELECT triggers have. How many rows should you expect that subquery to insert, update, or delete if it's used in a join clause? Or in the where clause of another insert/update/delete statement? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3321: No start service
The following bug has been logged online: Bug reference: 3321 Logged by: Alceu Paz Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Windows XP Description:No start service Details: When the service of postgres initiates windows Xp this marked to initiate automatic and it does not initiate. Only manually, that I make? In some windows xp functions correctly in others not and the version of xp is the same one. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3320: Error when using INSERT...RETURNING as a subquery
On Tue, 2007-05-29 at 18:10 +0100, Gregory Stark wrote: > It has the same problem that SELECT triggers have. How many rows should you > expect that subquery to insert, update, or delete if it's used in a join > clause? Or in the where clause of another insert/update/delete statement? > We could handle it essentially like a volatile set-returning function. It may be easy to shoot oneself in the foot, but that is true for many uses of volatile functions. If the argument is that we shouldn't make it any easier, that's a fair point, but this is one possible definition. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3320: Error when using INSERT...RETURNING as a subquery
Jeff Davis <[EMAIL PROTECTED]> writes: > On Tue, 2007-05-29 at 18:10 +0100, Gregory Stark wrote: >> It has the same problem that SELECT triggers have. How many rows should you >> expect that subquery to insert, update, or delete if it's used in a join >> clause? Or in the where clause of another insert/update/delete statement? > We could handle it essentially like a volatile set-returning function. Uh-huh. Please provide a concise, accurate definition of what that does. For extra points, be sure it describes the behavior of all recent Postgres versions. (And after that, we could argue about whether we actually *like* the described behavior ... which I'll bet we won't.) regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
