[HACKERS] Archlinux, ossp-uuid
Hi, guys. I try to build postgresql on archlinux server. I use --prefix=user --with-ossp-uuid flags Build process succeed, but when I try to execute following query === create or replace function uuid_generate_v1() returns uuid as '$libdir/uuid-ossp', 'uuid_generate_v1' volatile strict language C === I got error could not load libraty /usr/lib/postgresql/uuid-ossp.so: /usr/lib/postgresql/uuid-ossp.so: undefined symbol: uuid_error How I can fix it?t -- С уважением, Николай Ижиков nizhi...@gmail.com
Re: [HACKERS] WIP patch for parallel pg_dump
On Fri, Dec 24, 2010 at 06:37:26PM -0500, Andrew Dunstan wrote: On 12/24/2010 06:26 PM, Aidan Van Dyk wrote: On Fri, Dec 24, 2010 at 2:48 PM, Joshua D. Drakej...@commandprompt.com wrote: I would have to agree here. The idea that we have to search email is bad enough (issue/bug/feature tracker anyone?) but to have someone say, search the archives? That is just plain rude and anti-community. Saying search the bugtracker is no less rude than search the archives... And most of the bugtrackers I've had to search have way *less* ease-of-use for searching than a good mailing list archive (I tend to keep going back to gmane's search) It's deja vu all over again. See mailing list archives for details. LOL! Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MingW and MiniDumps
On 12/20/2010 01:25 PM, Magnus Hagander wrote:
On Mon, Dec 20, 2010 at 19:24, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstanand...@dunslane.net writes:
Maybe. I have no idea where narwhal got its version of dbghelp.h. I
copied the file from the SDK directory to mingw's include directory and
the build then ran perfectly. I think therefore the right thing is to
have a configure test for the file and for MINIDUMP_TYPE on win32, and
only build in crashdump if it passes those tests.
+1.
Suggested patch attached.
cheers
andrew
diff --git a/configure b/configure
index 51d27d8..388cf34 100755
--- a/configure
+++ b/configure
@@ -667,6 +667,7 @@ PTHREAD_CFLAGS
PTHREAD_LIBS
PTHREAD_CC
acx_pthread_config
+have_win32_dbghelp
HAVE_IPV6
LIBOBJS
OSSP_UUID_LIBS
@@ -20926,6 +20927,128 @@ cat confdefs.h \_ACEOF
#define HAVE_SYMLINK 1
_ACEOF
+ { $as_echo $as_me:$LINENO: checking for MINIDUMP_TYPE 5
+$as_echo_n checking for MINIDUMP_TYPE... 6; }
+if test ${ac_cv_type_MINIDUMP_TYPE+set} = set; then
+ $as_echo_n (cached) 6
+else
+ ac_cv_type_MINIDUMP_TYPE=no
+cat conftest.$ac_ext _ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h. */
+
+#define WIN32_LEAN_AND_MEAN
+#include windows.h
+#include string.h
+#include dbghelp.h
+
+int
+main ()
+{
+if (sizeof (MINIDUMP_TYPE))
+ return 0;
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try=$ac_compile
+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_compile) 2conftest.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_objext; then
+ cat conftest.$ac_ext _ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h. */
+
+#define WIN32_LEAN_AND_MEAN
+#include windows.h
+#include string.h
+#include dbghelp.h
+
+int
+main ()
+{
+if (sizeof ((MINIDUMP_TYPE)))
+ return 0;
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try=$ac_compile
+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_compile) 2conftest.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_objext; then
+ :
+else
+ $as_echo $as_me: failed program was: 5
+sed 's/^/| /' conftest.$ac_ext 5
+
+ ac_cv_type_MINIDUMP_TYPE=yes
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+else
+ $as_echo $as_me: failed program was: 5
+sed 's/^/| /' conftest.$ac_ext 5
+
+
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+{ $as_echo $as_me:$LINENO: result: $ac_cv_type_MINIDUMP_TYPE 5
+$as_echo $ac_cv_type_MINIDUMP_TYPE 6; }
+if test x$ac_cv_type_MINIDUMP_TYPE = xyes; then
+
+cat confdefs.h _ACEOF
+#define HAVE_MINIDUMP_TYPE 1
+_ACEOF
+
+pgac_minidump_type=yes
+else
+ pgac_minidump_type=no
+fi
+
+fi
+if test x$pgac_minidump_type = xyes ; then
+ have_win32_dbghelp=yes
+
+else
+ have_win32_dbghelp=no
+
fi
if test $with_readline = yes; then
diff --git a/configure.in b/configure.in
index b999b94..8ee2152 100644
--- a/configure.in
+++ b/configure.in
@@ -1350,6 +1350,16 @@ if test $PORTNAME = win32; then
AC_LIBOBJ(win32error)
AC_DEFINE([HAVE_SYMLINK], 1,
[Define to 1 if you have the `symlink' function.])
+ AC_CHECK_TYPES(MINIDUMP_TYPE, [pgac_minidump_type=yes], [pgac_minidump_type=no], [
+#define WIN32_LEAN_AND_MEAN
+#include windows.h
+#include string.h
+#include dbghelp.h])
+fi
+if test x$pgac_minidump_type = xyes ; then
+ AC_SUBST(have_win32_dbghelp,yes)
+else
+ AC_SUBST(have_win32_dbghelp,no)
fi
if test $with_readline = yes; then
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 7a61a5a..ebeee0c 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -363,6 +363,9 @@ ELF_SYSTEM= @ELF_SYS@
# Backend stack size limit has to be hard-wired on Windows (it's in bytes)
WIN32_STACK_RLIMIT=4194304
+# Set if we have a working win32 crashdump header
+have_win32_dbghelp = @have_win32_dbghelp@
+
# Pull in platform-specific magic
include $(top_builddir)/src/Makefile.port
diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index 6065e8c..d3f9bcd 100644
--- a/src/backend/main/main.c
+++ b/src/backend/main/main.c
@@ -85,7 +85,7 @@ main(int argc, char *argv[])
* If supported on the current platform, set up a handler to be called if
* the
Re: [HACKERS] WIP patch for parallel pg_dump
On Mon, Dec 6, 2010 at 7:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
However, if you were doing something like parallel pg_dump you could
just run the parent and child instances all against the slave, so the
pg_dump scenario doesn't seem to offer much of a supporting use-case for
worrying about this. When would you really need to be able to do it?
If you had several standbys, you could distribute the work of the
pg_dump among them. This would be a huge speedup for a large database,
potentially, thanks to parallelization of I/O and network. Imagine
doing a pg_dump of a 300GB database in 10min.
That does sound kind of attractive. But to do that I think we'd have to
go with the pass-the-snapshot-through-the-client approach. Shipping
internal snapshot files through the WAL stream doesn't seem attractive
to me.
While I see Robert's point about preferring not to expose the snapshot
contents to clients, I don't think it outweighs all other considerations
here; and every other one is pointing to doing it the other way.
How about the publishing transaction puts the snapshot in a (new) system
table and passes a UUID to its children, and the joining transactions looks
for that UUID in the system table using dirty snapshot (SnapshotAny) using a
security-definer function owned by superuser.
No shared memory used, and if WAL-logged, the snapshot would get to the
slaves too.
I realize SnapshotAny wouldn't be sufficient since we want the tuple to
become invisible when the publishing transaction ends (commit/rollback),
hence something akin to (new) HeapTupleSatisfiesStillRunning() would be
needed.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
Re: [HACKERS] SQL/MED - core functionality
On Wed, Dec 15, 2010 at 8:25 AM, Shigeru HANADA han...@metrosystems.co.jp wrote: In order to make review easier, fdw_core patch has been split into two parts, fdw_syntax and fdw_scan. Please apply fdw_scan onto fdw_syntax to test whole features. I'm working on getting a first chunk of this committed. I've removed a number of features that I don't think are absolutely required for an initial commit, simplified some things that seemed overly complicated to me, and then done a bunch of cleanup of what's left. It is still a very big patch, but it's approaching a size and level of complexity that seems manageable to me (currently, about 2300 lines). I'm not going to post it just yet because my version is still kind of a mess, but I thought a quick heads-up that I'm grinding through it would be a good idea, in order to avoid duplication of effort. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.
On Sat, Dec 25, 2010 at 3:39 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas rh...@postgresql.org writes: Add foreign data wrapper error code values for SQL/MED. Extracted from a much larger patch by Shigeru Hanada. This patch is quite incomplete. Any patch that adds to errcodes.h *must* also touch doc/src/sgml/errcodes.sgml src/pl/plpgsql/src/plerrcodes.h Drat. OK, will work on it tomorrow. I didn't realize those places needed to be updated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
