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
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
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
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
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
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:bgwriter
Philippe Amelant pamel...@companeo.com 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
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
Description:
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
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 startup
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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() run
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 guess
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.
On Thu, Jun 25, 2009 at 3:27 PM, Andreas
Wenka.w...@netzmeister-st-pauli.de 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
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 the
On Thu, 2009-06-25 at 11:31 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Meredith L. Patterson m...@osogato.com 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
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 ways
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
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 was that
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 correct
On Thu, 2009-06-25 at 12:33 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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-bugs
On Thu, 2009-06-25 at 19:37 +0300, Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
This is completely untested still, but does anyone immediately see any
more problems?
Isn't SetForwardFsyncRequests going to cause the final
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Thu, 2009-06-25 at 13:25 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
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 bgwriter
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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 wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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()
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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,
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
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 directed
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Thu, Jun 25, 2009 at 8:38 PM, Dustin Parkerdpar...@forwardslope.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Simon Riggs si...@2ndquadrant.com 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
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,
if
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 normal
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 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/GID
On Thu, 2009-06-25 at 17:11 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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 code
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Thu, 2009-06-25 at 17:17 -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 that fsync
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:
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
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 think
Peter Eisentraut pete...@gmx.net 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Simon Riggs si...@2ndquadrant.com 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
On Thu, 2009-06-25 at 18:40 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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
Simon Riggs si...@2ndquadrant.com 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
On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
William Chu w...@facorelogic.com 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
Chu, William w...@facorelogic.com 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
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Thu, Jun 25, 2009 at 2:29 PM, Peter Eisentraut pete...@gmx.net 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
ajmcello ajmcell...@gmail.com 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
On Fri, Jun 26, 2009 at 1:44 AM, Tom Lanet...@sss.pgh.pa.us 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
On Thu, Jun 25, 2009 at 5:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ajmcello ajmcell...@gmail.com 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
Greg Stark gsst...@mit.edu writes:
On Fri, Jun 26, 2009 at 1:44 AM, Tom Lanet...@sss.pgh.pa.us 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
ajmcello ajmcell...@gmail.com 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
Hi,
Thank you for addressing the problem!
On Fri, Jun 26, 2009 at 7:14 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com 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
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,
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
On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On the patch, the kluge to set InRecovery is unnecessary and confusing.
I'll look into a better way
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
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
We certainly update it an order of magnitude more often than before, but
I don't think that's
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 WALWriteAllowed()
89 matches
Mail list logo
