[BUGS] Error with refering to the header files
Hi , I’m new to postgres and I have some C files that execute sql commands in the early parser stage.. It has to include #include "libpq-fe.h" which is in the "interface" folder not the "include" folder so I edited the make file like following: #- # # Makefile for parser # # src/backend/parser/Makefile # #- SHLIB_LINK = $(libpq) SHLIB_PREREQS = submake-libpq FLEXFLAGS = -CF all: all-shared-lib subdir = src/backend/parser top_builddir = ../../.. include $(top_builddir)/src/Makefile.global include $(top_srcdir)/src/Makefile.shlib override CPPFLAGS := -I. -I$(srcdir) -I$(libpq_srcdir) $(CPPFLAGS) OBJS= analyze.o gram.o keywords.o kwlookup.o parser.o \ parse_agg.o parse_clause.o parse_coerce.o parse_collate.o parse_cte.o \ parse_expr.o parse_func.o parse_node.o parse_oper.o parse_param.o \ parse_relation.o parse_target.o parse_type.o parse_utilcmd.o scansup.o \ asqlTranslate.o annotation_catalog.o asql_add.o asql_archive.o asql_create.o \ asql_exec.o asql_select.o asql_utilts.o asql_updateAuthorization.o install: all installdirs install-lib installdirs: installdirs-lib uninstall: uninstall-lib clean distclean maintainer-clean: clean-lib include $(top_srcdir)/src/backend/common.mk # scan is compiled as part of gram gram.o: scan.c # Latest flex causes warnings in this file. ifeq ($(GCC),yes) gram.o: CFLAGS += -Wno-error -fPIC endif # There is no correct way to write a rule that generates two files. # Rules with two targets don't have that meaning, they are merely # shorthand for two otherwise separate rules. To be safe for parallel # make, we must chain the dependencies like this. The semicolon is # important, otherwise make will choose the built-in rule for # gram.y=>gram.c. gram.h: gram.c ; gram.c: gram.y ifdef BISON $(BISON) -d $(BISONFLAGS) -o $@ $< else @$(missing) bison $< $@ endif scan.c: scan.l ifdef FLEX $(FLEX) $(FLEXFLAGS) -o'$@' $< else @$(missing) flex $< $@ endif # Force these dependencies to be known even without dependency info built: gram.o keywords.o parser.o: gram.h # gram.c, gram.h, and scan.c are in the distribution tarball, so they # are not cleaned here. But I get the following error: --enable-new-dtags -L../../../src/interfaces/libpq -lpq /usr/bin/ld: analyze.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC analyze.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [.so] Error 1 --- Can anyone help please?? Thank you, Karim -- 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] pg_dump: SQL command failed
Hi, Tom. Thanks for the quick reply. anyway, for the purposes of options such as "-n".) So on reload, the > user function fails; it's referencing a function that doesn't exist > in the new database. That's not a bug. > I'm probably not understanding something: I'm not importing anything into a new database. I'm trying to dump an existing database that uses a couple of extensions. It is not intuitive that using extension functions cause pg_dump to fail. (The pg_dump has no command to work-around the issue.) I think I understand why this is (because the import into a new database would fail without the requisite extension), but surely that should generate an error on *import*, rather than on *export*? What am I "reloading" when running pg_dump? Also, pg_dump need not export the extension statement (although, that would be a nice feature). The expected behaviour is that pg_dump should export a valid database (to a text file). How else can I make a back-up? What I take from this is that it is not possible to use pg_dump to dump a database that uses extensions. That is what I believe to be a bug. > BTW, the reason the unaccent function isn't marked immutable is that its > behavior can be changed with ALTER TEXT DICTIONARY. This wrapper > function doesn't eliminate that risk (in fact it adds some new ones), > so it doesn't look very safe to me. > Thank you for the note! I'm using the following index: CREATE INDEX unaccented_words_idx ON superschema.table_name USING gin (superschema.unaccent_text(label::text) COLLATE pg_catalog."default" gin_trgm_ops); This was necessary so that an autocomplete field would match "creme" to "Crème" when using the ~~ operator, for example: SELECT id, label FROM superschema.table_name WHERE superschema.unaccent_text(label) ~~ '%$search_term%' ORDER BY similarity(label, '$search_term') DESC, label LIMIT 12 Took a few hours to get that to work. Would be nice to know if there's a better way, without having to wrap the unaccent function. Dave
Re: [BUGS] BUG #6638: Casablanca timezone is wrong
Thanks guys for your prompt support! I'm going to update Olson library on the concerned computer using the latest files. Thanks again. David Chuet Odotech inc. -Original Message- From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com] Sent: May-14-12 11:51 AM To: David Chuet Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #6638: Casablanca timezone is wrong On 14.05.2012 18:21, dch...@odotech.com wrote: > We get for Africa/Casablanca, timezone equal to WET with no DST. > > This is not true from 2010. > See Wikipedia, for Morocco: > > Time zone WET (UTC+0) > Summer (DST) WEST (UTC+1)(May 2nd to August 7th) PostgreSQL uses the timezone data from the so-called Olson library. See http://www.twinsun.com/tz/tz-link.htm. Looking at the upstream library, this is fixed in the most recent version (tzdata2012c), We will pick up that change in the next PostgreSQL minor release, ie. 9.0.8 for the 9.0 series. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] BUG #6638: Casablanca timezone is wrong
On 14.05.2012 18:21, dch...@odotech.com wrote: We get for Africa/Casablanca, timezone equal to WET with no DST. This is not true from 2010. See Wikipedia, for Morocco: Time zone WET (UTC+0) Summer (DST)WEST (UTC+1)(May 2nd to August 7th) PostgreSQL uses the timezone data from the so-called Olson library. See http://www.twinsun.com/tz/tz-link.htm. Looking at the upstream library, this is fixed in the most recent version (tzdata2012c), We will pick up that change in the next PostgreSQL minor release, ie. 9.0.8 for the 9.0 series. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] Fatal error in my PostgreSQL
"Suhad" writes: > I faced this error in my server logs if PostgreSQLapplication LOG: > unrecognized win32 error code: 487 , FATAL: could not reattach to shared > memory (key=5432001, addr=01D3): Invalid argument What PG version are you running? The last fix in that area was shipped in 8.3.8, 8.4.1, and later releases. We have not heard reports of this failure from anyone running newer releases. 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 #6638: Casablanca timezone is wrong
dch...@odotech.com writes: > We get for Africa/Casablanca, timezone equal to WET with no DST. > This is not true from 2010. > See Wikipedia, for Morocco: I wouldn't necessarily trust Wikipedia for that. We use the IANA (nee Olson) timezone database. If you think the information in that is wrong, you should take it up with the upstream maintainers: http://www.iana.org/time-zones As far as I can tell from a quick look in their mailing list archives, the timezone data shipped with 9.0.7 is correct for Morocco through 2011. It does not know about the 2012 DST law that was just published a few weeks ago, but unless you can provide use of a time machine, there's not a lot we can do about that. We customarily update to the latest timezone data files available from IANA whenever Postgres update releases are made. If you are in a bigger hurry than that, you can get the latest tzdata files from the above-mentioned page and drop them into the timezone directory in your installation. 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 #6638: Casablanca timezone is wrong
The following bug has been logged on the website: Bug reference: 6638 Logged by: David Chuet Email address: dch...@odotech.com PostgreSQL version: 9.0.7 Operating system: Windows 7 x64 Description: Using Postgresql command : -- SELECT * FROM pg_timezone_names -- We get for Africa/Casablanca, timezone equal to WET with no DST. This is not true from 2010. See Wikipedia, for Morocco: Time zone WET (UTC+0) Summer (DST)WEST (UTC+1)(May 2nd to August 7th) So, I cannot set correctly the DateTime for an install in Morocco. -- 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 #6637: Casablanca timezone is wrong
The following bug has been logged on the website: Bug reference: 6637 Logged by: David Chuet Email address: dch...@odotech.com PostgreSQL version: 9.0.7 Operating system: Windows 7 x64 Description: Using Postgresql command : -- SELECT * FROM pg_timezone_names -- We get for Africa/Casablanca, timezone equal to WET with no DST. This is not true from 2010. See Wikipedia, for Morocco: Time zone WET (UTC+0) Summer (DST)WEST (UTC+1)(May 2nd to August 7th) So, I cannot set correctly the DateTime for an install in Morocco. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Fatal error in my PostgreSQL
Dear , I faced this error in my server logs if PostgreSQLapplication LOG: unrecognized win32 error code: 487 , FATAL: could not reattach to shared memory (key=5432001, addr=01D3): Invalid argument How can I solve this problem ,please ?! Best Regards. <><> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
