Mark Gibson wrote:
AIX hasn't had any maintence levels applied yet,
so oslevel -r returns: 5300-01.
_SS_MAXSIZE has been set to 1025 manually, this was
required for 8.0.4.
But with 8.1.0 the patch for dynahash.c had to be
applied before the regression tests would run.
So the problem described in
At 4:09 PM -0500 11/9/05, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
I've been running the setup on 8.1b3 and 8.1RC1 without this
particular Assertion failure, but had not been using the NOWAIT flag
until today. During a period of perhaps 20 processes operating on
the queue
Joel Stevenson <[EMAIL PROTECTED]> writes:
> I've been running the setup on 8.1b3 and 8.1RC1 without this
> particular Assertion failure, but had not been using the NOWAIT flag
> until today. During a period of perhaps 20 processes operating on
> the queue it looks like postgres failed this ass
Joel Stevenson <[EMAIL PROTECTED]> writes:
> (gdb) p *CurrentTransactionState
> $3 = {transactionId = 1068154, subTransactionId = 1, name = 0x0,
> savepointLevel = 0,
>state = TRANS_ABORT, blockState = TBLOCK_ABORT, nestingLevel = 1,
>curTransactionContext = 0x9b06a9c, curTransactionOwner
At 3:24 PM -0500 11/9/05, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
Thanks Tom, and apologies for the confusion; not having worked w/gdb
before I was invoking it incorrectly. Here's what the core file
produced from the assertion failure has for a backtrace:
OK, now that th
Joel Stevenson <[EMAIL PROTECTED]> writes:
> Thanks Tom, and apologies for the confusion; not having worked w/gdb
> before I was invoking it incorrectly. Here's what the core file
> produced from the assertion failure has for a backtrace:
OK, now that that's straightened out, there are some mor
Thanks Tom, and apologies for the confusion; not having worked w/gdb
before I was invoking it incorrectly. Here's what the core file
produced from the assertion failure has for a backtrace:
$ gdb ./bin/postgres data/core.20633
(gdb) bt
#0 0x00138eff in raise () from /lib/tls/libc.so.6
#1 0x0
Joel Stevenson <[EMAIL PROTECTED]> writes:
> This produced a bunch of core files that show the following backtrace:
> #0 0x001ea038 in ?? ()
> #1 0xbfffa4d8 in ?? ()
> #2 0xbfffa5e0 in ?? ()
> #3 0xbfffa560 in ?? ()
> #4 0x08180844 in ?? ()
> #5 0x0005 in ?? ()
> #6 0xbfffa4e0 in ?? ()
At 11:42 AM -0500 11/9/05, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
gdb's 'bt' on one of the core files produces:
#0 0x00138eff in ?? ()
#1 0x0017ec8d in ?? ()
#2 0x00246cd8 in ?? ()
#3 0x in ?? ()
This looks like you have a "stripped" executable, which is
A backtrace from one of the cores would be a good start.
On Wed, Nov 09, 2005 at 07:44:01AM -0800, Joel Stevenson wrote:
> Sorry, I realize this bug is a little lean on details.
>
> PG is set up to serve multiple concurrent processes in a work queue
> fashion, therefore these processes are in co
Sorry, I realize this bug is a little lean on details.
PG is set up to serve multiple concurrent processes in a work queue
fashion, therefore these processes are in contention for the same
resources as the queue is basically a FIFO and I'm using SELECT ...
FOR UPDATE NOWAIT in each client to g
"Joel Stevenson" <[EMAIL PROTECTED]> writes:
I'm running into an Assertion failure this morning w/8.1.0. I believe it is
related to using the NOWAIT flag. Here is the log message:
TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) != ((TransactionId)
0))
: ((MyProc->xmin) != ((Tr
"Joel Stevenson" <[EMAIL PROTECTED]> writes:
> I'm running into an Assertion failure this morning w/8.1.0. I believe it is
> related to using the NOWAIT flag. Here is the log message:
> TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) != ((TransactionId)
> 0))
> : ((MyProc->xmin) != ((T
"Tom" <[EMAIL PROTECTED]> writes:
> GRANT usage on SCHEMA usermgr to g_usermgr_use;
> GRANT select on table a to g_usermgr;
> GRANT select on table b to g_usermgr;
Perhaps you meant to grant those select privileges to g_usermgr_use ?
Also, are you sure you were granting privileges on usermgr.a, a
The following bug has been logged online:
Bug reference: 2033
Logged by: Joel Stevenson
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: RHEL 3 update 6
Description:Assertion Failure: File: "procarray.c", Line: 492
Details:
Hi,
I'm runni
Sorry bub I have two different pc with the same problem.
What I'm doing wrong?
Thanks in advance
PostgreSQL 8.1 on Windows XP SP2 ITA
update from 8.0.4:
- backup previous data
- uninstall and erased PostgreSQL 8.0.4 directory
- rebooted system
- trying install 8.1, but on initdb ...
The files b
Using "char*" as an argument type instead of "const char*" in ecpglib.h
causes that for example the following sample program, basically
copied from docmentation
http://www.postgresql.org/docs/8.1/interactive/ecpg-dynamic.html ,
does not compile using "gcc-4.0.1":
test.pgc
#include
Title: Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited").
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cristiano
AnsaloniSent: 08 November 2005 15:35To:
pgsql-bugs@postgresql.orgSubject: [BUGS] Ps
The following bug has been logged online:
Bug reference: 2029
Logged by: Antonio
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: windows
Description:Error descriptions appear untranslated
Details:
Problem:
- Using Access 2000 connected via
The following bug has been logged online:
Bug reference: 2030
Logged by: Dragon
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: windows
Description:Chinese character support error
Details:
When I install postgresql server,I can not find th
Title: Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited").
Psql odbc driver version 8.01.01.00 doesn't remember "Cache size" option if it is set to 0 (to set "unlimited").
Instead, the "Maximum rows to retrieve" option in the Tab
The following bug has been logged online:
Bug reference: 2032
Logged by: Tom
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: win2k
Description:grant role bug
Details:
I've two login-roles ( usermgr, enduser ) each with a separate schema. I
"Maneesh Sharma" <[EMAIL PROTECTED]> writes:
> I am trying to install
> postgres8.0.4 on Linux but at tar command it is giving error every time.
It looks to me like you got an incomplete download.
> I also tried to downpload postgres file on different mirror sites but no
> change in error.
Maybe
The following bug has been logged online:
Bug reference: 2031
Logged by: Mark Gibson
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: AIX 5.3 (5300-01)
Description:Patch also required prior to ML3
Details:
Hello,
I've just downloaded and
24 matches
Mail list logo