*SIGH* Oh, well. I suppose I should have updated up development machine a while ago.
./configure; make here we come.
Thank you for looking at this. At least I can be re-assured that the problem is fixed
in later versions of Postgres.
GTG
>>> Tom Lane <[EMAIL PROTECTED]> 05/12/04 20:36 PM >>>
"Gordon Ross" <[EMAIL PROTECTED]> writes:
> switchboards=# select * from "DNOwner";
> server closed the connection unexpectedly
> The DNOwner table is the base table. There are other tables that inherit from this
> table, and doing a simple select on those produce the same result.
Hmm. Does 'se
switchboards=# \d "DNOwner";
Table "public.DNOwner"
Column| Type | Modifiers
-+-+
Id | integer | not null default nextval('"DNOwner_id_seq"'::text)
ExDirectory
"Gordon Ross" <[EMAIL PROTECTED]> writes:
>> 4. Do whatever it takes in the psql session to provoke crash
>> and send along the output of bt.
> Program received signal SIGSEGV, Segmentation fault.
> 0x806ba0a in nocachegetattr () at eval.c:88
> 88 eval.c: No such file or directory.
> (gdb) bt
>4. Do whatever it takes in the psql session to provoke crash. gdb
>should announce that the backend has gotten a signal 11. Now say
> gdb> bt
> gdb> quit
>
>and send along the output of bt.
Program received signal SIGSEGV, Segmentation fault.
0x806ba0a in nocachegetattr () at eval.c
"Gordon Ross" <[EMAIL PROTECTED]> writes:
> I've been using a PGSQL 7.3.1 system as my development box for some time, and so
> far, it worked fine. (This is running on Slackware distro with a 2.2.19 kernel under
> VMWare 4)
> However, yesterday, I added a column to a base table (that is inherited
I've been using a PGSQL 7.3.1 system as my development box for some time, and so far,
it worked fine. (This is running on Slackware distro with a 2.2.19 kernel under VMWare
4)
However, yesterday, I added a column to a base table (that is inherited by several
other tables). Shortly afterwards, w
On Wednesday 16 October 2002 06:54, Jyry Kuukkanen wrote:
> On Tue, 15 Oct 2002, Andreas Schmitz wrote:
> > I have a problem dumping with 7.2.3. When I do a pg_dumpall redirecting
> > this to a file I have >4 lines of schema and data. Running psql
> > template1 < the databases get partially c
On Tue, 15 Oct 2002, Andreas Schmitz wrote:
> I have a problem dumping with 7.2.3. When I do a pg_dumpall redirecting this
> to a file I have >4 lines of schema and data. Running psql template1 <
> the databases get partially created, i.e the schema is completely
> there but data even of
Hello,
I have a problem dumping with 7.2.3. When I do a pg_dumpall redirecting this
to a file I have >4 lines of schema and data. Running psql template1 <
the databases get partially created, i.e the schema is completely
there but data even of the big tables is missing. The dumpfile itse
10 matches
Mail list logo
