Re: [PATCHES] ALTER INDEX
This patch has a fix for a 'thought-o' in the docs. Gavin Index: doc/src/sgml/ref/alter_index.sgml === RCS file: /usr/local/cvsroot/pgsql-server/doc/src/sgml/ref/alter_index.sgml,v retrieving revision 1.1 diff -2 -c -r1.1 alter_index.sgml *** doc/src/sgml/ref/alter_index.sgml 13 Aug 2004 04:32:27 - 1.1 --- doc/src/sgml/ref/alter_index.sgml 13 Aug 2004 06:35:17 - *** *** 0 --- 1,188 + !-- + $PostgreSQL$ + PostgreSQL documentation + -- + + refentry id=SQL-ALTERINDEX + refmeta + refentrytitle id=sql-alterindex-titleALTER INDEX/refentrytitle + refmiscinfoSQL - Language Statements/refmiscinfo + /refmeta + + refnamediv + refnameALTER INDEX/refname + refpurposechange the definition of an index/refpurpose + /refnamediv + + indexterm zone=sql-alterindex + primaryALTER INDEX/primary + /indexterm + + refsynopsisdiv + synopsis + ALTER INDEX replaceable class=PARAMETERname/replaceable + replaceable class=PARAMETERaction/replaceable [, ... ] + ALTER INDEX replaceable class=PARAMETERname/replaceable + RENAME TO replaceable class=PARAMETERnew_name/replaceable + + where replaceable class=PARAMETERaction/replaceable is one of: + + OWNER TO replaceable class=PARAMETERnew_owner/replaceable + SET INDEXSPACE replaceable class=PARAMETERindexspace_name/replaceable + /synopsis + /refsynopsisdiv + + refsect1 + titleDescription/title + + para +commandALTER INDEX/command changes the definition of an existing index. +There are several subforms: + + variablelist + +varlistentry + termliteralOWNER/literal/term + listitem + para + This form changes the owner of the index to the + specified user. + /para + /listitem +/varlistentry + +varlistentry + termliteralSET TABLESPACE/literal/term + listitem + para + This form changes the index's tablespace to the specified tablespace and + moves the data file(s) associated with the index to the new tablespace. + See also + xref linkend=SQL-CREATETABLESPACE endterm=sql-createtablespace-title. + /para + /listitem +/varlistentry + +varlistentry + termliteralRENAME/literal/term + listitem + para + The literalRENAME/literal forms change the name of the index. + There is no effect on the stored data. + /para + /listitem +/varlistentry + + /variablelist + /para + + para +All the actions except literalRENAME/literal can be combined into +a list of multiple alterations to apply in parallel. + /para + + /refsect1 + + refsect1 + titleParameters/title + + variablelist + + varlistentry + termreplaceable class=PARAMETERname/replaceable/term + listitem +para + The name (possibly schema-qualified) of an existing index to + alter. +/para + /listitem + /varlistentry + + + varlistentry + termreplaceable class=PARAMETERnew_name/replaceable/term + listitem +para + New name for the index. +/para + /listitem + /varlistentry + + + varlistentry + termreplaceable class=PARAMETERnew_owner/replaceable/term + listitem +para + The user name of the new owner of the index. +/para + /listitem + /varlistentry + + varlistentry + termreplaceable class=PARAMETERtablespace_name/replaceable/term + listitem +para + The tablespace name to which the index will be moved. +/para + /listitem + /varlistentry + + /variablelist + /refsect1 + + refsect1 + titleNotes/title + +para + This same operations are supported by literalALTER TABLE/. See also + xref linkend=SQL-ALTERTABLE endterm=SQL-ALTERTABLE-TITLE. +/para + +para + Changing any part of a system catalog index is not permitted. +/para + /refsect1 + + refsect1 + titleExamples/title + para +To rename an existing index: + programlisting + ALTER INDEX distributors RENAME TO suppliers; + /programlisting + /para + + para + To move a index to a different tablespace: + programlisting + ALTER INDEX distributors SET TABLESPACE fasttablespace; + /programlisting + /para + + /refsect1 + + refsect1 + titleCompatibility/title + + para + literalALTER INDEX/ is a PostgreSQL extension. + /para + /refsect1 + /refentry + + !-- Keep this comment at the end of the file + Local variables: + mode: sgml + sgml-omittag:nil + sgml-shorttag:t + sgml-minimize-attributes:nil + sgml-always-quote-attributes:t + sgml-indent-step:1 + sgml-indent-data:t + sgml-parent-document:nil + sgml-default-dtd-file:../reference.ced + sgml-exposed-tags:nil + sgml-local-catalogs:/usr/lib/sgml/catalog + sgml-local-ecat-files:nil + End: + -- Index: src/backend/parser/gram.y
Re: [PATCHES] ALTER INDEX
Gavin Sherry wrote:
Index: src/bin/psql/tab-complete.c
===
RCS file: /usr/local/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -2 -c -r1.109 tab-complete.c
*** src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
--- src/bin/psql/tab-complete.c 13 Aug 2004 06:34:55 -
***
*** 633,637
{
static const char *const list_ALTER[] =
! {DATABASE, GROUP, SCHEMA, TABLE, TRIGGER, USER, NULL};
COMPLETE_WITH_LIST(list_ALTER);
--- 633,638
{
static const char *const list_ALTER[] =
! {DATABASE, GROUP, SCHEMA, TABLE, TRIGGER, USER, INDEX,
! NULL};
COMPLETE_WITH_LIST(list_ALTER);
***
*** 647,650
--- 648,661
COMPLETE_WITH_LIST(list_ALTERDATABASE);
}
+ /* ALTER INDEX name */
+ else if (pg_strcasecmp(prev3_wd, ALTER) == 0
+ pg_strcasecmp(prev2_wd, INDEX) == 0)
+ {
+ static const char *const list_ALTERDATABASE[] =
+ {SET TABLESPACE, OWNER TO, RENAME TO, NULL};
+
+ COMPLETE_WITH_LIST(list_ALTERDATABASE);
minor issue/nit(?): reusing list_ALTERDATABASE for the ALTER INDEX part
looks a little strange ...
Stefan(who could really need some feedback on his own tab-complete patch
*g*)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] ALTER INDEX
Oops.
Too much with the ol' cut and paste.
I'm happy to send an updated patch but perhaps the committer, assuming the
patch is accepted, would be kind enough to update for me.
Thanks for reviewing.
Gavin
On Fri, 13 Aug 2004, Stefan Kaltenbrunner wrote:
Gavin Sherry wrote:
Index: src/bin/psql/tab-complete.c
===
RCS file: /usr/local/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -2 -c -r1.109 tab-complete.c
*** src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
--- src/bin/psql/tab-complete.c 13 Aug 2004 06:34:55 -
***
*** 633,637
{
static const char *const list_ALTER[] =
! {DATABASE, GROUP, SCHEMA, TABLE, TRIGGER, USER, NULL};
COMPLETE_WITH_LIST(list_ALTER);
--- 633,638
{
static const char *const list_ALTER[] =
! {DATABASE, GROUP, SCHEMA, TABLE, TRIGGER, USER, INDEX,
!NULL};
COMPLETE_WITH_LIST(list_ALTER);
***
*** 647,650
--- 648,661
COMPLETE_WITH_LIST(list_ALTERDATABASE);
}
+ /* ALTER INDEX name */
+ else if (pg_strcasecmp(prev3_wd, ALTER) == 0
+ pg_strcasecmp(prev2_wd, INDEX) == 0)
+ {
+ static const char *const list_ALTERDATABASE[] =
+ {SET TABLESPACE, OWNER TO, RENAME TO, NULL};
+
+ COMPLETE_WITH_LIST(list_ALTERDATABASE);
minor issue/nit(?): reusing list_ALTERDATABASE for the ALTER INDEX part
looks a little strange ...
Stefan(who could really need some feedback on his own tab-complete patch
*g*)
!DSPAM:411c802d169118747610806!
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to Windows]
[redirecting] I have abstracted this problem, and we definitely have a newline bug that has to be fixed, IMNSHO. Attached are 2 scripts that are identical except that one has DOS-style line endings and one has Unix style line endings. The DOS-style just fails miserably with no warning. It's not related to Windows file-end munging - the problem is observable on Linux - psql doesn't correctly detect the end of copy input with \. if it's followed by CRNL. The attached patch appears to solve the problem. However, while it makes us conform to the first sentence below from the docs, it doesn't comply with the second. Not sure what to do about that. Maybe there's a better solution? COPY FROM can handle lines ending with newlines, carriage returns, or carriage return/newlines. To reduce the risk of error due to un-backslashed newlines or carriage returns that were meant as data, COPY FROM will complain if the line endings in the input are not all alike. cheers andrew Tom Haddon wrote: Here's what I can share, as there's some sensitive stuff in others. This is just a dump from one of the databases. I was able to load it using the \i switch, but it has only populated data from the first table. Also, it kept prompting me to hit a key as the screen was scrolling. This doesn't seem normal to me. And I tried running it as a SQL statement from within PgAdmin3, and got: ERROR: syntax error at or near 1 at character 15030 The first 1 you see is where this error is. COPY backup_data (id, lu, ub, tape, contents, last_writter, times_written) FROM stdin; 1 2004-07-13 09:37:14.78254 thaddon DLT05 Full Backup (including only 2004 filings) 6/9/04\r\n\r\nNow archived 2004-06-09 6 4 2004-07-13 09:40:57.876355 thaddon DLT09 Full Backup 7/12/04 2004-07-12 4 3 2004-07-21 16:28:09.843069 thaddon DLT07 Full Backup 7/21/04\r\n\r\nC:\\Perforce\\*.* /SUBDIR \r\nD:\\backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\insight_backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\equilar_ca\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\software\\*.* /SUBDIR /EXCLUDE \r\nHOTNSOUR\\sql_backup\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\06\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\07\\*.* /SUBDIR \r\nYODA\\qa\\*.* /SUBDIR \r\nMILLENIUM\\ExchangeBackup\\*.* /SUBDIR \r\n 2004-07-21 14 2 2004-07-22 13:27:01.657706 thaddon DLT06 Full Backup 7/22/04\r\n\r\nC:\\Perforce\\*.* /SUBDIR \r\nD:\\backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\insight_backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\equilar_ca\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\software\\*.* /SUBDIR /EXCLUDE \r\nHOTNSOUR\\sql_backup\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\06\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\07\\*.* /SUBDIR \r\nYODA\\qa\\*.* /SUBDIR \r\nMILLENIUM\\ExchangeBackup\\*.* /SUBDIR \r\n 2004-07-22 10 5 2004-07-27 10:49:22.786997 thaddon DLT08 Incremental backup since last full 7/21/04 last updated 7/23/04\r\n\r\nWill include (as of 7/23/04):\r\n\r\nC:\\Perforce\\*.* /SUBDIR \r\nD:\\backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\insight_backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\equilar_ca\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\software\\*.* /SUBDIR /EXCLUDE \r\nHOTNSOUR\\sql_backup\\*.* /SUBDIR \r\nYODA\\qa\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\06\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\07\\*.* /SUBDIR \r\nMILLENIUM\\ExchangeBackup\\*.* /SUBDIR \r\n 2004-07-23 3 6 2004-07-27 10:50:11.802647 thaddon DLT10 Differential backup since 7/21/04\r\n\r\nC:\\Perforce\\*.* /SUBDIR \r\nD:\\backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\insight_backup\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\equilar_ca\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\*.* /SUBDIR \r\nDMTNJ1-SERVER\\dmt_media\\public\\software\\*.* /SUBDIR /EXCLUDE \r\nHOTNSOUR\\sql_backup\\*.* /SUBDIR \r\nYODA\\qa\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\06\\*.* /SUBDIR \r\nYODA\\sec_filings\\filings\\2004\\07\\*.* /SUBDIR \r\nMILLENIUM\\ExchangeBackup\\*.* /SUBDIR \r\n 2004-07-27 1 \. Thanks, Tom -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 8:40 AM To: Tom Haddon Cc: [EMAIL PROTECTED] Subject: Re: [pgsql-hackers-win32] Import from Linux to Windows Tom Haddon wrote: I don't think so. Did a search for it in vi and nothing. It doesn't give me an error, just exits. Last statement is CREATE TABLE. Sorry, not very helpful... I think you'll need to let us look at the dump file to make any progress - otherwise we are just guessing in the dark. thanks andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster CREATE TABLE bar ( c text, d text ); CREATE TABLE
Re: [PATCHES] [BUGS] 8.0.0beta1: -lpthread missing
Martin Münstermann wrote: Hi! Martin M?nstermann wrote: OK, we now have thread compile failure reports on Debian and Slackware. The config/acx_pthread.m4 script basically tests these: acx_pthread_flags=3Dpthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config =09 in that order and exits once it finds the first one that can compile/link this: AC_TRY_LINK([#include pthread.h], [pthread_t th; pthread_join(th, 0); pthread_attr_init(0); pthread_cleanup_push(0, 0); pthread_create(0,0,0,0); pthread_cleanup_pop(0); ], [acx_pthread_ok=3Dyes]) Now, the big question is why -pthread can compile/link this successfully but -pthread isn't enough to build a library that uses threads. I suspect that on Solaris, without -lpthread the pthread-stubs in /usr/lib/libc.so might be called at runtime instead of the functional ones in libpthread.so. Could this easily be checked? I can confirm this suspect for Solaris8/gcc 3.2.3. How to reproduce it: Add a line like printf(### NOTE: check_sigpipe_handler called.\n); to check_sigpipe_handler() in fe-secure.c and rebuild libpq.so. The line is only dumped out (indicating that check_sigpipe_handler() is being called), when the library is linked with -lpthread. Without -lpthread no complains from the compiler or linker, but check_sigpipe_handler() is not called, because the stub of pthread_once() in libc.so does nothing. -- We need -lpthread on solaris, too. So the current CVS code is good? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [BUGS] 8.0.0beta1: -lpthread missing
OK, we now have thread compile failure reports on Debian and Slackware. The config/acx_pthread.m4 script basically tests these: acx_pthread_flags=3Dpthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config =09 in that order and exits once it finds the first one that can compile/link this: AC_TRY_LINK([#include pthread.h], [pthread_t th; pthread_join(th, 0); pthread_attr_init(0); pthread_cleanup_push(0, 0); pthread_create(0,0,0,0); pthread_cleanup_pop(0); ], [acx_pthread_ok=3Dyes]) Now, the big question is why -pthread can compile/link this successfully but -pthread isn't enough to build a library that uses threads. I suspect that on Solaris, without -lpthread the pthread-stubs in /usr/lib/libc.so might be called at runtime instead of the functional ones in libpthread.so. Could this easily be checked? Martin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Translation updates for 7.4/8.0: postgres-ru
Am Donnerstag, 12. August 2004 16:26 schrieb Serguei Mokhov: A new batch of translated messges for the backend. Please apply to both 7.4 and 8.0. Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Translation updates for 8.0: pg_controldata-ru, pg_resetxlog-ru, pgscripts-ru
Am Donnerstag, 12. August 2004 16:23 schrieb Serguei Mokhov: These are fully translated. Some messages were tweaked, with some errors fixed. Please install for 8.0. Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] PL/Perl document patch
Kind people,
The enclose patch clarifies and makes a more useful example for the
Global Values in PL/Perl section of the documents.
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
? plperl.diff
Index: plperl.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plperl.sgml,v
retrieving revision 2.26
diff -u -r2.26 plperl.sgml
--- plperl.sgml 21 Jul 2004 20:44:52 - 2.26
+++ plperl.sgml 13 Aug 2004 21:42:22 -
@@ -317,23 +317,25 @@
sect1 id=plperl-global
titleGlobal Values in PL/Perl/title
para
- You can use the %_SHARED to store data between function calls. WHY
-IS THIS A HASH, AND NOT A HASH REF?
+ You can use the %_SHARED to store data between function calls.
/para
para
For example:
programlisting
-CREATE OR REPLACE FUNCTION set_var(TEXT) RETURNS TEXT AS $$
-$_SHARED{first} = 'Hello, PL/Perl!';
-return 'ok';
+CREATE OR REPLACE FUNCTION set_var(name TEXT, val TEXT) RETURNS TEXT AS $$
+if ($_SHARED{$_[0]} = $_[1]) {
+return 'ok';
+} else {
+return Can't set shared variable $_[0] to $_[1];
+}
$$ LANGUAGE plperl;
-CREATE OR REPLACE FUNCTION get_var() RETURNS text AS $$
-return $_SHARED{first};
+CREATE OR REPLACE FUNCTION get_var(name TEXT) RETURNS text AS $$
+return $_SHARED{$_[0]};
$$ LANGUAGE plperl;
-SELECT set_var('hello plperl');
-SELECT get_var();
+SELECT set_var('sample', $q$Hello, PL/Perl! How's tricks?$q$);
+SELECT get_var('sample');
/programlisting
/para
---(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] Missing Manuals
Here's the manual pages that went missing a few weeks backI asked my secretary to post them through, and she had some success, though that looks like they were weeded out as spam/viruses. My continued absence is the result of a truck's surprise attempt to test my personal capability for crash recovery, which is luckily higher than expected - though my car was less lucky. :) I will write this up as SGML soon, though comments are welcome now. Best Regards, Simon Riggs pitr75_sect1 Description: Binary data ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to Windows]
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached patch appears to solve the problem. However, while it
makes us conform to the first sentence below from the docs, it doesn't
comply with the second. Not sure what to do about that. Maybe there's
a better solution?
Attached patch seems much better, I think.
I think it is still not quite there. Since as you noted the backend
will complain if line endings don't match, if we hit EOF then we have
to cons up a \. line with the correct ending. (BTW, this is not
actually necessary when talking 3.0 protocol, but it is when talking
to an older server.)
I modified the patch a little more and applied the attached. It seems
to work for me but could use more testing.
regards, tom lane
*** src/bin/psql/copy.c.origFri Aug 13 10:47:23 2004
--- src/bin/psql/copy.c Fri Aug 13 18:51:25 2004
***
*** 663,668
--- 663,669
boolcopydone = false;
boolfirstload;
boollinedone;
+ boolsaw_cr = false;
charcopybuf[COPYBUFSIZ];
char *s;
int bufleft;
***
*** 695,724
while (!linedone)
{ /* for each bufferload
in line ... */
s = copybuf;
for (bufleft = COPYBUFSIZ - 1; bufleft 0; bufleft--)
{
c = getc(copystream);
! if (c == '\n' || c == EOF)
{
linedone = true;
break;
}
*s++ = c;
}
*s = '\0';
if (c == EOF s == copybuf firstload)
{
! PQputline(conn, \\.);
copydone = true;
if (pset.cur_cmd_interactive)
puts(\\.);
break;
}
PQputline(conn, copybuf);
if (firstload)
{
! if (!strcmp(copybuf, \\.))
{
copydone = true;
break;
--- 696,744
while (!linedone)
{ /* for each bufferload
in line ... */
+ /* Fetch string until \n, EOF, or buffer full */
s = copybuf;
for (bufleft = COPYBUFSIZ - 1; bufleft 0; bufleft--)
{
c = getc(copystream);
! if (c == EOF)
{
linedone = true;
break;
}
*s++ = c;
+ if (c == '\n')
+ {
+ linedone = true;
+ break;
+ }
+ if (c == '\r')
+ saw_cr = true;
}
*s = '\0';
+ /* EOF with empty line-so-far? */
if (c == EOF s == copybuf firstload)
{
! /*
!* We are guessing a little bit as to the right
line-ending
!* here...
!*/
! if (saw_cr)
! PQputline(conn, \\.\r\n);
! else
! PQputline(conn, \\.\n);
copydone = true;
if (pset.cur_cmd_interactive)
puts(\\.);
break;
}
+ /* No, so pass the data to the backend */
PQputline(conn, copybuf);
+ /* Check for line consisting only of \. */
if (firstload)
{
! if (strcmp(copybuf, \\.\n) == 0 ||
! strcmp(copybuf, \\.\r\n) == 0)
{
copydone = true;
break;
***
*** 726,732
Re: [PATCHES] [HACKERS] Point in Time Recovery
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Now, if you say people will rarely turn archiving on/off, then one parameter seems to make more sense. I really can't envision a situation where people would do that. If you need PITR at all then you need it 24x7. I agree. The second parameter is only there to clarify the intent. 8.0 does introduce two good reasons to turn it on/off, however: - index build speedups - COPY speedups I would opt to make enabling/disabling archive_command require a postmaster restart. That way there would be no capability to take advantage of the incentive to turn it on/off. For TODO: It would be my intention (in 8.1) to make those available via switches e.g. NOT LOGGED options on CREATE INDEX and COPY, to allow users to take advantage of the no logging optimization without turning off PITR system wide. (Just as this is possible in Oracle and Teradata). I would also aim to make the first Insert Select into an empty table not logged (optionally). This is an important optimization for Oracle, teradata and DB2 (which uses NOT LOGGED INITIALLY). Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The attached patch appears to solve the problem. However, while it makes us conform to the first sentence below from the docs, it doesn't comply with the second. Not sure what to do about that. Maybe there's a better solution? Attached patch seems much better, I think. I think it is still not quite there. Since as you noted the backend will complain if line endings don't match, if we hit EOF then we have to cons up a \. line with the correct ending. (BTW, this is not actually necessary when talking 3.0 protocol, but it is when talking to an older server.) I modified the patch a little more and applied the attached. It seems to work for me but could use more testing. WorksForMe, and looks good. You're right, I had forgotten the EOF case. Should it be backported for the upcoming stable release(s)? Bruce and I were discussing this earlier. Pro: it's an ugly bug and hard to diagnose - things just seem to die for no apparent reason. Con: there's a workaround - just make sure to run dos2unix on your file if necessary. cheers andrew ---(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] Point in Time Recovery
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: I would opt to make enabling/disabling archive_command require a postmaster restart. That way there would be no capability to take advantage of the incentive to turn it on/off. We're generally not in the habit of making GUC parameters more rigid than the implementation absolutely requires. It would be my intention (in 8.1) to make those available via switches e.g. NOT LOGGED options on CREATE INDEX and COPY, to allow users to take advantage of the no logging optimization without turning off PITR system wide. (Just as this is possible in Oracle and Teradata). Isn't this in direct conflict with your opinion above? And I cannot say that I think this one is a good idea. We do not have support for selective catalog xlogging; if you do something like this then you *will* have a broken database after recovery, because it will contain those indexes but with invalid contents. I would also aim to make the first Insert Select into an empty table not logged (optionally). This is an important optimization for Oracle, teradata and DB2 (which uses NOT LOGGED INITIALLY). This is even worse: not only do you have a broken database, but you have no way to recover. (At least with an unlogged index you could fix it by REINDEX.) If you don't care about longevity of the table, then make it a temp table. The fact that Oracle does it does not automatically make it a good idea. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to
Andrew Dunstan [EMAIL PROTECTED] writes: Should it be backported for the upcoming stable release(s)? Bruce and I were discussing this earlier. Probably a good idea, since we do support psql on Windows even in the older releases. My personal opinion is to back-port only as far as 7.4, but if you feel like doing and testing it for 7.3 then I'll apply the patch. I need it tomorrow (Sat) though, as I'd like to wrap these releases Sunday. 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] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to
Tom Lane said: Andrew Dunstan [EMAIL PROTECTED] writes: Should it be backported for the upcoming stable release(s)? Bruce and I were discussing this earlier. Probably a good idea, since we do support psql on Windows even in the older releases. My personal opinion is to back-port only as far as 7.4, but if you feel like doing and testing it for 7.3 then I'll apply the patch. I need it tomorrow (Sat) though, as I'd like to wrap these releases Sunday. No, I think 7.4 should do. 7.3 users will still have the dos2unix workaround available. Are you going to do the 7.4 patch, or do you need me to? I normally only keep a HEAD tree checked out. A quick look at the cvsweb diffs suggests the patch should apply cleanly but with different line offsets. cheers andrew ---(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] [Fwd: Re: [pgsql-hackers-win32] Import from Linux to
Andrew Dunstan [EMAIL PROTECTED] writes: No, I think 7.4 should do. 7.3 users will still have the dos2unix workaround available. Are you going to do the 7.4 patch, or do you need me to? I normally only keep a HEAD tree checked out. A quick look at the cvsweb diffs suggests the patch should apply cleanly but with different line offsets. If you're sure the code in that routine hasn't changed since 7.4, then I can just apply the patch to that branch. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
