Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
On Wed, Dec 28, 2005 at 12:47:31AM +0200, Hannu Krosing wrote: I've thought of one other possibility, which is kind of at the extreme end of system implementation. Given the suggestion about not losing a whole table on unclean shutdown, how about using a single table, split. snip How would it work for indexes ? Hmm, it wouldn't, so scrap that. If any anyone ever gets indexes that work across multiple tables of an inheritence hierarchy, you could probably make it work for this. Otherwise... OTOH, triggers will trip you up also. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpIkidj3ZXQh.pgp Description: PGP signature
Re: [HACKERS] Possible savepoint bug
Tom Lane wrote: I wrote: Michael Paesold [EMAIL PROTECTED] writes: I am seeing a similar unique index bug here... This is PostgreSQL 8.1.1 on RHEL 3, Intel Xeon (i686). It looks like the problem is that index entries are being inserted out of order. After further investigation, it seems that the original sort order of the index was not C-locale, but something else --- I can reproduce the current index ordering except for a small number of new-ish tuples if I sort the data in en_US. We go out of our way to prevent the backend's locale from changing after initdb. Did you do something to override that? No, I am sure I did not do anything to change the locale itentionally. The cluster was initialized with initdb --no-locale... (and this is what it still is). Another theory is that this is a manifestation of the known problem with plperl sometimes changing the backend's locale setting. Is it possible that the index was created in a session that had previously run some plperl functions? This is a theory. The whole database was loaded using pg_restore, I still have the original dump so I will have a look at the dump now. The database actually contains some plperl functions. Restoring to a file I find some perhaps interesting facts perhaps relevant: *) SET check_function_bodies = false; So at least the syntax checking function should not be called. *) Old plperl call handler: The dump from 7.4.x created the public.plperl_call_handler() function, which I only dropped after the full dump was loaded. CREATE FUNCTION plperl_call_handler() RETURNS language_handler AS '$libdir/plperl', 'plperl_call_handler' LANGUAGE c; ALTER FUNCTION public.plperl_call_handler() OWNER TO postgres; CREATE TRUSTED PROCEDURAL LANGUAGE plperl HANDLER plperl_call_handler; *) There is a single plperl function that is only used in a view. (Btw. this view is totally unrelated to the given table and should never be used in the same backend session.) From the points above, I don't think the plperl function should have been called during load. Perhaps I am mistaken and plperl did really override the locale setting. Looking at the environment set for the postgres unix user, which is used to run Postgres, I see that LANG is set to the default value of en_US.UTF-8. So it seems possible that setting LANG to C here, could fix the problem. This still doesn't explain why the initial sort order is wrong here. The creation order in the dump is: CREATE TABLE... (without indexes) COPY ... ALTER TABLE ONLY properties ADD CONSTRAINT pk_properties... Please tell me if you need further information. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] sending mail from Postgres
Code from perl cookbook, wrapped in plperlu wrapper
not very portable, Net::SMTP would probably be better, and result in more
portable perl code.
Didn't test this - but it is copied straight from perl cookbook via
google: http://www.unix.org.ua/orelly/perl/cookbook/ch18_04.htm
CREATE OR REPLACE FUNCTION send_email(from_address text, to_address text,
subject text, body text) RETURNS void AS $$
use Mail::Mailer;
my ($from_address, $to_address, $subject, $body) = @_;
my $mailer = Mail::Mailer-new(sendmail);
$mailer-open({ From= $from_address,
To = $to_address,
Subject = $subject,
})
or die Can't open: $!;
print $mailer $body;
$mailer-close();
$$ LANGUAGE plperlu VOLATILE STRICT;
On Wed, 28 Dec 2005, Aftab Alam wrote:
Hi there,
How can i send mail form postgresql.
any suggestion.
thanx regards
aftab
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Don't steal; thou'lt never thus compete successfully in business. Cheat.
-- Ambrose Bierce
---(end of broadcast)---
TIP 1: 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
plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint bug)
Michael Paesold [EMAIL PROTECTED] writes: This is a theory. The whole database was loaded using pg_restore, I still have the original dump so I will have a look at the dump now. The database actually contains some plperl functions. OK, I think I have reproduced the problem. initdb in C locale, then start postmaster with LANG=en_US.UTF-8 in its environment. Then: z1=# create language plperl; CREATE LANGUAGE z1=# select 'enum.server_task_log.status.RUNNING'::varchar 'enum.server_task_log.status.keys'::varchar; ?column? -- t -- correct result for C locale (1 row) z1=# \c z1 You are now connected to database z1. z1=# SET check_function_bodies = false; SET z1=# create or replace function perlf() returns text as $$ z1$# return 'foo'; z1$# $$ language plperl; CREATE FUNCTION z1=# select 'enum.server_task_log.status.RUNNING'::varchar 'enum.server_task_log.status.keys'::varchar; ?column? -- f -- WRONG result for C locale (1 row) So the mere act of defining a plperl function, even with check_function_bodies = false, is sufficient to send control through that bit of libperl code that does setlocale(LC_ALL, ). Ugh. This is much worse than I thought. The reason I had not seen it before is that lc_collate_is_c caches its result, which means that if you do any text/varchar comparisons before first invoking libperl, you won't see any misbehavior (at least not when you started in C locale). The reconnect in the middle of the above test sequence is essential to reproduce the failure. We were talking last week about forcing the LANG/LC_ environment variables to match our desired settings within the postmaster. I think this example raises the priority of doing that by several notches :-( In the meantime, Michael, I'd suggest modifying your postmaster start script to force LANG=C, and then reindexing all indexes you have on text/varchar/char columns. That should get you out of the immediate problem and prevent it from recurring before we have a fix. (The system catalogs should be OK because they use name which is not locale-sensitive.) regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint bug)
I wrote: So the mere act of defining a plperl function, even with check_function_bodies = false, is sufficient to send control through that bit of libperl code that does setlocale(LC_ALL, ). Ugh. This is much worse than I thought. It seems one ingredient in this is that the plperl function validator fails to honor check_function_bodies, and hence is calling libperl anyway. I wonder if that explains the sudden rise in incidents in 8.1? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint bug)
Tom Lane said: I wrote: So the mere act of defining a plperl function, even with check_function_bodies = false, is sufficient to send control through that bit of libperl code that does setlocale(LC_ALL, ). Ugh. This is much worse than I thought. It seems one ingredient in this is that the plperl function validator fails to honor check_function_bodies, and hence is calling libperl anyway. I wonder if that explains the sudden rise in incidents in 8.1? That's probably because I was unaware of its existence. It should certainly be fixed, but surely at best this would only delay seeing the ugly locale effect - as soon as you call a perl function you'll be back in the same boat regardless. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint bug)
Andrew Dunstan [EMAIL PROTECTED] writes: It should certainly be fixed, but surely at best this would only delay seeing the ugly locale effect - as soon as you call a perl function you'll be back in the same boat regardless. Right, I was not suggesting that fixing the validator would avoid the bug. It just surprised me that libperl was getting called in the restore-a-dump scenario. BTW, I was just about to go change the validator, but if you want to do it go ahead... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint bug)
Tom Lane said: Andrew Dunstan [EMAIL PROTECTED] writes: It should certainly be fixed, but surely at best this would only delay seeing the ugly locale effect - as soon as you call a perl function you'll be back in the same boat regardless. Right, I was not suggesting that fixing the validator would avoid the bug. It just surprised me that libperl was getting called in the restore-a-dump scenario. BTW, I was just about to go change the validator, but if you want to do it go ahead... no, please do. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fixing row comparison semantics
On Mon, Dec 26, 2005 at 15:12:48 -0500, Gregory Maxwell [EMAIL PROTECTED] wrote: On 12/26/05, Pavel Stehule [EMAIL PROTECTED] wrote: (1,1) * (1,2) = true (1,2) * (2,1) is NULL (2,3) * (1,2) = false it's usefull for multicriterial optimalisation This is indeed a sane and useful function which should be adopted by the SQL standard.. in postgresql this would easily enough be implemented as a user function so I'm not sure we need special support for it. The idea is that in a multidimension comparison you can only sometimes say when one tuple is strictly less than (or greater than) another because differing dimensions are incomparable. So, like his example, we can not say if (1,2) is lesser or greater than (2,1) because saying so would require some priority of the dimensions which may not be known or may not exist, it is only clear that they are not equal.. That's normally called a partial order. From CS classes, I don't remember ever seeing and combined that way. Normally you just looked at whether or not was true or whether or not was true. Is it common in practice for people to want the answer to both of these at once? Also if you are really dealing with = and = (as your example above seems to imply), then there are 4 possible states (the new one being a = b) and you can't represent that with just 3 possible results. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Mention table in violates foreign key constraint message that
Does the regression test need to be updated as well for this? I am seeing a failure on my buildfarm machines. -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Wednesday, December 28, 2005 11:47 AM To: pgsql-committers@postgresql.org Subject: [COMMITTERS] pgsql: Mention table in violates foreign key constraint message that Log Message: --- Mention table in violates foreign key constraint message that was lacking it. Perhaps it was suppressed because of line length considerations, but table should appear. Modified Files: -- pgsql/src/backend/utils/adt: ri_triggers.c (r1.83 - r1.84) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/ utils/adt/ri_triggers.c.diff?r1=1.83r2=1.84) ---(end of broadcast)--- TIP 1: 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] FATAL: failed to initialize TimeZone to UNKNOWN
Hi, While trying to initdb using cvs tip, it dumps below error output: ... creating configuration files ... ok creating template1 database in pgd/base/1 ... FATAL: failed to initialize TimeZone to UNKNOWN child process exited with exit code 1 ... I edited some files but don't think they're related with this problem. Edited files are like.c, oracle_compat.c and pg_mb2wchar function in mbutils.c. (Actually, IIRC, pg_mb2wchar function is used nowhere in the code.) Attached a gdb output (tz_error.gdb) for initdb. Also, here's an strace -s 256 output for initdb: http://www.students.itu.edu.tr/~yazicivo/tz_error.strace (I'm not so experienced in debugging; if you'd need any further information just let me know.) I'd be so appreciated to hear any kind of help/idea/suggestion. Regards. $ gdb usr/bin/initdb ... (gdb) set args -D pgd (gdb) b bootstrap_template1 Breakpoint 1 at 0x804aef0: file initdb.c, line 1341. (gdb) run Starting program: /home/knt/farm/fake-root/usr/bin/initdb -D pgd The files belonging to this database system will be owned by user knt. This user must also own the server process. The database cluster will be initialized with locale tr_TR. The default database encoding has accordingly been set to LATIN5. creating directory pgd ... ok creating directory pgd/global ... ok creating directory pgd/pg_xlog ... ok creating directory pgd/pg_xlog/archive_status ... ok creating directory pgd/pg_clog ... ok creating directory pgd/pg_subtrans ... ok creating directory pgd/pg_twophase ... ok creating directory pgd/pg_multixact/members ... ok creating directory pgd/pg_multixact/offsets ... ok creating directory pgd/base ... ok creating directory pgd/base/1 ... ok creating directory pgd/pg_tblspc ... ok selecting default max_connections ... 10 selecting default shared_buffers/max_fsm_pages ... 50/2 creating configuration files ... ok Breakpoint 1, bootstrap_template1 (short_version=0x8056868 8.2) at initdb.c:1341 1341char *talkargs = ; (gdb) n 1345printf(_(creating template1 database in %s/base/1 ... ), pg_data); (gdb) 1346fflush(stdout); (gdb) creating template1 database in pgd/base/1 ... 1348 if (debug) (gdb) 1351bki_lines = readfile(bki_file); (gdb) 1355snprintf(headerline, sizeof(headerline), # PostgreSQL %s\n, (gdb) 1358if (strcmp(headerline, *bki_lines) != 0) (gdb) 1368bki_lines = replace_token(bki_lines, POSTGRES, effective_user); (gdb) 1370bki_lines = replace_token(bki_lines, ENCODING, encodingid); (gdb) 1378snprintf(cmd, sizeof(cmd), LC_COLLATE=%s, lc_collate); (gdb) 1379putenv(xstrdup(cmd)); (gdb) 1381snprintf(cmd, sizeof(cmd), LC_CTYPE=%s, lc_ctype); (gdb) 1382putenv(xstrdup(cmd)); (gdb) 1384unsetenv(LC_ALL); (gdb) 1387unsetenv(PGCLIENTENCODING); (gdb) 1389snprintf(cmd, sizeof(cmd), (gdb) 1393PG_CMD_OPEN; (gdb) 1395for (line = bki_lines; *line != NULL; line++) (gdb) FATAL: failed to initialize TimeZone to UNKNOWN 1397PG_CMD_PUTS(*line); (gdb) Program received signal SIGPIPE, Broken pipe. 0xb7d3e95e in write () from /lib/tls/libc.so.6 (gdb) ---(end of broadcast)--- TIP 1: 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
[HACKERS] Removing SORTFUNC_LT/REVLT
Greetings everybody, As part of the changes I would like relating to collations, the two sort options in inlineApplySortFunction() using only a less-than operator may become unsupportable. This has been indirectly discussed before [1] and no-one seemed to have an issue with it then. Internally nothing in PostgreSQL needs it, but if we want to keep supporting that ORDER BY ... USING clause it would have to stay. The issue is whether anything you want to ORDER BY needs to be described by an B-tree operator class, and hence have a real sort function. 1. Do people have any problems with this? 2. Would a patch for this be accepted seperate from the whole collation stuff? Have a nice day, [1] http://archives.postgresql.org/pgsql-hackers/2005-09/msg00784.php -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpA0lcLWPQHn.pgp Description: PGP signature
Re: [HACKERS] localization problem (and solution)
Andrew Dunstan [EMAIL PROTECTED] writes: We need to test any solution carefully on Windows, which deals with locales very differently from *nix, and where we still have some known locale issues (see recent discussion). I've committed a proposed change in HEAD --- would you check out the Windows behavior at your convenience? If it seems to work, I'll back-patch, but let's test first. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgadmin-hackers] pgAdmin translation to italian language
Dear Michele. Italian is no longer maintained and is long. Please contribute. We are welcome always.:-) http://www.pgadmin.org/translation.php Regards, Hiroshi Saito From: Michele Pigozzo I'd like to contribute to localize the application to italian language. Do you want my help?? I wait your reply. Michele ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Removing SORTFUNC_LT/REVLT
Martijn van Oosterhout kleptog@svana.org writes: The issue is whether anything you want to ORDER BY needs to be described by an B-tree operator class, and hence have a real sort function. 1. Do people have any problems with this? 2. Would a patch for this be accepted seperate from the whole collation stuff? I think it's reasonable to remove that feature, *after* we provide a workable substitute. So, no to both questions ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] localization problem (and solution)
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: We need to test any solution carefully on Windows, which deals with locales very differently from *nix, and where we still have some known locale issues (see recent discussion). I've committed a proposed change in HEAD --- would you check out the Windows behavior at your convenience? If it seems to work, I'll back-patch, but let's test first. Will try. Not quite sure how, though. Any suggestions? cheers andrew ---(end of broadcast)--- TIP 1: 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: [HACKERS] localization problem (and solution)
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've committed a proposed change in HEAD --- would you check out the Windows behavior at your convenience? If it seems to work, I'll back-patch, but let's test first. Will try. Not quite sure how, though. Any suggestions? Well, one thing to try is whether you can reproduce the plperl-induced breakage I posted this morning on Windows; and if so whether the patch fixes it. Also, what were those known locale issues you were referring to? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] localization problem (and solution)
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I've committed a proposed change in HEAD --- would you check out the Windows behavior at your convenience? If it seems to work, I'll back-patch, but let's test first. Will try. Not quite sure how, though. Any suggestions? Well, one thing to try is whether you can reproduce the plperl-induced breakage I posted this morning on Windows; and if so whether the patch fixes it. We have a build failure to fix first: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2005-12-29%2000:44:52 Also, what were those known locale issues you were referring to? The issue is that if I set my machine's locale to Turkish or French, say, it doesn't matter what locale I set during initdb or in postgresql.conf, the server's log messages always seem to come out in the machine's locale. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
Having read through this thread, I would like to propose a syntax/behavior. I think we all now agree that the logging is more part of the table than the command itself. Right now we have a COPY LOCK patch, but people are going to want to control logging for INSERT INTO ... SELECT, and UPDATE, and all sorts of other things, so I think we are best adding an ALTER TABLE capability. I am thinking of this syntax: ALTER TABLE name RELIABILITY option where option is: DROP [ TABLE ON CRASH ] DELETE [ ROWS ON CRASH ] EXCLUSIVE SHARE Let me explain each option. DROP would drop the table on a restart after a non-clean shutdown. It would do _no_ logging on the table and allow concurrent access, plus index access. DELETE is the same as DROP, but it just truncates the table (perhaps TRUNCATE is a better word). EXCLUSIVE would allow only a single session to modify the table, and would do all changes by appending to the table, similar to COPY LOCK. EXCLUSIVE would also not allow indexes because those can not be isolated like appending to the heap. EXCLUSIVE would write all dirty shared buffers for the table and fsync them before committing. SHARE is the functionality we have now, with full logging. Does this get us any closer to a TODO item? It isn't great, but I think it is pretty clear, and I assume pg_dump would use ALTER to load each table. The advanage is that the COPY statements themselves are unchanged so they would work in loading into older versions of PostgreSQL. --- Martijn van Oosterhout wrote: -- Start of PGP signed section. On Mon, Dec 26, 2005 at 12:03:27PM +, Simon Riggs wrote: I would not be against such a table-level switch, but the exact behaviour would need to be specified more closely before this became a TODO item, IMHO. Well, I think at a per table level is the only sensible level. If a table isn't logged, neither are the indexes. After an unclean shutdown the data could be anywhere between OK and rubbish, with no way of finding out which way. If someone has a 100 GB table, they would not appreciate the table being truncated if a transaction to load 1 GB of data aborts, forcing recovery of the 100 GB table. Ah, but wouldn't such a large table be partitioned in such a way that you could have the most recent partition having the loaded data. Personally, I think these shared temp tables have more applications than meet the eye. I've had systems with cache tables which could be wiped on boot. Though I think my preference would be to TRUNCATE rather than DROP on unclean shutdown. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. -- End of PGP section, PGP failed! -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] localization problem (and solution)
Andrew Dunstan [EMAIL PROTECTED] writes: We have a build failure to fix first: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2005-12-29%2000:44:52 Weird. It seems to be choking on linking to check_function_bodies, but plpgsql does that exactly the same way, and there's no problem there. I wonder whether all those warnings in the perl header files mean anything ... The issue is that if I set my machine's locale to Turkish or French, say, it doesn't matter what locale I set during initdb or in postgresql.conf, the server's log messages always seem to come out in the machine's locale. Is this possibly related to the fact that we don't even try to do setlocale() for LC_MESSAGES? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] localization problem (and solution)
Tom Lane said: Andrew Dunstan [EMAIL PROTECTED] writes: We have a build failure to fix first: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2005-12-29%2000:44:52 Weird. It seems to be choking on linking to check_function_bodies, but plpgsql does that exactly the same way, and there's no problem there. I wonder whether all those warnings in the perl header files mean anything ... We always get those - see http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=lorisdt=2005-12-23%2019%3A56%3A12stg=makefor example. One day when I get time I want to clean them up. The issue is that if I set my machine's locale to Turkish or French, say, it doesn't matter what locale I set during initdb or in postgresql.conf, the server's log messages always seem to come out in the machine's locale. Is this possibly related to the fact that we don't even try to do setlocale() for LC_MESSAGES We can't on Windows - it doesn't define LC_MESSAGES. But libintl does some stuff, I believe. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
now agree that the logging is more part of the table than the command itself. Right now we have a COPY LOCK patch, but people are going to want to control logging for INSERT INTO ... SELECT, and UPDATE, and all sorts of other things, so I think we are best adding an ALTER TABLE capability. I am thinking of this syntax: ALTER TABLE name RELIABILITY option where option is: DROP [ TABLE ON CRASH ] DELETE [ ROWS ON CRASH ] EXCLUSIVE SHARE I would say ON FAILURE (Crash just seems way to scary :)) Joshua D. Drake ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
Joshua D. Drake wrote: now agree that the logging is more part of the table than the command itself. Right now we have a COPY LOCK patch, but people are going to want to control logging for INSERT INTO ... SELECT, and UPDATE, and all sorts of other things, so I think we are best adding an ALTER TABLE capability. I am thinking of this syntax: ALTER TABLE name RELIABILITY option where option is: DROP [ TABLE ON CRASH ] DELETE [ ROWS ON CRASH ] EXCLUSIVE SHARE I would say ON FAILURE (Crash just seems way to scary :)) Agreed, maybe ON RECOVERY. -- 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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] sending mail from Postgres
On Wed, Dec 28, 2005 at 08:52:41AM +0530, Aftab Alam wrote: Hi there, How can i send mail form postgresql. Generally, it is a better idea either to poll your PostgreSQL database and send mail based on that, or use LISTEN/NOTIFY, rather than directly sending mail from your database. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Minor doc tweak: NOT NULL is
Christopher Kings-Lynne wrote: I hope you mean 'redundant with PRIMARY KEY in example'... Why? SERIAL implies NOT NULL (although PRIMARY KEY does as well, of course). -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Minor doc tweak: NOT NULL is
Why? SERIAL implies NOT NULL (although PRIMARY KEY does as well, of course). Ah yes you're right. I mixed up with the fact that SERIAL no longer implies UNIQUE... Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] WAL logs multiplexing?
On Wed, 2005-12-28 at 11:05 -0500, Tom Lane wrote: Dmitry Panov [EMAIL PROTECTED] writes: Yes, but if the server has crashed earlier the script won't be called and if the filesystem can't be recovered the changes will be lost. My point is the server should write into both (or more) files at the same time. As for that, I agree with the other person: a RAID array does that just fine, and with much higher performance than we could muster. BTW, I found something related in the TODO: http://momjian.postgresql.org/cgi-bin/pgtodo?pitr I think both approaches have the right to exist, but I prefer my because it looks more straightforward, it insures up-to-date recovery (no delays) and it reduces the traffic (as the partial logs have to be transferred in full by the proposed archive_current_wal_command). The only drawback is performance. Best regards, -- Dmitry O Panov | mailto:[EMAIL PROTECTED] Tula State University | Fidonet: Dmitry Panov, 2:5022/5.13 Dept. of CS NIT | http://www.tsu.tula.ru/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
