> You did say you tried already on Linux, right? Which version exactly?
Red Hat Linux release 7.2 (Enigma)
Kernel 2.4.7-10
> Can someone try the experiment on some *BSD platform? Three
> data points would make me reasonably comfortable that it doesn't fail on
> Unixen, and then I'll say Cy
Claudio Natoli <[EMAIL PROTECTED]> writes:
> As an attempt at quantification, I'll say this. We are currently using a
> test file with about 5000 pairs of create/drop. It (almost?) never makes it
> through a pass of this file. Your mileage may vary.
FWIW, I ran 1 create/drop pairs through 7.3.
> > where test.sql is a file composed of many, many thousands
> of the following pair of statements:
> > create table dud_table (f integer);
> > drop table dud_table;
> > Invariably, after some period of time, the second
> connection (B) will
> > hang.
>
> It would help if you would qua
[EMAIL PROTECTED] writes:
> where test.sql is a file composed of many, many thousands of the following pair of
> statements:
> create table dud_table (f integer);
> drop table dud_table;
> Invariably, after some period of time, the second connection (B) will
> hang.
It would help if y
Claudio Natoli ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Client connection to postgresql hangs indefinitely (under possibly pathological
scenarios)
Long Description
Configuration
=
WinNT 4.0.0 (build 1381 w/
Daniel Rubio <[EMAIL PROTECTED]> writes:
> Yes, there's a core in the data directory, here is the stack trace:
> bash-2.03# pstack /apps/pgsql-7.3.2/data/core
> core '/apps/pgsql-7.3.2/data/core' of 6308:
> /apps/pgsql-7.3.2/bin/postmaster -D /apps/pgsql-7.3.2/da
> 00123e24 user_group_bsearch_cm
On Fri, 2003-03-28 at 16:06, himansu biswal wrote:
> hi,
> i tried to execute psql template1.i got the problem
> below.plz help me out.
>
> [EMAIL PROTECTED] /]# su jat -
> [EMAIL PROTECTED] /]$ whoami
> jat
> [EMAIL PROTECTED] /]$ psql template1
> psql: FATAL 1: user "jat" does not exist
Postgr
Hi,
Everything my server output this message error:
DEBUG: query: update gn_anuncio set
qtdclk=qtdclk +1 where codanu=196789DEBUG:
CommitTransactionCommand/iG/dbms/postgres/bin/postmaster: BackendStartup:
pid 1136 user producao db producao socket 5FindExec: found
"/iG/dbms/postgres/bin
hi,
i tried to execute psql template1.i got the problem
below.plz help me out.
[EMAIL PROTECTED] /]# su jat -
[EMAIL PROTECTED] /]$ whoami
jat
[EMAIL PROTECTED] /]$ psql template1
psql: FATAL 1: user "jat" does not exist
thank you.
regards,
himansu
Hi,
The server (IBM) is one year old (I think).
Anyway, I found something like a workaround:
If I vacuum before executing my index script (after my loading
script has terminated), or after other huge data movements, the server
doesn't crash. So, is this typical for hardware failures?
Thanks,
hello,
im using PostgreSQL 7.3.1 on i686-pc-linux-gnu,
compiled by GCC 2.96.
i have a suggestion for the name of this DBMS, and
that it should not be PostgreSQL but it should be
PregreSQL, as im feeling its a DBMS that perhaps might
be used 100 years ago,,proof for this is its
techniques for showin
On Sun, 2003-03-30 at 19:20, Bruce Momjian wrote:
> The issue was that you might want to increase server logging in certain
> clients to help debug a problem.
That seems a little obscure to me -- IMHO it's not really worth adding
additional GUC complexity to account for it. Why not just use SUSET,
Andre Hackmann <[EMAIL PROTECTED]> writes:
> If I vacuum before executing my index script (after my loading
> script has terminated), or after other huge data movements, the server
> doesn't crash. So, is this typical for hardware failures?
Hm. If you can reproduce the problem on demand, I'd b
13 matches
Mail list logo
