The following bug has been logged online:
Bug reference: 4871
Logged by: Sami Kuhmonen
Email address: s...@tokavuh.com
PostgreSQL version: 8.4RC1
Operating system: Windows 7 x64 RC
Description:Cannot install with 1-click installer
Details:
I tried to install RC1 wit
The following bug has been logged online:
Bug reference: 4870
Logged by: Luis angel camacho
Email address: luis141...@hotmail.com
PostgreSQL version: 8.3
Operating system: windows xp de 32 bits
Description:don't start service
Details:
The server doesn't accept conn
Heikki Linnakangas writes:
> Here's a patch implementing the WALWriteAllowed() idea (I'm not wedded
> to the name). There's two things that trouble me with this patch:
I've committed this patch plus the mentioned revisions, along with a
bunch of code review of my own (mostly doctoring comments th
The following bug has been logged online:
Bug reference: 4885
Logged by: Uwe Liebehenz
Email address: liebeh...@mts-software.com
PostgreSQL version: 8.3.7
Operating system: windows xp
Description:OneClickInstaller dont work
Details:
Greetings from Germany!
I have t
Heikki Linnakangas writes:
> It's getting late again, and I'm afraid I have to stop for today :-(.
OK, I'll start from your last patch and see what I can do.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscr
Tom Lane wrote:
> I wrote:
>> Hmm ... this doesn't really feel cleaner to me, although I'm not sure
>> why not.
>
> Oh, I thought of a more concrete point: InRecovery is inherently a
> system-wide state, but XLogInsertAllowed is *not*. While we write
> the EOR checkpoint, we really want only the
"stalker" writes:
> I try to create Check Constraints for DB with Nested Set data model. When I
> write complex validation rule with OR-operator - result Description is
> incorrect.
> ALTER TABLE Catalog
> ADD CONSTRAINT ctg_check_ns CHECK (id_lft > id_rgt OR (id_lft = 0 AND
> id_lft = 0));
>
Tom Lane escribió:
> I wrote:
> > Hmm ... this doesn't really feel cleaner to me, although I'm not sure
> > why not.
>
> Oh, I thought of a more concrete point: InRecovery is inherently a
> system-wide state, but XLogInsertAllowed is *not*. While we write
> the EOR checkpoint, we really want only
The following bug has been logged online:
Bug reference: 4888
Logged by: stalker
Email address: chim...@bk.ru
PostgreSQL version: 8.3.7
Operating system: Debian 4.0 (etch)
Description:Removed brackets from Check Constraints expressions
Details:
I try to create Check
I wrote:
> Hmm ... this doesn't really feel cleaner to me, although I'm not sure
> why not.
Oh, I thought of a more concrete point: InRecovery is inherently a
system-wide state, but XLogInsertAllowed is *not*. While we write
the EOR checkpoint, we really want only the bgwriter to be authorized
to
Heikki Linnakangas writes:
> One idea is to merge LocalWALWriteAllowed and LocalRecoveryInProgress
> (and the corresponding shared variables too) into one XLogState variable
> with three states
> * in-recovery
> * normal operation
> * shutdown.
> The variable would always move from a lower state
Tom Lane wrote:
> Heikki Linnakangas writes:
>> - CreateCheckPoint() calls AdvanceXLInsertBuffer() before setting
>> LocalWALWriteAllowed. I don't see anything in AdvanceXLInsertBuffer()
>> that would fail, but it doesn't feel right. While strictly speaking it
>> doesn't insert new WAL records, it
Heikki Linnakangas writes:
> Here's a patch implementing the WALWriteAllowed() idea (I'm not wedded
> to the name).
I'm not either ... this morning it seems to me that XLogWriteAllowed
(or maybe XLogInsertAllowed?) would be more in keeping with the existing
code names in this area.
> There's two
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I observe that the substantial amount of care we have taken over
>> XLogFlush's handling of bad-input-LSN scenarios has been completely
>> destroyed by the UpdateMinRecoveryPoint patch, which will fail
>> disastrously (leaving the database unstartabl
The following bug has been logged online:
Bug reference: 4887
Logged by: Alexey Bashtanov
Email address: bashta...@imap.cc
PostgreSQL version: 8.3.1, 8.3.7
Operating system: Linux 2.6.20 FC5 i686, Linux 2.6.27 FC10 i686
Description:inclusion operator (@>) on tsqeries
On Fri, Jun 26, 2009 at 1:08 PM, Justin wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4886
> Logged by: Justin
> Email address: justin.br...@navy.mil
> PostgreSQL version: 8.3.7
> Operating system: Windows XP
> Description: Password Crash
> Deta
The following bug has been logged online:
Bug reference: 4886
Logged by: Justin
Email address: justin.br...@navy.mil
PostgreSQL version: 8.3.7
Operating system: Windows XP
Description:Password Crash
Details:
The % sign included in the password field crashes createus
Simon Riggs wrote:
> On Fri, 2009-06-26 at 05:14 +0100, Simon Riggs wrote:
>> On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote:
>
>>> What I am thinking is that instead of the hack of clearing
>>> LocalRecoveryInProgress to allow the current process to write WAL,
>>> we should have a separate tes
Hi,
On Fri, Jun 26, 2009 at 3:22 PM, Heikki
Linnakangas wrote:
> Are you actually seeing performance degradation caused by frequent
> pg_control updates? In the simple test scenarios I've tested, pg_control
> is updated only once every few WAL segments, and this with
> shared_buffer=32MB. With lar
19 matches
Mail list logo
