Re: [HACKERS] Ready for RC1
On 12/2/2004 8:16 PM, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: One more issue. Until we start RC, patches that are bug fixes will continue to be applied. Do we want that? By going RC we are basically saying we need to focus on docs and packaging and we perhaps can keep fixes for 8.0.1. In my mind RC means only critical bug fixes --- ie, just because it's a bug fix doesn't mean it won't be held for later. But RC doesn't mean no changes, period. It means we're trying to test the thing without any more code churn than absolutely necessary. The real problem at the moment is that we should have been in an only bug fixes mode for some time already, and you just pushed in two or three patches that look more like feature additions to me (and I gather to Peter as well). *That* is the reason people are getting antsy about whether we are RC-ready. I honestly can't tell whether these are bug fixes or not, especially the encoding changes, so I put them in the queue and when no one says anything I apply them. And that policy is wrong, IMHO. Put patches on the queue and apply them if nobody objects should be the default while we are in development. We were in beta5 and just agreed on getting ready for RC1, which means that the default action is not to apply it unless it is proven that it is a bugfix and only a bugfix with no feature slipping in together with a fix. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 8.0RC1 tomorrow
Bruce Momjian [EMAIL PROTECTED] writes: TODO item? Sure: * ANALYZE should record a pg_statistic entry for an all-NULL column regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Adding a suffix array index
On Sun, 28 Nov 2004 17:53:38 -0500, Tom Lane wrote: But is it cheaper, IO-wise to jump around in an index than to go back and forth between index and tuple blocks? Perhaps not --- but why would you be jumping around? Wouldn't the needed info appear in consecutive locations in the index? Searching for a match, using a suffix array entails a binary search in the suffix array (can be optimized through the use of a longest-common-prefix helper-array). So some amount of jumping is needed. Anyhow: I've given up trying to create the suffix array as a normal index type. As I'm running out of time, I'm inclined to hacks. I'm considering storing the index of a sequence in a large object which I then store a reference to in the data item: The large object interface seems like something I could use. Or I might store dnaseq values as - some meta-information, perhaps (like a hash value) - a reference to a large object containing the sequence - a reference to a large object containing the suffix array - a reference to a large object containing a helper-array (longest common prefix-information) One problem with this approach is that the related, large objects will not automatically be removed when a value is removed from a table (but that could probably be somewhat fixes using a trigger). Beyond being somewhat ugly: Is it possible? How much of[1] is still the case today? Are today's large objects somewhat corresponding to the article's description of v-segments? The article mentions that POSTGRES supported a CREATE LARGE TYPE construct. Am I right in assuming that today's corresponding construct is as exemplified in the manual: CREATE TYPE bigobj (INPUT = lo_filein, OUTPUT = lo_fileout,...) Reference 1: Stonebraker Olson: Large Object Support in POSTGRES (1993) http://epoch.cs.berkeley.edu:8000/postgres/papers/S2K-93-30.pdf -- Greetings from Troels Arvin, Copenhagen, Denmark ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Adding a suffix array index
Troels Arvin [EMAIL PROTECTED] writes: How much of[1] is still the case today? Reference 1: Stonebraker Olson: Large Object Support in POSTGRES (1993) http://epoch.cs.berkeley.edu:8000/postgres/papers/S2K-93-30.pdf Probably almost none of it ... the only thing I know about the Berkeley-era large object features is that at least two-thirds of that code got ripped out later. 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] Error handling in plperl and pltcl
On 12/2/2004 3:18 AM, Thomas Hallgren wrote:
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints and exception handling
should be kept separate. Consider the following two examples:
savepoint a
spi calls
savepoint b
spi calls
savepoint c
spi calls
switch(some test)
{
case 1:
rollback b;
commit a;
break;
case 2:
rollback c;
commit a;
break;
case 3:
rollback a;
break;
default:
commit a;
}
I don't know, but doing a lot of work only to later decide to throw it
away doesn't strike me as a good programming style. Some test should be
done before performing the work.
or nested try/catch where the catch doesn't access the database:
There is no try in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be the exceptions error message in cleartext, is assigned to the
optional variable specified. Thus, your code usually looks like this:
if {[catch {statements-that-might-fail} err]} {
on-error-action
} else {
on-success-action
}
foo()
{
try
{
spi calls;
}
catch
{
set some status;
re-throw;
}
}
and some other place in the code:
savepoint a
try
{
spi calls;
for(i = 0; i 100; ++i)
foo();
commit a;
}
catch
{
rollback a;
}
If normal savepoint hanling is disabled here in favor of your
suggestion, you will get 101 subtransations although only 1 is relevant.
Your example shows where leaving the burdon on the programmer can
improve performance. But change it to this:
foo {} {
spi-calls;
if {[catch {spi-call} err]} {
return boo: $err
}
return hooray
}
This function never throws any exception. And any normal Tcl programmer
would expect that the spi-calls done before the catch will either abort
the function on exception, or if they succeed, they get committed. What
you mean with normal savepoint handling in fact means that we don't
change catch at all but just expose the savepoint feature on the Tcl level.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] pg_restore --help
On Fri, Dec 03, 2004 at 01:35:55PM -0300, Alvaro Herrera wrote: In pg_restore --help I see this: -O, --no-owner do not output commands to set object ownership [...] -x, --no-privileges skip restoration of access privileges (grant/revoke) Sorry, of course the problem is not only pg_restore --no-owner, but also in pg_dump and pg_dumpall as well (albeit with a slightly different wording and meaning). -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La espina, desde que nace, ya pincha (Proverbio africano) ---(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] Who's in charge of torrents? [was: Easy way to download all .torrents]
On Thu, Dec 02, 2004 at 08:34:11PM -0600, Jim C. Nasby wrote: I've tried emailling David Fetter to no avail; anyone know who's in charge of the torrents or anyone who can answer my original question? I'm in charge, and re: your original question, perhaps some creative use of wget could help. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] pg_restore --help
People, In pg_restore --help I see this: -O, --no-owner do not output commands to set object ownership [...] -x, --no-privileges skip restoration of access privileges (grant/revoke) Do we talk about output commands to do things, or directly about restoration? I think -O description should be -O, --no-owner skip restoration of object ownership or something similar, to be consistent. Patch for that attached, but feel free to editorialize ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The ability to monopolize a planet is insignificant next to the power of the source Index: src/bin/pg_dump/pg_restore.c === RCS file: /home/alvherre/cvs/pgsql/src/bin/pg_dump/pg_restore.c,v retrieving revision 1.67 diff -c -r1.67 pg_restore.c *** src/bin/pg_dump/pg_restore.c27 Nov 2004 18:51:06 - 1.67 --- src/bin/pg_dump/pg_restore.c3 Dec 2004 16:34:50 - *** *** 376,382 printf(_( -I, --index=NAME restore named index\n)); printf(_( -L, --use-list=FILENAME use specified table of contents for ordering\n output from this file\n)); ! printf(_( -O, --no-owner do not issue commands to set object ownership\n)); printf(_( -P, --function=NAME(args)\n restore named function\n)); printf(_( -s, --schema-onlyrestore only the schema, no data\n)); --- 376,382 printf(_( -I, --index=NAME restore named index\n)); printf(_( -L, --use-list=FILENAME use specified table of contents for ordering\n output from this file\n)); ! printf(_( -O, --no-owner skip restoration of object ownership\n)); printf(_( -P, --function=NAME(args)\n restore named function\n)); printf(_( -s, --schema-onlyrestore only the schema, no data\n)); ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Port report--Linux/sparc32
I just compiled 8.0beta5 on my old Sparc 5. All tests passed. This is running Debian 3.0 with a 2.2.20 kernel. Sure took a long time. :) I can test on an ia32/RedHat 6.2 machine if that would be helpful. -Doug ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] multiline CSV fields
Patch applied. Thanks.
---
Andrew Dunstan wrote:
I wrote:
If it bothers you that much. I'd make a flag, cleared at the start of
each COPY, and then where we test for CR or LF in CopyAttributeOutCSV,
if the flag is not set then set it and issue the warning.
I didn't realise until Bruce told me just now that I was on the hook for
this. I guess i should keep my big mouth shut. (Yeah, that's gonna
happen ...)
Anyway, here's a tiny patch that does what I had in mind.
cheers
andrew
[ text/x-patch is unsupported, treating like TEXT/PLAIN ]
Index: copy.c
===
RCS file: /home/cvsmirror/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.234
diff -c -r1.234 copy.c
*** copy.c6 Nov 2004 17:46:27 - 1.234
--- copy.c2 Dec 2004 23:34:20 -
***
*** 98,103
--- 98,104
static EolType eol_type;/* EOL type of input */
static int client_encoding;/* remote side's character encoding */
static int server_encoding;/* local encoding */
+ static bool embedded_line_warning;
/* these are just for error messages, see copy_in_error_callback */
static bool copy_binary;/* is it a binary copy? */
***
*** 1190,1195
--- 1191,1197
attr = tupDesc-attrs;
num_phys_attrs = tupDesc-natts;
attr_count = list_length(attnumlist);
+ embedded_line_warning = false;
/*
* Get info about the columns we need to process.
***
*** 2627,2632
--- 2629,2653
!use_quote (c = *test_string) != '\0';
test_string += mblen)
{
+ /*
+ * We don't know here what the surrounding line end characters
+ * might be. It might not even be under postgres' control. So
+ * we simple warn on ANY embedded line ending character.
+ *
+ * This warning will disappear when we make line parsing
field-aware,
+ * so that we can reliably read in embedded line ending
characters
+ * regardless of the file's line-end context.
+ *
+ */
+
+ if (!embedded_line_warning (c == '\n' || c == '\r') )
+ {
+ embedded_line_warning = true;
+ elog(WARNING,
+ CSV fields with embedded linefeed or carriage
return
+ characters might not be able to be
reimported);
+ }
+
if (c == delimc || c == quotec || c == '\n' || c == '\r')
use_quote = true;
if (!same_encoding)
---(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
---(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
[HACKERS] OK, ready for RC1 or Beta6
OK, where are we in the release process? We still have a few open items, but those can be moved to the TODO list. Do we do RC1 or Beta6? -- 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] pg_restore --help
Alvaro Herrera [EMAIL PROTECTED] writes: Do we talk about output commands to do things, or directly about restoration? I think -O description should be -O, --no-owner skip restoration of object ownership This seems reasonable, but I wonder whether we should hold it for 8.1. There hasn't been any official declaration that translatable strings are frozen for 8.0 --- but are we at that point yet? Even if we're not at hard freeze, minor wording improvements might be out. Peter, I'll defer to your judgment on this ... 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] Error handling in plperl and pltcl
Jan Wieck wrote:
There is no try in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be the exceptions error message in cleartext, is assigned to the
optional variable specified. Thus, your code usually looks like this:
if {[catch {statements-that-might-fail} err]} {
on-error-action
} else {
on-success-action
}
Ok, I wasn't trying to write tcl ;-) just pseudo code proving a point.
This particular point is only valid until you expose the savepoint API's
(as you now suggest) though, so no disagreement there.
Your example shows where leaving the burdon on the programmer can
improve performance. But change it to this:
foo {} {
spi-calls;
if {[catch {spi-call} err]} {
return boo: $err
}
return hooray
}
This function never throws any exception. And any normal Tcl
programmer would expect that the spi-calls done before the catch will
either abort the function on exception, or if they succeed, they get
committed. What you mean with normal savepoint handling in fact
means that we don't change catch at all but just expose the savepoint
feature on the Tcl level.
Maybe Tcl programmers use catch very differently from what I'm used to
with try/catch in C++, C#, and Java. There, it's very common that you
use a catch to make sure that resources that you've utilized are freed
up, to do error logging, and to deal with errors that are recoverable.
If a catch containing an spi-function automatically implies a
subtransaction, then it might affect how people design their code since
the subtransaction is much more expensive then a mere catch.
Ideally, in a scenario where the caller of foo also calls other
functions and want to treat the whole call chain as a atomic, he would
start a subtransaction and do all of those calls within one catch where
an error condition would yield a rollback. Within each function he still
might want to catch code that eventually contains spi-calls but not for
the purpose of rolling back. The error condition is perhaps not even
caused by the spi-call but by something else that happened within the
same block of code. If it's unrecoverable, then he re-throws the error
of course.
The catch functionality is likely to be lean and mean. Implied
subtransactions will make it slower and thus not as suitable for control
flow as it normally would be. Where I come from, frequent use of
try/catch is encouraged since it results in good program design. I'm
concerned that what you are suggesting will make developers think twice
before they use a catch since they know what's implied.
I still believe that both catch (with try or no try) and savepoints are
simple and well known concepts that will benefit from being kept separate.
Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] pg_restore --help
On Fri, Dec 03, 2004 at 12:20:51PM -0500, Tom Lane wrote: This seems reasonable, but I wonder whether we should hold it for 8.1. There hasn't been any official declaration that translatable strings are frozen for 8.0 --- but are we at that point yet? Even if we're not at hard freeze, minor wording improvements might be out. Not sure, I've been holding translations precisely because strings are not frozen yet ... -- Alvaro Herrera ([EMAIL PROTECTED]) La virtud es el justo medio entre dos defectos (Aristóteles) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OK, ready for RC1 or Beta6
Bruce Momjian wrote: OK, where are we in the release process? We still have a few open items, but those can be moved to the TODO list. Do we do RC1 or Beta6? Considering all the patching that has been going on recently and the fact that we don't have any port reports, I think it's too early for a release candidate. I think we should release beta 6 immediately, call for port reports based on it, and then release RC1 as soon as we have an idea where the port reports are going, possibly in less than one week. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OK, ready for RC1 or Beta6
Peter Eisentraut wrote: Bruce Momjian wrote: OK, where are we in the release process? We still have a few open items, but those can be moved to the TODO list. Do we do RC1 or Beta6? Considering all the patching that has been going on recently and the fact that we don't have any port reports, I think it's too early for a release candidate. I think we should release beta 6 immediately, call for port reports based on it, and then release RC1 as soon as we have an idea where the port reports are going, possibly in less than one week. What about the build farm? Can't we assume we are pretty close to RC? -- 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] pg_restore --help
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Do we talk about output commands to do things, or directly about restoration? I think -O description should be -O, --no-owner skip restoration of object ownership This seems reasonable, but I wonder whether we should hold it for 8.1. There hasn't been any official declaration that translatable strings are frozen for 8.0 --- but are we at that point yet? Even if we're not at hard freeze, minor wording improvements might be out. Peter, I'll defer to your judgment on this ... Change it right now, and then we'll freeze. :) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] OK, ready for RC1 or Beta6
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: OK, where are we in the release process? We still have a few open items, but those can be moved to the TODO list. Do we do RC1 or Beta6? Considering all the patching that has been going on recently and the fact that we don't have any port reports, I think it's too early for a release candidate. I think we should release beta 6 immediately, call for port reports based on it, and then release RC1 as soon as we have an idea where the port reports are going, possibly in less than one week. What about the build farm? Can't we assume we are pretty close to RC? I would say no. 1. Buildfarm doesn't yet have that many platforms on it. 2. There are critical notices on buildfarm for some more popular platforms such as Solaris 9 and Open BSD. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(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] pg_restore --help
Peter Eisentraut [EMAIL PROTECTED] writes: Change it right now, and then we'll freeze. :) Done. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OK, ready for RC1 or Beta6
On Fri, 3 Dec 2004, Peter Eisentraut wrote: Bruce Momjian wrote: OK, where are we in the release process? We still have a few open items, but those can be moved to the TODO list. Do we do RC1 or Beta6? Considering all the patching that has been going on recently and the fact that we don't have any port reports, I think it's too early for a release candidate. I think we should release beta 6 immediately, call for port reports based on it, and then release RC1 as soon as we have an idea where the port reports are going, possibly in less than one week. If we are only concerned with Port related bug reports, and nothing that should require an initdb, I'd be okay with an RC1 ... it would indicate to everyone that we've finally locked down the code, and are only dealing with critical bug reports and documentation ... Thing is, I think we'd get more serious testing once we do say the code is locked in Release Mode, then if we release yet another beta .. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] OK, ready for RC1 or Beta6
On December 3, 2004 10:31 am, you wrote: Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: OK, where are we in the release process? We still have a few open items, but those can be moved to the TODO list. Do we do RC1 or Beta6? Considering all the patching that has been going on recently and the fact that we don't have any port reports, I think it's too early for a release candidate. I think we should release beta 6 immediately, call for port reports based on it, and then release RC1 as soon as we have an idea where the port reports are going, possibly in less than one week. What about the build farm? Can't we assume we are pretty close to RC? I would say no. 1. Buildfarm doesn't yet have that many platforms on it. 2. There are critical notices on buildfarm for some more popular platforms such as Solaris 9 and Open BSD. The OpenBSD error should be fixed by http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c?f=h;rev=1.60 and other than that I see noting on the build far that is questionable (other than the win32 regres test notice) Sincerely, Joshua D. Drake -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Error handling in plperl and pltcl
On 12/3/2004 12:23 PM, Thomas Hallgren wrote:
Jan Wieck wrote:
There is no try in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be the exceptions error message in cleartext, is assigned to the
optional variable specified. Thus, your code usually looks like this:
if {[catch {statements-that-might-fail} err]} {
on-error-action
} else {
on-success-action
}
Ok, I wasn't trying to write tcl ;-) just pseudo code proving a point.
This particular point is only valid until you expose the savepoint API's
(as you now suggest) though, so no disagreement there.
as you now suggest? I don't remember suggesting that. I concluded from
your statements that _you_ are against changing Tcl's catch but instead
want the savepoint functionality exposed to plain Tcl. So _you_ are
against _my_ suggestion because these two are mutually exclusive.
Maybe Tcl programmers use catch very differently from what I'm used to
with try/catch in C++, C#, and Java. There, it's very common that you
use a catch to make sure that resources that you've utilized are freed
up, to do error logging, and to deal with errors that are recoverable.
If a catch containing an spi-function automatically implies a
subtransaction, then it might affect how people design their code since
the subtransaction is much more expensive then a mere catch.
Ideally, in a scenario where the caller of foo also calls other
functions and want to treat the whole call chain as a atomic, he would
start a subtransaction and do all of those calls within one catch where
an error condition would yield a rollback. Within each function he still
might want to catch code that eventually contains spi-calls but not for
the purpose of rolling back. The error condition is perhaps not even
caused by the spi-call but by something else that happened within the
same block of code. If it's unrecoverable, then he re-throws the error
of course.
You want the capabilities of C or Assembler (including all possible
failures that lead to corruptions) in a trusted procedural language. I
call that far from ideal.
The catch functionality is likely to be lean and mean. Implied
subtransactions will make it slower and thus not as suitable for control
flow as it normally would be. Where I come from, frequent use of
try/catch is encouraged since it results in good program design. I'm
concerned that what you are suggesting will make developers think twice
before they use a catch since they know what's implied.
The point we where coming from was Tom's proposal to wrap each and every
single SPI call into its own subtransaction for semantic reasons. My
proposal was an improvement to that with respect to performance and IMHO
also better matching the semantics.
Your suggestion to expose a plain savepoint interface to the programmer
leads directly to the possiblity to commit a savepoint made by a
sub-function in the caller and vice versa - which if I understood Tom
correctly is what we need to avoid.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OK, ready for RC1 or Beta6
Darcy Buskermolen [EMAIL PROTECTED] writes: On December 3, 2004 10:31 am, you wrote: 2. There are critical notices on buildfarm for some more popular platforms such as Solaris 9 and Open BSD. The OpenBSD error should be fixed by http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c?f=h;rev=1.60 Right, that was my silly oversight last night. and other than that I see noting on the build far that is questionable (other than the win32 regres test notice) It's too bad the buildfarm reports don't show more details about what CVS pull they're using exactly. I think that this case might be fixed by the tweaking I did yesterday, but I can't tell whether that run occurred before or after that commit. In any case it's not a real failure, just an output-ordering difference. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Error handling in plperl and pltcl
Jan Wieck [EMAIL PROTECTED] writes: Your suggestion to expose a plain savepoint interface to the programmer leads directly to the possiblity to commit a savepoint made by a sub-function in the caller and vice versa - which if I understood Tom correctly is what we need to avoid. If we expose a savepoint-style interface in the PLs, it'll need to be restricted to the cases we can actually support. I don't have a problem with the idea in the abstract, but there was no time to do it for 8.0. I think we can add that on in 8.1, or later, without creating any backwards-compatibility issues compared to where we are now --- at least not for pltcl and plperl. (We might regret having tied subtransactions to exceptions in plpgsql, not sure.) The real issue is whether the required restrictions would be ugly enough that savepoint syntax doesn't seem like a nice API. I thought so when I did the coding for plpgsql, but I'm less sure at the moment. You'd probably have to prototype an implementation to find out for certain. It might be that the only real restriction is to make savepoint names local to functions (a/k/a savepoint levels), which wouldn't be bad at all. 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] Error handling in plperl and pltcl
On Dec 3, 2004, at 2:04 PM, Jan Wieck wrote: [snip] The point we where coming from was Tom's proposal to wrap each and every single SPI call into its own subtransaction for semantic reasons. My proposal was an improvement to that with respect to performance and IMHO also better matching the semantics. Your suggestion to expose a plain savepoint interface to the programmer leads directly to the possiblity to commit a savepoint made by a sub-function in the caller and vice versa - which if I understood Tom correctly is what we need to avoid. The JDBC interface exposes the savepoint interface, via setSavepoint(), releaseSavepoint(), and rollback(Savepoint sp) methods on the Connection, and Thomas's design of PL/Java offers the SPI via mapping it onto JDBC. Would client-side JDBC also suffer from the same potential issue of 'commit a savepoint made by a sub-function'? Or is this something SPI-specific? Or, finally, is this an issue of interacting with other PL languages who won't expose savepoint-ish functionality? IMO, if it smells like JDBC, it oughta smell as close to 100% like JDBC, allowing folks to possibly relocate some of their code to run inside PG. Ugly savepoint handling and all. James Robinson Socialserve.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Error handling in plperl and pltcl
James Robinson [EMAIL PROTECTED] writes: The JDBC interface exposes the savepoint interface, via setSavepoint(), releaseSavepoint(), and rollback(Savepoint sp) methods on the Connection, and Thomas's design of PL/Java offers the SPI via mapping it onto JDBC. Would client-side JDBC also suffer from the same potential issue of 'commit a savepoint made by a sub-function'? No, it's not a problem for client-side JDBC, because that's executing in a client thread that's not going to have its state affected by telling the server to roll back some work. The fundamental problem on the server side is keeping rollback from wiping your execution stack and local variables out from under you :-(. Or is this something SPI-specific? AFAICS the same problem would occur whether the PL used SPI or not; certainly bypassing SPI to use the database engine more directly wouldn't solve it. 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
Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Joshua D. Drake [EMAIL PROTECTED] writes: 1. Buildfarm doesn't yet have that many platforms on it. It's not as bad as all that. Our current list of supported platforms (ie, things that got tested last time) is AIX Free/Open/NetBSDcovered by buildfarm HPUXused daily by moi IRIX Linux covered by buildfarm OS Xtested pretty often by moi Solaris covered by buildfarm Tru64 UnixWare Windows/Cygwin covered by buildfarm With respect to hardware it's x86 covered by buildfarm ia64 x86_64 covered by buildfarm ARM Alpha MIPScovered by buildfarm m68k PA-RISC used daily by moi PPC tested pretty often by moi RS6000 isn't this same as PPC? S/390 Sparc covered by buildfarm Considering that we have both 32- and 64-bit, little- and big-endian hardware in there, most of the basic hardware gotchas are covered; the only thing I think is at much risk is the spinlock assembler code, which we change seldom. Where the buildfarm falls down a bit is on the cross-product coverage. But I think you're not going to get the cross product without a call for port reports; there aren't that many people who are going to offer dedicated time on every random platform there is. It would be nice to get an Alpha into the buildfarm, and PPC too. 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: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Tom Lane wrote: Where the buildfarm falls down a bit is on the cross-product coverage. But I think you're not going to get the cross product without a call for port reports; there aren't that many people who are going to offer dedicated time on every random platform there is. Once RC1 is out and the build farm has picked it up, we should start filling out our little table with the build farm results and then look for ways to fill the holes. Does the build farm turn on all the compiler options? It really should. I'm looking for /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
On Fri, Dec 03, 2004 at 03:20:48PM -0500, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: 1. Buildfarm doesn't yet have that many platforms on it. It's not as bad as all that. Our current list of supported platforms (ie, things that got tested last time) is AIX Free/Open/NetBSDcovered by buildfarm HPUXused daily by moi IRIX Linux covered by buildfarm OS Xtested pretty often by moi Solaris covered by buildfarm Tru64 UnixWare Windows/Cygwin covered by buildfarm With respect to hardware it's x86 covered by buildfarm ia64 x86_64 covered by buildfarm ARM Alpha MIPScovered by buildfarm m68k PA-RISC used daily by moi PPC tested pretty often by moi RS6000 isn't this same as PPC? This is the IBM Power4 and now Power5 architecture which is different from the PowerPC. Ken ---(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: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Peter Eisentraut [EMAIL PROTECTED] writes: Does the build farm turn on all the compiler options? It really should. I'm looking for /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl I was just thinking about what the buildfarm should do with configure options. IMHO it would be most useful if we could have it testing a variety of different combinations. For instance, that stupid mistake I made last night would only have been detected by testing the combination --with-openssl and *not* --enable-thread-safety. We obviously are not going to have enough machines to test every possible combination, let alone every combination on every platform, but maybe we could make sure that interesting option combinations appear at least once among the set of buildfarm machines. I think it would be useful to cover all 16 permutations of --enable-thread-safety --with-krb5 --with-pam -with-openssl if possible, since those potentially interact in libpq. The --with-tcl --with-perl --with-python switches are probably pretty independent of these, but we should have one or two buildfarm machines trying each language if possible. Other switches that should be getting used by some but not all machines: --enable-integer-datetimes --enable-nls --without-readline(just to make sure it builds) --without-zlib(ditto) Finally, while I think most of the platforms should use --enable-debug and --enable-cassert to aid in tracking down problems, there should be one machine building without these, just to catch silly mistakes. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Error handling in plperl and pltcl
Jan Wieck wrote: as you now suggest? I don't remember suggesting that. I concluded from your statements that _you_ are against changing Tcl's catch but instead want the savepoint functionality exposed to plain Tcl. So _you_ are against _my_ suggestion because these two are mutually exclusive. I probably misinterpreted what you wrote in your last post where you wrote What you mean with normal savepoint handling in fact means that we don't change catch at all but just expose the savepoint feature on the Tcl level.. I thought you ment that you actually would expose the savepoints in Tcl. You want the capabilities of C or Assembler (including all possible failures that lead to corruptions) in a trusted procedural language. I call that far from ideal. No I don't. I'm not sure how you came to that conclusion. I'm all for a good, 100% safe design and clean interfaces. The point we where coming from was Tom's proposal to wrap each and every single SPI call into its own subtransaction for semantic reasons. My proposal was an improvement to that with respect to performance and IMHO also better matching the semantics. As I said earlier, I think you proposal is great as a stop-gap solution for 8.0. But when full savepoint support is enabled using SPI calls, the implementation should change IMHO. Your suggestion to expose a plain savepoint interface to the programmer leads directly to the possiblity to commit a savepoint made by a sub-function in the caller and vice versa - which if I understood Tom correctly is what we need to avoid. That particluar scenario is very easy to prevent. You just maintain a savepoint structure that keeps track of function call level. The lifecycle of a savepoint cannot exceed the lifecycle of the invocation where it was created and it cannot be released or rolled back at a higher level. An attemt to do so would yield an unrecoverable error. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OK, ready for RC1 or Beta6
Tom Lane wrote: It's too bad the buildfarm reports don't show more details about what CVS pull they're using exactly. Snapshot is the UTC time at which the cvs pull was done. Clients report what files have changed since the last run, and also, in the case of a failure, what files have changed since the last successful run. See for example http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dogdt=2004-12-03%2000:06:02 The Windows and Cygwin clients are not currently doing this, as they are running experimental code in which it has been temporarily disabled. I guess I could actually get CVS revision info via cvs status for these files and report it, if you think that would be useful. This at least is one case where another SCR system than CVS would be nicer - in SVN for example you would just report the tree id. I think that this case might be fixed by the tweaking I did yesterday, but I can't tell whether that run occurred before or after that commit. In any case it's not a real failure, just an output-ordering difference. I am running it again to see. I agree that at worst it would require an alternative output file, assuming we aren't bothered by these ordering differences. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Tom/all, I have setup the following running debian linux. MIPS, MIPSEL, ALPHA, PARISC, M68K, ARM, SPARC, I386. I have the build farm running local and I have just started to get the systems registered. I am also willing to aquire other hardware/ operating systems in an effort to give something back to the Postgresql community Jim -- Original Message --- From: Tom Lane [EMAIL PROTECTED] To: Joshua D. Drake [EMAIL PROTECTED] Cc: PostgreSQL-development [EMAIL PROTECTED] Sent: Fri, 03 Dec 2004 15:20:48 -0500 Subject: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6) Joshua D. Drake [EMAIL PROTECTED] writes: 1. Buildfarm doesn't yet have that many platforms on it. It's not as bad as all that. Our current list of supported platforms (ie, things that got tested last time) is AIX Free/Open/NetBSDcovered by buildfarm HPUXused daily by moi IRIX Linux covered by buildfarm OS Xtested pretty often by moi Solaris covered by buildfarm Tru64 UnixWare Windows/Cygwin covered by buildfarm With respect to hardware it's x86 covered by buildfarm ia64 x86_64 covered by buildfarm ARM Alpha MIPScovered by buildfarm m68k PA-RISC used daily by moi PPC tested pretty often by moi RS6000 isn't this same as PPC? S/390 Sparc covered by buildfarm Considering that we have both 32- and 64-bit, little- and big-endian hardware in there, most of the basic hardware gotchas are covered; the only thing I think is at much risk is the spinlock assembler code, which we change seldom. Where the buildfarm falls down a bit is on the cross-product coverage. But I think you're not going to get the cross product without a call for port reports; there aren't that many people who are going to offer dedicated time on every random platform there is. It would be nice to get an Alpha into the buildfarm, and PPC too. 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 --- End of Original Message --- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] 1 Hour To RC1 ...
Approx ... but, if anyone has anything they want to say before that happens, you have an hour left to god save your souls *muhahahaha* Okay, not that bad ... but, just figured I'd give a heads up in case someone was just finishing off something ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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
[HACKERS] 8.0.0beta5 FailedAssertion (Crash) when casting composite types
template2=# SELECT version(); version -- PostgreSQL 8.0.0beta5 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.2 (Debian 3.4.2-3) (1 row) template2=# CREATE TABLE base (i integer); CREATE TABLE template2=# CREATE TABLE derived () INHERITS (base); CREATE TABLE template2=# INSERT INTO derived (i) VALUES (0); INSERT 0 1 template2=# SELECT derived::base FROM derived; TRAP: FailedAssertion(!(typeId == ( (olddata)-t_choice.t_datum.datum_typeid )), File: tuptoaster.c, Line: 830) Ouch! The actual case that I discovered this on had extra columns in the derived table and I was expecting some sort of error message (and I guess I got one - just a little more extreme than I was expecting) -- Kris Shannon [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Peter Eisentraut wrote: Tom Lane wrote: Where the buildfarm falls down a bit is on the cross-product coverage. But I think you're not going to get the cross product without a call for port reports; there aren't that many people who are going to offer dedicated time on every random platform there is. Once RC1 is out and the build farm has picked it up, we should start filling out our little table with the build farm results and then look for ways to fill the holes. Does the build farm turn on all the compiler options? It really should. I'm looking for /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check I know you're busy, but please take a few moments to check out how it works. The configuration is chosen in the config file for each member, rather than being dictated centrally. Every report (success and failure) shows the config settings. The only setting that buildfarm needs to set itself is --prefix which is chosen relative to another config file setting. Everything else is up to the farm member sysadmin to choose appropriately. A single member can run more than one branch, and per-branch config can be set up. A single machine can run more than one farm member (e.g. to use different compilers). In addition to the steps above, we do the following: initdb pg_ctl start make installcheck make contrib make contrib::installcheck pg_ctl stop The worth of these extra steps has already been shown - a number of bugs of unknown age and provenance have been fixed, especially in contrib. It is possible to run the buildfarm yourself without even being registered on www.pgbuildfarm.org - the script has a --nosend option which means it doesn't try to upload its results to the server. I encourage anyone interested in running buildfarm to try this option first. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OK, ready for RC1 or Beta6
On December 3, 2004 11:14 am, Tom Lane wrote: Darcy Buskermolen [EMAIL PROTECTED] writes: On December 3, 2004 10:31 am, you wrote: 2. There are critical notices on buildfarm for some more popular platforms such as Solaris 9 and Open BSD. The OpenBSD error should be fixed by http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe- secure.c?f=h;rev=1.60 Right, that was my silly oversight last night. and other than that I see noting on the build far that is questionable (other than the win32 regres test notice) It's too bad the buildfarm reports don't show more details about what CVS pull they're using exactly. I think that this case might be fixed by the tweaking I did yesterday, but I can't tell whether that run occurred before or after that commit. In any case it's not a real failure, just an output-ordering difference. http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2004-12-03%2020:54:53 Lends me to think your tweek didn't push hard enough in the right spots. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Hi *, is somebody working on these two issues on the TODO-List? 1) Prevent default re-use of sysids for dropped users and groups Currently, if a user is removed while he still owns objects, a new user given might be given their user id and inherit the previous users objects. 2) Prevent dropping user that still owns objects, or auto-drop the objects if NOT I like to take care of them. ( At least I like to try it. I need a special task to get things started rather to read the code over and over again ) cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] OK, ready for RC1 or Beta6
Andrew Dunstan wrote: I think that this case might be fixed by the tweaking I did yesterday, but I can't tell whether that run occurred before or after that commit. In any case it's not a real failure, just an output-ordering difference. I am running it again to see. I agree that at worst it would require an alternative output file, assuming we aren't bothered by these ordering differences. No, it's still there :-( cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Andrew Dunstan [EMAIL PROTECTED] writes: The configuration is chosen in the config file for each member, rather than being dictated centrally. This is good. Now what we need is a little cooperation among the buildfarm team to make sure that the collective set of cases tested covers all the interesting combinations of configure flags, as per my followup ... A single member can run more than one branch, and per-branch config can be set up. A single machine can run more than one farm member (e.g. to use different compilers). Yeah, on platforms where there's a non-gcc vendor compiler, testing with the vendor compiler is very interesting. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] OK, ready for RC1 or Beta6
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: It's too bad the buildfarm reports don't show more details about what CVS pull they're using exactly. Snapshot is the UTC time at which the cvs pull was done. That's good but it's of limited use to me, since the snaps are (I presume) against the anonymous-CVS server which lags commits on the master by I'm-not-sure-how-much. Clients report what files have changed since the last run, and also, in the case of a failure, what files have changed since the last successful run. Cool, I had not seen it do that before. If we could get the CVS version number of each mentioned file into that, it would go a long way towards helping identify exactly what's being tested. 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: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Jim Buttafuoco [EMAIL PROTECTED] writes: I have setup the following running debian linux. MIPS, MIPSEL, ALPHA, PARISC, M68K, ARM, SPARC, I386. I have the build farm running local and I have just started to get the systems registered. Excellent, that's very good news. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OK, ready for RC1 or Beta6
Darcy Buskermolen [EMAIL PROTECTED] writes: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2004-12-03%2020:54:53 Lends me to think your tweek didn't push hard enough in the right spots. Yup, you're right. I used a bigger hammer ;-) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
On Dec 3, 2004, at 2:33 PM, Kenneth Marshall wrote: On Fri, Dec 03, 2004 at 03:20:48PM -0500, Tom Lane wrote: PPC tested pretty often by moi RS6000 isn't this same as PPC? This is the IBM Power4 and now Power5 architecture which is different from the PowerPC. Yeah, it's confusing. I believe that Power3 (also known as PowerPC 630), Power4, and Power5 satisfy the requirements of being both Power architecture and PowerPC architecture processors. Not all PowerPC processors are Power processors. I believe that all modern Power processors are PowerPC processors (the Power2 P2SC was the last non-PowerPC Power processor, IIRC). IBM's Power architecture has architectural features for Server systems (with a capital S there) that PowerPC for workstations (Apple) and embedded (Moto/IBM) shouldn't be required to have, and is also IBM's own solely-owned branding. Hence the differentiation. That's what I've pieced together anyway. You'll probably find multi-OS-testing (various versions of AIX, Linux, MacOS X on PPC and/or PowerPC) much more important than differentiating particular pieces of hardware in the PPC or RS6000 category, assuming both 32-bit and 64-bit is covered and also that SMP tests are made. Does 'make check' test SMP? -Travis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OK, ready for RC1 or Beta6
On Fri, 3 Dec 2004, Tom Lane wrote: That's good but it's of limited use to me, since the snaps are (I presume) against the anonymous-CVS server which lags commits on the master by I'm-not-sure-how-much. 19 * * * * /projects/update_anoncvs.sh Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Travis P [EMAIL PROTECTED] writes: You'll probably find multi-OS-testing (various versions of AIX, Linux, MacOS X on PPC and/or PowerPC) much more important than differentiating particular pieces of hardware in the PPC or RS6000 category, assuming both 32-bit and 64-bit is covered and also that SMP tests are made. Agreed. Does 'make check' test SMP? Yes; not very hard, but it will usually catch bad problems, especially over the long haul of many retries. 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] OK, ready for RC1 or Beta6
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: It's too bad the buildfarm reports don't show more details about what CVS pull they're using exactly. Snapshot is the UTC time at which the cvs pull was done. That's good but it's of limited use to me, since the snaps are (I presume) against the anonymous-CVS server which lags commits on the master by I'm-not-sure-how-much. In my case it's against my local CVSup mirror, which is updated every 15 minutes. The buildfarm config lets you choose what repo to use. Nevertheless I take your point. Clients report what files have changed since the last run, and also, in the case of a failure, what files have changed since the last successful run. Cool, I had not seen it do that before. If we could get the CVS version number of each mentioned file into that, it would go a long way towards helping identify exactly what's being tested. Feature request filed on pgfoundry - not sure when I'll get to it. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
schmidtm [EMAIL PROTECTED] writes: is somebody working on these two issues on the TODO-List? 1) Prevent default re-use of sysids for dropped users and groups I don't know of anyone actively working on it, but if you check the archives you'll find that the preferred solution approach is pretty well hashed out --- it boils down to creating a shared sequence object and using that, rather than a MAX(sysid) query, to select default sysids. The painful part of this is just that bootstrap mode doesn't currently have any support for creating sequences. I don't think fixing that will be hugely hard, but it might be a bit tedious. 2) Prevent dropping user that still owns objects, or auto-drop the objects No one has any idea how to do this reasonably --- the problem is you have no visibility into databases other than the one you're connected to, so you can't tell what the user owns in other databases. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] rc1 packaged ...
look her over ... I forced a sync to the ftp.postgresql.org server, so its available there ... will announce later this evening baring any 'its broken' commends ;) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] somebody working on: Prevent default re-use of sysids
On Fri, 3 Dec 2004, Tom Lane wrote: 2) Prevent dropping user that still owns objects, or auto-drop the objects No one has any idea how to do this reasonably --- the problem is you have no visibility into databases other than the one you're connected to, so you can't tell what the user owns in other databases. What about Alvaro's shared dependencies work: http://archives.postgresql.org/pgsql-hackers/2004-10/msg00963.php Kris Jurka ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Calling for translation finalization
Leading up to the release of PostgreSQL 8.0, the development group has agreed to freeze the message strings, so now is the right time to send in message translations for the 8.0 release. See http://developer.postgresql.org/~petere/nlsinfo/ for information on how to contribute. If there are already translations in your language, it would make sense to contact the previous translator before starting on your own. If there are no previous translations in your language, you will probably not be able to finish all of them in time for the release. But partial translations will be accepted, and updated translations will be considered for subsequent minor releases. I also want to point out the translation effort of the JDBC driver at http://jdbc.postgresql.org/development/translation.html The JDBC driver team is also preparing for a release and would surely welcome your contribution. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Kris Jurka [EMAIL PROTECTED] writes: On Fri, 3 Dec 2004, Tom Lane wrote: No one has any idea how to do this reasonably --- the problem is you have no visibility into databases other than the one you're connected to, so you can't tell what the user owns in other databases. What about Alvaro's shared dependencies work: http://archives.postgresql.org/pgsql-hackers/2004-10/msg00963.php I think the practicality of that is still TBD ... particularly with respect to the question of tracking ACL entries as opposed to just owners. If we could track such things, then the whole notion of sysids for users could probably go away, and we could just use OIDs for them. So I'm not against pursuing the idea, I'm just worried about the overhead and locking implications. 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] rc1 packaged ...
Marc G. Fournier [EMAIL PROTECTED] writes: look her over ... I forced a sync to the ftp.postgresql.org server, so its available there ... will announce later this evening baring any 'its broken' commends ;) Tarball looks alright to me. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] --prefix=/Program\ Files and build failures
While monkeying around with configure --prefix I fond the following. (there may be more but this one was still in my scroll back... [...snip..] /usr/local/bin/gmake -C ecpglib install gmake[4]: Entering directory `/usr/local/src/postgresql-8.0.0/src/interface s/ecpg/ecpglib' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -fpic -DPIC -DFRONTEND -I../../../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq -I../../../../src/port -I../../../../src/include -c -o path.o path.c path.c: In function `get_share_path': path.c:375: warning: unknown escape sequence `\ ' path.c:375: warning: unknown escape sequence `\ ' path.c: In function `get_etc_path': path.c:384: warning: unknown escape sequence `\ ' path.c:384: warning: unknown escape sequence `\ ' path.c: In function `get_include_path': path.c:393: warning: unknown escape sequence `\ ' path.c:393: warning: unknown escape sequence `\ ' path.c: In function `get_pkginclude_path': path.c:402: warning: unknown escape sequence `\ ' path.c:402: warning: unknown escape sequence `\ ' path.c: In function `get_includeserver_path': path.c:411: warning: unknown escape sequence `\ ' path.c:411: warning: unknown escape sequence `\ ' -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] --prefix=/Program\ Files and build failures
Darcy Buskermolen [EMAIL PROTECTED] writes: While monkeying around with configure --prefix I fond the following. You probably shouldn't backslash the space. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] somebody working on: Prevent default re-use of sysids
Kris Jurka wrote: On Fri, 3 Dec 2004, Tom Lane wrote: 2) Prevent dropping user that still owns objects, or auto-drop the objects No one has any idea how to do this reasonably --- the problem is you have no visibility into databases other than the one you're connected to, so you can't tell what the user owns in other databases. What about Alvaro's shared dependencies work: http://archives.postgresql.org/pgsql-hackers/2004-10/msg00963.php That is for allowing comments on global tables like pg_shadow and pg_database. I don't think it relates to finding if someone owns objects in another database. -- 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] --prefix=/Program\ Files and build failures
Tom Lane wrote: Darcy Buskermolen [EMAIL PROTECTED] writes: While monkeying around with configure --prefix I fond the following. You probably shouldn't backslash the space. Also recall that we have just gone through some pain so we can make a postgres installation relocatable. One of the benefits is this is that you shouldn't have to do stuff like this. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] somebody working on: Prevent default re-use of sysids
On Fri, 3 Dec 2004, Bruce Momjian wrote: What about Alvaro's shared dependencies work: http://archives.postgresql.org/pgsql-hackers/2004-10/msg00963.php That is for allowing comments on global tables like pg_shadow and pg_database. I don't think it relates to finding if someone owns objects in another database. I quote from the first paragraph of the given link: I'm currently playing with implementing a shared dependency catalog, to keep track of objects pointing to global objects, currently users and tablespaces. So it is forbidden to drop a user that owns tables (or whatever objects) on other databases. Kris Jurka ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] somebody working on: Prevent default re-use of sysids
Kris Jurka wrote: On Fri, 3 Dec 2004, Bruce Momjian wrote: What about Alvaro's shared dependencies work: http://archives.postgresql.org/pgsql-hackers/2004-10/msg00963.php That is for allowing comments on global tables like pg_shadow and pg_database. I don't think it relates to finding if someone owns objects in another database. I quote from the first paragraph of the given link: I'm currently playing with implementing a shared dependency catalog, to keep track of objects pointing to global objects, currently users and tablespaces. So it is forbidden to drop a user that owns tables (or whatever objects) on other databases. Interesting. I didn't realize he was doing dependency between global and db-local objects. -- 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] 8.0RC1 tomorrow
I wrote: I started work today on a page that lists all the members. Now viewable here: http://www.pgbuildfarm.org/cgi-bin/show_members.pl In due course, the branch names will be links to the build history. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] So is there a 8.0RC1 tomorrow
Out of all of the messages on this thread, I am still not sure... Is there an RC1 coming out RSN? Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] So is there a 8.0RC1 tomorrow
[EMAIL PROTECTED] wrote: Out of all of the messages on this thread, I am still not sure... Is there an RC1 coming out RSN? Yes, it has been packaged and is now propogating to the mirrors. It is on the main ftp site now under /pub/beta/*rc1*. -- 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] So is there a 8.0RC1 tomorrow
CONGRATULATIONS BTW - I have the OS/2 port running through to creating the template0 and template1 databases with initdb. I have a glitch with the fork() processing that seems to be in the OS/2 GCC 3.3.5 runtime, but I expect to have that resolved shortly. I am going to apply the patches from os/2 beta5 to RC 1 and see how it works. Lorne In [EMAIL PROTECTED], on 12/03/04 at 11:29 PM, Bruce Momjian [EMAIL PROTECTED] said: [EMAIL PROTECTED] wrote: Out of all of the messages on this thread, I am still not sure... Is there an RC1 coming out RSN? Yes, it has been packaged and is now propogating to the mirrors. It is on the main ftp site now under /pub/beta/*rc1*. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] rc1 fedora core rpms
As promised, I've posted 8.0.0rc1 rpms here: http://www.joeconway.com/postgresql-8.0.0rc/ Again note that these are not official PGDG rpms, just my own home brew. In addition to the change of Postgres itself from beta5 to rc1, I updated jdbc to latest beta (pg80b1.308*). Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
