Re: [HACKERS] SQL-Invoked Procedures for 8.1
On Mon, Oct 04, 2004 at 03:10:24PM -0400, Alvaro Herrera wrote: So you aren't aware of the dollar-quoting feature? You may want to take a look at that ... Can someone point me to a url? I haven't been able to find anything about this... -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SQL-Invoked Procedures for 8.1
On Wed, Oct 06, 2004 at 01:34:00AM -0500, Jim C. Nasby wrote: On Mon, Oct 04, 2004 at 03:10:24PM -0400, Alvaro Herrera wrote: So you aren't aware of the dollar-quoting feature? You may want to take a look at that ... Can someone point me to a url? I haven't been able to find anything about this... http://developer.postgresql.org/docs/postgres/sql-syntax.html#SQL-SYNTAX-CONSTANTS Keep in mind that this is 8.0 only ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Al principio era UNIX, y UNIX habló y dijo: Hello world\n. No dijo Hello New Jersey\n, ni Hello USA\n. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] win32 tablespace handing
hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] More pgindent bizarreness
On Fri, 2004-10-01 at 06:48, Bruce Momjian wrote: Yes, that is what I am thinking. I have worked around other bugs in the C code before by doing things with the shell script though this problem seems hard to clean up with a shell script. I found GNU indent to be even harder to fix. Have you taken a look at astyle? I haven't used it, but it might be worth considering. http://astyle.sourceforge.net/ -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Make configure use krb5-config
I have checked current CVS and the kerberos configuration stuff has changed since 7.4.X, but it doesn't use the krb5_prefix/bin/krb5-config idea you have. Would you download a recent snapshot and resubmit a patch that works against our current configure code? Thanks. --- Daniel Ahlin wrote: Hi This is a patch against 7.4.5 to make configure use the krb5-config in the heimdal Kerberos 5 implementation to get compile flags (instead of using preset values). Content-Description: Patch to make configure use krb5-config [ Attachment, skipping... ] I hope it can be of use. Regards Daniel Ahlin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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 4: Don't 'kill -9' the postmaster
Re: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) -- Reini Urban ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Reini Urban said: Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) No, of course not. That would only check the machine where you compile, not where you install/run. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] SQL-Invoked Procedures for 8.1
Alvaro Herrera [EMAIL PROTECTED] writes: On Wed, Oct 06, 2004 at 01:34:00AM -0500, Jim C. Nasby wrote: On Mon, Oct 04, 2004 at 03:10:24PM -0400, Alvaro Herrera wrote: So you aren't aware of the dollar-quoting feature? You may want to take a look at that ... Can someone point me to a url? I haven't been able to find anything about this... http://developer.postgresql.org/docs/postgres/sql-syntax.html#SQL-SYNTAX-CONSTANTS Also, many of the function examples in Section V, http://developer.postgresql.org/docs/postgres/server-programming.html have been updated to use dollar-quote style. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Pl/perl broken on Windows
I'm getting the following build failure in pl/perl on Win32. I'm guessing this has something to do with the recent rehashing of make/include files, but I don't know what exactly. This is on a fresh checkout. Regards, Dave. make[3]: Entering directory `/cvs/pgsql/src/pl/plperl' gcc -O2 -fno-strict-aliasing -I. -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../../src/include/port/win32 -IC:/Perl/lib/CORE -c -o plperl.o plperl.c In file included from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32.h:219: conflicting types for `uid_t' ../../../src/include/pg_config_os.h:198: previous declaration of `uid_t' C:/Perl/lib/CORE/win32.h:220: conflicting types for `gid_t' ../../../src/include/pg_config_os.h:199: previous declaration of `gid_t' In file included from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32.h:226:1: warning: isnan redefined In file included from ../../../src/include/utils/timestamp.h:16, from ../../../src/include/utils/nabstime.h:20, from ../../../src/include/access/xact.h:20, from ../../../src/include/utils/tqual.h:19, from ../../../src/include/access/relscan.h:18, from ../../../src/include/access/heapam.h:18, from plperl.c:47: c:/mingw/include/math.h:324:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:239:1: warning: rename redefined In file included from ../../../src/include/c.h:784, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/port.h:177:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:246:1: warning: open redefined In file included from ../../../src/include/c.h:784, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/port.h:190:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:254:1: warning: mkdir redefined In file included from ../../../src/include/c.h:85, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/pg_config_os.h:13:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:304:1: warning: kill redefined In file included from ../../../src/include/c.h:784, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/port.h:148:1: warning: this is the location of the previous definition make[3]: *** [plperl.o] Error 1 make[3]: Leaving directory `/cvs/pgsql/src/pl/plperl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cvs/pgsql/src/pl' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cvs/pgsql/src' make: *** [all] Error 2 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Andrew Dunstan wrote: Reini Urban said: Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) No, of course not. That would only check the machine where you compile, not where you install/run. Tablespaces are not supported on NT4. They throw an error. -- 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: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban said: Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) No, of course not. That would only check the machine where you compile, not where you install/run. Tablespaces are not supported on NT4. They throw an error. So just describe in the docs that only NTFS5 (i.e. W2K and up) supports th new tablespace feature. I could find my cygwin niche then to support it by our native and slow symlink implementation :) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] win32 tablespace handing
Reini Urban wrote: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban said: Zeugswetter Andreas SB SD schrieb: hardlinks and junctions don't work across physical disks, only symlinks. Where did you read this? I just looked and can see no such restriction. There is no such restriction for junctions, I just tried it to be safe. Yes, sorry. I had old NTFS4 information. NTFS5 supports volume mount points now too. But shouldn't we check in configure :) for this filesystem then? (Ha! ntfs5.m4 for MSVC folks) No, of course not. That would only check the machine where you compile, not where you install/run. Tablespaces are not supported on NT4. They throw an error. So just describe in the docs that only NTFS5 (i.e. W2K and up) supports th new tablespace feature. I could find my cygwin niche then to support it by our native and slow symlink implementation :) I think we are fine. We have already discussed not even supporting NT4 because tablespaces don't work, but now it will throw a not supported error, which seems fine. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Pl/perl broken on Windows
OK, I have adjusted the code to use #define for the plperl compile. This should prevent the conflict you are getting when perl defines uid_t too. --- Dave Page wrote: I'm getting the following build failure in pl/perl on Win32. I'm guessing this has something to do with the recent rehashing of make/include files, but I don't know what exactly. This is on a fresh checkout. Regards, Dave. make[3]: Entering directory `/cvs/pgsql/src/pl/plperl' gcc -O2 -fno-strict-aliasing -I. -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../../src/include/port/win32 -IC:/Perl/lib/CORE -c -o plperl.o plperl.c In file included from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32.h:219: conflicting types for `uid_t' ../../../src/include/pg_config_os.h:198: previous declaration of `uid_t' C:/Perl/lib/CORE/win32.h:220: conflicting types for `gid_t' ../../../src/include/pg_config_os.h:199: previous declaration of `gid_t' In file included from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32.h:226:1: warning: isnan redefined In file included from ../../../src/include/utils/timestamp.h:16, from ../../../src/include/utils/nabstime.h:20, from ../../../src/include/access/xact.h:20, from ../../../src/include/utils/tqual.h:19, from ../../../src/include/access/relscan.h:18, from ../../../src/include/access/heapam.h:18, from plperl.c:47: c:/mingw/include/math.h:324:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:239:1: warning: rename redefined In file included from ../../../src/include/c.h:784, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/port.h:177:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:246:1: warning: open redefined In file included from ../../../src/include/c.h:784, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/port.h:190:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:254:1: warning: mkdir redefined In file included from ../../../src/include/c.h:85, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/pg_config_os.h:13:1: warning: this is the location of the previous definition In file included from C:/Perl/lib/CORE/win32.h:549, from C:/Perl/lib/CORE/win32thread.h:4, from C:/Perl/lib/CORE/perl.h:2056, from plperl.c:62: C:/Perl/lib/CORE/win32iop.h:304:1: warning: kill redefined In file included from ../../../src/include/c.h:784, from ../../../src/include/postgres.h:48, from plperl.c:40: ../../../src/include/port.h:148:1: warning: this is the location of the previous definition make[3]: *** [plperl.o] Error 1 make[3]: Leaving directory `/cvs/pgsql/src/pl/plperl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cvs/pgsql/src/pl' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cvs/pgsql/src' make: *** [all] Error 2 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/include/port/win32.h === RCS file: /cvsroot/pgsql-server/src/include/port/win32.h,v retrieving revision 1.37 diff -c -c -r1.37 win32.h *** src/include/port/win32.h6 Oct 2004 09:35:23 - 1.37 --- src/include/port/win32.h6 Oct 2004 16:31:20 - *** *** 194,202 --- 194,210 /* * Supplement to sys/types.h. + * + * Perl already has conflicting defines for
Re: [HACKERS] FunctionCall2 performance
On Mon, Oct 04, 2004 at 02:42:43PM -0400, Greg Stark wrote: Mark Wong [EMAIL PROTECTED] writes: Links to results are here: 7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/ 8.0beta3 - http://www.osdl.org/projects/dbt2dev/results/dev4-010/180/ Are those cyclic spikes an artifact of the load of the tests? Or are they artifacts of the postgres checkpoint process? If they're an artifact of the test is it possible to randomize the number iterations and time each connection does before issuing the slower queries? Or somehow avoid generating these spikes? If they're an artifact of the checkpoint process I wonder if there are parameters that can be tweaked to smooth it out more. Some of those transactions/second drops are quite dramatic. It seems like you're averaging 200 txn/s normally but having it drop down to less than half that periodically. In the past, they have been artifacts of the checkpoint process. They do smooth out as I increase the checkpoint segments and the timeout. Although I know that doesn't exactly exclude other explanations. There are 5000 emulated clients connected through 100 database connections for both of those tests, attempting 1 of 5 different transactions. I hope that's random enough. :) When I run a less intense workload, everything smooths out a bit more too but it doesn't stress the system nearly as much. Mark ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] FunctionCall2 performance
On Wed, Oct 06, 2004 at 10:01:42AM -0700, Mark Wong wrote: On Mon, Oct 04, 2004 at 02:42:43PM -0400, Greg Stark wrote: Mark Wong [EMAIL PROTECTED] writes: Links to results are here: 7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/ 8.0beta3 - http://www.osdl.org/projects/dbt2dev/results/dev4-010/180/ Are those cyclic spikes an artifact of the load of the tests? Or are they artifacts of the postgres checkpoint process? In the past, they have been artifacts of the checkpoint process. They do smooth out as I increase the checkpoint segments and the timeout. Although I know that doesn't exactly exclude other explanations. Another knob to test would be bgwriter parameters, say bgwriter_percent to maybe 5 or 10. That should distribute more evenly the load. http://archives.postgresql.org/pgsql-hackers/2004-09/msg00623.php -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La rebeldía es la virtud original del hombre (Arthur Schopenhauer) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
Is this fixed? --- Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Maybe we could avoid removing it until the next checkpoint? Or is that not enough. Maybe it could stay there forever :/ Part of the problem here is that this code has to serve several purposes. We have different scenarios to worry about: * crash recovery from the most recent checkpoint * PITR replay over a long interval (many checkpoints) * recovery in the face of a partially corrupt filesystem It's the last one that is mostly bothering me at the moment. I don't want us to throw away data simply because the filesystem forgot an inode. Yeah, we might not have enough data in the WAL log to completely reconstruct a table, but we should push out what we do have, *not* toss it into the bit bucket. In the first case (straight crash recovery) I think it is true that any reference to a missing file is a reference to a file that will get deleted before recovery finishes. But I don't think that holds for PITR (we might be asked to stop short of where the table gets deleted) nor for the case where there's been filesystem damage. 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SRF/dropped column bug
I can confirm this bug still exists in CVS. --- Joe Conway wrote: I see this behavior with CVS tip: CREATE TABLE wibble (a integer, b integer); INSERT INTO wibble VALUES (1,1); ALTER TABLE wibble ADD COLUMN c BIGINT; UPDATE wibble SET c = b; ALTER TABLE wibble DROP COLUMN b; ALTER TABLE wibble RENAME c TO b; CREATE FUNCTION foobar() RETURNS SETOF wibble AS 'SELECT * FROM wibble' LANGUAGE SQL; regression=# SELECT * FROM wibble; a | b ---+--- 1 | 1 (1 row) regression=# select * from foobar(); a | b ---+--- 1 | (1 row) The example comes from a complaint in January 2004, at which time it would instead throw an ERROR: ERROR: query-specified return row and actual function return row do not match I'll start digging into this, but any hints on where to look would be greatly appreciated. Thanks, Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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: [HACKERS] [PATCHES] That dump-comments-on-composite-type-columns
Christopher Kings-Lynne wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: OK, I can do this, but I don't think I'll have time for the first beta. No problem. Another interesting think I noticed in pg_dump is dumping of LOBs. It seems to declare a cursor that fetches the blobs and then issues a fetch 1000 to get the first 1000 lobs. It never seems to execute any further fetches. Am I right that if you have more than 1000 lobs in postgres, pg_dump won't dump them? I checked and though the Fetch string is issued outside the loop, it keeps getting used inside the loop. There was some strange capitalization that confused things and I cleaned that up. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PITR question
[EMAIL PROTECTED] wrote:
Hi Every one.
At least I made PITR working however I still have 2 questions:
1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table note the time in logs
pg_ctl stop
rm -rf $PGDATA
restore backup
put the timestamp in recovery.conf and recover_inclusive=false
pg_ctl start
... you end up with a core dump (signal 6) and an error saying that you
can't stop before end of backup.
This is because it's the FIRST transaction after backup and ending restore
BEFORE this means ending before the end of backup...
Was this corrected? I don't see any followups to it in the archives.
2)
How do I restore EVERY database to the end of logs BUT one?
Same case here:
I wrongly droped a table so I restart and end the recovery before the drop
but I still want all the other DB in the cluster to go to the end of logs.
I ass/u/me I cant restore just the DB dir??
No, there is no way to restore just one database to an earlier time than
the others.
--
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: [HACKERS] DROP TABLESPACE causes panic during recovery
Bruce Momjian [EMAIL PROTECTED] writes: Is this fixed? Yes. 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: [HACKERS] Two-phase commit
Quite some time ago, Heikki Linnakangas [EMAIL PROTECTED] wrote: I haven't received any comments and there hasn't been any discussion on the implementation, I suppose that nobody has given it a try. :( I finally got around to taking a close look at this. There's a good bit undone, as you well know, but it seems like it can be the basis for a workable feature. I do have a few comments to make. At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue COMMIT PREPARED gid for the same gid several times without error. Consider a scenario where the transaction monitor crashes during the commit phase. When it recovers, it will be aware that it had committed to commit, but it won't know which nodes were successfully committed. So it will need to resend the COMMIT commands. It would be bad for the nodes to simply say yes boss if they are told to COMMIT a gid they have no record of. So I think the gid's have to stick around after COMMIT PREPARED or ROLLBACK PREPARED, and there needs to be a fourth command (RELEASE PREPARED?) to actually remove the state data when the transaction monitor is satisfied that everything's done. RELEASE of an unknown gid is okay to be a no-op. Implementation-wise, I really dislike storing the info in a shared hash table, because I don't see any reasonable bound on the size of the hash table (your existing code uses 100 which is about as arbitrary as it gets). Plus the actual content of each entry is not fixed-size either. This is not very workable given our fixed-size shared memory mechanism. The idea that occurs to me instead is to not use WAL or shared memory at all for keeping the prepared-transaction state info. Instead, suppose that we store the status information in a file named after the GID, $PGDATA/pg_twophase/gid. We could write the file with a CRC similarly to what's done for pg_control. Once such a file is written and fsync'd, it's equally as reliable as a WAL record would be, so it seems safe enough to me to report the PREPARE as done. COMMIT, ROLLBACK, and the pg_prepared_xacts system view would look into the pg_twophase directory to find out all about active prepared transactions; RELEASE PREPARED would simply delete the appropriate file. (Note: commit or rollback would need to take the transaction XID from the GID file and then look in pg_clog to find out if the transaction were already committed. These operations do not change the pg_twophase file, but they do write a normal transaction-commit or -abort WAL record and update pg_clog.) I think this would offer better performance as well as being more scalable, because the implementation you have looks like it would have some contention for the shared GID hashtable. I would be inclined to require GIDs to be numbers (probably int8's) instead of strings, so that we don't have any problems with funny characters in the file names. That's negotiable though, as we could certainly uuencode the strings or something to avoid that trap. You were concerned about how to mark prepared transactions in pg_clog, given that Alvaro had already commandeered state '11' for subtransactions. Since only a toplevel transaction can be prepared, it might work to allow state '11' with a zero pg_subtrans parent link to mean a prepared transaction. This would imply factoring prepared XIDs into GlobalXmin (so that pg_subtrans entries don't get recycled too soon) but we probably have to do that anyway. AFAICS, prepared but uncommitted XIDs have to be considered still InProgress, so if they are less than GlobalXmin we'd lose. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Re: [HACKERS] PITR question
Bruce Momjian [EMAIL PROTECTED] wrote on 06.10.2004, 21:15:34:
[EMAIL PROTECTED] wrote:
Hi Every one.
At least I made PITR working however I still have 2 questions:
1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table note the time in logs
pg_ctl stop
rm -rf $PGDATA
restore backup
put the timestamp in recovery.conf and recover_inclusive=false
pg_ctl start
... you end up with a core dump (signal 6) and an error saying that you
can't stop before end of backup.
This is because it's the FIRST transaction after backup and ending restore
BEFORE this means ending before the end of backup...
Was this corrected? I don't see any followups to it in the archives.
Not by me, though I was definitely working on crash recovery then. ;-)
Olivier is right in the explanation of this, but it doesn't seem that a
core dump is the appropriate response.
I'll correct this... though (for me) low prio fix should be done by
around last week Oct.
Apologies to Olivier and thanks to Bruce for re-raising the issue.
Best Regards,
Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pgindent complaint of the day
This case in xlog.c is representative of a disease that pgindent has had for awhile: @@ -4276,7 +4300,8 @@ StartupXLOG(void) if (needNewTimeLine)/* stopped because of stop request */ ereport(FATAL, (errmsg(requested recovery stop point is before end time of backup dump))); - else/* ran off end of WAL */ + else +/* ran off end of WAL */ ereport(FATAL, (errmsg(WAL ends before end time of backup dump))); } I'm not sure of all the triggering conditions, but every so often it decides to move a line-ending comment to its own line (which is a wrong policy in the first place IMHO) and forgets to indent it. I've mostly seen it on else lines but I'm not sure that's the only case. 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
Re: Re: Re: [HACKERS] PITR question
[EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: ... you end up with a core dump (signal 6) and an error saying that you can't stop before end of backup. Was this corrected? I don't see any followups to it in the archives. Not by me, though I was definitely working on crash recovery then. ;-) Olivier is right in the explanation of this, but it doesn't seem that a core dump is the appropriate response. The error is intentional. The reason it's converted to a core dump is simply that the whole of recovery is run as a critical section, and so any fatal error is promoted to PANIC. We could think about a different rule about whether to force a core dump in these circumstances, but I can't say that I am very excited about it. I'd rather have the dump and not need it than vice versa. 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])
Re: [HACKERS] Two-phase commit
Tom Lane wrote: At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue COMMIT PREPARED gid for the same gid several times without error. Consider a scenario where the transaction monitor crashes during the commit phase. When it recovers, it will be aware that it had committed to commit, but it won't know which nodes were successfully committed. So it will need to resend the COMMIT commands. It would be bad for the nodes to simply say yes boss if they are told to COMMIT a gid they have no record of. So I think the gid's have to stick around after COMMIT PREPARED or ROLLBACK PREPARED, and there needs to be a fourth command (RELEASE PREPARED?) to actually remove the state data when the transaction monitor is satisfied that everything's done. RELEASE of an unknown gid is okay to be a no-op. Isn't this usually where the GTM would issue recover requests to determine the state of the individual resources involved in the global transaction, and then only commit/abort the resources that need it? (I think the equivalent in Heikki's work is a SELECT of the pg_prepared_xact view) I found the Berkeley DB distributed transaction docs quite useful for working out how two-phase commit fits together: http://pybsddb.sourceforge.net/ref/xa/intro.html I would be inclined to require GIDs to be numbers (probably int8's) instead of strings, so that we don't have any problems with funny characters in the file names. That's negotiable though, as we could certainly uuencode the strings or something to avoid that trap. Aren't the GIDs generated externally by the GTM? We need more than an int8 there. See for example Heikki's JDBC driver patch: it is given a javax.transaction.xa.Xid by the TM in prepare/commit/etc. The Xid is basically just a couple of raw bytearrays. The driver base64-encodes that into a string GID to give to the backend. -O ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two-phase commit
Oliver Jowett [EMAIL PROTECTED] writes: At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue COMMIT PREPARED gid for the same gid several times without error. Isn't this usually where the GTM would issue recover requests to determine the state of the individual resources involved in the global transaction, and then only commit/abort the resources that need it? (I think the equivalent in Heikki's work is a SELECT of the pg_prepared_xact view) Well, the question is how long must the individual databases retain state with which to answer recover requests. I don't like forever, so I'm proposing that there should be an explicit command to say you can forget about this gid. Note that this is only really necessary because of Heikki's choice to make the API work in terms of a user-assigned GID. If PREPARE returned the internal XID and then the COMMIT/ROLLBACK PREPARED statements took the XID and not a GID, we could answer subsequent recover requests for quite a long time by consulting pg_clog. But then the transaction monitor would have to maintain the map from its GIDs to per-node XIDs, so unless it's going to have such functionality anyway, it's reasonable to ask the database to keep the map. (Either way, you're not going to want to drop the mapping entry until the transaction monitor knows all the commits are done.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two-phase commit
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue COMMIT PREPARED gid for the same gid several times without error. Isn't this usually where the GTM would issue recover requests to determine the state of the individual resources involved in the global transaction, and then only commit/abort the resources that need it? (I think the equivalent in Heikki's work is a SELECT of the pg_prepared_xact view) Well, the question is how long must the individual databases retain state with which to answer recover requests. I don't like forever, so I'm proposing that there should be an explicit command to say you can forget about this gid. As I understand it, you don't need to keep state for committed txns, it's only the prepared-but-not-yet-resolved txns that you have to respond to a recover request with. Then it seems like we already have a forget about this GID command for prepared transactions: ROLLBACK PREPARED. Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back? -O ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two-phase commit
On Wed, 2004-10-06 at 18:50, Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue COMMIT PREPARED gid for the same gid several times without error. Isn't this usually where the GTM would issue recover requests to determine the state of the individual resources involved in the global transaction, and then only commit/abort the resources that need it? (I think the equivalent in Heikki's work is a SELECT of the pg_prepared_xact view) Well, the question is how long must the individual databases retain state with which to answer recover requests. I don't like forever, so I'm proposing that there should be an explicit command to say you can forget about this gid. Isn't this exactly what the forget request is for in the XACoordinator? I think it's standard for Java at the very least. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two-phase commit
Oliver Jowett [EMAIL PROTECTED] writes: Tom Lane wrote: Well, the question is how long must the individual databases retain state with which to answer recover requests. As I understand it, you don't need to keep state for committed txns, I think that's clearly wrong: TM -- DB: COMMIT PREPARED foo DB does it and forgets gid foo TM crashes and restarts TM -- DB: what's the state of foo? DB -- TM: go away, never heard of it I suppose you could code the TM to treat this as meaning it was committed but I think the folly of that is obvious. Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back? Yeah, there's another set of issues there. Personally I always thought that 2PC was a fundamentally broken concept, because it's got so many squirrelly cases where the guarantees you thought you were buying with all this overhead vanish into thin air. 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: [HACKERS] Two-phase commit
On Wed, Oct 06, 2004 at 05:46:10PM -0400, Tom Lane wrote: You were concerned about how to mark prepared transactions in pg_clog, given that Alvaro had already commandeered state '11' for subtransactions. Since only a toplevel transaction can be prepared, it might work to allow state '11' with a zero pg_subtrans parent link to mean a prepared transaction. This would imply factoring prepared XIDs into GlobalXmin (so that pg_subtrans entries don't get recycled too soon) but we probably have to do that anyway. AFAICS, prepared but uncommitted XIDs have to be considered still InProgress, so if they are less than GlobalXmin we'd lose. This seems to work. I am concerned with a different issue: what issues arise regarding snapshots? Do concurrent xacts see a prepared one as running? I'm not sure but I think so. So they have to be able to at least get its Xid, no? As soon as you have that stored somewhere, you have to ensure that an arbitrary number of Xids, or better, snapshots, have to be somewhere. The 100 concept does not impress me either. So if you can have an arbitrary number of snapshots, you can as well have an arbitrary number of WITH HOLD open cursors, without the ugly Materialize node. Am I right? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two-phase commit
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Tom Lane wrote: Well, the question is how long must the individual databases retain state with which to answer recover requests. As I understand it, you don't need to keep state for committed txns, I think that's clearly wrong: TM -- DB: COMMIT PREPARED foo DB does it and forgets gid foo TM crashes and restarts TM -- DB: what's the state of foo? DB -- TM: go away, never heard of it I suppose you could code the TM to treat this as meaning it was committed I believe that is exactly what the TM does. Can you take a look at http://pybsddb.sourceforge.net/ref/xa/build.html (it's fairly brief) and point out any holes in the logic there? but I think the folly of that is obvious. It's fragile in the face of badly implemented TMs or resources, but other than that it seems OK to me. What was the problem you were thinking of in particular? Yeah, there's another set of issues there. Personally I always thought that 2PC was a fundamentally broken concept, because it's got so many squirrelly cases where the guarantees you thought you were buying with all this overhead vanish into thin air. You can get around some of the issues via 3PC but that has even *more* overhead. And noone actually implements it as far as I know :) 2PC is OK if you are only expecting it to handle certain failure modes, e.g. no byzantine failures, no loss of stable storage, no extended communication failures. In general, the two-army problem just sucks.. -O ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two-phase commit
Alvaro Herrera [EMAIL PROTECTED] writes: I am concerned with a different issue: what issues arise regarding snapshots? Do concurrent xacts see a prepared one as running? I'm not sure but I think so. So they have to be able to at least get its Xid, no? Hmm, that's a good point. It seems that uncommitted prepared XIDs have to be included whenever a Snapshot is manufactured. That means we need reasonably fast access to that set of XIDs, which is something I was thinking we wouldn't need to support. It's hard to see how to handle that without some sort of shared-memory data structure listing those XIDs. (This also blows out of the water the present preallocated-space-for-the-XID-lists memory allocation in GetSnapshot, but that was never more than the most marginal hack anyway.) As soon as you have that stored somewhere, you have to ensure that an arbitrary number of Xids, or better, snapshots, have to be somewhere. The 100 concept does not impress me either. So if you can have an arbitrary number of snapshots, you can as well have an arbitrary number of WITH HOLD open cursors, without the ugly Materialize node. Am I right? Nope. Snapshots are not the reason we have to materialize WITH HOLD cursors. Locks are. I suppose you could think about treating a WITH HOLD cursor like an uncommitted prepared transaction, but I'm not sure it's worth the overhead. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two-phase commit
Rod Taylor wrote: On Wed, 2004-10-06 at 18:50, Tom Lane wrote: Well, the question is how long must the individual databases retain state with which to answer recover requests. I don't like forever, so I'm proposing that there should be an explicit command to say you can forget about this gid. Isn't this exactly what the forget request is for in the XACoordinator? I think it's standard for Java at the very least. I think XAResource.forget() is to do with transactions that have heuristically completed (completion of a txn without explicit directions from the TM?), rather than the normal case. -O ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SQL-Invoked Procedures for 8.1
On Thu, 23 Sep 2004, Josh Berkus wrote:
For anyone who doesn't know what I'm talking about, it's this form:
CREATE PROCEDURE do_some_work ( alpha INT, beta INT, gamma TEXT )
etc.
Where you can:
CALL do_some_work( alpha = 5, beta = 7 )
.. and then gamma picks up its default, if any, or even:
If we make SPs unique by schema.name then we can support default values.
This is largely a feature of SQL Server. The syntax they use is:
argname argtype = default value
That is, something like (in PostgreSQL style syntax)
CREATE PROCEDURE foo(bar int = 1) ...
This syntax is fairly straight forward but another idea, keeping with
syntax else where, is:
CREATE PROCEDURE foo(bar int DEFAULT 1)
Is this too verbose? Do others have thoughts?
My real question, however, is do we want default values at all. Josh has
been fairly keen on them but I haven't seen much outright support for the
idea other than Joe and Joshua (perhaps a few others) putting the argument
that anything which eases the burden of migration from SQL Server is
(potentially) a good thing.
I could see an argument, however, that this (as well as the named
parameter notation) requires us to do a fairly large amount of work for
what is only a potential pay off. That is, to have these features, we
should probably store SPs in a new system catalog since otherwise we'd be
using with two different primary keys and we'd be enforcing different
rules when we add records.
So, the new SP system catalog would have no rettype column but it would
have a parameter modes column and, potentially, a default values column.
Doing this is only a matter of work, but it does leave us with a question
to answer. Can we always distinguish whether or not we're executing a
function or a procedure based on context? The reason is, if we cannot, I
believe, have a procedure with the same name as a function, since this is
the way in which we would determine what it is we need to execute.
I think we can distinguish between functions and procedures based on
context -- there is one case which will affect people, however.
1) Standard routine invocation
In the majority of cases, procedures will be invoked via CALL. We will
have to say that even functions which return void cannot be invoked by
CALL. I don't think that's a loss.
Only functions can be invoked in SELECT, UPDATE, DELETE, INSERT statements
-- which makes sense. So there is no confusion there.
2) Triggers
This is uglier. We currently have a syntax in trigger definition which
reads: ... EXECUTE PROCEDURE funcname. I'm not sure what inspired this
but SQL99, 2003, Oracle, DB2 etc allow you to more or less execute SQL --
which may include something which invokes a function or procedure.
I'm not suggesting we go down that path -- unless people really want it --
but it is a case where we cannot distinguish between a function and a
procedure. There are a few ways of tackling this:
i) Only procedures can be execute
Only procedures can be executed by triggers. We may be able to ease the
burden of backward compatibility issues by having pg_dump with 8.1
identify functions which return trigger as being procedures -- but, its
possible that people have defined trigger functions as foo(), foo(int),
etc. That is, they're using overloading, and we wont support that with
procedures -- if we take the path outlined in this email, that is. So,
there are potentially annoying upgrade problems for some users.
We *also* lose some functionality. BEFORE row-based triggers can return
NULL and the executor will be instructured to disregard the current tuple.
We will probably not be able to do this with procedures, unless we want an
OUT parameter to do it. I really dislike this idea.
ii) add EXECUTE FUNCTION
This gives us the option of allowing people to keep the existing
functionality and have a (relatively) simple upgrade path. It does,
however, move us further away from the spec and what other databases have.
iii) Support functions and procedures through SQL
Instead of adding EXECUTE FUNCTION, we could have:
FOR EACH { ROW | STATEMENT } { SELECT funcname | CALL procedure }
This gives us the option, I believe, of moving to full SQL comformance in
the future as well as giving people (and pg_dump) and upgrade path.
iv) Any other ideas?
3) PL/PgSQL
Neil's recent bare function calls patch for PL/PgSQL creates a situation
where we cannot distinguish between functions and procedures. For example:
DECLARE
i int := 1
BEGIN
foo(i);
END:
Is foo() a function or procedure? I think it is reasonable to say that
only procedures can be called in this fashion, and that function need be
invoked with PERFORM or in a query, as we have in 7.4, etc.
There are probably other cases that I haven't thought of.
Ideas, comments, criticisms?
Thanks,
Gavin
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] initdb crash
Hi, I saw a initdb crashes when it is creating the template1 database. I couldn't figure out what is wrong. I attached the backtrace and some architecture/compiler info. If someone needs more info, drop me a line. = Euler Taveira de Oliveira euler[at]yahoo_com_br ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/[EMAIL PROTECTED]:~/pgsql/cvs/install/bin$ gdb initdb GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-slackware-linux... (gdb) r -D /home/euler/cvs/install/data Starting program: /home/euler/pgsql/cvs/install/bin/initdb -D /home/euler/cvs/install/data [New Thread 16384 (LWP 593)] Os arquivos deste sistema de banco de dados pertencerão ao usuário euler. Esse usuário deve ser o dono do processo do servidor também. O agrupamento de banco de dados será inicializado com localidade pt_BR. A codificação padrão do banco de dados foi ajustada para LATIN1. criando diretório /home/euler/cvs/install/data ... ok criando diretório /home/euler/cvs/install/data/global ... ok criando diretório /home/euler/cvs/install/data/pg_xlog ... ok criando diretório /home/euler/cvs/install/data/pg_xlog/archive_status ... ok criando diretório /home/euler/cvs/install/data/pg_clog ... ok criando diretório /home/euler/cvs/install/data/pg_subtrans ... ok criando diretório /home/euler/cvs/install/data/base ... ok criando diretório /home/euler/cvs/install/data/base/1 ... ok criando diretório /home/euler/cvs/install/data/pg_tblspc ... ok selecionando max_connections padrão ... 100 selecionando shared_buffers padrão ... 1000 criando arquivos de configuração ... ok criando banco de dados template1 em /home/euler/cvs/install/data/base/1 ... TRAP: FailedAssertion(!(((bool) ((dbNode) != ((Oid) 0, Arquivo: tablespace.c, Linha: 116) Program received signal SIGPIPE, Broken pipe. [Switching to Thread 16384 (LWP 593)] 0x40304708 in write () from /lib/libc.so.6 (gdb) bt #0 0x40304708 in write () from /lib/libc.so.6 #1 0x40363d24 in __DTOR_END__ () from /lib/libc.so.6 #2 0x402a0d2e in new_do_write () from /lib/libc.so.6 #3 0x402a0cc6 in _IO_new_do_write () from /lib/libc.so.6 #4 0x402a1969 in _IO_new_file_sync () from /lib/libc.so.6 #5 0x4029618a in fflush () from /lib/libc.so.6 #6 0x0804aa0a in bootstrap_template1 (short_version=0xffe0 Address 0xffe0 out of bounds) at initdb.c:1198 #7 0x0804cd36 in main (argc=134997404, argv=0xb8d4) at initdb.c:2466 #8 0x40246d06 in __libc_start_main () from /lib/libc.so.6 (gdb) The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED]:~/pgsql/cvs/install/bin$ initdb --version initdb (PostgreSQL) 8.0.0beta3 [EMAIL PROTECTED]:~/pgsql/cvs/install/bin$ uname -a Linux ripley 2.4.26 #5 SMP Qui Abr 22 11:53:28 BRT 2004 i686 unknown unknown GNU/Linux [EMAIL PROTECTED]:~/pgsql/cvs/install/bin$ cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 287674368 275853312 118210560 42905600 184172544 Swap: 213848064 8650752 205197312 MemTotal: 280932 kB MemFree: 11544 kB MemShared: 0 kB Buffers: 41900 kB Cached: 177500 kB SwapCached: 2356 kB Active: 139360 kB Inactive: 110220 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 280932 kB LowFree: 11544 kB SwapTotal: 208836 kB SwapFree: 200388 kB [EMAIL PROTECTED]:~/pgsql/cvs/install/bin$ gcc --version gcc (GCC) 3.2.3 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~/pgsql/cvs/install/bin$ bison --version bison (GNU bison) 1.875 Escrito por Robert Corbett e Richard Stallman. Copyright © 2002 Free Software Foundation, Inc. Este é um software livre; veja o código fonte para condições de copyright. Não existe NENHUMA garantia; nem mesmo a garantia implícita de COMERCIABILIDADE ou ADEQUAÇÃO À QUALQUER FINALIDADE PARTICULAR. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pgindent complaint of the day
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
and this does exactly as you describe by putting the comment on its own
line. I just changed it to:
...
so that the new comment will have the same indenting as the else that
was input.
If it were the else's indent plus one more tab it would be reasonably
sane; it'd match the indentation of what comes next.
OK, I can do that but consider:
else /* comment */
{
something;
}
If we go without the special indent we get at worst case:
else
/* comment */
something;
while with an extra indent we get this as worst case:
else
/* comment */
{
something;
}
which seems like a worse worst case. :-)
--
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: [HACKERS] pgindent complaint of the day
Tom Lane wrote: This case in xlog.c is representative of a disease that pgindent has had for awhile: @@ -4276,7 +4300,8 @@ StartupXLOG(void) if (needNewTimeLine)/* stopped because of stop request */ ereport(FATAL, (errmsg(requested recovery stop point is before end time of backup dump))); - else/* ran off end of WAL */ + else +/* ran off end of WAL */ ereport(FATAL, (errmsg(WAL ends before end time of backup dump))); } I'm not sure of all the triggering conditions, but every so often it decides to move a line-ending comment to its own line (which is a wrong policy in the first place IMHO) and forgets to indent it. I've mostly seen it on else lines but I'm not sure that's the only case. You are correct that it only happens on comments on an else line. The problem is that there is a BSD indent bug that will stop processing the file in such cases so we have in pgindent: # workaround for indent bug with 'else' handling sed 's;\([} ]\)else[]*\(/\*.*\)$;\1else\ \2;g' | and this does exactly as you describe by putting the comment on its own line. I just changed it to: # workaround for indent bug with 'else' handling sed 's;\([} ]\)else\([ ]*\)\(/\*.*\)$;\1else\ \2\3;g' | so that the new comment will have the same indenting as the else that was input. It should help but will not be perfect. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SRF/dropped column bug
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I can confirm this bug still exists in CVS. I have a fix for this, but cannot commit just yet as we seem to be having network problems again :-( Yes, I have already beeped Marc. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] SRF/dropped column bug
Bruce Momjian [EMAIL PROTECTED] writes: I can confirm this bug still exists in CVS. I have a fix for this, but cannot commit just yet as we seem to be having network problems again :-( 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: [HACKERS] pgindent complaint of the day
Bruce Momjian [EMAIL PROTECTED] writes: and this does exactly as you describe by putting the comment on its own line. I just changed it to: ... so that the new comment will have the same indenting as the else that was input. If it were the else's indent plus one more tab it would be reasonably sane; it'd match the indentation of what comes next. 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
Re: [HACKERS] pgindent complaint of the day
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: If it were the else's indent plus one more tab it would be reasonably sane; it'd match the indentation of what comes next. OK, I can do that but consider: [ other case ] Just out of curiosity, what will pgindent do when re-run on the file with the comment already split to the next line? My experience with it so far is that it will not move a comment that starts in column 1, but it will feel free to re-indent a comment that has some indentation. A reasonable goal here would be that running pgindent a second time does not create immediate further changes. 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: [HACKERS] initdb crash
On Wed, 6 Oct 2004, Euler Taveira de Oliveira wrote: Hi, I saw a initdb crashes when it is creating the template1 database. I couldn't figure out what is wrong. I attached the backtrace and some architecture/compiler info. If someone needs more info, drop me a line. Can you run initdb with the -d flag? Also, the directory paths you included suggest that there might be some old code sitting around. Did you do a make distclean? Gavin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL-Invoked Procedures for 8.1
Gavin,
My real question, however, is do we want default values at all. Josh has
been fairly keen on them but I haven't seen much outright support for the
idea other than Joe and Joshua (perhaps a few others) putting the argument
that anything which eases the burden of migration from SQL Server is
(potentially) a good thing.
Let me advance the reason *I* want them.I do a lot of applications with
extensive, procedure-driven business logic. One of the things I constantly
run up against is when a widely used procedure needs a new parameter. With
functions as they stand now, I have to create a shell function that
encompasses the new parameter -- which starts to get hard to track when it's
happened 3 or 4 times. (woe is the lot of those with spec drift)
It also allows code neatness by not forcing you to constantly look up the
order of parameters in the function catalog. For example, this:
sf_cases ( user = 124223,
session = 114643343,
casename= 'VIKTOR',
client = 'KELLEY',
managedby = NULL,
status = 1,
fuzzysearch = TRUE,
filedafter = NULL,
format = 'long',
page= 1,
resultsper = 15 );
Is easier to both read an maintain than:
sf_cases ( 124223, 114643343, 'VIKTOR', 'KELLEY', NULL, 1, TRUE,
NULL, 'long', 1, 15);
Of course, this is as true of functions as it will be of procedures. So half
the functionality that I'm angling for to support with calling named params
could be accomplished within the context of overloading just by extending the
named param patch in 8.0 to cover calling functions/SPs in the format above.
Therefore: the arguments you raise about the difficulty of implementing a
seperate catalog are strong ones, and you are probably correct in the
tradeoff being a bad one.
And, not that I think about it, I have a way to support DEFAULT params within
the context of overloading. Let me muse it over and I'll get back to you.
I think we can distinguish between functions and procedures based on
context -- there is one case which will affect people, however.
So, do we still need to distinguish if we're not supporting default params?
iii) Support functions and procedures through SQL
Instead of adding EXECUTE FUNCTION, we could have:
FOR EACH { ROW | STATEMENT } { SELECT funcname | CALL procedure }
This gives us the option, I believe, of moving to full SQL comformance in
the future as well as giving people (and pg_dump) and upgrade path.
I like this because of the SQL conformance, completely aside from issues of
determinism.
Is foo() a function or procedure? I think it is reasonable to say that
only procedures can be called in this fashion, and that function need be
invoked with PERFORM or in a query, as we have in 7.4, etc.
Frankly, I agree here. For one thing, any Function being called in that
fashion is effectively being treated as a procedure -- the value it returns
is being thrown away.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
