Re: [BUGS] Re: BUG #5065: pg_ctl start fails as administrator, with could not locate matching postgres executable
On Tue, Oct 20, 2009 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: Seems like it would be worth the trouble to identify exactly what the critical difference is. Given Jesse's description of the systems he's seen this on, I suspect we'll be very lucky if we pin that down, unless it is something as simple as win2k3+administrator+command line (which I'll try to test shortly) - but that doesn't tally with the occasional cases of this I still hear about (usually from our poker-playing users) who are using the installer and Vista or XP as a general rule. The other thing to bear in mind is that the entire OS and much of the surrounding software (such as AV) is closed source, so we have no idea what any of it is doing under the hood, or how it may have changed from version to version. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PGDay.EU 2009 Conference: http://2009.pgday.eu/start -- 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 #5129: LIMIT not correct.
On Wednesday 21 October 2009 05:37:36 Thach Anh Tran wrote: The following bug has been logged online: Bug reference: 5129 Logged by: Thach Anh Tran Email address: myqua...@gmail.com PostgreSQL version: 8.3.8 Operating system: Linux Description:LIMIT not correct. Details: the LIMIT clause is not reply correct number of rows and rows returns. Read the second caution block in the relevant section of the manual: http://www.postgresql.org/docs/current/interactive/sql-select.html#SQL-FOR- UPDATE-SHARE It is possible for a SELECT command using both LIMIT and FOR UPDATE/SHARE clauses to return fewer rows than specified by LIMIT. This is because LIMIT is applied first. The command selects the specified number of rows, but might then block trying to obtain a lock on one or more of them. Once the SELECT unblocks, the row might have been deleted or updated so that it does not meet the query WHERE condition anymore, in which case it will not be returned. Andres -- 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] Re: BUG #5065: pg_ctl start fails as administrator, with could not locate matching postgres executable
On Wed, Oct 21, 2009 at 8:45 AM, Dave Page dp...@pgadmin.org wrote:
On Tue, Oct 20, 2009 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Seems like it would be worth the trouble to identify exactly what the
critical difference is.
Given Jesse's description of the systems he's seen this on, I suspect
we'll be very lucky if we pin that down, unless it is something as
simple as win2k3+administrator+command line (which I'll try to test
shortly) - but that doesn't tally with the occasional cases of this I
still hear about (usually from our poker-playing users) who are using
the installer and Vista or XP as a general rule.
I tested in 2k3, and was surprised to see that whilst initdb worked
fine in 8.4.1 (that's where the problem traditionally shows up),
starting the server failed:
C:\pgsqlbin\pg_ctl -D data start
server starting
C:\pgsqlFATAL: XX000: C:/pgsql/bin/postgres.exe: could not locate
matching postgres executable
LOCATION: getInstallationPaths, .\src\backend\postmaster\postmaster.c:1070
Jesse's patched version works as it should. This makes it clear that
the re-factoring of the way the security token is created and the
process started is not the really important part of this patch - this
is:
- if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, psidUser))
- {
+ if (!AddAccessAllowedAceEx(pacl, ACL_REVISION, OBJECT_INHERIT_ACE,
GENERIC_ALL, psidUser))
+ {
This function call is adding the new access control entry to the DACL,
and in Jesse's modified version it's specifying that the ACE should be
inheritable.
The other refactoring is still important however - without it, I still
see the error. I would guess that you cannot add an inheritable ACE
once the process has been created, but I cannot say for certain.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start
--
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 #5127: AbstractJdbc2Connection#doRollback should throws Exception if connection is closed
Is it possible that you have autoCommit set to true? No, it is impossible as you know. Sample code I wrote is just a sample. Actually I use a DI container (Seasar, it is a popular DI container in Japan), and Seasar provides DBCP implementation. This makes me concerned that fixing the bug in the JDBC driver could expose serious bugs in application code, and break things which are currently working, for some values of working. :-( Indeed. But on the other hand, it is serious problem that PostgreSQL doesn't behave like other JDBC drivers. On a related note, JDK 6's JDBC is based on JDBC 4.0 spec. I see JDK 5's, and I found a bit of difference to 6's. http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Connection.html#rollback() | SQLException - if a database access error occurs or this Connection | object is in auto-commit mode There is no explicit spec about use of closed connection! Because PostgreSQL's JDBC Driver is based on JDBC 3 specification, it maybe that this is not a bug. I'm still thinking that this is driver's bug. But if PostgreSQL team decides that it's not a bug and won't fix, I accept the inevitable. And I wait for a version compliant for JDBC 4.0. Regards, takiguchi -- 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] Re: BUG #5065: pg_ctl start fails as administrator, with could not locate matching postgres executable
Dave Page dp...@pgadmin.org writes: This function call is adding the new access control entry to the DACL, and in Jesse's modified version it's specifying that the ACE should be inheritable. Hah, so now we have a theory. The other refactoring is still important however - without it, I still see the error. I would guess that you cannot add an inheritable ACE once the process has been created, but I cannot say for certain. That would make sense if the state gets copied to the process at time of creation. Okay, I'm satisfied that this is a believable patch... 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] Re: BUG #5065: pg_ctl start fails as administrator, with could not locate matching postgres executable
On Wed, Oct 21, 2009 at 15:07, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: This function call is adding the new access control entry to the DACL, and in Jesse's modified version it's specifying that the ACE should be inheritable. Hah, so now we have a theory. The other refactoring is still important however - without it, I still see the error. I would guess that you cannot add an inheritable ACE once the process has been created, but I cannot say for certain. That would make sense if the state gets copied to the process at time of creation. Okay, I'm satisfied that this is a believable patch... From a quick look, it looks fine to me. I don't have time to do a complete check right now, but I'll do that as soon as I can and then commit it - unless people feel it's more urgent than maybe a week worst case, in which case someone else has to pick it up :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] Re: BUG #5065: pg_ctl start fails as administrator, with could not locate matching postgres executable
Magnus Hagander wrote: From a quick look, it looks fine to me. I don't have time to do a complete check right now, but I'll do that as soon as I can and then commit it - unless people feel it's more urgent than maybe a week worst case, in which case someone else has to pick it up :-) I'd rather wait till you can check it. cheers andrew -- 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 #5129: LIMIT not correct.
Andres Freund and...@anarazel.de writes: On Wednesday 21 October 2009 05:37:36 Thach Anh Tran wrote: the LIMIT clause is not reply correct number of rows and rows returns. Read the second caution block in the relevant section of the manual: http://www.postgresql.org/docs/current/interactive/sql-select.html#SQL-FOR- UPDATE-SHARE There has been some discussion of changing that, and it might happen for 8.5. It's essentially impossible to fix in existing releases though, because changing it requires a major restructuring of the executor. 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
[BUGS] BUG #5130: Failed to run initdb:1
The following bug has been logged online: Bug reference: 5130 Logged by: Email address: flamindrag...@gmail.com PostgreSQL version: any Operating system: Win XP Pro SP2 Description:Failed to run initdb:1 Details: here's the log of the bug The files belonging to this database system will be owned by user SYSTEM. This user must also own the server process. The database cluster will be initialized with locale Polish_Poland.1250. initdb: could not find suitable text search configuration for locale Polish_Poland.1250 The default text search configuration will be set to simple. creating directory C:/Program Files/PostgreSQL/8.3/data ... ok creating subdirectories ... ok selecting default max_connections ... Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. 10 selecting default shared_buffers/max_fsm_pages ... Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. 400kB/2 creating configuration files ... ok creating template1 database in C:/Program Files/PostgreSQL/8.3/data/base/1 ... ok initializing pg_authid ... Nie moľna odnale«† okre˜lonego pliku. child process exited with exit code 1 initdb: removing data directory C:/Program Files/PostgreSQL/8.3/data Nie moľna odnale«† okre˜lonego pliku. = unable to find the file -- 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 #5126: convert_to preventing index scan
On Mon, 2009-10-19 at 11:05 +, Roman Kapusta wrote: I have table with bytea column, which is indexed (1) I want to use index during pattern matching (eg. dir like someDirectoryName || '/%'), but concatenation of two strings cause error (2) So I have to use function convert_to (converting text to bytea), but this has awful explain plan (3) You haven't told us how the convert_to function is defined. -- 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 #5131: The pgsql will lost
The following bug has been logged online: Bug reference: 5131 Logged by: aihongwei Email address: ufo008...@163.com PostgreSQL version: 8.0.0 Operating system: linux x86_64 Description:The pgsql will lost Details: In x86_64 platform, I input command ulimit -s 2048 to limit the stack size.Then I startup the server,and when i do some recursion operation, the pgsql will lost in some time. It seems that The stack_max_depth does work. example: CREATE FUNCTION infinite_recurse() returns int as 'select infinite_recurse()' language sql; select infinite_recurse(); -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
