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 unstartable/unrecoverable) if a
> bogusly la
Fujii Masao wrote:
> On Fri, Jun 26, 2009 at 7:14 AM, Heikki
> Linnakangas wrote:
>> We certainly update it an order of magnitude more often than before, but
>> I don't think that's an issue. We're talking about archive recovery
>> here. It's not like in normal operation where a corrupt pg_control
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 test function WALWriteAllo
On Fri, 2009-06-26 at 10:56 +0900, Fujii Masao wrote:
> Hi,
>
> Thank you for addressing the problem!
>
> On Fri, Jun 26, 2009 at 7:14 AM, Heikki
> Linnakangas wrote:
> > We certainly update it an order of magnitude more often than before, but
> > I don't think that's an issue. We're talking abo
On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> On the patch, the kluge to set InRecovery is unnecessary and confusing.
> >>
> >> I'll look into a better way to do that tonight. Did y
Tom,
What's odd is after the DBA added the proper IP address entries to the
pg_hba.conf I was able to connect properly.
Regards,
Wil
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, June 25, 2009 4:27 PM
To: Chu, William
Cc: pgsql-bugs@postgresql.org
Subject
I wrote:
> ... Never mind that complaint then.
Be advised that I'm going to be on the warpath again in the morning.
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, wh
Hi,
Thank you for addressing the problem!
On Fri, Jun 26, 2009 at 7:14 AM, Heikki
Linnakangas wrote:
> We certainly update it an order of magnitude more often than before, but
> I don't think that's an issue. We're talking about archive recovery
> here. It's not like in normal operation where a c
ajmcello writes:
> The only downside with adding o to tar that I can see is if it isn't
> supported by a non-GNU version of tar.
It's required by the Single Unix Spec
http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html
(although that specifically disallows the ordering "oxf" that you
sugge
Greg Stark writes:
> On Fri, Jun 26, 2009 at 1:44 AM, Tom Lane wrote:
>> Maybe putting "o" into the options in doc/Makefile is a good
>> idea.
> I wonder why we have tarballs inside of tarballs.
That's been complained about before, but getting rid of it is a larger
change than I care to underta
On Thu, Jun 25, 2009 at 5:44 PM, Tom Lane wrote:
> ajmcello writes:
> > # make
> > make -C doc all
> > make[1]: Entering directory `/nfs/fsp1/web/postgresql-8.3.7/doc'
> > gzip -d -c man.tar.gz | /bin/tar xf -
> > /bin/tar: man1/clusterdb.1: Cannot change ownership to uid 258, gid 258:
> > Inval
On Fri, Jun 26, 2009 at 1:44 AM, Tom Lane wrote:
> Maybe putting "o" into the options in doc/Makefile is a good
> idea.
I wonder why we have tarballs inside of tarballs. Why not just have
the files directly in a subdirectory of the install tarball already?
> I'm wondering why we've not had compl
ajmcello writes:
> # make
> make -C doc all
> make[1]: Entering directory `/nfs/fsp1/web/postgresql-8.3.7/doc'
> gzip -d -c man.tar.gz | /bin/tar xf -
> /bin/tar: man1/clusterdb.1: Cannot change ownership to uid 258, gid 258:
> Invalid argument
> /bin/tar: Error exit delayed from previous errors
>
On Thu, Jun 25, 2009 at 2:29 PM, Peter Eisentraut wrote:
> On Friday 26 June 2009 00:04:02 Alfred Monticello wrote:
> > in doc/Makefile, tar is run to extract an archive with xf options. Needs
> > oxf to map to owner of person running tar, otherwise Invalid Argument
> > occurs and the Makefile er
Simon Riggs writes:
> On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>>> On the patch, the kluge to set InRecovery is unnecessary and confusing.
>>
>> I'll look into a better way to do that tonight. Did you have any
>> specific improvement in mind?
> Yes, all already
"Chu, William" writes:
> What's odd is after the DBA added the proper IP address entries to the
> pg_hba.conf I was able to connect properly.
Well, something else must have happened in there...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
"William Chu" writes:
> The following error message occurs when the IP address is not present in the
> pg_hba.conf. The error message is misleading and should actually say
> something to the effect, "Connection refused due to lack of access
> permission".
> java.io.IOException: An SQL exception
On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On the patch, the kluge to set InRecovery is unnecessary and confusing.
>
> I'll look into a better way to do that tonight. Did you have any
> specific improvement in mind?
Yes, all already mentioned on this thread.
Simon Riggs writes:
> On the patch, the kluge to set InRecovery is unnecessary and confusing.
I'll look into a better way to do that tonight. Did you have any
specific improvement in mind?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
The following bug has been logged online:
Bug reference: 4884
Logged by: William Chu
Email address: w...@facorelogic.com
PostgreSQL version: 7.4.5
Operating system: RedHat Enterprise 5.3
Description:Misleading error message
Details:
The following error message occur
On Thu, 2009-06-25 at 18:40 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2009-06-26 at 00:37 +0300, Heikki Linnakangas wrote:
> >> Ok, I've committed the above fixes everyone agreed on.
>
> > At this stage of RC, I expected you to post the patch and have the other
> > 2 people workin
Simon Riggs writes:
> On Fri, 2009-06-26 at 00:37 +0300, Heikki Linnakangas wrote:
>> Ok, I've committed the above fixes everyone agreed on.
> At this stage of RC, I expected you to post the patch and have the other
> 2 people working actively on this issue review it before you commit.
We're goi
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The behavior you seem to have in mind would be completely disastrous
>> from a performance standpoint, as we'd be writing and fsyncing
>> pg_control constantly during a recovery.
> Please define "constantly". We discussed that part of the patch here
Peter Eisentraut writes:
> Are you running the extraction as root user?
As far as I can find, there is no explicit recommendation in the
installation instructions that you not do the build as root.
Perhaps we should add one.
regards, tom lane
--
Sent via pgsql-bugs mail
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> I wouldn't consider that a
>> good idea from a reliability standpoint either --- the more writes to
>> pg_control, the more risk of fatal corruption of that file.
>
> We certainly update it an order of magnitude more often than before, but
> I don't
On Fri, 2009-06-26 at 00:37 +0300, Heikki Linnakangas wrote:
> Ok, I've committed the above fixes everyone agreed on.
Sorry, but I haven't agreed to very much of what you just committed.
There are some unnecessary and confusing hacks that really don't help
anybody sort out why any of this has
Tom Lane wrote:
> The behavior you seem to have in mind would be completely disastrous
> from a performance standpoint, as we'd be writing and fsyncing
> pg_control constantly during a recovery.
Please define "constantly". We discussed that part of the patch here:
http://archives.postgresql.org/m
Heikki Linnakangas writes:
> Simon Riggs wrote:
>> AFAICS the problem Heikki is worried about exists 8.2+. If you stop
>> recovery, edit recovery.conf to an earlier recovery target and then
>> re-run recovery then it is possible that data that would not exist until
>> after the (new) recovery poin
Simon Riggs wrote:
> AFAICS the problem Heikki is worried about exists 8.2+. If you stop
> recovery, edit recovery.conf to an earlier recovery target and then
> re-run recovery then it is possible that data that would not exist until
> after the (new) recovery point has made its way to disk. The co
On Thu, 2009-06-25 at 17:17 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > We do store the minimum recovery point required by the base backup in
> > control file, but it's not advanced once the recovery starts. So if you
> > start recovery, starting from say 123, let it progress to locat
Simon Riggs wrote:
> On Thu, 2009-06-25 at 15:10 -0400, Tom Lane wrote:
>
>> So to summarize the state of play, it seems
>> we have these issues:
>>
>> * need to delete startup process's local pendingOpsTable once bgwriter
>> is launched, so that requests go to bgwriter instead
>
> Need to ensure
On Thu, 2009-06-25 at 17:11 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > So, yes, there are some places where InRecovery is used in code executed
> > by the bgwriter, but the correct fix is to use RecoveryIsInProgress().
>
> Agreed, but this gets us no closer to solving the real problem, whi
On Friday 26 June 2009 00:04:02 Alfred Monticello wrote:
> in doc/Makefile, tar is run to extract an archive with xf options. Needs
> oxf to map to owner of person running tar, otherwise Invalid Argument
> occurs and the Makefile errors out.
>
> A better solution might be to compact postgres as UID
The following bug has been logged online:
Bug reference: 4883
Logged by: Alfred Monticello
Email address: ajmcell...@gmail.com
PostgreSQL version: All
Operating system: Linux
Description:tar xf fails on NFS4 mounts
Details:
in doc/Makefile, tar is run to extract an
On Thu, 2009-06-25 at 22:29 +0300, Heikki Linnakangas wrote:
> Hmm, I see another small issue. We now keep track of the "minimum
> recovery point". Whenever a data page is flushed, we set minimum
> recovery point to the LSN of the page in XLogFlush(), instead of
> fsyncing WAL like we do in norma
Heikki Linnakangas writes:
> We do store the minimum recovery point required by the base backup in
> control file, but it's not advanced once the recovery starts. So if you
> start recovery, starting from say 123, let it progress to location 456,
> kill recovery and start it again, but only let it
Simon Riggs writes:
> So, yes, there are some places where InRecovery is used in code executed
> by the bgwriter, but the correct fix is to use RecoveryIsInProgress().
Agreed, but this gets us no closer to solving the real problem, which is
that when we perform the end-of-recovery checkpoint, we
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> I would like an explanation of why minimum recovery point needs to
>>> be advanced at all. If there's any use for it, it is surely part
>>> of functionality that is not there in 8.4.
>
>> It gives protection against starting up
On Thu, 2009-06-25 at 22:29 +0300, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > While nosing around the problem areas, I think I've found yet another
> > issue here. The global bool InRecovery is only maintained correctly
> > in the startup process, which wasn't a problem before 8.4. However,
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I would like an explanation of why minimum recovery point needs to
>> be advanced at all. If there's any use for it, it is surely part
>> of functionality that is not there in 8.4.
> It gives protection against starting up the database too early.
On Thu, Jun 25, 2009 at 8:38 PM, Dustin Parker wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4882
> Logged by: Dustin Parker
> Email address: dpar...@forwardslope.com
> PostgreSQL version: 8.3.7
> Operating system: Windows XP Professional, SP3
> Descri
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> Actually, what in the world is the purpose of that code at all?
>
>> Huh? The only other place where we advance minimum recovery point is
>> CreateRestartPoint() when we skip the restartpoint. The
>> UpdateMinRecoveryPoint() call
On Thu, 2009-06-25 at 15:10 -0400, Tom Lane wrote:
> So to summarize the state of play, it seems
> we have these issues:
>
> * need to delete startup process's local pendingOpsTable once bgwriter
> is launched, so that requests go to bgwriter instead
Need to ensure that fsync requests are direc
The following bug has been logged online:
Bug reference: 4882
Logged by: Dustin Parker
Email address: dpar...@forwardslope.com
PostgreSQL version: 8.3.7
Operating system: Windows XP Professional, SP3
Description:One-click installer crashes with certain service account
Heikki Linnakangas writes:
> Tom Lane wrote:
>> We would want the end-of-recovery checkpoint to act like it's not in
>> recovery anymore for this purpose, no?
> For the purpose of updating min recovery point, we want it to act like
> it *is* still in recovery.
Well, without a clear explanation o
On Thu, 2009-06-25 at 15:10 -0400, Tom Lane wrote:
> Are you (Heikki and Simon) in a position to finish these things today?
Certainly will try.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> ... I think it might be better to fix
>>> things so that InRecovery is maintained correctly in the bgwriter too.
>
>> We could set InRecovery=true in CreateCheckPoint if it's a startup
>> checkpoint, and reset it afterwards. I'm
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Actually, what in the world is the purpose of that code at all?
> Huh? The only other place where we advance minimum recovery point is
> CreateRestartPoint() when we skip the restartpoint. The
> UpdateMinRecoveryPoint() call in XLogFlush() is what w
Tom Lane wrote:
> I wrote:
>> Heikki Linnakangas writes:
>>> Hmm, I see another small issue. We now keep track of the "minimum
>>> recovery point". Whenever a data page is flushed, we set minimum
>>> recovery point to the LSN of the page in XLogFlush(), instead of
>>> fsyncing WAL like we do in no
I wrote:
> Heikki Linnakangas writes:
>> Hmm, I see another small issue. We now keep track of the "minimum
>> recovery point". Whenever a data page is flushed, we set minimum
>> recovery point to the LSN of the page in XLogFlush(), instead of
>> fsyncing WAL like we do in normal operation.
> We w
Heikki Linnakangas writes:
> Tom Lane wrote:
>> ... I think it might be better to fix
>> things so that InRecovery is maintained correctly in the bgwriter too.
> We could set InRecovery=true in CreateCheckPoint if it's a startup
> checkpoint, and reset it afterwards. I'm not 100% sure it's safe t
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Here's a patch taking that approach, and I think it's better than the
>> previous one. I was afraid we would lose robustness if we have to set
>> the shared state as "out of recovery" before requesting the checkpoint,
>> but we can use the same tric
Tom Lane wrote:
> +1, I think that's okay. So to summarize the state of play, it seems
> we have these issues:
>
> * need to delete startup process's local pendingOpsTable once bgwriter
> is launched, so that requests go to bgwriter instead
>
> * need to push end-of-recovery checkpoint into bgwr
Tom Lane wrote:
> While nosing around the problem areas, I think I've found yet another
> issue here. The global bool InRecovery is only maintained correctly
> in the startup process, which wasn't a problem before 8.4. However,
> if we are making the bgwriter execute the end-of-recovery checkpoin
Heikki Linnakangas writes:
> Tom Lane wrote:
>> On the other point: are we going to eliminate mdunlink's isRedo
>> parameter? Maybe the better thing is to have its callers pass the value
>> of InArchiveRecovery?
> I think my initial analysis of this bug was bogus. There's nothing wrong
> with md
On Thu, 2009-06-25 at 21:59 +0300, Heikki Linnakangas wrote:
> I think my initial analysis of this bug was bogus.
Perhaps, but the pendingOpsTable issue is a serious one, so we haven't
wasted our time by fixing it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services an
While nosing around the problem areas, I think I've found yet another
issue here. The global bool InRecovery is only maintained correctly
in the startup process, which wasn't a problem before 8.4. However,
if we are making the bgwriter execute the end-of-recovery checkpoint,
there are multiple pl
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Here's a patch taking that approach, and I think it's better than the
>> previous one. I was afraid we would lose robustness if we have to set
>> the shared state as "out of recovery" before requesting the checkpoint,
>> but we can use the same tric
On Thu, 2009-06-25 at 14:46 -0400, Tom Lane wrote:
> On the other point: are we going to eliminate mdunlink's isRedo
> parameter? Maybe the better thing is to have its callers pass the value
> of InArchiveRecovery?
We have one caller that is using a parameter incorrectly. It seems we
should cor
Heikki Linnakangas writes:
> Here's a patch taking that approach, and I think it's better than the
> previous one. I was afraid we would lose robustness if we have to set
> the shared state as "out of recovery" before requesting the checkpoint,
> but we can use the same trick we were using in sta
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Simon Riggs wrote:
>>> On Thu, 2009-06-25 at 12:43 -0400, Tom Lane wrote:
What about "revert the patch"?
>>> That's probably just as dangerous.
>
>> I don't feel comfortable either reverting such a big patch at last
>> minute.
>
> Yeah, I'm no
Simon Riggs wrote:
> On Thu, 2009-06-25 at 13:25 -0400, Tom Lane wrote:
>> I looked through the callers of smgrdounlink(), and found that
>> FinishPreparedTransaction passes isRedo = true. I'm not sure at the
>> moment what the reasoning behind that was, but it does seem to mean that
>> checking I
On Thu, 2009-06-25 at 13:25 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > It's tempting to just remove the "!isRedo" condition, but then we have
> > another problem: if bgwriter hasn't been started yet, and the shmem
> > queue is full, we get stuck in register_unlink() trying to send th
Heikki Linnakangas writes:
> Simon Riggs wrote:
>> On Thu, 2009-06-25 at 12:43 -0400, Tom Lane wrote:
>>> What about "revert the patch"?
>>
>> That's probably just as dangerous.
> I don't feel comfortable either reverting such a big patch at last
> minute.
Yeah, I'm not very happy with that eit
Heikki Linnakangas writes:
> It's tempting to just remove the "!isRedo" condition, but then we have
> another problem: if bgwriter hasn't been started yet, and the shmem
> queue is full, we get stuck in register_unlink() trying to send the
> message and failing.
> In archive recovery, we always s
Simon Riggs wrote:
> On Thu, 2009-06-25 at 12:43 -0400, Tom Lane wrote:
>
>> What about "revert the patch"?
>
> That's probably just as dangerous.
I don't feel comfortable either reverting such a big patch at last
minute. Would need a fair amount of testing to make sure that the
revertion is cor
On Thu, 2009-06-25 at 12:43 -0400, Tom Lane wrote:
> What about "revert the patch"?
That's probably just as dangerous.
Much easier to just avoid that state altogether, if you must.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bu
On Thu, 2009-06-25 at 19:37 +0300, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> This is completely untested still, but does anyone immediately see any
> >> more problems?
> >
> > Isn't SetForwardFsyncRequests going to cause the final mdsync to fail?
>
> Yes, I
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Isn't SetForwardFsyncRequests going to cause the final mdsync to fail?
> Yes, I just noticed that myself, testing it for the first time. That
> check needs to be suppressed in the startup checkpoint.
Ugh. Better would be to move the responsibility
On Thu, 2009-06-25 at 12:33 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > This is completely untested still, but does anyone immediately see any
> > more problems?
>
> Isn't SetForwardFsyncRequests going to cause the final mdsync to fail?
Yes it will, as it is now.
I didn't read the
Tom Lane wrote:
> Heikki Linnakangas writes:
>> This is completely untested still, but does anyone immediately see any
>> more problems?
>
> Isn't SetForwardFsyncRequests going to cause the final mdsync to fail?
Yes, I just noticed that myself, testing it for the first time. That
check needs to
Heikki Linnakangas writes:
> This is completely untested still, but does anyone immediately see any
> more problems?
Isn't SetForwardFsyncRequests going to cause the final mdsync to fail?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
On Thu, 2009-06-25 at 19:20 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >
> But we need to set LocalRecoveryInProgress appropriately
> > also.
>
> Yeah, the trouble is to tell bgwriter that it's OK for it to create the
> checkpoint, which includes writing a WAL record, while still ke
Simon Riggs wrote:
> On Thu, 2009-06-25 at 18:12 +0300, Heikki Linnakangas wrote:
>
>> A short fix would be to have bgwriter do the shutdown checkpoint instead
>> in archive recovery. I don't recall if there was a reason it wasn't
>> coded like that to begin with, though.
>
> I think the problem
On Thu, 2009-06-25 at 18:57 +0300, Heikki Linnakangas wrote:
> I came up with the attached patch, which includes Simon's patch to
> have all fsync requests forwarded to bgwriter during archive recovery.
> To fix the startup checkpoint issue, startup process requests a forced
> restartpoint, which
On Thu, 2009-06-25 at 18:12 +0300, Heikki Linnakangas wrote:
> A short fix would be to have bgwriter do the shutdown checkpoint instead
> in archive recovery. I don't recall if there was a reason it wasn't
> coded like that to begin with, though.
I think the problem was that it was coded both wa
"Meredith L. Patterson" writes:
> Magnus Hagander wrote:
>> We might want to consider using a safer hash for the password storage at
>> some point, but from what I gather it's not really urgent for *that* use.
>>
> It would be a lot more urgent if we weren't salting, but IIRC we are.
I don't rea
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Heikki Linnakangas wrote:
>>> Hmm, what happens when the startup process performs a write, and
>>> bgwriter is not running? Do the fsync requests queue up in the shmem
>>> queue until the end of recovery when bgwriter is launched? I guess I'll
>>> ha
On Thu, 2009-06-25 at 11:31 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Heikki Linnakangas wrote:
> >> Hmm, what happens when the startup process performs a write, and
> >> bgwriter is not running? Do the fsync requests queue up in the shmem
> >> queue until the end of recovery when b
On Thu, 2009-06-25 at 17:02 +0300, Heikki Linnakangas wrote:
> I think the real problem is this in mdunlink():
>
> > /* Register request to unlink first segment later */
> > if (!isRedo && forkNum == MAIN_FORKNUM)
> > register_unlink(rnode);
>
> When we replay the unlink of
Heikki Linnakangas writes:
> Heikki Linnakangas wrote:
>> Hmm, what happens when the startup process performs a write, and
>> bgwriter is not running? Do the fsync requests queue up in the shmem
>> queue until the end of recovery when bgwriter is launched? I guess I'll
>> have to try it out...
>
On Thu, Jun 25, 2009 at 3:27 PM, Andreas
Wenk wrote:
>
> I am running a Kubuntu 9.04 Jaunty OS. I wanted to check out the one click
> installer from http://www.enterprisedb.com/getfile.jsp?fileid=570 - the file
> is postgresql-8.4.0-rc1-1-linux.bin. Downloaded 2009-06-18 00:09. The
> installation p
Tom Lane wrote:
> Heikki Linnakangas writes:
>> In archive recovery, we always start bgwriter at the beginning of WAL
>> replay. In crash recovery, we don't start bgwriter until the end of wAL
>> replay. So we could change the "!isRedo" condition to
>> "!InArchiveRecovery". It's not a very clean s
On Thu, 2009-06-25 at 17:35 +0300, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Hmm, what happens when the startup process performs a write, and
> > bgwriter is not running? Do the fsync requests queue up in the shmem
> > queue until the end of recovery when bgwriter is launched? I gu
On Thu, 2009-06-25 at 12:55 +, Fujii Masao wrote:
> The restartpoint by bgwriter in recovery mode caused the following error.
>
> ERROR: could not fsync segment 0 of relation base/11564/16422_fsm: No
> such file or directory
I think I see a related bug also.
register_dirty_segment() r
Heikki Linnakangas writes:
> In archive recovery, we always start bgwriter at the beginning of WAL
> replay. In crash recovery, we don't start bgwriter until the end of wAL
> replay. So we could change the "!isRedo" condition to
> "!InArchiveRecovery". It's not a very clean solution, but it's simp
Heikki Linnakangas wrote:
> Hmm, what happens when the startup process performs a write, and
> bgwriter is not running? Do the fsync requests queue up in the shmem
> queue until the end of recovery when bgwriter is launched? I guess I'll
> have to try it out...
Oh dear, doesn't look good. The star
The following bug has been logged online:
Bug reference: 4881
Logged by: Andreas Wenk
Email address: a.w...@netzmeister-st-pauli.de
PostgreSQL version: 8.4 RC1
Operating system: Linux Kubuntu 9.04 Jaunty
Description:KDE 4.2 not running any more when installing one cli
Simon Riggs wrote:
> On Thu, 2009-06-25 at 12:55 +, Fujii Masao wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 4879
>> Logged by: Fujii Masao
>> Email address: masao.fu...@gmail.com
>> PostgreSQL version: 8.4dev
>> Operating system: RHEL5.1 x86_64
"Philippe Amelant" writes:
> In the first case you have a month with 31 days and in the second you
> have a month with 30 days
The interval comparisons have no way to know that, so they arbitrarily
assume that '1 month' is equivalent to '30 days'. This isn't going to
be changed. If you don't li
On Thu, 2009-06-25 at 12:55 +, Fujii Masao wrote:
> The following bug has been logged online:
>
> Bug reference: 4879
> Logged by: Fujii Masao
> Email address: masao.fu...@gmail.com
> PostgreSQL version: 8.4dev
> Operating system: RHEL5.1 x86_64
> Description:bgwr
The following bug has been logged online:
Bug reference: 4879
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: 8.4dev
Operating system: RHEL5.1 x86_64
Description:bgwriter fails to fsync the file in recovery mode
Details:
The restartpo
Noone's answered this. I'd really like to install Postgres on my work station.
-Original Message-
From: Dave Page [mailto:dp...@pgadmin.org]
Sent: Friday, May 15, 2009 5:00 AM
To: Krimstock, Roger I (Roger)
Cc: Pg Bugs; Magnus Hagander
Subject: Re: [BUGS] BUG #4785: Installation fai
The problem is the definition of a month. That can be 28, 29, 30 or 31
days. This is what the manual says about age():
age(timestamp, timestamp)
interval
Subtract arguments, producing a "symbolic" result that uses years and
months
So, it's just a symbolic age, not an exact age. The same occu
Le jeudi 25 juin 2009 à 11:40 +0200, Frank Heikens a écrit :
> select
> age(
> '2009-06-23 18:36:05.064066+02' ,
> '2009-05-12 18:36:05.064066+02') ;
>
> Result: "1 mon 11 days"
>
> select justify_interval('1000 hours');
>
> Result: "1 mon 11 days 16:00:00"
>
>
select
age(
'2009-06-23 18:36:05.064066+02' ,
'2009-05-12 18:36:05.064066+02') ;
Result: "1 mon 11 days"
select justify_interval('1000 hours');
Result: "1 mon 11 days 16:00:00"
select
age(
'2009-06-23 18:36:05.064066+02' ,
The following bug has been logged online:
Bug reference: 4878
Logged by:
Email address: pamel...@companeo.com
PostgreSQL version: 8.2.4, 8.3.6
Operating system: linux
Description:function age() give a wrong interval
Details:
age() report a wrong interval in some ca
97 matches
Mail list logo
