Re: [PATCHES] [subxacts] Fixing TODO items
On Tue, Jul 27, 2004 at 01:32:01PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: There are some likely controversial changes; the Xid caches, in the first place. No kidding ;-) Do you have any theoretical or practical evidence for the usefulness of the negxids cache? Seems to me the shared memory space would be better spent on allowing deeper nesting of the running-subxids list. Also, what happened to marking whether the running-subxids list has overflowed? If none of them have then there's no need to wonder whether we have a still-running subxact. Oh, sure, I had forgot about the overflow flag. I am working on that now. The apparent lack of any locking on these data structures seems wrong too. Well, storing the main Xid of a transaction in PGPROC is regarded as atomic and it has no locking (other than SInvalLock in shared mode). I think the correct solution would be to lock both the main Xid and the XidCache with a per-backend LWLock, but you already rejected that idea. My current patch uses SInvalLock in shared mode to protect reading and writing the XidCaches. I am not sure this is a very good idea, but it doesn't seem unreasonable either. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Et put se mouve (Galileo Galilei) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] USING INDEX TABLESPACE
create table test (a integer primary key index tablespace loc); create table test (a integer unique index tablespace loc); create table test (a integer); alter table test add primary key(a) index tablespace loc; create table test (a integer); alter table test add unique(a) index tablespace loc; Crap! I left out the word 'using' on all those examples :/ create table test (a integer primary key using index tablespace loc); create table test (a integer unique using index tablespace loc); create table test (a integer); alter table test add primary key(a) using index tablespace loc; create table test (a integer); alter table test add unique(a) using index tablespace loc; Chris ---(end of broadcast)--- TIP 3: 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
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Dave, now that we are nearing beta, I think we need to correct the
initdb problem with removing the directory on Win32. Would you code
this up as something that sits in /port/dirmod.c and have both initdb
and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I
think those are the only two. DROP TABLESPACE?)
I wanted to keep a solution that was as native to the OS as possible,
but because we can't do that on Win32 and few people like the unix
system call to 'rm', it is time to clean it up.
One question --- why is there a sleep loop needed for unlink in your
patch?
---
Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 19 June 2004 00:22
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Cannot initdb in cvs tip
Dave Page [EMAIL PROTECTED] writes:
I'm getting the following error when trying to initdb with CVS tip.
creating template1 database in
C:/msys/1.0/local/pgsql/data/base/1 ...
ERROR: could not open segment 1 of relation 1663/1/1255
(target block
26189776): No such file or directory
The target block number is obviously broken :-(. But maybe
you have a build consistency problem --- did you try a make
distclean and full rebuild?
OK, that cured that one - thanks.
although it says it's clearing the contents of the directory, in
actual fact it leaves the directory structure in place, thus a
subsequent initdb will not run without a manual clearup.
Hm. The rmtree() function in initdb.c is responsible for
this, and I see it has WIN32-specific behavior, which is
evidently wrong.
Can you recommend a fix?
The current solution does an rmdir /q /s $PGDATA if the datadir was
created, and del /q /s $PGDATA if the directory already existed. The
second case will not work, as del will not remove directories. AFAICS,
there is no easy way to do this using system() as rmdir won't accept
wildcards, so we can't do del $PGDATA/* rmdir $PGDATA/*.
It seems to me that the simple answer is to put Andrew's recursive
unlink code back in (as he suggested), which Bruce removed as rm etc.
were being used in commands/dbcommands.c (which should work fine under
Windows). Patch below
Regards, Dave
*** initdb.c.orig Sat Jun 19 22:15:28 2004
--- initdb.c Sat Jun 19 23:02:10 2004
***
*** 132,137
--- 132,144
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
static bool rmtree(char *path, bool rmtopdir);
+
+ #ifdef WIN32
+ static int init_unlink(const char *);
+ #else
+ #define init_unlink(x) unlink( (x) )
+ #endif /* WIN32 */
+
static char **replace_token(char **lines, char *token, char
*replacement);
static char **readfile(char *path);
static void writefile(char *path, char **lines);
***
*** 245,264
static bool
rmtree(char *path, bool rmtopdir)
{
! charbuf[MAXPGPATH + 64];
! #ifndef WIN32
! /* doesn't handle .* files, but we don't make any... */
! snprintf(buf, sizeof(buf), rm -rf \%s\%s, path,
! rmtopdir ? : /*);
! #else
! snprintf(buf, sizeof(buf), %s /s /q \%s\,
! rmtopdir ? rmdir : del, path);
! #endif
! return !system(buf);
}
/*
* make a copy of the array of lines, with token replaced by
replacement
--- 252,349
static bool
rmtree(char *path, bool rmtopdir)
{
! charfilepath[MAXPGPATH];
! DIR*dir;
! struct dirent *file;
! char **filenames;
! char **filename;
! int numnames = 0;
! struct stat statbuf;
! /*
! * we copy all the names out of the directory before we start
modifying
! * it.
! *
! */
!
! dir = opendir(path);
! if (dir == NULL)
! return false;
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! numnames++;
! }
!
! rewinddir(dir);
!
! filenames = xmalloc((numnames + 2) * sizeof(char *));
! numnames = 0;
!
! while ((file = readdir(dir)) != NULL)
! {
! if (strcmp(file-d_name, .) != 0
strcmp(file-d_name, ..) != 0)
! filenames[numnames++] = xstrdup(file-d_name);
! }
!
! filenames[numnames] = NULL;
!
! closedir(dir);
!
! /* now we have the names we can start removing things */
!
! for (filename = filenames; *filename; filename++)
! {
! snprintf(filepath, MAXPGPATH, %s/%s, path, *filename);
!
! if (stat(filepath, statbuf) != 0)
! return false;
!
! if (S_ISDIR(statbuf.st_mode))
! {
! /*
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 28 July 2004 09:29 To: Dave Page Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED] Subject: Re: [HACKERS] Cannot initdb in cvs tip Dave, now that we are nearing beta, I think we need to correct the initdb problem with removing the directory on Win32. Would you code this up as something that sits in /port/dirmod.c and have both initdb and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I think those are the only two. DROP TABLESPACE?) I'm pretty busy right now and can't guarantee I'll even be able to look at this until Friday (I spent the last 2 days on pg stuff so need to do some other things at work :-( ). If anyone has more time please shout, otherwise I'll get to this as soon as I can. I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. Yup. One question --- why is there a sleep loop needed for unlink in your patch? I don't know - which leads me nicely onto point out that it's not my patch :-) I think it was Andrew that orginally wrote it - I just created the patch to put it back in after it was removed. Regards, Dave. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Some release notes corrections.
Here's a patch of things I think may need to be adjusted. Maybe all or some of the changes will prove useful. Thanks, Brian B. --- release.sgml.orig 2004-07-28 00:01:22.620329079 -0400 +++ release.sgml2004-07-28 00:04:15.712796036 -0400 @@ -171,7 +171,7 @@ para Server configuration parameters SortMem and VacuumMem have been renamed to work_mem and maintenance_work_mem to better reflect - their use. The original names still supported. + their use. The original names are still supported. /para /listitem @@ -775,7 +775,7 @@ listitem para - Allowing composite types as table columns (Tom) + Allow composite types as table columns (Tom) /para /listitem @@ -812,7 +812,7 @@ Allow ALTER DATABASE ... OWNER (Euler Taveira de Oliveira) /para para - Previously this required modifying the system tables. + Previously, this required modifying the system tables. /para /listitem @@ -857,7 +857,7 @@ listitem para Add pg_get_serial_sequence() to return the serial columns - sequence name(Christopher Kings-Lynne) + sequence name (Christopher Kings-Lynne) /para para This allows automated scripts to reliabily find the serial @@ -875,7 +875,7 @@ listitem para - Warn of primary/foreign key mismatch requires costly lookup + Warn that primary/foreign key mismatch requires costly lookup. /itemizedlist /sect3 @@ -1011,7 +1011,7 @@ listitem para - Warn of empty string being passes to oid/float4/float8 data types; 7.6 + Warn of empty string being passed to oid/float4/float8 data types; 7.6 will throw an error instead (Neil) /para /listitem ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Andrew Dunstan wrote: I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop needed for unlink in your patch? We will just be calling the existing pgunlink() (which has a sleep) in the Windows cases, so this question becomes moot. Great. Thanks. Sorry I delayed addressing this for so long. Should we look at replacing cp/copy in 7.6? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Andrew Dunstan [EMAIL PROTECTED] writes: The small wrinkle here is that rmtree needs to make a copy of the file names before it starts removing things. In the backend case that means calling palloc() and friends - am I correct in assuming it is reasonable to do this in whatever context happens to be current when rmtree is called? Sure. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Bruce Momjian wrote: Dave, now that we are nearing beta, I think we need to correct the initdb problem with removing the directory on Win32. Would you code this up as something that sits in /port/dirmod.c and have both initdb and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I think those are the only two. DROP TABLESPACE?) The small wrinkle here is that rmtree needs to make a copy of the file names before it starts removing things. In the backend case that means calling palloc() and friends - am I correct in assuming it is reasonable to do this in whatever context happens to be current when rmtree is called? (I promise to make it clean up nicely). I wanted to keep a solution that was as native to the OS as possible, but because we can't do that on Win32 and few people like the unix system call to 'rm', it is time to clean it up. One question --- why is there a sleep loop needed for unlink in your patch? We will just be calling the existing pgunlink() (which has a sleep) in the Windows cases, so this question becomes moot. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Some release notes corrections.
Thanks, applied. --- Brian B. wrote: Here's a patch of things I think may need to be adjusted. Maybe all or some of the changes will prove useful. Thanks, Brian B. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Admin functions contrib
I talked to Tom about this today. First, I want to apologize for running you around in circles in this. I don't think we are giving it the attention it needs because of our schedule. I also think the functionality is drifting into the new features territory and this is also part of the delay you are seeing. I think you did a great thing by breaking the patch into two parts: one for logging, and the other for log reading and other stuff. The logging part is already in the patch queue. As for the function below, I first think the security issue brough up about them wasn't a valid concern because as I stated someone could just load the plperl server-side language and do anything to the OS. In fact this might be the best solution for you. Instead of trying to code read/write/rename/unlink and other functions into the backend as hardcoded, why not just have pgadmin load plperlu and as the super-user you have access to that functionality, and much more, especially with the new plperl in 7.5. In fact, your goal of modifying the postgresql.conf file is much more natural in perl than in the API you supplied, and probably more reliable. So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. --- Andreas Pflug wrote: These files add administrative functions to pgsql 7.5. All are used by pgAdmin3 or will be used in the near future if available. This is meant as contrib module, whilst IMHO all these functions should be integrated into the backend. Included are functions to log file access These where previously posted together with the logger subprocess patch and might get committed to the backend code. misc. send SIGHUP to postmaster generic file access functions These are more restrictive than the previously posted: Write access is necessary for files to rename and unlink, and paths are restricted to PGDATA and the logdir. size functions These are 7.5 replacements for dbsize. Regards, Andreas subdir = contrib/admin top_builddir = ../.. include $(top_builddir)/src/Makefile.global MODULE_big = admin DATA_built = admin.sql DOCS = README.admin OBJS = size.o genfile.o misc.o include $(top_srcdir)/contrib/contrib-global.mk /* ** * Administrative functions * * */ /* database object size functions (admin.c) */ CREATE FUNCTION pg_tablespace_size(oid) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_tablespace_size' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_database_size(oid) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_database_size' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_relation_size(oid) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_relation_size' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_size_pretty(bigint) RETURNS text AS 'MODULE_PATHNAME', 'pg_size_pretty' LANGUAGE C STABLE STRICT; /* generic file access functions (genfile.c) */ CREATE FUNCTION pg_file_stat(text) RETURNS record AS 'MODULE_PATHNAME', 'pg_file_stat' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_length(text) RETURNS bigint AS 'SELECT len FROM pg_file_stat($1) AS s(len int8, c timestamp, a timestamp, m timestamp, i bool)' LANGUAGE SQL VOLATILE STRICT; CREATE FUNCTION pg_file_read(text, bigint, bigint) RETURNS text AS 'MODULE_PATHNAME', 'pg_file_read' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_write(text, text, bool) RETURNS bigint AS 'MODULE_PATHNAME', 'pg_file_write' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_rename(text, text, text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_file_rename' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_unlink(text) RETURNS bool AS 'MODULE_PATHNAME', 'pg_file_unlink' LANGUAGE C VOLATILE STRICT; CREATE FUNCTION pg_file_rename(text, text) RETURNS bool AS 'SELECT pg_file_rename($1, $2, NULL); ' LANGUAGE SQL VOLATILE STRICT; CREATE FUNCTION pg_dir_ls(text, bool) RETURNS setof text AS 'MODULE_PATHNAME', 'pg_dir_ls' LANGUAGE C VOLATILE STRICT; /* Miscellaneous functions (misc.c) */ CREATE FUNCTION pg_reload_conf() RETURNS int4 AS 'MODULE_PATHNAME', 'pg_reload_conf' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_logfile_rotate() RETURNS bool AS 'MODULE_PATHNAME', 'pg_logfile_rotate' LANGUAGE C STABLE STRICT; CREATE FUNCTION pg_logdir_ls() RETURNS setof record AS 'MODULE_PATHNAME', 'pg_logdir_ls' LANGUAGE C VOLATILE STRICT; CREATE VIEW pg_logdir_ls AS SELECT * FROM pg_logdir_ls() AS A (filetime timestamp, pid int4, filename text); Misc functions for administrative purposes
Re: [PATCHES] logger subprocess
Bruce Momjian wrote: 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. Do not apply. I'm investigating issues under win32. Main issue: pgpipe doesn't create a pipe, but sockets. win32 doesn't like to redirect stderr into sockets... There's also an issue about file handles not being inherited. The file handles are there with _spawnl, but not CreateProcess (despite bInheritHandles=true). Still hunting. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
Bruce Momjian wrote:
Andrew Dunstan wrote:
I wanted to keep a solution that was as native to the OS as possible,
but because we can't do that on Win32 and few people like the unix
system call to 'rm', it is time to clean it up.
One question --- why is there a sleep loop needed for unlink in your
patch?
We will just be calling the existing pgunlink() (which has a sleep) in
the Windows cases, so this question becomes moot.
Great. Thanks. Sorry I delayed addressing this for so long.
Please check the enclosed patch to see if it does what you want.
Should we look at replacing cp/copy in 7.6?
probably. Put it as a possible TODO maybe.
cheers
andrew
Index: src/Makefile.global.in
===
RCS file: /projects/cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.189
diff -c -r1.189 Makefile.global.in
*** src/Makefile.global.in 2 Jun 2004 21:05:52 - 1.189
--- src/Makefile.global.in 28 Jul 2004 17:29:31 -
***
*** 340,346
#
# substitute implementations of the C library
! LIBOBJS = @LIBOBJS@ exec.o noblock.o path.o pipe.o pgsleep.o pgstrcasecmp.o sprompt.o thread.o
ifneq (,$(LIBOBJS))
LIBS := -lpgport $(LIBS)
--- 340,346
#
# substitute implementations of the C library
! LIBOBJS = @LIBOBJS@ dirmod.o exec.o noblock.o path.o pipe.o pgsleep.o pgstrcasecmp.o sprompt.o thread.o
ifneq (,$(LIBOBJS))
LIBS := -lpgport $(LIBS)
Index: src/backend/commands/dbcommands.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/dbcommands.c,v
retrieving revision 1.137
diff -c -r1.137 dbcommands.c
*** src/backend/commands/dbcommands.c 25 Jun 2004 21:55:53 - 1.137
--- src/backend/commands/dbcommands.c 28 Jul 2004 17:29:32 -
***
*** 915,921
Relation rel;
HeapScanDesc scan;
HeapTuple tuple;
- char buf[MAXPGPATH + 100];
rel = heap_openr(TableSpaceRelationName, AccessShareLock);
scan = heap_beginscan(rel, SnapshotNow, 0, NULL);
--- 915,920
***
*** 938,954
continue;
}
! #ifndef WIN32
! snprintf(buf, sizeof(buf), rm -rf '%s', dstpath);
! #else
! snprintf(buf, sizeof(buf), rmdir /s /q \%s\, dstpath);
! #endif
! if (system(buf) != 0)
{
ereport(WARNING,
(errmsg(could not remove database directory \%s\,
dstpath),
- errdetail(Failing system command was: %s, buf),
errhint(Look in the postmaster's stderr log for more information.)));
}
--- 937,947
continue;
}
! if (! rmtree(dstpath,true) )
{
ereport(WARNING,
(errmsg(could not remove database directory \%s\,
dstpath),
errhint(Look in the postmaster's stderr log for more information.)));
}
Index: src/bin/initdb/Makefile
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/Makefile,v
retrieving revision 1.41
diff -c -r1.41 Makefile
*** src/bin/initdb/Makefile 24 May 2004 01:01:37 - 1.41
--- src/bin/initdb/Makefile 28 Jul 2004 17:29:32 -
***
*** 15,21
override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS)
! OBJS= initdb.o exec.o
all: submake-libpq submake-libpgport initdb
--- 15,21
override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS)
! OBJS= initdb.o exec.o dirmod.o
all: submake-libpq submake-libpgport initdb
***
*** 25,30
--- 25,33
exec.c: % : $(top_srcdir)/src/port/%
rm -f $@ $(LN_S) $ .
+ dirmod.c: % : $(top_srcdir)/src/port/%
+ rm -f $@ $(LN_S) $ .
+
install: all installdirs
$(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X)
Index: src/bin/initdb/initdb.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
retrieving revision 1.44
diff -c -r1.44 initdb.c
*** src/bin/initdb/initdb.c 19 Jul 2004 02:47:12 - 1.44
--- src/bin/initdb/initdb.c 28 Jul 2004 17:29:32 -
***
*** 135,141
static void *xmalloc(size_t size);
static char *xstrdup(const char *s);
- static bool rmtree(char *path, bool rmtopdir);
static char **replace_token(char **lines, char *token, char *replacement);
static char **readfile(char *path);
static void writefile(char *path, char **lines);
--- 135,140
***
*** 241,270
}
/*
- * delete a directory tree recursively
- * assumes path points to a valid directory
- * deletes everything under path
- * if rmtopdir is true deletes the directory too
- */
- static bool
- rmtree(char *path, bool rmtopdir)
- {
- char buf[MAXPGPATH + 64];
-
- #ifndef WIN32
- /* doesn't handle .* files, but we don't make any... */
- snprintf(buf, sizeof(buf), rm -rf \%s\%s, path,
- rmtopdir ? : /*);
- #else
- snprintf(buf, sizeof(buf), %s /s /q \%s\,
-
Re: [PATCHES] [subxacts] Fixing TODO items
On Tue, Jul 27, 2004 at 01:32:01PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: There are some likely controversial changes; the Xid caches, in the first place. No kidding ;-) Ok, here is another try. This patch includes both the Xid cache rewrite, source documentation (removed the big comment in xact.c and added a README file), htup.h comments updated, and some user documentation. BTW, the overflow bit is certainly a better approach than the negative cache. I am not sure about locking w.r.t. the XidCache though. Please take a look at it. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Maybe there's lots of data loss but the records of data loss are also lost. (Lincoln Yeoh) diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/advanced.sgml 04pgproc/doc/src/sgml/advanced.sgml *** 00orig/doc/src/sgml/advanced.sgml 2004-04-14 16:45:53.0 -0400 --- 04pgproc/doc/src/sgml/advanced.sgml 2004-07-27 10:29:09.0 -0400 *** *** 257,262 --- 257,310 you are using. /para /note + +para + It's possible to control the statements in a transaction in a more + granular fashion through the use of firsttermsavepoints/. Savepoints + allow you to selectively discard parts of the transaction, while + committing the rest. This is done be defining a savepoint with + commandSAVEPOINT/, to which you can later roll back using + commandROLLBACK TO/. All statements between defining the savepoint + and rolling back to it will have no effect on the final transaction. +/para + +para + After rolling back to a savepoint, it continues to be defined, so you can + roll back to it several times. Conversely, if you are sure you won't need + to roll back to a particular savepoint again, it can be released, so the + system can free some resources. Keep in mind that releasing a savepoint + will automatically release all savepoints that were defined after it. +/para + +para + Remembering the bank database, suppose we debit $100.00 from Alice's + account, and credit Bob's account, only to find later that we wanted to + credit Wally's account. We could do it using savepoints like + + programlisting + BEGIN; + UPDATE accounts SET balance = balance - 100.00 + WHERE name = 'Alice'; + SAVEPOINT my_savepoint; + UPDATE accounts SET balance = balance + 100.00 + WHERE name = 'Bob'; + -- oops ... forget that and use Wally's account + ROLLBACK TO my_savepoint; + UPDATE accounts SET balance = balance + 100.00 + WHERE name = 'Wally'; + COMMIT; + /programlisting +/para + +para + This example is, of course, oversimplified, but there's a lot of control + to be had over a transaction block through the use of savepoints. + Moreover, commandROLLBACK TO/ is the only way to regain control of a + transaction block that was automatically put on aborted state by the + system for some reason, short of rolling it back completely and starting + again. +/para + /sect1 diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/allfiles.sgml 04pgproc/doc/src/sgml/ref/allfiles.sgml *** 00orig/doc/src/sgml/ref/allfiles.sgml 2004-06-26 00:28:45.0 -0400 --- 04pgproc/doc/src/sgml/ref/allfiles.sgml 2004-07-27 10:29:09.0 -0400 *** *** 88,96 --- 88,99 !entity notify system notify.sgml !entity preparesystem prepare.sgml !entity reindexsystem reindex.sgml + !entity releaseSavepoint system release.sgml !entity reset system reset.sgml !entity revoke system revoke.sgml !entity rollback system rollback.sgml + !entity rollbackTo system rollback_to.sgml + !entity savepoint system savepoint.sgml !entity select system select.sgml !entity selectInto system select_into.sgml !entity setsystem set.sgml diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/begin.sgml 04pgproc/doc/src/sgml/ref/begin.sgml *** 00orig/doc/src/sgml/ref/begin.sgml 2004-01-11 06:24:17.0 -0300 --- 04pgproc/doc/src/sgml/ref/begin.sgml2004-07-27 10:29:09.0 -0400 *** *** 145,150 --- 145,151 memberxref linkend=sql-commit endterm=sql-commit-title/member memberxref linkend=sql-rollback endterm=sql-rollback-title/member memberxref linkend=sql-start-transaction endterm=sql-start-transaction-title/member +memberxref linkend=sql-savepoint endterm=sql-savepoint-title/member /simplelist /refsect1 /refentry diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/release.sgml 04pgproc/doc/src/sgml/ref/release.sgml *** 00orig/doc/src/sgml/ref/release.sgml1969-12-31 21:00:00.0 -0300 --- 04pgproc/doc/src/sgml/ref/release.sgml 2004-07-27 10:29:09.0 -0400 *** *** 0 --- 1,138 +
Re: [PATCHES] pgxs: build infrastructure for extensions v4
Dear peter, Please find attached another new version of a patch which provides a working infrastructure for pg extensions. I hope it addresses all of Peter's comments. I'll be away for the next 3 weeks, so if minor changes are required it would be best if you could proceed without me... This patch breaks building outside the source tree in a very elaborate and obvious way. Unfortunately, this is all tied together so I haven't figured out yet if it can be fixed easily. I do not get your point. the aim is to be able to build outside the source tree as well? Also, the use of the install targets is a bit strange (install-all-headers install libpgport.a). I would simply not bother and install everything all the time. However, those who advocate the install-all-headers target may want to propose a different scheme. part of this existed before the patch. I tried to make the best of existing targets, especially as you requested that less targets should be used. I do agree with you that installing libgport.a under install-all-headers looks stupid, but the idea behind all-headers is that all which is required for extensions is installed. What about install-dev-files? or anything less misleading? I updated all contrib makefiles so that they can be used either the standard way after a configure, or the new way without needing a configure but with an already installed postgreSQL. Just try them with cd contrib/foo ; make USE_PGXS=1 install *AFTER* postgresql has been configure, compiled and installed. It should be compiled and installed wrt to the first pg_config which is found in the path. This is redundant. I think by now I'm looking for a patch that does not touch contrib at all (except perhaps contrib-global.mk). I really just touch that file in contrib. The only other exceptions are when other files were directly included or to reorder include wrt mqcro definitions, as far as I can remember. Much of the trouble arises from being too clever around there. We're trying to allow external modules to build, not internal ones. I really want to be able to install contribs as an afterthought and without reconfiguring. anyway, sorry I cannot really help as I m away from home. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pg_ctl -o option dumps core when processing postmaster arguments...
Uh, this patch is strange: -#define WHITESPACE \f\n\r\t\v/* as defined by isspace() */ +#define WHITESPACE \f\n\r\t\v\0 /* as defined by isspace() */ They are processed the same by the backend because every string has a trailing null. I think there must be some other bug that this covers up. --- Sean Chittenden wrote: The attached space adds '\0' as a whitespace character and prevents pg_ctl from running out of bounds when processing arguments for -o. I don't think this ever worked, at least on Mac, but I suspect every platform suffered from this bug. % gdb ./bin/pg_ctl GNU gdb 5.3-20030128 (Apple version gdb-309) (Thu Dec 4 15:41:30 GMT 2003) This GDB was configured as powerpc-apple-darwin. Reading symbols for shared libraries done (gdb) set arg -w -o -F start (gdb) run Starting program: /usr/local/pgsql/bin/pg_ctl -w -o -F start Reading symbols for shared libraries ++.. done waiting for postmaster to start... Program received signal EXC_BAD_ACCESS, Could not access memory. test_postmaster_connection () at pg_ctl.c:363 363 p++; (gdb) bt #0 test_postmaster_connection () at pg_ctl.c:363 #1 0x3594 in do_start () at pg_ctl.c:539 #2 0x3594 in do_start () at pg_ctl.c:539 #3 0x4874 in main (argc=-1610604968, argv=0x0) at pg_ctl.c:1360 (gdb) p *p $1 = 0 '\0' -sc [ Attachment, skipping... ] -- Sean Chittenden -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
