Re: [BUGS] Segfaults and assertion failures with not too extraordinary views and queries
I wrote: > Hm, I see the assert failure, but this example doesn't seem to crash > when asserts are off, and I'd not expect it to: it should either work or > elog(ERROR) in ExecRestrPos. So maybe you've found more than one issue. The attached patch fixes the failure you exhibited, but I still don't see how this problem would lead to a non-assert crash --- what you should get is elog(ERROR, "unrecognized node type") from ExecRestrPos. So please try some more test cases and see if there's another problem lurking. BTW, the problem was due to code added in response to an earlier gripe of yours (allowing gating conditions to be pushed further down in the join tree). Maybe you're the only person stressing that particular aspect of the planner ... regards, tom lane bin6U84pyjFzO.bin Description: result-mark-82.patch ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Segfaults and assertion failures with not too extraordinary views and queries
Phil Frost <[EMAIL PROTECTED]> writes: > I have been attempting to migrate my application from 8.1 to 8.2.3. > In doing so, I found some queries would always cause the postgres > backend to die with a segfault. I was advised to rebuild with -- > enable-debug --enable-cassert, and so I did. The same query would now > cause an assertion failure instead of segfaulting. Hm, I see the assert failure, but this example doesn't seem to crash when asserts are off, and I'd not expect it to: it should either work or elog(ERROR) in ExecRestrPos. So maybe you've found more than one issue. Can you get a stack trace from a case that causes a non-assert core dump? (You don't need to rebuild, just set debug_assertions = 0 while testing.) regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] Segfaults and assertion failures with not too extraordinary views and queries
I have been attempting to migrate my application from 8.1 to 8.2.3.
In doing so, I found some queries would always cause the postgres
backend to die with a segfault. I was advised to rebuild with --
enable-debug --enable-cassert, and so I did. The same query would now
cause an assertion failure instead of segfaulting. I reduced a dump
of my database as much as possible and arrived at this:
SET client_min_messages = warning;
CREATE SCHEMA private;
CREATE TABLE private.orderitem (
objectid integer
);
CREATE FUNCTION public.i_have_global_priv() RETURNS boolean
AS $$
select true;
$$
LANGUAGE sql STABLE SECURITY DEFINER; -- removing security
definer avoids the problem
CREATE TABLE private.orderitemproduct (
objectid integer NOT NULL
);
CREATE VIEW public.orderitemproduct AS
SELECT orderitemproduct.objectid FROM private.orderitemproduct
WHERE i_have_global_priv(); -- not calling i_have_global_priv avoids
the problem
CREATE VIEW public.orderitem_with_prices AS
SELECT 1 FROM private.orderitem LEFT JOIN orderitemproduct USING
(objectid);
-- removing either pkey avoids the problem
ALTER TABLE ONLY private.orderitem
ADD CONSTRAINT orderitem_pkey PRIMARY KEY (objectid);
ALTER TABLE ONLY private.orderitemproduct
ADD CONSTRAINT orderitemproduct_pkey PRIMARY KEY (objectid);
SELECT * FROM orderitem_with_prices; -- succeeds
SELECT * FROM orderitem_with_prices limit 1; -- fails, output below
Apparently, even asking "EXPLAIN SELECT * FROM orderitem_with_prices
limit 1;" causes the same problem. The server log will contain this:
TRAP: FailedAssertion("!(!(eflags & 0x0008))", File: "nodeResult.c",
Line: 183)
LOG: server process (PID 12838) was terminated by signal 6
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2007-02-14 17:00:32 EST
LOG: checkpoint record is at 0/4AA38710
LOG: redo record is at 0/4AA38710; undo record is at 0/0; shutdown
FALSE
LOG: next transaction ID: 0/12285; next OID: 2457841
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery
in progress
LOG: redo starts at 0/4AA38758
LOG: unexpected pageaddr 0/43A54000 in log file 0, segment 74,
offset 10829824
LOG: redo done at 0/4AA53B24
LOG: database system is ready
gcc provides the wisdom:
Program received signal SIGABRT, Aborted.
0x9004796c in kill ()
(gdb) bt
#0 0x9004796c in kill ()
#1 0x9012dc14 in abort ()
#2 0x00206fa0 in ExceptionalCondition (conditionName=0x2 0x2 out of bounds>, errorType=0x25 ,
fileName=0x8 , lineNumber=80) at assert.c:51
#3 0x000f8c18 in ExecInitResult (node=0xe48740, estate=0x204901c,
eflags=8) at nodeResult.c:183
#4 0x000e60f8 in ExecInitNode (node=0xe48740, estate=0x204901c,
eflags=8) at execProcnode.c:141
#5 0x000f7aa0 in ExecInitMergeJoin (node=0xe4885c, estate=0x204901c,
eflags=0) at nodeMergejoin.c:1539
#6 0x000e61c8 in ExecInitNode (node=0xe4885c, estate=0x204901c,
eflags=0) at execProcnode.c:212
#7 0x000fa64c in ExecInitLimit (node=0xe488e8, estate=0x204901c,
eflags=0) at nodeLimit.c:337
#8 0x000e6258 in ExecInitNode (node=0xe488e8, estate=0x204901c,
eflags=0) at execProcnode.c:260
#9 0x000e5274 in ExecutorStart (queryDesc=0x2045c48, eflags=0) at
execMain.c:628
#10 0x001863b8 in PortalStart (portal=0x204701c, params=0x0,
snapshot=0x0) at pquery.c:426
#11 0x00182388 in exec_simple_query (query_string=0x202da1c "select *
from orderitem_with_prices limit 1;") at postgres.c:902
#12 0x00183c98 in PostgresMain (argc=4, argv=0x2011790,
username=0x20118a8 "postgres") at postgres.c:3424
#13 0x00154880 in ServerLoop () at postmaster.c:2931
#14 0x00155d38 in PostmasterMain (argc=3, argv=0x1900750) at
postmaster.c:963
#15 0x001094fc in main (argc=3, argv=0x1900780) at main.c:188
pg_config tells me that i run:
BINDIR = /usr/local/pgsql/bin
DOCDIR = /usr/local/pgsql/doc
INCLUDEDIR = /usr/local/pgsql/include
PKGINCLUDEDIR = /usr/local/pgsql/include
INCLUDEDIR-SERVER = /usr/local/pgsql/include/server
LIBDIR = /usr/local/pgsql/lib
PKGLIBDIR = /usr/local/pgsql/lib
LOCALEDIR =
MANDIR = /usr/local/pgsql/man
SHAREDIR = /usr/local/pgsql/share
SYSCONFDIR = /usr/local/pgsql/etc
PGXS = /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--with-python' '--with-openssl' '--enable-debug' '--
enable-cassert'
CC = gcc -no-cpp-precomp
CPPFLAGS =
CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -
Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
CFLAGS_SL =
LDFLAGS =
LDFLAGS_SL =
LIBS = -lpgport -lssl -lcrypto -lz -lreadline -lm
VERSION = PostgreSQL 8.2.3
uname adds:
Darwin Coding-Mac.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8
17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power
Macint
Re: [BUGS] BUG #2997: parse error: setObject("2004-August-15",java.sql.Types.DATE)
Bruce Momjian wrote:
> Floyd Shackelford wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference: 2997
> > Logged by: Floyd Shackelford
> > Email address: [EMAIL PROTECTED]
> > PostgreSQL version: 8.2.0
> > Operating system: windows xp
> > Description:parse error:
> > setObject("2004-August-15",java.sql.Types.DATE)
> > Details:
> >
> > jdbc: postgresql-8.2-504.jdbc3.jar
> >
> > this generates a number format exception:
> > preparedStatement.setObject(indx,"2004-August-15",java.sql.Types.DATE)
> >
> > this works:
> > preparedStatement.setObject(indx,"2004-08-15",java.sql.Types.DATE)
> >
> > i prefer to use the former.
>
> OK, but we only support the later.
Well to be specific, PostgreSQL supports both:
test=> select '2004-August-15'::date;
date
2004-08-15
(1 row)
but jdbc only supports the later, so I suggest you contact the jdbc
maintaners.
--
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 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2993: The program "postgres" is needed by initdb but was not found ...
On Wed, Feb 14, 2007 at 01:49:43PM +0100, Filippo Toso wrote: > Dear Magnus, > > > > The pgsql directory privileges are set to Everyone (Full Control). > > > > Hmm. Bummer. I really thought that was it. Can you check the full > > directory tree up to the root directory as well, to see if there's > > someplace else there where the user couldn't get in withotu admin/pu? > > The directory structure is the following: > > C:\pgsql\bin\initdb.exe > C:\pgsql\bin\postgres.exe > > I have logged out and re-logged in as an user of Users group. As this user I > can create/edit/delete all the files and directories in all the folders and > subfolders of C:\pgsql\, I can start C:\pgsql\bin\initdb.exe and it works > perfectly. If I try to do the same as Administrator, it fails. This sounds a lot like the user is getting the permissions through Administrators or Power Users. Note that Administrators != Administrator. If permissions are set with the group only, you will get the error. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2997: parse error: setObject("2004-August-15",java.sql.Types.DATE)
Floyd Shackelford wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2997
> Logged by: Floyd Shackelford
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.0
> Operating system: windows xp
> Description:parse error:
> setObject("2004-August-15",java.sql.Types.DATE)
> Details:
>
> jdbc: postgresql-8.2-504.jdbc3.jar
>
> this generates a number format exception:
> preparedStatement.setObject(indx,"2004-August-15",java.sql.Types.DATE)
>
> this works:
> preparedStatement.setObject(indx,"2004-08-15",java.sql.Types.DATE)
>
> i prefer to use the former.
OK, but we only support the later.
--
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 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [BUGS] BUG #2975: UNIQUE INDEX doesn't work
On Wed, Feb 14, 2007 at 10:01:58AM +0100, Steven Lambert wrote: > You are right, the index has more columns and one of them have most of the > time the value NULL. > It is the date when the record has been "deleted" See "Unique Constraints" in the documentation, in particular the last paragraph: http://www.postgresql.org/docs/8.1/interactive/ddl-constraints.html#AEN2016 "However, null values are not considered equal in this comparison. That means even in the presence of a unique constraint it is possible to store duplicate rows that contain a null value in at least one of the constrained columns." This has been discussed before; search the archives for words like "null", "unique", and "comparison" or "compare". -- Michael Fuhr ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2998: Installation Failed due to Permissions
On Tue, Feb 13, 2007 at 05:22:01AM +, Michael wrote: > > The following bug has been logged online: > > Bug reference: 2998 > Logged by: Michael > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.3 > Operating system: Windows XP SP2 > Description:Installation Failed due to Permissions > Details: > > I tried installing but I get > > Failed to set permission on the installed files. > Please see the logfile in 'C:/\8.2\tmp\pgpem.log'. > > I am installing using my own admin account with full rights. Can you please > help me to fix this? did you check what's in the logfile? Also, check the permissinoso n the install path and all the way down - full permissions for *your* account is required to set the permissions (the service account only needs read on things except the data directory) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2993: The program "postgres" is needed by initdb but was not found ...
On Mon, Feb 12, 2007 at 09:08:11PM +0100, Filippo Toso wrote: > Dear Magnus, > > > Can you check the permissions on your pgsql directory? If your account > > only has permissions through the admin or power users group, you will > > need to grant it explicit permissions (since it gives up admin and power > > users when it starts) > > > > //Magnus > > The pgsql directory privileges are set to Everyone (Full Control). Hmm. Bummer. I really thought that was it. Can you check the full directory tree up to the root directory as well, to see if there's someplace else there where the user couldn't get in withotu admin/pu? //Magnus ---(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
