Do we still need the lastsysoid column in pg_database if we do things
this way? Seems like what you really want is to suppress all the
objects that are in template0, so you really only need one lastsysoid
value, namely template0's. The other entries are useless AFAICS.
Where would you
On Wed, 8 Nov 2000, Christof Petig wrote:
Karel Zak wrote:
What about parameters? Normally you can prepare a statement and execute it
We have in PG parameters, see SPI, but now it's used inside backend only
and not exist statement that allows to use this feature in be-fe.
Sad.
At 08:59 9/11/00 +0100, Zeugswetter Andreas SB wrote:
Just seems like we'd be forcing non-standard syntax on
ourselves when/if
CREATE DATABASE becomes CREATE SCHEMA;
I do not think this will be the way.
I know there was a lot of discussion of this a while ago, but was there a
consistant
Tom Lane wrote:
Do we still need the lastsysoid column in pg_database if we do things
this way? Seems like what you really want is to suppress all the
objects that are in template0, so you really only need one lastsysoid
value, namely template0's. The other entries are useless AFAICS.
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Where would you store the value if not in pg_database?
No other ideas at the moment. I was just wondering whether there was any
way to delete it entirely, but seems like we want to have the value for
template0 available. The old way
At 05:47 PM 11/8/00 -0600, Luis =?UNKNOWN?Q?Maga=F1a?= wrote:
insert into employee(title,first_name,start_date,charge) values('Mr.
X','Smith',date(now()),'None');
insert into employee(title,first_name,start_date,charge) values('Mr.
Y','Smith',date(now()),'None');
insert into
On Mié 08 Nov 2000 19:34, Tom Lane wrote:
Well, maybe. But is it worth the trouble? Hard to believe anyone else
did the same thing.
If socklen_t exists, it's presumably the right thing to use, so if we
just hardwire "void - socklen_t", I think it'd be OK. If we're wrong,
we'll hear
At 09:47 9/11/00 -0500, Jan Wieck wrote:
To make pg_dump failsafe, we'd IMHO need to freeze all
objects that come with template0 copying.
For now we have oid's 1-16383 hardwired from the bki files.
Some 16384-x get allocated by initdb after bootstrap, so
we
Tom Lane writes:
If socklen_t exists, it's presumably the right thing to use, so if
we just hardwire "void - socklen_t", I think it'd be OK. If we're
wrong, we'll hear about it...
Ah, if only life were that simple ;-/
Depending on the version of Solaris and the compiler flags the third
Philip Warner [EMAIL PROTECTED] writes:
Presumably this was raised before, but I'd love to see the consensus view,
if it is documented.
AFAIR, the discussion trailed off without any specific decisions being
made. One of the things that's still very open in my mind is whether
we want to keep
Philip Warner [EMAIL PROTECTED] writes:
I'd be interested to know the reason for killing the other backends;
Because they all share the same shared-memory pool. After a backend
crash you can't be sure whether shared memory is corrupted or not.
(Even if it's not been actively scribbled on by
Jan Wieck [EMAIL PROTECTED] writes:
For now we have oid's 1-16383 hardwired from the bki files.
Some 16384-x get allocated by initdb after bootstrap, so
we just need to bump the oid counter at the end of initdb (by
some bootstrap interface command) to lets say
To me, though, the point of independent databases is that they be
*independent*, and therefore if we keep them I'd vote for mapping them
to the top-level SQL notion (catalog, you said?). Schemas ought to be
substructure within a database.
Yes, that was also "sort of" the bottom line of the
At 10:36 9/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Presumably this was raised before, but I'd love to see the consensus view,
if it is documented.
AFAIR, the discussion trailed off without any specific decisions being
made. One of the things that's still very open
At 10:43 9/11/00 -0500, Tom Lane wrote:
Would there be any potential to avoid these (possibly) unnecessary deaths?
No, at least it'll never get my vote.
Presumably other than limiting to one 'database' per installation?
Philip Warner [EMAIL PROTECTED] writes:
I think the hierarchy goes:
Environment-Catalog-Schema
From what I can tell:
1. the environment contains truly general things like the SQL parser, the
tools for connecting to the DB etc - which I assume also contains the
user-authorization stuff.
3. Schemas are what we call databases. They contain tables, views wtc.
Let us not start this all over again. Our database would correspond to a catalog
if we put schemas below our database hierarchy.
The standard requires, that you see all schemas within one catalog in
one user session. We
Peter Eisentraut writes:
[EMAIL PROTECTED] writes:
Depending on the version of Solaris and the compiler flags the
third argument can be a pointer to socklen_t, void, size_t or
int.
The argument is question cannot possibly be of a different width
than int, unless someone is
At 10:43 AM 11/9/00 -0500, Tom Lane wrote:
Would there be any potential to avoid these (possibly) unnecessary deaths?
No, at least it'll never get my vote.
Besides, it's not that difficult for an application to recover from these
prophylactic backend deaths. My PG driver for AOLserver does
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
Does this occur after a prior error message? I have been suspicious
because there isn't a mechanism to clear the syscache-busy flags during
xact abort.
I don't know if I've seen the cases you pointed out.
I have the following gdb back trace.
"Kevin O'Gorman" [EMAIL PROTECTED] writes:
I'm just catching up to the tip of the current tree, and find
that I have a reported failure in initdb.
initdb works fine for me (as of CVS from about 11:30AM EST today).
Try running it with -d or -v or whatever the verbose-output option
is to get
Tom Lane wrote:
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
Does this occur after a prior error message? I have been suspicious
because there isn't a mechanism to clear the syscache-busy flags during
xact abort.
I don't know if I've seen the cases you pointed out.
I have the following
Alfred Perlstein [EMAIL PROTECTED] writes:
I have a program that does a:
DECLARE getsitescursor CURSOR FOR select...
I ^C'd it and it didn't properly shut down the channel to
postgresql and I got this crash:
...
These sources are the current CVS sources with the exception of
some removed
Tom asked me to bust it some more 8-)
I've attached the query and the gdb backtrace. This is very
repeatable, so if there's more info needed, let me know.
--
Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED]
Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED]
At school:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
My concern is the robustness of rel cache.
It seems pretty dangerous to discard system relation
descriptors used for cache mechanism especially in
case of error recovery.
It also seems pretty dangerous to recontruct relation
I said:
So there's more to this than just killing
a client that has a cursor.
OK, after digging some more, it seems that the critical requirement
is that the cursor's query contain a hash join. I've been able to
reproduce a crash here...
regards, tom lane
On Wednesday 08 November 2000 10:15, Tom Lane wrote:
At 14:04 7/11/00 -0500, Jan Wieck wrote:
FWIW, what about having another "template0" database, where
nobody can add user data. Initially, template0 and template1
are identically. CREATE DATABASE get's a new switch (used by
the
I said:
OK, after digging some more, it seems that the critical requirement
is that the cursor's query contain a hash join.
Here's the deal:
test7=# set enable_mergejoin to off;
SET VARIABLE
test7=# begin;
BEGIN
-- I've previously checked that this produces a hash join plan:
test7=# declare c
Mark Hollomon [EMAIL PROTECTED] writes:
How does this solve the 'ALTER FUNCTION' problem?
What's that got to do with it?
regards, tom lane
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why? We are able to construct all the non-nailed relcache entries
from scratch during backend startup. That seems a sufficient
proof that we can reconstruct any or all of them on demand.
Hmm,why is it sufficent ?
At backend startup
At 22:24 9/11/00 -0500, Mark Hollomon wrote:
On Wednesday 08 November 2000 10:15, Tom Lane wrote:
At 14:04 7/11/00 -0500, Jan Wieck wrote:
FWIW, what about having another "template0" database, where
nobody can add user data. Initially, template0 and template1
are identically. CREATE
I guess the immediate question is do we want to hold up 7.0.3 release
for a fix? This bug is clearly ancient, so I'm not sure it's
appropriate to go through a fire drill to fix it for 7.0.3.
Comments?
We have delayed 7.0.3 already. Tom is fixing so many bugs, we may find
at some point that
* Bruce Momjian [EMAIL PROTECTED] [001109 18:55] wrote:
I guess the immediate question is do we want to hold up 7.0.3 release
for a fix? This bug is clearly ancient, so I'm not sure it's
appropriate to go through a fire drill to fix it for 7.0.3.
Comments?
We have delayed 7.0.3
On Thu, 9 Nov 2000, Alfred Perlstein wrote:
* Bruce Momjian [EMAIL PROTECTED] [001109 18:55] wrote:
I guess the immediate question is do we want to hold up 7.0.3 release
for a fix? This bug is clearly ancient, so I'm not sure it's
appropriate to go through a fire drill to fix it for
The Hermit Hacker [EMAIL PROTECTED] writes:
Tom, if you can plug this one in the next, say, 48hrs (Saturday night),
please do ... else, I'll announce 7.0.3 on Saturday night and we'll leave
it with such a large showstopper :(
I do have an idea for a simple stopgap answer --- testing now ...
"Kevin O'Gorman" [EMAIL PROTECTED] writes:
Program received signal SIGSEGV, Segmentation fault.
attnameAttNum (rd=0x1, a=0x82172a0 "product_level") at parse_relation.c:967
967 for (i = 0; i rd-rd_rel-relnatts; i++)
(gdb) bt
#0 attnameAttNum (rd=0x1, a=0x82172a0
The Hermit Hacker [EMAIL PROTECTED] writes:
Tom, if you can plug this one in the next, say, 48hrs (Saturday night),
Done. Want to generate some new 7.0.3 release-candidate tarballs?
regards, tom lane
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Results: 5000 transactions took ~60 sec in 7.1, ~550 sec in 7.0.2 with fsync
and ~60 sec without fsync.
So, seems that WAL added not just complexity to system -:)
Sounds great!
I'm going to commit redo for sequences tomorrow evening and
#define
On Thu, 9 Nov 2000, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Tom, if you can plug this one in the next, say, 48hrs (Saturday night),
Done. Want to generate some new 7.0.3 release-candidate tarballs?
Done, and just forced a sync to ftp.postgresql.org of the new tarballs
* The Hermit Hacker [EMAIL PROTECTED] [001109 20:19] wrote:
On Thu, 9 Nov 2000, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Tom, if you can plug this one in the next, say, 48hrs (Saturday night),
Done. Want to generate some new 7.0.3 release-candidate tarballs?
Jan Wieck wrote:
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Where would you store the value if not in pg_database?
No other ideas at the moment. I was just wondering whether there was any
way to delete it entirely, but seems like we want to have the value for
template0
At 23:23 9/11/00 -0600, [EMAIL PROTECTED] wrote:
Philip Warner wrote:
Relying of values of numeric OIDs is definitely clunky, but it's all we can
do at the moment.
I held that one up, but now I am wondering: would checking a "don't
dump me" flag involve any more code or or would it be any
Philip Warner [EMAIL PROTECTED] writes:
I have also mentioned this on two occasions now, and each has met with
total silence. I have come to interpret this to mean either (a) the idea is
too stupid to rate a comment, or (b) go ahead with the proposal.
More like "oof ..."
You're right, it's
Karel Zak wrote:
On Wed, 8 Nov 2000, Christof Petig wrote:
Karel Zak wrote:
What about parameters? Normally you can prepare a statement and execute it
We have in PG parameters, see SPI, but now it's used inside backend only
and not exist statement that allows to use this
Peter Eisentraut [EMAIL PROTECTED] writes:
Well, we need *some* way to extract a representation like "w.x.y.z/n".
If you don't like text() as the name of that formatting function,
suggest another name...
all_octets(cidr)::text maybe?
No, because that doesn't accurately describe what it does
Philip Warner writes:
I'd be very interested if someone could post the current thinking re:
schemas, catalogs, and environments, because the way I read the SQL99 docs,
the catalog seems to correspond to a single postgres installation, and a
schema seems to correspond to a postgres database
[EMAIL PROTECTED] writes:
Depending on the version of Solaris and the compiler flags the third
argument can be a pointer to socklen_t, void, size_t or int.
I think what I'm going to do is this: The argument is question cannot
possibly be of a different width than int, unless someone is
* Tom Lane [EMAIL PROTECTED] [001109 10:30]:
Peter Eisentraut [EMAIL PROTECTED] writes:
Well, we need *some* way to extract a representation like "w.x.y.z/n".
If you don't like text() as the name of that formatting function,
suggest another name...
all_octets(cidr)::text maybe?
No,
48 matches
Mail list logo
