Re: [PATCHES] [GENERAL] pg_dump and schema namespace notes
Rory Campbell-Lange wrote: I think this is a suggestion/comment! pg_dump man page: --schema-only Dump only the schema (data definitions), no data I think this use of the word schema is confusing, meaning data definitions, whereas elsewhere in the man page schema are used as a namespace definition. --schema=schema Dump the contents of schema only. If this option is not speci- fied, all non-system schemas in the target database will be dumped It would be nice if this could be a comman separated list (like set search_path; A,info,public etc). I have updated the pg_dump manual page to more clearly distinguish the two meanings of schema. I referred to object definitions more frequently. Applied patch attached. -- 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 Index: doc/src/sgml/ref/pg_dump.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/pg_dump.sgml,v retrieving revision 1.71 diff -c -c -r1.71 pg_dump.sgml *** doc/src/sgml/ref/pg_dump.sgml 7 Jun 2004 20:35:57 - 1.71 --- doc/src/sgml/ref/pg_dump.sgml 10 Jul 2004 15:47:45 - *** *** 112,118 termoption--data-only//term listitem para ! Dump only the data, not the schema (data definitions). /para para --- 112,118 termoption--data-only//term listitem para ! Dump only the data, not the object definitions (schema) /para para *** *** 233,239 para Output a commandtar/command archive suitable for input into applicationpg_restore/application. Using this archive format ! allows reordering and/or exclusion of schema elements at the time the database is restored. It is also possible to limit which data is reloaded at restore time. /para --- 233,239 para Output a commandtar/command archive suitable for input into applicationpg_restore/application. Using this archive format ! allows reordering and/or exclusion of database objects at the time the database is restored. It is also possible to limit which data is reloaded at restore time. /para *** *** 246,253 para Output a custom archive suitable for input into applicationpg_restore/application. This is the most flexible ! format in that it allows reordering of data load as well ! as schema elements. This format is also compressed by default. /para /listitem /varlistentry --- 246,253 para Output a custom archive suitable for input into applicationpg_restore/application. This is the most flexible ! format in that it allows reordering of loading data as well ! as object definitions. This format is also compressed by default. /para /listitem /varlistentry *** *** 322,328 ownership of objects to match the original database. By default, applicationpg_dump/application issues commandSET SESSION AUTHORIZATION/command ! statements to set ownership of created schema elements. These statements will fail when the script is run unless it is started by a superuser (or the same user that owns all of the objects in the script). --- 322,328 ownership of objects to match the original database. By default, applicationpg_dump/application issues commandSET SESSION AUTHORIZATION/command ! statements to set ownership of created database objects. These statements will fail when the script is run unless it is started by a superuser (or the same user that owns all of the objects in the script). *** *** 354,360 termoption--schema-only/option/term listitem para ! Dump only the schema (data definitions), no data. /para /listitem /varlistentry --- 354,360 termoption--schema-only/option/term listitem para ! Dump only the object definitions (schema), not data. /para /listitem /varlistentry ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] contrib/dbmirror
On 7/1/2004 12:39 AM, Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Attached is a 1 line bug fix for dbmirror that was submitted. It fixes a bug where some transactions could be dropped when writing mirrored SQL statements to files. I know that there were discussions regarding removing the replication contribs (rserv and dbmirror) prior to 7.5 release, but given that that has not happened yet, any objections to me applying this? There was talk of removing rserv, because it's seriously obsolete and not maintained, but I don't think the same argument applies to dbmirror. Patch away. There was never any intention to remove them. They should be relocated to the pgfoundry. The reason for this is that up to today, people looking for replication solutions find rserv in contrib and waste time with it. Others try dbmirror and later on apply their results with trigger based replication to Slony and think must be slow. dbmirror is well maintained, and I know that it can and will do things that Slony is not planned to do (like keyrange based partial replication). It should be kept, but from the past discussions we know that contrib is a location that makes a lot of people assume that those things are recommended, preferred or some such. Jan regards, tom lane ---(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 -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] build infrastructure for extensions v3
Bruce Momjian wrote: Wow, that is a big patch. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. ISTM that this version still does not allow building contrib without having installed pg_config first. That is a no-no. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] value.h has no VALUE_H
The outer #define was forgotten. Attached patch adds it; please apply. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Sallah, I said NO camels! That's FIVE camels; can't you count? (Indiana Jones) Index: src/include/nodes/value.h === RCS file: /home/alvherre/cvs/pgsql-server/src/include/nodes/value.h,v retrieving revision 1.1 diff -c -r1.1 value.h *** src/include/nodes/value.h 7 Jan 2004 18:43:36 - 1.1 --- src/include/nodes/value.h 10 Jul 2004 23:11:00 - *** *** 11,16 --- 11,19 *- */ + #ifndef VALUE_H + #define VALUE_H + #include nodes/nodes.h /*-- *** *** 54,56 --- 57,61 extern Value *makeFloat(char *numericStr); extern Value *makeString(char *str); extern Value *makeBitString(char *str); + + #endif/* VALUE_H */ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] build infrastructure for extensions v3
Peter Eisentraut [EMAIL PROTECTED] writes: ISTM that this version still does not allow building contrib without having installed pg_config first. That is a no-no. Sounds like the list of objections is getting shorter anyway ;-). Do you feel that this patch is going in basically the right direction? I've not had any time to look at it myself ... regards, tom lane ---(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] [HACKERS] Configuration patch
I have applied the non-include parts of this patch, which allows the configuration files to exist outside the data directory. I have added a TODO: * Add include functionality to postgresql.conf Patch attached and applied. It still needs more documentation. Right now only the postmaster manual page describes this functionality. Maybe it needs initdb support too so it can be done automatically. Is this a TODO? Also, the old code allowed the postmaster to start if it couldn't find postgresql.conf. I changed it in this patch because the new decoupling of the file locations makes a missing postgresql.conf much more likely, and of course it will never work without a postgresql.conf when they are decoupled anyway. Should we fail if we can't find pg_ident.conf? Right now we don't. --- [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: AFAICS this patch breaks standalone backends, since the smarts involved in dealing with the new flavors of directory layouts were not taught to postgres.c. Hmm, I guess its time to get a CVS version of PG. This was originally done in 7.3 and migrated to 7.4. 7.5 is substantially different? The same issue applied in 7.4 and before; but yes, all that code looks noticeably different in CVS tip. As for include not being a variable, no it isn't. It is a new class of GUC parameter. Would you like a better syntax? As I said, I think this class of GUC parameter is ill-considered. See below FWIW: This is exactly the same syntax that was discussed, and no one brought up that it was a problem. You even said you liked the idea of include. I like the idea of include. I don't like this implementation. OK. I wanted to create a generic facility for smarter configuration. Being able to create functions and pass parameters should allow smaller more focused configuration parsing. I don't believe include is a representative of a class; it seems a specialized one-of-a-kind thing. If you had one or two more examples of this class then I might think you are onto something, but as-is there is no reason to think that you've got a well-defined idea or have made the right decisions about how it should work. OK, imagine this, maybe not right now, but in the future.. In the configuration file, one can load C code modules like in apache. Not just SQL functions, but modules of functionality, like foreign table types. Basically, include is not a variable because neither set include nor show include are sensible operations at all. Implementing it in a way that makes you have to deal with these possibilities is simply wrongheaded. Another reason why it's not a variable is that processing it as a variable means the sub-file is not read in the order that the user would naturally expect; with the implementation as you have it, the behavior would be quite surprising as to which file wins if both outer file and subfile set the same variable. (Take another look at guc-file.l: it eats the whole file and only then starts to evaluate variables.) What I'd think is reasonable is a special case hack in guc-file.l that checks for opt_name = include and does something immediately upon seeing it. (CVS tip has a special hack for custom_variable_classes here, which has got problems of its own because that *is* a variable, but that's right around where I'd envision inserting code for include.) I'm open to suggestions. Would you prefer stating the function parameters with a special character? '#' is taken, how about '!' ? is in: It's not the syntax I'm objecting to; it's the implementation. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 Index: doc/src/sgml/runtime.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.268 diff -c -c -r1.268 runtime.sgml *** doc/src/sgml/runtime.sgml 27 Jun 2004 22:58:19 - 1.268 --- doc/src/sgml/runtime.sgml 11 Jul 2004 00:06:48 - *** *** 563,568 --- 563,616 any desired selection condition. /para +sect2 id=runtime-config-configuration-files + titleConfiguration Files/title + + variablelist + + varlistentry id=guc-pgdata xreflabel=pgdata + termvarnamepgdata/varname (typestring/type)/term + listitem +para + Specifies the directory to use for data storage
Re: [PATCHES] [HACKERS] Configuration patch
Oh, also, I was not able to put a name on the patch because I only have a 'pgsql' email address for the submitter. Hope that is OK. --- [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: This patch incorporates a number of changes suggested by the group. The purpose of this patch is to move postgresql to a position where all configuration options are specified in one place. The postgresql.conf file could completely document a postgresql environment. AFAICS this patch breaks standalone backends, since the smarts involved in dealing with the new flavors of directory layouts were not taught to postgres.c. Hmm, I guess its time to get a CVS version of PG. This was originally done in 7.3 and migrated to 7.4. 7.5 is substantially different? The documentation is rather lacking as well. include is not really a variable and should not be documented as if it were --- for one thing, that leaves the reader wondering if he can only specify it once. The other added variables are insufficiently doc'd because there is no explanation of the defaults. Also I should think that somewhere in the admin guide there should be an explanation of the different ways you can lay out the files and why you might choose different ones. It's also highly unclear how you get such a setup established, when there's been no change in the behavior of initdb. I can write the docs. The primary purpose of this patch is to enable the functionality for those who need it. I was sure it would be impractical to get a concensus on changing PostgreSQL's default behavior, but this functionality can be used by OS vendors and consultants alike. As for include not being a variable, no it isn't. It is a new class of GUC parameter. Would you like a better syntax? FWIW: This is exactly the same syntax that was discussed, and no one brought up that it was a problem. You even said you liked the idea of include. ProcessConfigFile will dump core on out-of-memory (test for malloc failure is in the wrong place). I also think some memory leaks have been introduced in ReadConfigFile. I will double check. The test for malloc failure may have drifted over time. There should be no memory leaks, but again, I'll double check. The whole concept of a function GUC variable seems very ill-advised to me; for one thing, what will show include or set include do? Can a user do ALTER USER SET include = foo? I think it would have been better to hard-wire the handling of 'include' in the guc file reader, and not try to make it act like a variable. I wanted to create a generic facility for smarter configuration. Being able to create functions and pass parameters should allow smaller more focused configuration parsing. I'm open to suggestions. Would you prefer stating the function parameters with a special character? '#' is taken, how about '!' ? is in: !include ... -- 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 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
Added to TODO, just so we don't forget later: * Use a phantom command counter for nested subtransactions to reduce tuple overhead --- Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Hmm ... yes, this could be very ugly indeed, but I haven't even looked at the executor code so I can't comment. Are executor nodes copyable? Nope, and even if we had support for that the executor tree per se is just the tip of the iceberg. There's also indexscan status, SRF function internal state, yadda yadda. I think the odds of doing something with all that stuff for 7.5 are exactly zero ... we'd better define a stopgap behavior. Oh, and I've been playing with large objects and I've encountered bugs elsewhere. I'll look at it with the new patch you just posted. Wouldn't surprise me, we've not looked at that yet either. I do feel that we have enough things working that we should commit to nested transactions for 7.5. There will be some things that we have to restrict, such as cursors and perhaps large objects. But it's surely better than no subtransactions at all. 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 -- 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] Updated ALTER TABLE ... SET TABLESPACE patch
I realize this still need WAL work, but we should get this in. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Gavin Sherry wrote: Hi all, Attached is an updated ALTER TABLE ... SET TABLESPACE patch. It uses the block by block copy mechanism proposed by Tom and handles i) ALTER TABLE index and ii) Copying of TOAST tables and the TOAST table's index. It doesn't handle copying of system tables (pg_largeobject) and, in the interests of code reuse, the patch fiddles with the code used by CLUSTER. This isn't great but I wanted to get a patch in before 1 July since I think the feature is very important -- even for the first release. Thanks, Gavin Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 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] [pgsql-hackers-win32] Data directory with trailing [back]slash
OK, I have fixed the problem. While your patch got close, it is best to
fix the problem in trim_trailing_separator() rather than above.
Tom already fixed the Unix case by preventing a path of '/' from being
stripped. This patch prevents c:/ and //network/ from being stripped
too. (Tom already mentioned Win32 would need work.)
---
Andrew Dunstan wrote:
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
---(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
--
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
Index: src/port/path.c
===
RCS file: /cvsroot/pgsql-server/src/port/path.c,v
retrieving revision 1.21
diff -c -c -r1.21 path.c
*** src/port/path.c 10 Jul 2004 22:58:42 - 1.21
--- src/port/path.c 11 Jul 2004 02:50:49 -
***
*** 389,395
trim_trailing_separator(char *path)
{
char *p = path + strlen(path);
!
/* trim off trailing slashes */
if (p path)
for (p--; p path IS_DIR_SEP(*p); p--)
--- 389,414
trim_trailing_separator(char *path)
{
char *p = path + strlen(path);
!
! #ifdef WIN32
! /* Skip over network and drive specifiers for win32 */
! if (strlen(path) = 2)
! {
! if (IS_DIR_SEP(path[0]) IS_DIR_SEP(path[1]))
! {
! path += 2;
! while (*path !IS_DIR_SEP(*path))
! path++;
! }
! else if (isalpha(path[0]) path[1] == ':')
! {
! path++;
! if (IS_DIR_SEP(path[1]))
! path++;
! }
! }
! #endif
!
/* trim off trailing slashes */
if (p path)
for (p--; p path IS_DIR_SEP(*p); p--)
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] pg_dump --clean w/ = 7.2 server
Where are we on this? --- Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: Possibly the most correct solution is to assign the name public to the dummy schema that pg_dump creates internally when talking to a pre-7.3 server. I was considering that they might want to restore the dump into another schema and that would be easier with an unqualified name. I don't really understand why the name needs to be fully qualified in the first place. Because it's entirely too likely that you'll drop the wrong thing if you issue an unqualified DROP. 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 -- 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] OWNER TO mega patch #2
Already been applied by Tom, Bruce. Chris Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Christopher Kings-Lynne wrote: Hi, This is the final patch that adds OWNER TO commands to every object. This includes tablespaces. I have also added RENAME TO on tablespaces. Full docs changes are included (+ 3 new files that must be put in doc/src/sgml/ref). All new regression tests included also. Please review and apply this soon so that I can fix pg_dump to use these new commands before the 30th :) Cheers, Chris [ application/x-gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
