The following bug has been logged online:
Bug reference: 2975
Logged by: Steven
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Windows Xp Sp2
Description:UNIQUE INDEX doesn't work
Details:
I have a unique index on a table, but
The following bug has been logged online:
Bug reference: 4626
Logged by: Steven Mezzadri
Email address: smezz...@livonia.k12.mi.us
PostgreSQL version: 8.1.11
Operating system: CentOS 5.2
Description:postgresql recovery problem
Details:
The database for our moodle
The following bug has been logged online:
Bug reference: 5120
Logged by: Steven McLellan
Email address: smclel...@mintel.com
PostgreSQL version: 8.3.x
Operating system: FreeBSD 6.2
Description:Performance difference between running a query with
named cursor and
Sorry for a downer on an excellent piece of software.
--
Darren Steven
Applications Specialist
Networking Tasmania
Telstra Australia
Ph.1800 813 302
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this
-directory (copied all files to
/home/postgres and created a softlink from /var/lib/postgres to
/home/postgres, while postgresql was not running.)
For me this was only a testdatabase, so for me it is not an urgent problem,
but I hope this can be solved.
Steven.
--
Hi All,
I've just compiled and checked version 7.2 of the system on BSDI 4.0 and
have noticed the following errors in the regression.diffs file
! psql: PQconnectPoll() -- couldn't send startup packet: errno=32
! Broken pipe
This is occurring for almost all of the test. Does anyone have any ide
lar errors from bash. I can't see any reason why the fork
would fail however.
I'm not sure it' related, but I thought it worth mentioning. Any suggestions
are welcome.
Regards,
- Steve Nunez
On 4/3/02 4:36, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Steven N=
Is there any way to work around this problem? We no longer have support for
this machine, so will probably not be able to recompile the kernel. Strange
too, that it didn't happen on earlier versions.
Regards,
- Steve Nunez
On 4/3/02 10:15, "Tom Lane" <[EMAIL PROTECTED]&g
That was it. All tests (except random and float8) pass. Thanks very much.
- Steve Nunez
On 4/3/02 13:03, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Steven N=?ISO-8859-1?B?+vE=?=ez wrote:
>> Is there any way to work around this problem? We no longer have suppor
Hi All,
I've just compiled and checked version 7.2 of the system on BSDI 4.0 and
have noticed the following errors in the regression.diffs file
! psql: PQconnectPoll() -- couldn't send startup packet: errno=32
! Broken pipe
This is occurring for almost all of the test. Does anyone have any ide
This time I've included the log file...
su-2.02$ cat postmaster.log
DEBUG: database system was shut down at 2002-03-03 19:43:39 EST
DEBUG: checkpoint record is at 0/109664
DEBUG: redo record is at 0/109664; undo record is at 0/0; shutdown TRUE
DEBUG: next transaction id: 89; next oid: 16556
D
The following bug has been logged online:
Bug reference: 2553
Logged by: Steven Adams
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Red Hat Linux 3.2.3-42
Description:Outer join bug
Details:
Every time I use an outer join as the last
The following bug has been logged online:
Bug reference: 2582
Logged by: Steven Azar
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Linux 2.6.15.6-1.smp.x86.i686.cmov #1 SMP Tue Mar 7
00:18:47 EST 2006 i686 athlon i386 GNU/Linux
Description
de_nr)VALUES ($1,$2,$3,$4,lo_import($5),$6,$7,$8,$9,$10,$11,$12,$13,$14);$BODY$LANGUAGE 'sql' VOLATILE; Already thank you,greetings,Steven Lambert
Postgres 8.2.4.
Would this be considered a bug or is the tablespace info excluded for
a particular reason?
# CREATE TABLESPACE foo_space LOCATION '/some/dir';
# CREATE TABLE foo (a int);
# CREATE INDEX foo_idx ON foo(a) TABLESPACE foo_space;
# SELECT pg_get_indexdef(oid) FROM pg_class WHERE reln
The following bug has been logged online:
Bug reference: 3883
Logged by: Steven Flatt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.1
Description:Autovacuum deadlock with truncate?
Details:
This isn't a postgres deadloc
On 1/17/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > This isn't a postgres deadlock per se, but the end result is that two
> > postgres backends are stuck, each waiting on a PGSemaphoreLock that the
> > other presumably has. The processes have been stuck for hours.
>
> Can you reproduce this
On 1/17/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, that's not what the backtraces say. The autovac process is trying
> to get super-exclusive lock on a buffer (apparently in relation 16783
> --- what is that?). There's no evidence in the stack trace that the
> TRUNCATE process has any conflict
On 1/17/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Do you still have the hung processes available? It would be really
> useful to take a look at the buffer header that the autovac process's
> LockBufferForCleanup() is working on. (In gdb, "f 3" then "p *bufHdr")
Well I just lost the hung processe
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
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
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
The following bug has been logged online:
Bug reference: 3898
Logged by: Steven Flatt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.1
Description:Postgres autovacuum not respecting pg_autovacuum.enabled
= false
Details:
I
On 1/23/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Steven Flatt" <[EMAIL PROTECTED]> writes:
> > I noticed that the Postgres autovacuum process was vacuuming some tables
> > that had enabled = false in pg_autovacuum.
>
> I thin
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
UNSUBSCRIBE
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
The following bug has been logged online:
Bug reference: 1662
Logged by: Steven Mooij
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: i386-pc-linux-gnu, compiled by GCC i386-linux-gcc (GCC)
3.3.5 (Debian 1:3.3.5-12)
Description:Table
The following bug has been logged online:
Bug reference: 2168
Logged by: Steven Mooij
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Linux
Description:45.000.000 records too much?
Details:
Tried to copy the result of a join into another
postgresql 8.0.3 on a 2.6.12 linux kernel.
(Previously i tested with postgresql 7.4.9 on a 2.6.15 kernel.)
I think you will be able to repeat the experiment with this information.
Regards,
Steven
---(end of broadcast)---
TIP 4: Have you searched
Tom Lane wrote:
"Steven Mooij" <[EMAIL PROTECTED]> writes:
testsearch=> insert into t_documentword2 (SELECT document_id,
t_word2.id,
frequency from t_documentword, t_word2 where t_documentword.word =
t_word2.word);
server closed the connection unexpectedly
Seneca Cunningham wrote:
Steven Mooij wrote:
Some additional info. We repeated the test on different hardware with
unfortunately the same result. This is the output of the postgresql
logfile of that experiment:
[log messages about processes kill 9ed]
This time we tested with
ep me on the CC for replies.
I would very much appreciate help tracking this down! Thanks for your time :)
Steven Schlansker
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Aug 19, 2010, at 2:35 PM, Tom Lane wrote:
> Steven Schlansker writes:
>> I'm having a rather annoying problem - a particular string is causing the
>> Postgres COPY functionality to lose a byte, causing data corruption in
>> backups and transferred data.
>
>
On Aug 19, 2010, at 3:24 PM, Tom Lane wrote:
> Steven Schlansker writes:
>>
>> I'm not at all experienced with character encodings so I could
>> be totally off base, but isn't it wrong to ever call isspace(0x85),
>> whatever the result may be, given that
The following bug has been logged online:
Bug reference: 6182
Logged by: Steven Williams
Email address: stwilli...@novell.com
PostgreSQL version: 8.5.3
Operating system: SuSE Linux 11
Description:/etc/init.d/postgresql-8.4 is incomplete for chkconfig
Details
t is only constructed once. This would alleviate
the immediate problem from my viewpoint.
If you would like more information, I do have the problem reproduced here
in a controlled environment and would love nothing more than to test
patches or provide whatever information might be helpful to fix this
POSTGRESQL BUG REPORT TEMPLATE
Your name : Steven Smith
Your email address : [EMAIL
37 matches
Mail list logo
