[BUGS] Default password

Hello, please can you send me the default user and password and how we can find it? Thanks

Re: [BUGS] BUG #3883: Autovacuum deadlock with truncate?

On Jan 21, 2008 3:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > I think we need to make some fixes here, but the fixes would mainly > consist of complaining about the first approach ;-). The second one > is a much safer way to do it. > Second approach looks good. Thanks for all your help! Steve

Re: [BUGS] BUG #3883: Autovacuum deadlock with truncate?

"Steven Flatt" <[EMAIL PROTECTED]> writes: > On Jan 21, 2008 1:24 PM, Tom Lane <[EMAIL PROTECTED]> wrote: >> Well, there's our problem: for some reason PID 7908 has this buffer >> pinned, which is blocking the vacuum. That seems pretty darn odd for >> a process that is about to (try to) truncate t

Re: [BUGS] BUG #3891: Multiple UPDATE doesn't handle UNIQUE constraint correctly

On Mon, Jan 21, 2008 at 08:17:47AM +, Adriaan van Os wrote: > > The following bug has been logged online: > > Bug reference: 3891 > Logged by: Adriaan van Os > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.4 > Operating system: Mac OS X 10.5 > Description:

Re: [BUGS] BUG #3883: Autovacuum deadlock with truncate?

On Jan 21, 2008 1:24 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Well, there's our problem: for some reason PID 7908 has this buffer > pinned, which is blocking the vacuum. That seems pretty darn odd for > a process that is about to (try to) truncate the table. The only way > I can imagine is that

Re: [BUGS] BUG #3883: Autovacuum deadlock with truncate?

On Jan 18, 2008 10:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > Hm, PIN_COUNT_WAITER flag is still set, and refcount = 2 saying there is > still someone else pinning the buffer, so nothing evidently wrong here. > > Could you check PrivateRefCount[14407] in both cores? > Okay, got two new hung proc

Re: [BUGS] BUG #3883: Autovacuum deadlock with truncate?

"Steven Flatt" <[EMAIL PROTECTED]> writes: > (gdb) f 3 > (gdb) p *bufHdr > $1 = {tag = {rnode = {spcNode = 1663, dbNode = 16384, relNode = 16648}, > blockNum = 3}, flags = 70, usage_count = 0, refcount = 2, > wait_backend_pid = 23965, buf_hdr_lock = 0 '\0', buf_id = 501, > freeNext = -2, io

Re: [BUGS] BUG #3881: lo_open leaks memory

Michael Akinde <[EMAIL PROTECTED]> writes: > I use the following script to create a test table. For > /tmp/oidfile.temp, I use "FAQ_farsi" from the PostgreSQL installation > (about 140kb). Okay, I ran this with about 900MB of shared buffers (about as much as I thought I could make it without des

Re: [BUGS] BUG #3881: lo_open leaks memory

Michael Akinde <[EMAIL PROTECTED]> writes: > Some observations: > - With small blobs, the memory usage doesn't blow up in this way. The > problem seems to require "big" blobs (although 140kb isn't really that > much). Ah, that may be the root of the difference in our results --- I was trying wit

Re: [BUGS] BUG #3881: lo_open leaks memory

I updated the database to PostgreSQL 8.2.6, but this does not appear to make any difference. I use the following script to create a test table. For /tmp/oidfile.temp, I use "FAQ_farsi" from the PostgreSQL installation (about 140kb). create table gridvalue (gridoid oid); --delete from gridval

Re: [BUGS] BUG #3892: Invalid week determination

Roman wrote: > > I see in the doc: ( however it does not explain the case ) > > week > The number of the week of the year that the day is in. By definition (ISO > 8601), the first week of a year contains January 4 of that year. (The > ISO-8601 week starts on Monday.) In other words, the first Thur

Re: [BUGS] BUG #3891: Multiple UPDATE doesn't handle UNIQUE constraint correctly

Adriaan van Os wrote: This will cause a UNIQUE violation in de middle of the UPDATE statement, although after completion of the statement there is no such violation. This is not a bug. Although deferred constraints are not yet implemented for Postgres, the docs at

Re: [BUGS] Casting on the limit

Thank you:) I didn't even thought of this case. I am a bit surprised that "::" has higher precedence than negation, but maybe it has some cause. Sorry for sending it to this list. Best regards, Otto 2008/1/21, Heikki Linnakangas <[EMAIL PROTECTED]>: > Ottó Havasvölgyi wrote: > > In 8.2.5: > > >

Re: [BUGS] Casting on the limit

Ottó Havasvölgyi wrote: In 8.2.5: This does not work (out of range): select -32768::int2 But this works: select cast(-32768 as int2); What is the difference between the two syntax in the background? I always thought they are the same. "select -32768::int2" is equal to "select -(32768::int2)"

[BUGS] BUG #3892: Invalid week determination

The following bug has been logged online: Bug reference: 3892 Logged by: Roman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: FC6 Description:Invalid week determination Details: Hello Today is 2007-01-21. select to_char(now(),'WW'

[BUGS] BUG #3891: Multiple UPDATE doesn't handle UNIQUE constraint correctly

The following bug has been logged online: Bug reference: 3891 Logged by: Adriaan van Os Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Mac OS X 10.5 Description:Multiple UPDATE doesn't handle UNIQUE constraint correctly Details: Suppose

Re: [BUGS] Casting on the limit

But 8.2.6 works the same. I have just upgraded. 2008/1/21, Ottó Havasvölgyi <[EMAIL PROTECTED]>: > Sorry, version is 8.2.4 > > 2008/1/21, Ottó Havasvölgyi <[EMAIL PROTECTED]>: > > Hi, > > > > In 8.2.5: > > > > This does not work (out of range): > > select -32768::int2 > > > > But this works: > > s

Re: [BUGS] Casting on the limit

Sorry, version is 8.2.4 2008/1/21, Ottó Havasvölgyi <[EMAIL PROTECTED]>: > Hi, > > In 8.2.5: > > This does not work (out of range): > select -32768::int2 > > But this works: > select cast(-32768 as int2); > > What is the difference between the two syntax in the background? I > always thought they

[BUGS] Casting on the limit

Hi, In 8.2.5: This does not work (out of range): select -32768::int2 But this works: select cast(-32768 as int2); What is the difference between the two syntax in the background? I always thought they are the same. Best regards, Otto ---(end of broadcast)--