[PATCHES] libpq.so linking problem on Solaris using --with-gssapi
When building PostgreSQL 8.3 on Solaris using the configure option --with-gssapi, libpq.so is not linked correctly. This line in the libpq Makefile is selecting the appropriate linker options: --- SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi_krb5 -lssl -lsocket -lnsl -lresolv -lintl, $(LIBS)) $(LDAP_LIBS_FE) $(PTHREAD_LIBS) --- This includes -lgssapi_krb5, but for Solaris this should be just -lgss. The result is that libpq.so does not load libgss.so. psql still works because it apparently loads libgss.so before it loads libpq.so, otherwise it would surely have been discovered earlier. But when I tried to run a test for the TCL client interface I got: --- TCL test status: Started couldn't load file libpgtcl1.5.so: ld.so.1: tclsh8.4: fatal: relocation error: file /lib/libpq.so.5: symbol GSS_C_NT_HOSTBASED_SERVICE: referenced symbol not found while executing load libpgtcl1.5.so (file ./import_sampledata.tcl line 7) --- This could affect other clients too. The fix is simply to add -lgss to the list, as the attached patch does. I'm pretty sure no other Makefiles are affected. Tested on Solaris (x86 and sparc), and also Linux (RHEL 5). I plan to apply this patch when I integrate 8.3.0 into OpenSolaris. -- Bjorn Munch Database Technology Group Sun Microsystems *** src/interfaces/libpq/Makefile.orig Mon Mar 3 16:33:11 2008 --- src/interfaces/libpq/Makefile Tue Mar 4 12:24:08 2008 *** *** 56,62 # shared library link. (The order in which you list them here doesn't # matter.) ifneq ($(PORTNAME), win32) ! SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi_krb5 -lgss -lssl -lsocket -lnsl -lresolv -lintl, $(LIBS)) $(LDAP_LIBS_FE) $(PTHREAD_LIBS) else SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi32 -lssl -lsocket -lnsl -lresolv -lintl $(PTHREAD_LIBS), $(LIBS)) $(LDAP_LIBS_FE) endif --- 56,62 # shared library link. (The order in which you list them here doesn't # matter.) ifneq ($(PORTNAME), win32) ! SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi_krb5 -lssl -lsocket -lnsl -lresolv -lintl, $(LIBS)) $(LDAP_LIBS_FE) $(PTHREAD_LIBS) else SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi32 -lssl -lsocket -lnsl -lresolv -lintl $(PTHREAD_LIBS), $(LIBS)) $(LDAP_LIBS_FE) endif -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] [HACKERS] Show INHERIT in \du
Brendan Jurd escribió: I've done up a patch per Tom's idea of combining the binary role attributes into a single column. This patch seems to be missing from the queue. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
[PATCHES] WIP: guc enums
Attached is my first work at implementing GUC enums. It's not done yet,
obviously, but I did hit a problem that I need to ask about. So I'll just
send what I have now for comments.
The patch only converts a couple of the potential enum variables to the new
type, mainly as a proof of concept. But already I hit the problem twice -
the variable that holds the value of the guc enum is a C enum itself, which
gives a compiler warning when I pass a pointer to it for
config_enum.variable. (in this case, Log_error_verbosity and log_statement
are enums and have the problem, but client_min_messages, log_min_messages
and log_min_error_statement are already int and don't have it)
On my platform (linux x86) it works fine when I just cast this to (int *),
but I'm unsure if that's going to be safe on other platforms. I had some
indication that it's probably not?
And if not, the only way I know to do it is to change the C level enums to
be an int and use #define:s instead of what's there now. If that's
required, is that an acceptable change in order to implement this? If not,
any better ideas on how to do it?
And finally, please let me know if I seem to be off on a completely wrong
track with this :-)
//Magnus
Index: src/backend/catalog/system_views.sql
===
RCS file: /cvsroot/pgsql/src/backend/catalog/system_views.sql,v
retrieving revision 1.48
diff -c -r1.48 system_views.sql
*** src/backend/catalog/system_views.sql1 Jan 2008 19:45:48 -
1.48
--- src/backend/catalog/system_views.sql3 Mar 2008 20:20:28 -
***
*** 173,179
SELECT *
FROM pg_show_all_settings() AS A
(name text, setting text, unit text, category text, short_desc text,
extra_desc text,
! context text, vartype text, source text, min_val text, max_val text);
CREATE RULE pg_settings_u AS
ON UPDATE TO pg_settings
--- 173,179
SELECT *
FROM pg_show_all_settings() AS A
(name text, setting text, unit text, category text, short_desc text,
extra_desc text,
! context text, vartype text, source text, min_val text, max_val text,
enumvals text);
CREATE RULE pg_settings_u AS
ON UPDATE TO pg_settings
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.432
diff -c -r1.432 guc.c
*** src/backend/utils/misc/guc.c30 Jan 2008 18:35:55 - 1.432
--- src/backend/utils/misc/guc.c3 Mar 2008 20:20:29 -
***
*** 144,161
GucSource source);
static const char *assign_session_replication_role(const char *newval, bool
doit,
GucSource
source);
- static const char *assign_log_min_messages(const char *newval, bool doit,
- GucSource source);
- static const char *assign_client_min_messages(const char *newval,
- bool doit, GucSource source);
- static const char *assign_min_error_statement(const char *newval, bool doit,
- GucSource source);
- static const char *assign_msglvl(int *var, const char *newval, bool doit,
- GucSource source);
- static const char *assign_log_error_verbosity(const char *newval, bool doit,
- GucSource source);
- static const char *assign_log_statement(const char *newval, bool doit,
-GucSource source);
static const char *show_num_temp_buffers(void);
static bool assign_phony_autocommit(bool newval, bool doit, GucSource source);
static const char *assign_custom_variable_classes(const char *newval, bool
doit,
--- 144,149
***
*** 181,186
--- 169,209
static bool assign_maxconnections(int newval, bool doit, GucSource source);
/*
+ * Options for enum values exported from this module
+ */
+ static const struct config_enum_entry config_message_levels[] = {
+ {debug, DEBUG2},
+ {debug5, DEBUG5},
+ {debug4, DEBUG4},
+ {debug3, DEBUG3},
+ {debug2, DEBUG2},
+ {debug1, DEBUG1},
+ {log, LOG},
+ {info, INFO},
+ {notice, NOTICE},
+ {warning, WARNING},
+ {error, ERROR},
+ {fatal, FATAL},
+ {panic, PANIC},
+ {NULL, 0}
+ };
+
+ static const struct config_enum_entry log_error_verbosity_options[] = {
+ {default, PGERROR_DEFAULT},
+ {terse, PGERROR_TERSE},
+ {verbose, PGERROR_VERBOSE},
+ {NULL, 0}
+ };
+
+ static const struct config_enum_entry log_statement_options[] = {
+ {none, LOGSTMT_NONE},
+ {ddl, LOGSTMT_DDL},
+ {mod, LOGSTMT_MOD},
+ {all, LOGSTMT_ALL},
+ {NULL, 0}
+ };
+
+ /*
*
Re: [PATCHES] [HACKERS] Show INHERIT in \du
Alvaro Herrera wrote: Brendan Jurd escribi?: I've done up a patch per Tom's idea of combining the binary role attributes into a single column. This patch seems to be missing from the queue. Yes because I am still processing email from two weeks ago. I was in Europe for a week. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] [HACKERS] Show INHERIT in \du
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Brendan Jurd wrote:
I've done up a patch per Tom's idea of combining the binary role
attributes into a single column.
Each attribute which differs from the default is listed on a separate
line, like so:
List of roles
Role name | Attributes | Member of
-++---
bob || {readers,writers}
brendanjurd | Superuser | {}
: Create role
: Create DB
harry | No inherit | {}
jim | 10 connections | {readers}
readers | No login | {}
writers | No login | {}
(6 rows)
Notes:
* The patch relies on array_to_string's current treatment of NULL
values in the array; they are ignored. If that behaviour changes in
the future, the \du output will become very ugly indeed.
* I'm not sure whether No login and No inherit are the best
phrases to use. I took my cue from the SQL setting names NOLOGIN and
NOINHERIT, but maybe something more grammatically sensible with
Cannot login and No inheritance would be preferable.
* If accepted, this patch would supercede the earlier patch mentioned
by Bernd Helmle upthread, which adds LOGIN to the output as a new
column: http://archives.postgresql.org/pgsql-patches/2007-11/msg00014.php
Cheers,
BJ
[ Attachment, skipping... ]
---(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://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your Subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] Fix for initdb failures on Vista
On Fri, Feb 29, 2008 at 6:41 PM, Magnus Hagander [EMAIL PROTECTED] wrote: Will you provide a patch for that, or should I? (I remind you I have no box ready to reproduce it on, so it helps a lot if you can do it :-P) Patch attached. Tested on XP and Vista. -- Dave Page EnterpriseDB UK Ltd: http://www.enterprisedb.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk pg_regress_dacl.diff Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] Fix for initdb failures on Vista
On Tue, Mar 04, 2008 at 03:28:30PM +, Dave Page wrote: On Fri, Feb 29, 2008 at 6:41 PM, Magnus Hagander [EMAIL PROTECTED] wrote: Will you provide a patch for that, or should I? (I remind you I have no box ready to reproduce it on, so it helps a lot if you can do it :-P) Patch attached. Tested on XP and Vista. Applied to HEAD and 8.3, thanks. Does not apply to 8.2, since we don't use CreateProcessAsUser() there at all. //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
[PATCHES] 64-bit CommandIds
Hi,
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
The feature is off by default, you need to --enable-huge-commandid.
It fails only one regression test (without_oid) that measures the saved
space in 8.3.
Also, modifying FirstCommandId to be (132ULL - 4) to early overflow
the 32-bit limit) doesn't show any real problem besides the combocid
regression failure that explicitly lists cmin/cmax values, which is
expected.
It was written by Zoltán Böszörményi [EMAIL PROTECTED] and
Hans-Jürgen Schönig [EMAIL PROTECTED]
Best regards,
Zoltán Böszörményi
--
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
diff -dcrpN pgsql.orig/configure pgsql-cid64/configure
*** pgsql.orig/configure 2008-03-02 13:44:42.0 +0100
--- pgsql-cid64/configure 2008-03-04 16:53:46.0 +0100
*** if test -n $ac_init_help; then
*** 1349,1354
--- 1349,1355
Optional Features:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --enable-huge-commandidenable 64-bit CommandId support
--enable-integer-datetimes enable 64-bit integer date/time support
--enable-nls[=LANGUAGES] enable Native Language Support
--disable-shareddo not build shared libraries
*** fi
*** 2175,2180
--- 2176,2219
#
+ # 64-bit CommandId
+ #
+ echo $as_me:$LINENO: checking whether to build with 64-bit CommandId support 5
+ echo $ECHO_N checking whether to build with 64-bit CommandId support... $ECHO_C 6
+
+ pgac_args=$pgac_args enable_huge_commandid
+
+ # Check whether --enable-huge-commandid or --disable-huge-commandid was given.
+ if test ${enable_huge_commandid+set} = set; then
+ enableval=$enable_huge_commandid
+
+ case $enableval in
+ yes)
+
+ cat confdefs.h \_ACEOF
+ #define USE_64BIT_COMMANDID 1
+ _ACEOF
+
+ ;;
+ no)
+ :
+ ;;
+ *)
+ { { echo $as_me:$LINENO: error: no argument expected for --enable-huge-commandid option 5
+ echo $as_me: error: no argument expected for --enable-huge-commandid option 2;}
+{ (exit 1); exit 1; }; }
+ ;;
+ esac
+
+ else
+ enable_huge_commandid=no
+
+ fi;
+
+ echo $as_me:$LINENO: result: $enable_huge_commandid 5
+ echo ${ECHO_T}$enable_huge_commandid 6
+
+ #
# 64-bit integer date/time storage (--enable-integer-datetimes)
#
{ echo $as_me:$LINENO: checking whether to build with 64-bit integer date/time support 5
diff -dcrpN pgsql.orig/configure.in pgsql-cid64/configure.in
*** pgsql.orig/configure.in 2008-03-02 13:44:43.0 +0100
--- pgsql-cid64/configure.in 2008-03-04 16:53:46.0 +0100
*** PGAC_ARG_REQ(with, libs, [ --with-
*** 128,133
--- 128,142
#
+ # 64-bit CommandId
+ #
+ AC_MSG_CHECKING([whether to build with 64-bit CommandId support])
+ PGAC_ARG_BOOL(enable, huge-commandid, no, [ --enable-huge-commandidenable 64-bit CommandId support],
+ [AC_DEFINE([USE_64BIT_COMMANDID], 1,
+ [Define to 1 if you want 64-bit CommandId support. (--enable-huge-commandid)])])
+ AC_MSG_RESULT([$enable_huge_commandid])
+
+ #
# 64-bit integer date/time storage (--enable-integer-datetimes)
#
AC_MSG_CHECKING([whether to build with 64-bit integer date/time support])
diff -dcrpN pgsql.orig/doc/src/sgml/installation.sgml pgsql-cid64/doc/src/sgml/installation.sgml
*** pgsql.orig/doc/src/sgml/installation.sgml 2008-02-18 13:49:58.0 +0100
--- pgsql-cid64/doc/src/sgml/installation.sgml 2008-03-04 17:16:14.0 +0100
*** su - postgres
*** 1011,1016
--- 1011,1027
/varlistentry
varlistentry
+termoption--enable-huge-commandid/option/term
+listitem
+ para
+ Use 64-bit CommandIds if you are planning to run transactions
+ consisting of more than 4 billion commands. This is off by default
+ to save disk space.
+ /para
+/listitem
+ /varlistentry
+
+ varlistentry
termoption--enable-integer-datetimes/option/term
listitem
para
diff -dcrpN pgsql.orig/src/backend/access/transam/xact.c pgsql-cid64/src/backend/access/transam/xact.c
*** pgsql.orig/src/backend/access/transam/xact.c 2008-01-15 19:56:59.0 +0100
--- pgsql-cid64/src/backend/access/transam/xact.c 2008-03-04 16:57:54.0 +0100
*** CommandCounterIncrement(void)
*** 592,598
--- 592,602
currentCommandId -= 1;
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ #ifdef USE_64BIT_COMMANDID
+ errmsg(cannot have more than 2^64-1 commands in a transaction)));
+ #else
errmsg(cannot have more than 2^32-1 commands in a transaction)));
+ #endif
}
currentCommandIdUsed = false;
diff -dcrpN
Re: [PATCHES] 64-bit CommandIds
Zoltan Boszormenyi wrote: attached is our patch against HEAD which enables extending CommandIds to 64-bit. This is for enabling long transactions that really do that much non-read-only work in one transaction. I think you should add a pg_control field and corresponding check, to avoid a 64bit-Cid postmaster to start on a 32bit-Cid data area and vice versa. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] 64-bit CommandIds
Alvaro Herrera írta: Zoltan Boszormenyi wrote: attached is our patch against HEAD which enables extending CommandIds to 64-bit. This is for enabling long transactions that really do that much non-read-only work in one transaction. I think you should add a pg_control field and corresponding check, to avoid a 64bit-Cid postmaster to start on a 32bit-Cid data area and vice versa. You're right, thanks. -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
[PATCHES] actualized SQL/PSM patch
Hello I actualized sql/psm patch. This patch can be downloaded from http://www.pgsql.cz/patches/plpgpsm.diff.gz Documentation is on wiki http://www.pgsql.cz/index.php/SQL/PSM_Manual Regards Pavel Stehule -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] 64-bit CommandIds
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
I think you should add a pg_control field and corresponding check, to
avoid a 64bit-Cid postmaster to start on a 32bit-Cid data area and vice
versa.
I added the check but I needed to add it BEFORE checking for
toast_max_chunk_size otherwise it complained about this more
cryptic problem. I think it's cleaner to report this failure to know
why toast_max_chunk_size != TOAST_MAX_CHUNK_SIZE.
Best regards,
Zoltán Böszörményi
--
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
diff -dcrpN pgsql.orig/configure pgsql-cid64/configure
*** pgsql.orig/configure 2008-03-02 13:44:42.0 +0100
--- pgsql-cid64/configure 2008-03-04 16:53:46.0 +0100
*** if test -n $ac_init_help; then
*** 1349,1354
--- 1349,1355
Optional Features:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --enable-huge-commandidenable 64-bit CommandId support
--enable-integer-datetimes enable 64-bit integer date/time support
--enable-nls[=LANGUAGES] enable Native Language Support
--disable-shareddo not build shared libraries
*** fi
*** 2175,2180
--- 2176,2219
#
+ # 64-bit CommandId
+ #
+ echo $as_me:$LINENO: checking whether to build with 64-bit CommandId support 5
+ echo $ECHO_N checking whether to build with 64-bit CommandId support... $ECHO_C 6
+
+ pgac_args=$pgac_args enable_huge_commandid
+
+ # Check whether --enable-huge-commandid or --disable-huge-commandid was given.
+ if test ${enable_huge_commandid+set} = set; then
+ enableval=$enable_huge_commandid
+
+ case $enableval in
+ yes)
+
+ cat confdefs.h \_ACEOF
+ #define USE_64BIT_COMMANDID 1
+ _ACEOF
+
+ ;;
+ no)
+ :
+ ;;
+ *)
+ { { echo $as_me:$LINENO: error: no argument expected for --enable-huge-commandid option 5
+ echo $as_me: error: no argument expected for --enable-huge-commandid option 2;}
+{ (exit 1); exit 1; }; }
+ ;;
+ esac
+
+ else
+ enable_huge_commandid=no
+
+ fi;
+
+ echo $as_me:$LINENO: result: $enable_huge_commandid 5
+ echo ${ECHO_T}$enable_huge_commandid 6
+
+ #
# 64-bit integer date/time storage (--enable-integer-datetimes)
#
{ echo $as_me:$LINENO: checking whether to build with 64-bit integer date/time support 5
diff -dcrpN pgsql.orig/configure.in pgsql-cid64/configure.in
*** pgsql.orig/configure.in 2008-03-02 13:44:43.0 +0100
--- pgsql-cid64/configure.in 2008-03-04 16:53:46.0 +0100
*** PGAC_ARG_REQ(with, libs, [ --with-
*** 128,133
--- 128,142
#
+ # 64-bit CommandId
+ #
+ AC_MSG_CHECKING([whether to build with 64-bit CommandId support])
+ PGAC_ARG_BOOL(enable, huge-commandid, no, [ --enable-huge-commandidenable 64-bit CommandId support],
+ [AC_DEFINE([USE_64BIT_COMMANDID], 1,
+ [Define to 1 if you want 64-bit CommandId support. (--enable-huge-commandid)])])
+ AC_MSG_RESULT([$enable_huge_commandid])
+
+ #
# 64-bit integer date/time storage (--enable-integer-datetimes)
#
AC_MSG_CHECKING([whether to build with 64-bit integer date/time support])
diff -dcrpN pgsql.orig/doc/src/sgml/installation.sgml pgsql-cid64/doc/src/sgml/installation.sgml
*** pgsql.orig/doc/src/sgml/installation.sgml 2008-02-18 13:49:58.0 +0100
--- pgsql-cid64/doc/src/sgml/installation.sgml 2008-03-04 17:16:14.0 +0100
*** su - postgres
*** 1011,1016
--- 1011,1027
/varlistentry
varlistentry
+termoption--enable-huge-commandid/option/term
+listitem
+ para
+ Use 64-bit CommandIds if you are planning to run transactions
+ consisting of more than 4 billion commands. This is off by default
+ to save disk space.
+ /para
+/listitem
+ /varlistentry
+
+ varlistentry
termoption--enable-integer-datetimes/option/term
listitem
para
diff -dcrpN pgsql.orig/src/backend/access/transam/xact.c pgsql-cid64/src/backend/access/transam/xact.c
*** pgsql.orig/src/backend/access/transam/xact.c 2008-01-15 19:56:59.0 +0100
--- pgsql-cid64/src/backend/access/transam/xact.c 2008-03-04 16:57:54.0 +0100
*** CommandCounterIncrement(void)
*** 592,598
--- 592,602
currentCommandId -= 1;
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ #ifdef USE_64BIT_COMMANDID
+ errmsg(cannot have more than 2^64-1 commands in a transaction)));
+ #else
errmsg(cannot have more than 2^32-1 commands in a transaction)));
+ #endif
}
currentCommandIdUsed = false;
diff -dcrpN
Re: [PATCHES] WIP: guc enums
Magnus Hagander wrote:
The patch only converts a couple of the potential enum variables to the new
type, mainly as a proof of concept. But already I hit the problem twice -
the variable that holds the value of the guc enum is a C enum itself, which
gives a compiler warning when I pass a pointer to it for
config_enum.variable. (in this case, Log_error_verbosity and log_statement
are enums and have the problem, but client_min_messages, log_min_messages
and log_min_error_statement are already int and don't have it)
On my platform (linux x86) it works fine when I just cast this to (int *),
but I'm unsure if that's going to be safe on other platforms. I had some
indication that it's probably not?
No, I don't think that's safe. Some googleing (*) suggests that the
compiler is free to choose any integer type for an enum. If you do
*((int *)enumptr) = x, and the compiler chose a 16-bit type for the
enum, you overwrite some unrelated piece of memory.
And if not, the only way I know to do it is to change the C level enums to
be an int and use #define:s instead of what's there now. If that's
required, is that an acceptable change in order to implement this? If not,
any better ideas on how to do it?
Yuck :-(.
We could keep using the assignment hooks. But they could be a lot
simpler than they are nowadays, if the string - int conversion was done
by the GUC machinery:
static const char *
assign_client_min_messages(int newval, bool doit, GucSource source)
{
client_min_messages = newval;
}
Another idea would be cajole the compiler to choose a type of the same
length as int, by adding a dummy enum value to the enum, like:
enum client_min_messages {
DEBUG,
INFO,
...,
DUMMY = INT_MAX
}
Though I guess it might in theory choose something even wider, and the
*((int *)enumptr) = x would fail to set all the bits of the enum variable.
BTW, shouldn't be using malloc in config_enum_get_options...
(*): http://david.tribble.com/text/cdiffs.htm#C99-enum-type
and what I believe to be the current C99 standard, see 6.7.2.2
Enumeration specifiers:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your Subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Pavel Stehule wrote: Hello I actualized sql/psm patch. This patch can be downloaded from http://www.pgsql.cz/patches/plpgpsm.diff.gz Documentation is on wiki http://www.pgsql.cz/index.php/SQL/PSM_Manual Regards Pavel Stehule -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] WIP: guc enums
Heikki Linnakangas [EMAIL PROTECTED] writes: Magnus Hagander wrote: On my platform (linux x86) it works fine when I just cast this to (int *), but I'm unsure if that's going to be safe on other platforms. I had some indication that it's probably not? No, I don't think that's safe. Some googleing (*) suggests that the compiler is free to choose any integer type for an enum. Yeah, it's absolutely not safe. What I'd suggest is declaring the actual variable as int. You can still use an enum typedef to declare the values, and just avert your eyes when you have to cast the enum to int or vice versa. (This is legal per C spec, so you won't introduce any portability issues when you do it.) regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] libpq.so linking problem on Solaris using --with-gssapi
Bjorn Munch [EMAIL PROTECTED] writes: The fix is simply to add -lgss to the list, as the attached patch does. I'm pretty sure no other Makefiles are affected. Applied, thanks. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
