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 allow
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
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
Philip Warner wrote:
> I think both this and the OID-wrap problem will be permanent features until
> we have a non-oid-based dump procedure. Pretty much every piece of metadata
> needs some kind of 'I am a system object, don't dump me' flag.
Curiously enough, Philip, you seem to have been ahea
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 fo
* 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 t
> > I'm going to commit redo for sequences tomorrow evening and
> > #define XLOG by default after this (initdb will be required).
>
> I suggest bumping the catversion.h number when you #define XLOG,
> so that people won't be able to accidentally start an old postmaster
> with new DB or vice versa
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 ta
"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
> #de
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
I've run some tests with 7.1 + WAL & 7.0.2
Setup: 5 tables (i int, t text), 10 records in each table,
sizeof(t column) is rand(256), indices on i column for all tables.
-B 16384 -A 0 (+ --wal_buffers=256 in 7.1)
System: SUN Ultra 10, 512M RAM, 1 (fast) IDE disk
Test: 5 clients simultaneously
"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),
> 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 .
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 f
* 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
> 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 t
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 identic
* 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)::tex
* Tom Lane <[EMAIL PROTECTED]> [001109 18:30] wrote:
> 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'
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 backen
Mark Hollomon <[EMAIL PROTECTED]> writes:
> How does this solve the 'ALTER FUNCTION' problem?
What's that got to do with it?
regards, tom lane
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
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
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
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 re
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: mailt
* Alfred Perlstein <[EMAIL PROTECTED]> [001109 17:07] wrote:
> 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:
[snip]
> These sources are the current CVS sources with the
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 r
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:
#0 0x4828ffc8 in kill () from /usr/lib/libc.so.4
#1 0x482cbbf2 in abort () from /usr/lib/libc.so.4
#2 0x814442f in ExcAbort () a
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
> descriptors especia
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 hav
I wrote:
> On top of that, we have the issue I was concerned about that there is
> no mechanism for clearing the cache-busy flags during xact abort.
Hmm, brain cells must be fading fast. On looking into the code I
find that there *is* such a mechanism --- installed by yours truly,
only three mon
> Rather than trying to fix this stuff, I propose that we simply remove
> the test for recursive use of a syscache. AFAICS it will never catch
> any real bugs in production. It might catch bugs in development (ie,
> someone messes up the startup sequence in a way that causes a truly
> circular c
"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
"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 trac
I'm just catching up to the tip of the current tree, and find
that I have a reported failure in initdb. It seems to go through
(most of) the steps, and just reports failure. I can thereafter
start a backend using an old RedHat script (which tries to run
initdb again but can't because the directo
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Oh no,my point isn't on this line but on the line
> estate->es_result_relation_info = NULL;
Oh, I see --- this is mistakenly assuming that es_result_relation_info
*always* points at one of the Append's relations. So there are actually
two rel-r
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 doe
Peter Eisentraut <[EMAIL PROTECTED]> 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.
> I think what I'm going to do is this: The argument is question cannot
> possibly be o
At 17:34 9/11/00 +0100, Peter Eisentraut wrote:
>
>The thing you get from initdb is a "cluster of catalogs", a database is a
>"catalog", a schema is something below a catalog. (There is no such
>thing as an "environment" as a hierarchy level.)
I think that's what SQL99 calls the 'cluster of cat
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 som
At 17:10 9/11/00 +0100, Zeugswetter Andreas SB wrote:
>
>> 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
[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 *rea
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 databas
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
Phil -
My take on this can be found at:
http://www.postgresql.org/mhonarc/pgsql-hackers/2000-03/msg00137.html
Peter agrees with me (from my personal archive: the postgresql.org one
has holes in it!):
http://cooker.ir.rice.edu/postgresql/msg19913.html
There was another discussion, a little ear
Philip Warner writes:
> Perhaps I'm wrong, but I think most people will equate database
> with a schema (ie. the thing in which you define tables).
I agree with most of what you say. However I am used to conflating
catalog with database. For example, the last product I put together
had one re
> I agree; it's a pain that one DB misbehaving kills an entire installation.
If that is of concern you need separate postmasters, no way around that,
and imho not a problem at all.
Andreas
> 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 d
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-authorizatio
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?
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
> 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
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 sa
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
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 kee
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 thir
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> in fact template0 needn't be a real database at all, just a
>> $PGDATA/base subdirectory with no pg_database entry.
> I like this "not really a database" idea.
> Might even be something for $libdir, no ?
I thought about that but concluded th
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
>
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 he
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 employee(title,fir
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
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.
But, how can I do ?
I have to recall the same routine many times. I tried to prepare and declare
the cursor inside the routine but when I compile with ecpg I receive the
error Cursor already defined.
Maurizio
.
- Original Message -
From: "Michael Meskes" <[EMAIL PROTECTED]>
To: "Maurizi
I have my server set up with one production postgres installation, and each
user can have their own database for their own use (usually web-related).
There are a limited number of trusted users, and I recently allowed one to
define a C-language stored procedure. Unfortunately, I *think* this caus
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
con
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<->f
> >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 woul
68 matches
Mail list logo
