[PATCHES] pg_ctl reference page
It seems the pg_ctl reference page is missing the documentation for register/unregister for windows services. Attached is a patch taht adds this (be sure to verify the markup before any commit, though!) //Magnus pgctlref.patch Description: pgctlref.patch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [BUGS] BUG #1466: #maintenace_work_mem = 16384
The proposed test on Redirect_stderr looks pretty fishy too; for one thing it will almost certainly not be the right thing inside the stderr logger subprocess itself. Could you explain further what the issue is there? Inside the logger subprocess, Redirect_stderr is guaranteed true (since it'll be inherited from the postmaster) and therefore the proposed change ensures that anything the logger might want to complain about goes to the original stderr, ie, into the bit bucket rather than someplace useful. Perhaps something like if ((!Redirect_stderr || am_syslogger) pgwin32_is_service()) would be reasonable. snip lots of others Here is an updated patch, that should take care of this. Tested that it solves the problem reported. There is special code in the send_message_to_server_log function to make sure it's written directly to the file. If the logger is complaining, it's quite possibly because it's unable to write to its file. Now that you mention it, doesn't this code go into infinite recursion if write_syslogger_file_binary() tries to ereport? I haven't looked at this part, it appears a separate (but closely related) issue. Perhaps Andreas can comment on this? //Magnus stderr.patch Description: stderr.patch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Change to -f in examples with input files
Folks, Please find enclosed a patch, per Dennis Björklund, that uses -f for input files rather than . This makes error messages, c. more expressive. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! Index: doc/src/sgml/backup.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.55 diff -c -r2.55 backup.sgml *** doc/src/sgml/backup.sgml22 Jan 2005 22:56:35 - 2.55 --- doc/src/sgml/backup.sgml20 Feb 2005 20:45:07 - *** *** 177,183 /synopsis The resulting dump can be restored with applicationpsql/: synopsis ! psql template1 lt; replaceable class=parameterinfile/replaceable /synopsis (Actually, you can specify any existing database name to start from, but if you are reloading in an empty cluster then literaltemplate1/ --- 177,183 /synopsis The resulting dump can be restored with applicationpsql/: synopsis ! psql template1 -f replaceable class=parameterinfile/replaceable /synopsis (Actually, you can specify any existing database name to start from, but if you are reloading in an empty cluster then literaltemplate1/ *** *** 1210,1216 gmake install initdb -D /usr/local/pgsql/data postmaster -D /usr/local/pgsql/data ! psql template1 lt; backup /programlisting See xref linkend=runtime about ways to start and stop the --- 1210,1216 gmake install initdb -D /usr/local/pgsql/data postmaster -D /usr/local/pgsql/data ! psql template1 -f backup /programlisting See xref linkend=runtime about ways to start and stop the ---(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] Change to -f in examples with input files
David Fetter wrote: Please find enclosed a patch, per Dennis Björklund, that uses -f for input files rather than . This makes error messages, c. more expressive. To be portable, options must be before non-option arguments, so you need to rearrange the command-line arguments in the examples if you want to make that change. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] CSV multiline final fix
Well, in response to the huge number (0) of comments on my POC patch to
fix this, I prepared the attached patch, which improves on my previous
effort a bit (there was one obscure failure case which is now handled).
Basically, all the required logic is in a new function CopyReadLineCSV()
which is almost but not quite like CopyReadLine(). The new function
keeps just enough state to know if a line ending sequence (CR, CRLF, or
LF) is part of a quoted field or not. This gets rid of the need for
special casing embedded line endings on input elsewhere, so that is
removed, as is the warning about them on output that we added back in
december (as we then thought just before release). Lastly, the docs are
also patched.
Also attached is my tiny test file - maybe we need to cover this in
regression tests?
cheers
andrew
diff -c -r ../../pgbf/root/REL8_0_STABLE/pgsql/doc/src/sgml/ref/copy.sgml
./doc/src/sgml/ref/copy.sgml
*** ../../pgbf/root/REL8_0_STABLE/pgsql/doc/src/sgml/ref/copy.sgml Mon Jan
3 19:39:53 2005
--- ./doc/src/sgml/ref/copy.sgmlSun Feb 20 19:18:54 2005
***
*** 496,508
para
CSV mode will both recognize and produce CSV files with quoted
values containing embedded carriage returns and line feeds. Thus
! the files are not strictly one line per table row like text-mode
! files. However, productnamePostgreSQL/productname will reject
! commandCOPY/command input if any fields contain embedded line
! end character sequences that do not match the line ending
! convention used in the CSV file itself. It is generally safer to
! import data containing embedded line end characters using the
! text or binary formats rather than CSV.
/para
/note
--- 496,503
para
CSV mode will both recognize and produce CSV files with quoted
values containing embedded carriage returns and line feeds. Thus
! the files are not strictly one line per table row as are text-mode
! files.
/para
/note
***
*** 513,518
--- 508,515
might encounter some files that cannot be imported using this
mechanism, and commandCOPY/ might produce files that other
programs cannot process.
+ It is generally safer to import data using the text or binary formats,
+if possible, rather than using CSV format.
/para
/note
diff -c -r ../../pgbf/root/REL8_0_STABLE/pgsql/src/backend/commands/copy.c
./src/backend/commands/copy.c
*** ../../pgbf/root/REL8_0_STABLE/pgsql/src/backend/commands/copy.c Fri Dec
31 16:59:41 2004
--- ./src/backend/commands/copy.c Sun Feb 20 13:40:56 2005
***
*** 98,104
static EolType eol_type; /* EOL type of input */
static intclient_encoding;/* remote side's character encoding */
static intserver_encoding;/* local encoding */
- static bool embedded_line_warning;
/* these are just for error messages, see copy_in_error_callback */
static bool copy_binary; /* is it a binary copy? */
--- 98,103
***
*** 140,145
--- 139,145
char *delim, char *null_print, bool csv_mode, char *quote, char *escape,
List *force_notnull_atts);
static bool CopyReadLine(void);
+ static bool CopyReadLineCSV(char * quote, char * escape);
static char *CopyReadAttribute(const char *delim, const char *null_print,
CopyReadResult *result, bool *isnull);
static char *CopyReadAttributeCSV(const char *delim, const char *null_print,
***
*** 1191,1197
attr = tupDesc-attrs;
num_phys_attrs = tupDesc-natts;
attr_count = list_length(attnumlist);
- embedded_line_warning = false;
/*
* Get info about the columns we need to process.
--- 1191,1196
***
*** 1718,1724
ListCell *cur;
/* Actually read the line into memory here */
! done = CopyReadLine();
/*
* EOF at start of line means we're done. If we see
EOF after
--- 1717,1723
ListCell *cur;
/* Actually read the line into memory here */
! done = csv_mode ? CopyReadLineCSV(quote, escape) :
CopyReadLine();
/*
* EOF at start of line means we're done. If we see
EOF after
***
*** 2194,2199
--- 2193,2448
return result;
}
+ /*
+ * Read a line for CSV copy mode. Differences from standard mode:
+ * . CR an NL are not special inside quoted fields - they just get added
+ * to the buffer.
+ * . \ is not magical except as the start of the end of data marker.
+ *
+ */
+
+ static bool
+ CopyReadLineCSV(char * quote, char * escape)
+ {
+ bool
Re: [PATCHES] Patch for disaster recovery
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: Not sure where this leads to, but it's not leading to an undocumented one-line hack in tqual.c, and definitely not *that* one-line hack. Sorry, here is the proper change I just applied: /* This is to be used only for disaster recovery and requires serious analysis. */ #ifndef MAKE_ALL_TUPLES_VISIBLE return false; #else return true; #endif AFAICS this has no value whatsoever. Assuming that someone has a disaster recovery problem on their hands, how likely is it that they will know that that code is there, or be able to turn it on (most users don't compile from source anymore), or be able to use it effectively, given the complete lack of documentation? As is, this is of value only to someone familiar with the code, and such a someone could go in and modify the logic for themselves just as easily as turn on a #define. I think the only real effect of this patch will be to confuse people who are reading the source code. tqual.c is already complicated and fragile enough --- it doesn't need conditionally compiled features that we can't even explain the use of. I need a note somewhere to remember where to tell people to modify the code to recovery something. Do you have a better idea? You want just a comment rather than a define? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] Patch for disaster recovery
Bruno Wolff III wrote: On Sun, Feb 20, 2005 at 09:43:11 -0500, Bruce Momjian pgman@candle.pha.pa.us wrote: We regularly have people on IRC who delete data and then want to recover it. By having the define it makes it easier for us to help them without them having to add actual C code. Does that make sense? You aren't going to get a consistant snapshot if you get back all of the deleted rows. With autovacuum it is going to get harder to do this, because accidentally making large changes in a table is going to trigger a vacuum. Right, but as far as I remember the vacuum isn't going to reuse the rows. Rather, it is just going to mark them for later reuse. It seems like the right way to do this is a recovery using the PITR system and putting effort into making that easier is the way to go. You are assuming someone is running PITR already, which they might not. This define is just so we can help folks recover deleted stuff under our guidance. Also, I think a general GUC mechanism is too dangerous. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] Patch for disaster recovery
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: Not sure where this leads to, but it's not leading to an undocumented one-line hack in tqual.c, and definitely not *that* one-line hack. Sorry, here is the proper change I just applied: /* This is to be used only for disaster recovery and requires serious analysis. */ #ifndef MAKE_ALL_TUPLES_VISIBLE return false; #else return true; #endif AFAICS this has no value whatsoever. Assuming that someone has a disaster recovery problem on their hands, how likely is it that they will know that that code is there, or be able to turn it on (most users don't compile from source anymore), or be able to use it effectively, given the complete lack of documentation? As is, this is of value only to someone familiar with the code, and such a someone could go in and modify the logic for themselves just as easily as turn on a #define. I think the only real effect of this patch will be to confuse people who are reading the source code. tqual.c is already complicated and fragile enough --- it doesn't need conditionally compiled features that we can't even explain the use of. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pg_ctl reference page
On Sun, 2005-02-20 at 19:56 +0100, Magnus Hagander wrote: It seems the pg_ctl reference page is missing the documentation for register/unregister for windows services. Attached is a patch taht adds this (be sure to verify the markup before any commit, though!) Applied to HEAD and REL8_0_STABLE. Thanks for the patch. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Bibliography updates
On Sun, 2005-02-20 at 11:18 -0700, Michael Fuhr wrote: The attached patch updates three books in the Bibliography to their most recent editions. Patch applied to HEAD. Thanks. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] WIP: pl/pgsql cleanup
Tom Lane wrote: Still a few bricks shy of a load I fear [...] My apologies; thanks for the code review. regression=# create or replace function foo() returns int language plpgsql as $$ regression$# begin regression$# return ; regression$# end$$; CREATE FUNCTION regression=# select foo(); server closed the connection unexpectedly If you're going to stick a NULL into the return's expression then you'd better check for same when it's used. Right. Better I think is to only allow a missing RETURN expression for functions declared to return void anyway; that catches the mistake at compile-time. I've implemented this behavior in the revised patch. The error message in this scenario is still a little poor: create function missing_return_expr() returns int as $$ begin return ; end;$$ language plpgsql; ERROR: syntax error at end of input at character 8 QUERY: SELECT CONTEXT: SQL statement in PL/PgSQL function missing_return_expr near line 2 LINE 1: SELECT ^ Is it worth putting in a special-case to look for an unexpected ';' in either the RETURN production or read_sql_construct() ? What I was actually intending to check when I ran into that is why some of the error paths in your FOR-loop rewrite use plpgsql_error_lineno = $1; while others have plpgsql_error_lineno = plpgsql_scanner_lineno(); I suspect the former is more appropriate, at least for errors that reference the FOR variable and not some other part of the statement. Also why the inconsistent use of yyerror() vs ereport()? Sorry, both of these result from sloppiness on my part: I think the code was originally correct, but I tried to refactor some of the more complex parts of the FOR statement production into a separate function, and eventually wasn't able to (because of the `forvariable' union member). When I gave up and reverted the code, I obviously wasn't careful enough. Attached is a revised patch. -Neil plpgsql_cleanup-34.patch.gz Description: application/gzip ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
