[BUGS] BUG #6344: Trouble with plperl
The following bug has been logged on the website: Bug reference: 6344 Logged by: Kirill Email address: k_deni...@inbox.ru PostgreSQL version: 9.1.2 Operating system: Linux Debian Description: plperl function: open(FILE,">>/test/test.txt"); print FILE "Проверка(Cyrillic text)"; close FILE; Base codepage and client codepage cp1251. Record in file broken codepage. -- 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 flex error in guc-file.l kills the postmaster
On Sat, Dec 17, 2011 at 11:04:43PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Setting aside whether we should offer a better diagnostic when a user points
> > "include" at a directory, the yy_fatal_error hack that made sense for scan.l
> > doesn't cut it for guc-file.l. Like other guc-file.l errors, we need to
> > choose the elevel based on which process is running the code. ERROR is
> > never
> > the right choice. We should instead stash the message, longjmp out of the
> > flex parser, and proceed to handle the error mostly like a regular syntax
> > error. See attached small patch.
>
> Well, if you're going to criticize the original method as being hackish,
> you really need to offer a cleaner substitute than this one ;-). In
> particular I'm not happy with adding a sigsetjmp() cycle for every
> single token parsed.
On the contrary, I want to make it even more of a hack to get better behavior!
Here's a version that calls sigsetjmp() once per file. While postgresql.conf
scanning hardly seems like the place to be shaving cycles, this does catch
fatal errors in functions other than yylex(), notably yy_create_buffer().
> > On a related note, the out-of-memory handling during config file reload is
> > inconsistent. guc-file.l uses palloc/pstrdup in various places. An OOM at
> > those sites during a reload would kill the postmaster.
>
> If you've got OOM in the postmaster, you're dead anyway. I feel no
> compulsion to worry about this.
Works for me.
Thanks,
nm
*** a/src/backend/utils/misc/guc-file.l
--- b/src/backend/utils/misc/guc-file.l
***
*** 20,28
#include "utils/guc.h"
! /* Avoid exit() on fatal scanner errors (a bit ugly -- see yy_fatal_error) */
#undef fprintf
! #define fprintf(file, fmt, msg) ereport(ERROR, (errmsg_internal("%s", msg)))
enum {
GUC_ID = 1,
--- 20,40
#include "utils/guc.h"
! /*
! * flex emits a yy_fatal_error() function that it calls in response to
! * critical errors like malloc failure, file I/O errors, and detection of
! * internal inconsistency. That function prints a message and calls exit().
! * Mutate it to instead stash the message and jump out of the parser. Assume
! * all msg arguments point to string constants; this holds for flex 2.5.31
! * (earliest we support) and flex 2.5.35 (latest as of this writing).
! */
! static const char *GUC_flex_fatal_errmsg;
! static sigjmp_buf *GUC_flex_fatal_jmp;
#undef fprintf
! #define fprintf(file, fmt, msg) \
! 0; /* eat cast to void */ \
! GUC_flex_fatal_errmsg = msg; \
! siglongjmp(*GUC_flex_fatal_jmp, 1)
enum {
GUC_ID = 1,
***
*** 464,482 ParseConfigFp(FILE *fp, const char *config_file, int depth,
int elevel,
ConfigVariable **head_p, ConfigVariable **tail_p)
{
boolOK = true;
! YY_BUFFER_STATE lex_buffer;
int errorcount;
int token;
/*
* Parse
*/
- lex_buffer = yy_create_buffer(fp, YY_BUF_SIZE);
- yy_switch_to_buffer(lex_buffer);
-
ConfigFileLineno = 1;
errorcount = 0;
/* This loop iterates once per logical line */
while ((token = yylex()))
{
--- 476,511
ConfigVariable **head_p, ConfigVariable **tail_p)
{
boolOK = true;
! volatile YY_BUFFER_STATE lex_buffer = NULL;
int errorcount;
int token;
+ sigjmp_buf flex_fatal_jmp;
+
+ if (sigsetjmp(flex_fatal_jmp, 1) == 0)
+ GUC_flex_fatal_jmp = &flex_fatal_jmp;
+ else
+ {
+ /*
+* Regain control after a fatal, internal flex error. It may
have
+* corrupted parser state. Consequently, abandon the file, but
trust
+* that the state remains sane enough for yy_delete_buffer().
+*/
+ elog(elevel, "%s at file \"%s\" line %u",
+GUC_flex_fatal_errmsg, config_file, ConfigFileLineno);
+
+ yy_delete_buffer(lex_buffer);
+ return false;
+ }
/*
* Parse
*/
ConfigFileLineno = 1;
errorcount = 0;
+ lex_buffer = yy_create_buffer(fp, YY_BUF_SIZE);
+ yy_switch_to_buffer(lex_buffer);
+
/* This loop iterates once per logical line */
while ((token = yylex()))
{
***
*** 532,537 ParseConfigFp(FILE *fp, const char *config_file, int depth,
int elevel,
--- 561,567
depth + 1,
elevel,
head_p,
tail_p))
OK = false;
+ GUC_flex_fatal_jmp = &flex_fatal_jmp;
yy_switch_to_buffer(lex_buffer);
Re: [BUGS] BUG #6309: ECPG pre-processor issue
On Fri, Nov 25, 2011 at 12:51:51PM +, Andrew Milne wrote: > The ECPG pre-processor seems to be incorrectly reporting an error when > parsing "EXEC SQL AT :cnx DEALLOCATE..." style commands. Thanks for bringing this up. These checks seem to be leftovers from the old code that only emulated prepare statments. I've removed the checks for all versions starting at 8.4. The next release should be fine for you. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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 #6343: PGTYPES library missing qualifiers
On Fri, Dec 16, 2011 at 03:33:18PM +, koj...@hello-channel.com wrote: > The last argument is the formatting string, yet isn't constant. This > generates warnings/errors on many compilers that are watching for discarding > of qualifiers when passing in string literals. It's a simple fix, although I > ... Changed in our master branch. Thanks for bringing this up. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Hello all,
Heikki Linnakangas wrote:
> An even better approach would be to have a configure test for
> __sync_lock_test_and_set. A quick google search suggests that Intel
> C Compiler version >= 11.0 also supports __sync_lock_test_and_set,
> for example.
Right,
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
explicitly refers to intel CC as well.
> It probably makes sense to use it on any platform where it's
> defined. Presumably an implementation provided by the compiler is
> always going to be at least as good as any magic assembler
> incantations we can come up with.
I agree. How about a patch like this? It uses builtin atomics if
available, and falls back to the custom implementations if not.
Note that a simple AC_CHECK_FUNC(__sync_lock_test_and_set) does not
work, so I used a slightly more complicated AC_TRY_LINK() which also
verifies that __sync_lock_release() is available.
The patch is against 9.1.2, but I suppose it also applies to trunk
(except perhaps the autogenerated configure part, this needs an
autoheader/autoconf run).
Thanks for considering,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Description: Use gcc/intel cc builtin atomic operations for test-and-set, if available (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html)
Author: Martin Pitt
Index: postgresql-9.1-9.1.2/configure.in
===
--- postgresql-9.1-9.1.2.orig/configure.in 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/configure.in 2011-12-18 23:30:47.940475128 +0100
@@ -1522,6 +1522,18 @@
AC_SUBST(LDAP_LIBS_FE)
AC_SUBST(LDAP_LIBS_BE)
+# gcc and intel compiler provide builtin functions for atomic test-and-set
+AC_MSG_CHECKING([whether the C compiler provides atomic builtins])
+AC_TRY_LINK([], [int lock = 0; __sync_lock_test_and_set(&lock, 1); __sync_lock_release(&lock);],
+ [have_cc_atomics="yes"],
+ [have_cc_atomics="no"]
+)
+if test "$have_cc_atomics" = yes; then
+ AC_MSG_RESULT(yes)
+ AC_DEFINE(HAVE_CC_ATOMICS, 1, [Define to 1 if compiler provides atomic builtins])
+else
+ AC_MSG_RESULT(no)
+fi
# This test makes sure that run tests work at all. Sometimes a shared
# library is found by the linker, but the runtime linker can't find it.
Index: postgresql-9.1-9.1.2/configure
===
--- postgresql-9.1-9.1.2.orig/configure 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/configure 2011-12-18 23:31:00.304475596 +0100
@@ -23602,6 +23602,69 @@
+# gcc and intel compiler provide builtin functions for atomic test-and-set
+{ $as_echo "$as_me:$LINENO: checking whether the C compiler provides atomic builtins" >&5
+$as_echo_n "checking whether the C compiler provides atomic builtins... " >&6; }
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+int
+main ()
+{
+int lock = 0; __sync_lock_test_and_set(&lock, 1); __sync_lock_release(&lock);
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (ac_try="$ac_link"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
+$as_echo "$ac_try_echo") >&5
+ (eval "$ac_link") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest$ac_exeext && {
+ test "$cross_compiling" = yes ||
+ $as_test_x conftest$ac_exeext
+ }; then
+ have_cc_atomics="yes"
+else
+ $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ have_cc_atomics="no"
+
+fi
+
+rm -rf conftest.dSYM
+rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
+ conftest$ac_exeext conftest.$ac_ext
+if test "$have_cc_atomics" = yes; then
+ { $as_echo "$as_me:$LINENO: result: yes" >&5
+$as_echo "yes" >&6; }
+
+cat >>confdefs.h <<\_ACEOF
+#define HAVE_CC_ATOMICS 1
+_ACEOF
+
+else
+ { $as_echo "$as_me:$LINENO: result: no" >&5
+$as_echo "no" >&6; }
+fi
# This test makes sure that run tests work at all. Sometimes a shared
# library is found by the linker, but the runtime linker can't find it.
Index: postgresql-9.1-9.1.2/src/include/pg_config.h.in
===
--- postgresql-9.1-9.1.2.orig/src/include/pg_config.h.in 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/src/include/pg_config.h.in 2011-12-18 23:30:34.752474625 +0100
@@ -87,6 +87,9 @@
/* Define to 1 if you have the `cbrt' function. */
#undef HAVE_CBRT
+/* Define to 1 if compiler provides atomic builtins */
+#un
Re: [BUGS] BUG #6344: Trouble with plperl
On Sun, Dec 18, 2011 at 01:25, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6344
> Logged by: Kirill
> Email address: k_deni...@inbox.ru
> PostgreSQL version: 9.1.2
> Operating system: Linux Debian
> Description:
>
> plperl function:
> open(FILE,">>/test/test.txt");
> print FILE "Проверка(Cyrillic text)";
> close FILE;
> Base codepage and client codepage cp1251.
> Record in file broken codepage.
Im not exactly sure what you are saying, but my hunch is you need to
use Encode or give the file handle an encoding:
binmode(FILE, ':encoding(cp1251)'); (or via open)
or
use Encode qw(encode);
my $str =decode("cp1251", "Проверка(Cyrillic text));
print FILE $str;
--
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 #6345: "forget the password for reinstallaion"
The following bug has been logged on the website: Bug reference: 6345 Logged by: manoj Email address: manojk.softengin...@gmail.com PostgreSQL version: 9.1.2 Operating system: window 7 Description: i have downloaded latest version of postgresql ,but due certain anomalies , i have unistall it , but after some time , i decided to reinsatll it , but it want pre existing password for installation , i have completely deleted various files of postgresql including registry cleanup as well but i am unable to install it again , please help. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
