Re: [PATCHES] [HACKERS] Cannot initdb in cvs tip
-Original Message- From: John Hansen [mailto:[EMAIL PROTECTED] Sent: Sun 6/20/2004 2:27 AM To: Dave Page Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED] Subject: Re: [HACKERS] Cannot initdb in cvs tip you could of course rmdir /s /q $PGDATA mkdir $PGDATA if the purpose is to leave the directory intact if it already existed prior to install. Permissions may not allow you to do that. Regards, Dave ---(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] Compiling libpq with VisualC
Tom wrote: It's there to declare struct timeval, and I'm fairly certain that diking it out of the header would break things on some platforms. Where does Windows define struct timeval? struct timeval is defined in winsock.h under vc6. I'm checking for _MSC_VER now. Agreed. We define FRONTEND when compiling libpq. Please test for that and send another patch. elog.h is included in postgres.h, which is included in many src/port/*.c. Many of them are pretty straight, not requiring any backend specific stuff, so the attached patch will change postgres.h to c.h for most of them. Regards, Andreas Index: include/libpq/libpq-be.h === RCS file: /projects/cvsroot/pgsql-server/src/include/libpq/libpq-be.h,v retrieving revision 1.45 diff -u -r1.45 libpq-be.h --- include/libpq/libpq-be.h21 May 2004 05:08:04 - 1.45 +++ include/libpq/libpq-be.h20 Jun 2004 09:19:54 - @@ -18,7 +18,12 @@ #ifndef LIBPQ_BE_H #define LIBPQ_BE_H +#if _MSC_VER 0 +/* struct timeval is declared in winsock.h */ +#else #include sys/time.h +#endif + #ifdef USE_SSL #include openssl/ssl.h Index: port/getopt.c === RCS file: /projects/cvsroot/pgsql-server/src/port/getopt.c,v retrieving revision 1.5 diff -u -r1.5 getopt.c --- port/getopt.c 4 Aug 2003 00:43:33 - 1.5 +++ port/getopt.c 20 Jun 2004 09:19:55 - @@ -32,7 +32,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF */ -#include postgres.h +#include c.h #if defined(LIBC_SCCS) !defined(lint) Index: port/getrusage.c === RCS file: /projects/cvsroot/pgsql-server/src/port/getrusage.c,v retrieving revision 1.4 diff -u -r1.4 getrusage.c --- port/getrusage.c29 Nov 2003 19:52:13 - 1.4 +++ port/getrusage.c20 Jun 2004 09:19:55 - @@ -16,7 +16,7 @@ #include stdio.h #include errno.h -#include postgres.h +#include c.h #include rusagestub.h /* This code works on: Index: port/gettimeofday.c === RCS file: /projects/cvsroot/pgsql-server/src/port/gettimeofday.c,v retrieving revision 1.4 diff -u -r1.4 gettimeofday.c --- port/gettimeofday.c 21 May 2004 05:08:05 - 1.4 +++ port/gettimeofday.c 20 Jun 2004 09:19:55 - @@ -23,7 +23,7 @@ * SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. */ -#include postgres.h +#include c.h #include sys/time.h Index: port/kill.c === RCS file: /projects/cvsroot/pgsql-server/src/port/kill.c,v retrieving revision 1.1 diff -u -r1.1 kill.c --- port/kill.c 27 May 2004 13:08:57 - 1.1 +++ port/kill.c 20 Jun 2004 09:19:55 - @@ -14,7 +14,7 @@ *- */ -#include postgres.h +#include c.h #ifdef WIN32 /* signal sending */ Index: port/noblock.c === RCS file: /projects/cvsroot/pgsql-server/src/port/noblock.c,v retrieving revision 1.1 diff -u -r1.1 noblock.c --- port/noblock.c 10 Mar 2004 21:12:49 - 1.1 +++ port/noblock.c 20 Jun 2004 09:19:55 - @@ -12,7 +12,7 @@ *- */ -#include postgres.h +#include c.h #include sys/types.h #include fcntl.h Index: port/pgsleep.c === RCS file: /projects/cvsroot/pgsql-server/src/port/pgsleep.c,v retrieving revision 1.3 diff -u -r1.3 pgsleep.c --- port/pgsleep.c 12 Apr 2004 16:19:18 - 1.3 +++ port/pgsleep.c 20 Jun 2004 09:19:56 - @@ -10,7 +10,7 @@ * *- */ -#include postgres.h +#include c.h #include unistd.h #include sys/time.h Index: port/pgstrcasecmp.c === RCS file: /projects/cvsroot/pgsql-server/src/port/pgstrcasecmp.c,v retrieving revision 1.1 diff -u -r1.1 pgstrcasecmp.c --- port/pgstrcasecmp.c 7 May 2004 00:24:59 - 1.1 +++ port/pgstrcasecmp.c 20 Jun 2004 09:19:56 - @@ -20,7 +20,7 @@ * *- */ -#include postgres.h +#include c.h #include ctype.h Index: port/pipe.c === RCS file: /projects/cvsroot/pgsql-server/src/port/pipe.c,v retrieving revision 1.5 diff -u -r1.5 pipe.c --- port/pipe.c 11 Jun 2004 03:48:35 - 1.5 +++ port/pipe.c 20 Jun 2004 09:19:56 - @@ -15,7 +15,7 @@ *- */ -#include postgres.h +#include c.h #ifdef WIN32 int Index: port/sprompt.c
Re: [PATCHES] eventlog fix
Hello, I downloaded and compiled all files you store in CVS pgevent directory and it works. Following the discusion posted yesterday, I made a test with SimpleMC a alternative MC compiler ( http://www.volny.cz/xnavara/SimpleMC.zip) but unfortunatelly it doesn't works MSG0001.bin file generated are differents and consequently Messages are seing missing for Windows eventviewer. regards Laurent Ballester - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Laurent Ballester [EMAIL PROTECTED] Cc: Alvaro Herrera [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 20, 2004 3:33 AM Subject: Re: [PATCHES] eventlog fix Patch applied, with doc additions I already posted. Please test CVS and let me know how it works. I added a README containing your explaination below for our later reference. I added the MSG01.bin as a binary CVS checkin. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Attached is a patch implementing this functionality. I've modified make_new_heap() as well as swap_relfilenodes() to not assume that tablespaces remain the same from old to new heap. I thought it better to go down this road than introduce a lot of duplicate code. I have tried your patches and it works great. Thanks. One thing I noticed was if I change tablespace for a table having indexes, they are left in the old tablespace and the table itself was moved to the new tablespace. I regard this is a good thing since I could assign different table spaces for table and indexes. It would be even better to assign different tablespaces for each index. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Attached is a patch implementing this functionality. I've modified make_new_heap() as well as swap_relfilenodes() to not assume that tablespaces remain the same from old to new heap. I thought it better to go down this road than introduce a lot of duplicate code. I have tried your patches and it works great. Thanks. One thing I noticed was if I change tablespace for a table having indexes, they are left in the old tablespace and the table itself was moved to the new tablespace. I regard this is a good thing since I could assign different table spaces for table and indexes. It would be even better to assign different tablespaces for each index. Hm. It seems there's a problem with tablespaces. What I did was: pgbench -i test alter table accounts set tablespace mydb2; \d accounts backend crashes by signal 11... -- Tatsuo Ishii ---(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
Re: [PATCHES] pg_ctl service integration for WIN32
Amended patch attached. Claudio Hi! Been testing this, and found a couple of small issues. Attached is a patch that fixes these. (Note - Claudios patch is included in this one, since it hasn't been applied yet..) The issues: 1) When something goes bad, output went to stderr. No way to see that on win32. Changed to put it to the eventlog when stderr is not a tty. This also replaces the fprintf(stderr with write_stderr(, the same way my backend patch does (updated version coming up soon). 2) Append .exe to the filename if that is not done automatically. It wasn't done for me, but since other have had it running, it must work sometimes... Without this, the service won't stard with an error stating that there is no valid win32 executable availeble. 3) Prepend .\ to the account name used to register the service, if no domain is specified. Required for local domains, and makes it easier for those not used to having to type .\ for local accounts.. Apart from those, looks good to me. //Magnus pg_ctl_service.patch Description: pg_ctl_service.patch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] stderr win32 admin check
Attached is the updated version of this patch, which now includes proper testing for win32 service running. This is tested and verified with Claudios service wrapper pg_ctl patch (including the parts I added and sent in a short while ago). security.c goes in backend/port/win32/ //Magnus -Original Message- From: Magnus Hagander Sent: den 19 juni 2004 13:55 To: Bruce Momjian Cc: Tom Lane; [EMAIL PROTECTED] Subject: Re: [PATCHES] stderr win32 admin check I plan to resubmit this patch shortly (hopefully during the weekend) including supprot for detecting if running as a service (and thus pick eventlog support). From what I can tell, the rest should be Ok to go, so expect a new one shortly. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Magnus, where are we on this refactoring process. --- Magnus Hagander wrote: * Created function write_stderr(const char *fmt, ...), used before elog can be used. This function will write to stderr on unix and on win32 fconsole. It will write to the eventlog on win32 when running as a service. * Changed all (most? I think I got all) fprintf(stderr,...) to use this function instead. That way, we gain the ability to put all the other preivously-stderr-messages to the eventlog as well. I'm not sure this is a good idea. The remaining uses of stderr were that way for a reason, not because someone had forgot to change them into elog calls. It would be a lot less invasive to just move the privilege check as you originally intended. I figured as long as nothing dangerous (e.g. using memory allocations etc) is done in the function, it should be just as safe as fprintf. On Unix, it does nothing more than a simple fprintf anyway (one call deeper). The only difference in practice is that we can put them in the eventlog on win32 (again, only using calls that are safe in this context). If we do it the other way, we are going to lose these other messages when running as a service on win32 (since we specifically are not using ereport(), per what you say above). Also, this would remove the check so you could do initdb and other operations that are blocked today (that don't go through postmaster.c) when being root, I assumed that was not good either... //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 security.c Description: security.c ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] initdb initial password from file
Attached is a patch that adds the option --pwfile=filename to initdb. The first line of this file is used to set the new superuser password (the same way --pwprompt asks for one). This feature is needed for the win32 GUI installer (possibly other installers?), which need a way to specify the password to be set. Per previous discussions commandline parameter or environment variable are not secure. Storing it in a file is the same thing libpq does for ~/.pgpass, and should be secure enough, I think. //Magnus initdb_pwfile.patch Description: initdb_pwfile.patch ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Cancel/Kill backend functions -- docs
Here's at least some documentation about these. Not sure if we want to refer to these somewhere else as well, but this gives them entries in misc functions. I don't have a working SGML build environment, so I'm not sure if this will turn out the way it's supposed (or even work at all). I tried to model it on stuff that's nearby. If not, let me know where I missed and I'll update it. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: den 2 juni 2004 23:30 To: Magnus Hagander Cc: Neil Conway; [EMAIL PROTECTED] Subject: Re: [PATCHES] Cancel/Kill backend functions Patch applied. Thanks. Not sure where to document them. I think we talked about this already. I updated the system catalog version. --- signal_funcs_doc.patch Description: signal_funcs_doc.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] stderr win32 admin check
I am confused. There are no hooks to call this function right now. Is it called by Claudio's patch? --- Magnus Hagander wrote: Attached is the updated version of this patch, which now includes proper testing for win32 service running. This is tested and verified with Claudios service wrapper pg_ctl patch (including the parts I added and sent in a short while ago). security.c goes in backend/port/win32/ //Magnus -Original Message- From: Magnus Hagander Sent: den 19 juni 2004 13:55 To: Bruce Momjian Cc: Tom Lane; [EMAIL PROTECTED] Subject: Re: [PATCHES] stderr win32 admin check I plan to resubmit this patch shortly (hopefully during the weekend) including supprot for detecting if running as a service (and thus pick eventlog support). From what I can tell, the rest should be Ok to go, so expect a new one shortly. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Magnus, where are we on this refactoring process. --- Magnus Hagander wrote: * Created function write_stderr(const char *fmt, ...), used before elog can be used. This function will write to stderr on unix and on win32 fconsole. It will write to the eventlog on win32 when running as a service. * Changed all (most? I think I got all) fprintf(stderr,...) to use this function instead. That way, we gain the ability to put all the other preivously-stderr-messages to the eventlog as well. I'm not sure this is a good idea. The remaining uses of stderr were that way for a reason, not because someone had forgot to change them into elog calls. It would be a lot less invasive to just move the privilege check as you originally intended. I figured as long as nothing dangerous (e.g. using memory allocations etc) is done in the function, it should be just as safe as fprintf. On Unix, it does nothing more than a simple fprintf anyway (one call deeper). The only difference in practice is that we can put them in the eventlog on win32 (again, only using calls that are safe in this context). If we do it the other way, we are going to lose these other messages when running as a service on win32 (since we specifically are not using ereport(), per what you say above). Also, this would remove the check so you could do initdb and other operations that are blocked today (that don't go through postmaster.c) when being root, I assumed that was not good either... //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 Content-Description: security.c [ Attachment, skipping... ] -- 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
Re: [PATCHES] stderr win32 admin check
You probably would've been a lot less confused if I had actually included the *patch* along with the C file.. Sorry! //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: den 20 juni 2004 20:27 To: Magnus Hagander Cc: Tom Lane; [EMAIL PROTECTED] Subject: Re: [PATCHES] stderr win32 admin check I am confused. There are no hooks to call this function right now. Is it called by Claudio's patch? --- Magnus Hagander wrote: Attached is the updated version of this patch, which now includes proper testing for win32 service running. This is tested and verified with Claudios service wrapper pg_ctl patch (including the parts I added and sent in a short while ago). security.c goes in backend/port/win32/ //Magnus -Original Message- From: Magnus Hagander Sent: den 19 juni 2004 13:55 To: Bruce Momjian Cc: Tom Lane; [EMAIL PROTECTED] Subject: Re: [PATCHES] stderr win32 admin check I plan to resubmit this patch shortly (hopefully during the weekend) including supprot for detecting if running as a service (and thus pick eventlog support). From what I can tell, the rest should be Ok to go, so expect a new one shortly. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Magnus, where are we on this refactoring process. --- Magnus Hagander wrote: * Created function write_stderr(const char *fmt, ...), used before elog can be used. This function will write to stderr on unix and on win32 fconsole. It will write to the eventlog on win32 when running as a service. * Changed all (most? I think I got all) fprintf(stderr,...) to use this function instead. That way, we gain the ability to put all the other preivously-stderr-messages to the eventlog as well. I'm not sure this is a good idea. The remaining uses of stderr were that way for a reason, not because someone had forgot to change them into elog calls. It would be a lot less invasive to just move the privilege check as you originally intended. I figured as long as nothing dangerous (e.g. using memory allocations etc) is done in the function, it should be just as safe as fprintf. On Unix, it does nothing more than a simple fprintf anyway (one call deeper). The only difference in practice is that we can put them in the eventlog on win32 (again, only using calls that are safe in this context). If we do it the other way, we are going to lose these other messages when running as a service on win32 (since we specifically are not using ereport(), per what you say above). Also, this would remove the check so you could do initdb and other operations that are blocked today (that don't go through postmaster.c) when being root, I assumed that was not good either... //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 Content-Description: security.c [ Attachment, skipping... ] -- 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 stderr.patch Description: stderr.patch ---(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] nested xacts and phantom Xids
Alvaro Herrera [EMAIL PROTECTED] writes: Here I present the nested transactions patch and the phantom Xids patch that goes with it. I looked at the phantom XIDs stuff a bit. I still have little confidence that the concept is correct :-( but here are some comments on the code level. + * They are marked immediately in pg_subtrans as direct childs of the topmost + * Xid (no matter how deep we are in the transaction tree), Why is that a good idea --- won't it cause problems when you commit/abort an intermediate level of subtransaction? + * All this happens when HeapTupleHeaderSetXmax is called and the Xmin of the + * tuple is one of the Xids of the current transaction. + * + * Note that HeapTupleHeaderGetXmax/GetXmin return the masqueraded Xmin and + * Xmax, not the real one in the tuple header. I think that putting this sort of logic into Set/Get Xmin/Xmax is a horrid idea. They are supposed to be transparent fetch/store macros, not arbitrarily-complex filter functions. They're also supposed to be reasonably fast :-( + * ... We know to do this when SetXmax is called + * on a tuple that has the HEAP_MARKED_FOR_UPDATE bit set. Uglier and uglier. *** *** 267,274 return true; /* deleting subtransaction aborted */ ! if (TransactionIdDidAbort(HeapTupleHeaderGetXmax(tuple))) ! return true; Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple))); --- 268,276 return true; /* deleting subtransaction aborted */ ! if (tuple-t_infomask HEAP_XMIN_IS_PHANTOM) ! if (TransactionPhantomIsCommittedPhantom(HeapTupleHeaderGetPhantomId(tuple))) ! return true; Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple))); Er, what happened to checking for the deleting subtransaction aborted case? On the whole, I think this was an interesting exercise but also an utter failure. We'd be far better off to eat the extra 4 bytes per tuple header and put back the separate Xmax field. The costs in both runtime and complexity/reliability of this patch are simply not justified by a 4-byte savings. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Tablespaces
On Sun, 20 Jun 2004, Simon Riggs wrote: On Thu, 2004-05-27 at 07:59, Gavin Sherry wrote: Attached is my latest patch implementing tablespaces. This has all the functionality I was planning for 7.5. Most of the information about the patch is contained in the patch/documentation, previous submissions and the archives. Testing, review, comments would be greatly appreciated. I've reviewed your patch by eye, but can't see anything in your patch about relocating the pg_xlog directory. I didn't intend on looking at that in this patch. pg_xlog is only referred to in 4 lines in the code (incl. PITR patch): - xlog.c - pgarch.c (PITR patch) - initdb.c - pgresetxlog.c Each time it is simply setting a string to the location of the xlog directory. If we could work out a way of... i) letting the pg_xlog be created by default ii) then transferring this to another tablespace later? That would give us maximum flexibility, since you may wish to change location later when workload changes/increases. Sounds reasonable. Perhaps adding a GUC...for wal_tablespace (pls suggest name!) defaults to the pg_xlog directory, when not listed? Changeable only at postmaster startup... This could be done independently of tablespaces, but I think any directory flexibility/change should work using the tablespace infrastructure, not in addition to it. If the change is as simple as you propose, it has nothing to do with the tablespace code. Also, I don't see any situation where we would want to make use of the tablespace code. Could we discuss this? it sounds like a change we could make happen fairly quickly now your code is in place. Again, I don't think my code really has any affect on the location of xlog. Of course, I accept that many may say that such a change is not really needed, but then... Comments anyone? Gavin ---(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
Re: [PATCHES] nested xacts and phantom Xids
Bruce Momjian [EMAIL PROTECTED] writes: I don't feel too bad about the runtime cost if only subtransactions are paying that cost. That's exactly why I'm so exercised about what's been done to the HeapTupleSet/Get macros. That's significant cost that's paid even when you're not using *any* of this stuff. I know we are really stretching the system here but I would like to try a little more rather than give up and taking a space hit for all tuples. I don't even have any confidence that there are no fundamental bugs in the phantom-xid concept :-(. I'd be willing to play along if an implementation that seemed acceptable speedwise were being offered, but this thing is not preferable to four-more-bytes even if it works. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] nested xacts and phantom Xids
Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Here I present the nested transactions patch and the phantom Xids patch that goes with it. I looked at the phantom XIDs stuff a bit. I still have little confidence that the concept is correct :-( but here are some comments on the code level. + * They are marked immediately in pg_subtrans as direct childs of the topmost + * Xid (no matter how deep we are in the transaction tree), Why is that a good idea --- won't it cause problems when you commit/abort an intermediate level of subtransaction? I don't think so. The phantom xid is used only by the outside transaction waiting for that tuple to be committe or aborted. The outside tranaction will sleep on the topmost xid completing, then check the phantom xid status for commit/abort. Within the transaction, I think he uses command counter to know the creation and destruction sub-xid. I think right now phantom xids are used only for making parts of a subtransaction committed or aborted and only in cases where the tuple is created and destroyed by parts of the same transaction tree. I don't feel too bad about the runtime cost if only subtransactions are paying that cost. I know we are really stretching the system here but I would like to try a little more rather than give up and taking a space hit for all tuples. Let me add that outside transactions read those phantom xid only when they are doing dirty reads. What I don't understand is when do outside transactions see tuples created inside a transaction? INSERT into a table with a unique key? Once the main transaction commits, these phantom tuples should work just like ordinary tuples except they get their cmin overwritten when they are expired, I think. -- 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] nested xacts and phantom Xids
Bruce Momjian [EMAIL PROTECTED] writes: Let me add that outside transactions read those phantom xid only when they are doing dirty reads. What I don't understand is when do outside transactions see tuples created inside a transaction? INSERT into a table with a unique key? Once the main transaction commits, these phantom tuples should work just like ordinary tuples except they get their cmin overwritten when they are expired, I think. You're not doing anything to increase my confidence level in this concept. You invented it, and even you aren't sure how it works. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] nested xacts and phantom Xids
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Let me add that outside transactions read those phantom xid only when they are doing dirty reads. What I don't understand is when do outside transactions see tuples created inside a transaction? INSERT into a table with a unique key? Once the main transaction commits, these phantom tuples should work just like ordinary tuples except they get their cmin overwritten when they are expired, I think. You're not doing anything to increase my confidence level in this concept. You invented it, and even you aren't sure how it works. And your point is? I am trying to help Alvaro. I came up with an idea, and some thought it would help solve the problem. What ideas do you have to help him? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [pgsql-hackers-win32] Data directory with trailing [back]slash
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
It's not possible to start the postmaster on win32 with:
postmaster -D d:\pgdata\
or
postmaster -D d:/pgdata/
Sounds like canonicalize_path() needs to be applied a bit sooner than
it is.
BTW I think canonicalize_path() is a few bricks shy of a load yet:
I'm not sure it works well with Windows drive-letters, and it definitely
will strip significant slashes when given input like '/' or 'C:\'.
Feel free to fix those problems while at it...
Or use the attached patch, which I think does it right.
cheers
andrew
Index: src/port/path.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/path.c,v
retrieving revision 1.20
diff -c -r1.20 path.c
*** src/port/path.c 11 Jun 2004 17:09:13 - 1.20
--- src/port/path.c 21 Jun 2004 00:19:27 -
***
*** 115,121
--- 115,144
if (*p == '\\')
*p = '/';
}
+
+ /* skip network and drive specifiers for win32 */
+ if (strlen(path) = 2)
+ {
+ if (path[0] == '/' path[1] == '/')
+ {
+ /* network drive */
+ path = strstr(path + 2, /);
+ if (path == NULL)
+ return;
+ }
+ else if (path[1] == ':'
+ ((path[0] = 'a' path[0] = 'z') ||
+ (path[0] = 'A' path[0] = 'Z')))
+ {
+ /* local drive */
+ path += 2;
+ }
+ }
+
#endif
+
+ if (path[0] == '/')/* don't trim leading '/'. */
+ ++path;
trim_trailing_separator(path);
}
---(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
Re: [PATCHES] nested xacts and phantom Xids
Alvaro Herrera [EMAIL PROTECTED] writes: Here I present the nested transactions patch and the phantom Xids patch that goes with it. I took a very preliminary look through the nested-xacts patch, too. Missing: rollback of SET CONSTRAINTS and GUC vars. There's a good deal more than that missing :-(. Here are the modules or actions that are called in CommitTransaction and/or AbortTransaction that have not yet been touched by the patch: shared-inval message queue processing (inval.c) lo_commit localbuf.c (refcounts need fixed same as bufmgr) eoxactcallbacks API needs extension GUC namespace (temp namespace cleanup) files (close/drop temp files) reset current userid during xact abort password file updating SetReindexProcessing disable (can these be nested??) Of these the one that I think most urgently needs attention is inval.c; that is complicated code already and figuring out what should happen for subtrans commit/abort is not trivial. The others look relatively straightforward to fix, if tedious. Given patches for inval.c and guc.c, I would say that the patch is functionally close enough to done that we could commit to including it in 7.5 --- the other stuff could be wrapped up post-feature-freeze. BUT (you knew there was a but coming, right?) ... I am really really disturbed about the potential performance hit from this patch. I don't think we want to have a nested-transaction feature that imposes significant overhead on people who aren't actually using nested transactions. As I looked through the patch I found quite a few places that would impose such overhead. The main thing that's bothering me is that TransactionIdIsInProgress has been turned from a relatively cheap test (just scan the in-memory PGPROC array) into an exceedingly expensive one. It's gratutitously badly coded (for N open main transactions it does N searches of the subtrans tree, when one would do), but I don't really want it going to the subtrans tree at all during typical cases. We had talked about keeping a limited number of active subtrans IDs in the PGPROC array, and I think we're really going to need to do that to buy back performance here. (BTW, what is the intended behavior of TransactionIdIsInProgress for a committed or aborted subtransaction whose parent is still open? If it has to recognize aborted subtranses as still in progress then things get very messy, but I think it probably doesn't have to.) I'm quite unhappy with the wide use of SubTransXidsHaveCommonAncestor to replace TransactionIdEquals in tqual.c, too. This turns very cheap tests into very expensive ones --- whether or not you use subtransactions --- and unfortunately tqual.c is coded on the assumption that these tests are cheap. We can *not* afford to repeat SubTransXidsHaveCommonAncestor for every open main transaction every time we check a tuple. In many ways this is the same problem as with TransactionIdIsInProgress, and it probably needs a similar solution. Also I found it annoying that XactLockTableWait waits for a top xact even when target subxact has already aborted; possibly this is even a recipe for deadlock. Perhaps should iterate up the tree one level at a time, waiting for each? Would mean that subxacts have to acquire a lock on their xid that other people can wait for, but this is not necessarily bad. (In fact, if we do that then I don't think XactLockTableWait has to change at all.) So I think there are several must-fix performance issues as well before we can make a decision to accept this for 7.5. I'd feel better about this if we had another month, but with ten days before feature freeze it's gonna be touch and go. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] nested xacts and phantom Xids
Bruce Momjian [EMAIL PROTECTED] writes: What ideas do you have to help him? Eat the four-byte overhead. Quite frankly, given the other functionality and performance issues he has to solve in the next ten days (see my other message just now), I think he'd be a fool to spend one more minute on phantom XIDs. Maybe for 7.6 someone will have the time to make the idea work. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Admin guide tablespace docs
Gavin Sherry [EMAIL PROTECTED] writes: Attached. Applied with minor editorialization. Thanks. regards, tom lane ---(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
[PATCHES] pg_get_serial_sequence
Hi, Attached is a new backend function, pg_get_serial_sequence. It allows you get a sequence name in a format suitable for use with the sequence functions. Has docs and regression. I updated pg_dump to use it as well. Tested against 7.5 and 7.4 backends, with independent and dependent sequences. Handles quoting, escaping and schema-qualification. Someone might want to run their eyes over my doc changes (I have no way of compiling them) and check that my function is done in the most efficient way. (It's small!) Chris pg_get_serial_sequence.txt.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 8: explain analyze is your friend
