"Lee McKeeman" writes:
> This may not be the appropriate place to check this, but when I filed
> the bug with the tracking number 4593, in relation to some sort order
> behavior which seemed erroneous to me.
That bug number never came by here --- might've gotten eaten by spam
filters? Anyway, we
Hello,
I have problem with instalation on step 8 (on PostgreSQL Setup
Instructions)-
Initial database cluster.
It´s written there - The Postere SQL data direktory must be on an NTFS
formatted volume. If you wish
to install the data direktory on another type of partition you must
initiali
2009/1/5 Tomáš Dixa :
> Hello,
>
>
>
> I have problem with instalation on step 8 (on PostgreSQL Setup
> Instructions)-
>
> Initial database cluster.
>
>
>
> It´s written there – The Postere SQL data direktory must be on an NTFS
> formatted volume. If you wish
>
> to install the data direktory on an
On Sun, 2009-01-04 at 21:52 +0100, Martin Pitt wrote:
> 11 wakeups per minute is not dramatic, and with
> PostgreSQL being a server application, perfect power management is
> certainly the least concern for you.
Is this 11 per minute, or 11 per second?
> - Forwarded message from Xavier Bes
Tom Lane wrote:
> Alvaro Herrera writes:
> > I think we must blame bgwriter then. I had a look at it some time ago
> > to how hard would it be to remove the useless wakeups and concluded that
> > it wasn't really worth the trouble.
>
> I've got similar complaints in the RH/Fedora bugzilla. It's
On Mon, Jan 5, 2009 at 2:47 PM, Lee McKeeman
wrote:
> I got a "stalled post" message because at the time of filing I was not
> on this list. I don't know when moderators would look at it, and if
> perhaps they deemed that it should not be posted, so it was discarded
> without me being notified.
W
Hi Simon,
Simon Riggs [2009-01-05 12:13 +]:
> Seems consistent with wal_writer_delay = 200ms and bgwriter_delay =
> 200ms, plus some other minor noise.
Ah, thanks.
> So its not a "bug" and won't get "fixed".
Right, it's not a bug in the sense of "does not behave as intended".
Purely a wishl
I got a "stalled post" message because at the time of filing I was not
on this list. I don't know when moderators would look at it, and if
perhaps they deemed that it should not be posted, so it was discarded
without me being notified. I have the text that was generated by the web
form, and can sen
On Mon, 2009-01-05 at 12:21 +0100, Martin Pitt wrote:
> Hi Simon,
>
> Simon Riggs [2009-01-05 10:57 +]:
> > Is this 11 per minute, or 11 per second?
>
> Per second.
Seems consistent with wal_writer_delay = 200ms and bgwriter_delay =
200ms, plus some other minor noise.
So its not a "bug" an
In that case, I will paste what I got back when I entered the bug via
the web form:
- - - - - -
The following bug has been logged online:
Bug reference: 4593
Logged by: Lee McKeeman
Email address: lmckee...@opushealthcare.com
PostgreSQL version: 8.3.4, 8.2.6
Operating system:
Hi Simon,
Simon Riggs [2009-01-05 10:57 +]:
> Is this 11 per minute, or 11 per second?
Per second.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
Hi All,
I have a database that refuses to start due to the afformentioned error. I am
running POstgreSQL 8.1.11 on a Debian Etch box.
Does anyone know what this error means and how to recover from it?
Any help will be very much appreciated.
Thanks,
Val
P.S. Here is the complete output I get
val writes:
> I have a database that refuses to start due to the afformentioned error. I am
> running POstgreSQL 8.1.11 on a Debian Etch box.
> Jan 5 10:36:29 db2 postgres[17111]: [11-1] PANIC: failed to re-find parent
> key in "100924" for split pages 1606/1673
Hmm ... I wonder if this is t
Richard Evans wrote:
I've taken a look at the current development snapshot ane made a new
patch. This is against the snapshot source dated 2008-12-30.
This is now committed.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Mon, 2009-01-05 at 09:03 -0600, Lee McKeeman wrote:
> I did not see anything that indicated to me that order by may not be
> handled properly at the read committed isolation level, so I do believe
> this to be erroneous behavior, and therefore a bug. I have attempted
> this in 8.3.4 and
> 8.2.6
"Lee McKeeman" writes:
> Description:order by is not honored after select ... for update
The reason for this behavior is that SELECT FOR UPDATE substitutes the
latest version of the row at the time the row lock is acquired, which is
the very last step after the selection and ordering have
On Dec 30, 2008, at 4:56 AM, Peter Eisentraut wrote:
Vincent Predoehl wrote:
This is not the config.log file from the run that produced the
warning you are complaining about.
I did run configure several times since the error. I know nothing
of autoconf and didn't know to save the config.lo
The following bug has been logged online:
Bug reference: 4598
Logged by: Radu Buzila
Email address: r...@buzila.com
PostgreSQL version: 8.3
Operating system: Mac OS X (OS not relevant, I'm using the thin JDBC
driver: postgresql-8.3-604.jdbc3.jar)
Description:flaw in h
Tom,
We don't actually select * without a where clause in our actual use
case, I just wrote as concise a test case as I thought I could to
demonstrate the behavior. We have a where clause that limits the rows
that are locked (otherwise we could just do a table lock rather than
using row-level lock
On Mon, 2009-01-05 at 15:42 -0500, Tom Lane wrote:
> The only way to avoid this would be to lock before the sort, which could
> have the effect of locking more rows than are returned (if you also use
> LIMIT);
How would that work in the case of an index scan sort?
Regards,
Jeff Davis
-
Jeff Davis writes:
> On Mon, 2009-01-05 at 15:42 -0500, Tom Lane wrote:
>> The only way to avoid this would be to lock before the sort, which could
>> have the effect of locking more rows than are returned (if you also use
>> LIMIT);
> How would that work in the case of an index scan sort?
It wo
21 matches
Mail list logo
