, Andres.
>
> Are there any plans to commit this patch and what version it is going
> to be done to?
>
> Thank you.
I'll be committing this soon, since we're likely coming up to the next
point release soon.
Thanks for the reminder.
--
Simon Riggs http://www
ly tuned, as yet. Some room
for improvement exists.
In some cases, conscious choices were made to keep processing on
master fast at the expense of speed on the standby.
There doesn't seem to be anything which is in itself an error here.
--
Simon Riggs http://www.2ndQuadrant
On 27 May 2013 15:31, Tom Lane wrote:
> Simon Riggs writes:
>> On 26 May 2013 17:10, Tom Lane wrote:
>>> More readable would be to invent an intermediate nonterminal falling
>>> between ColId and ColLabel, whose expansion would be "IDENT |
>>&
o many people are
bothered, since no complaints in 3 years. Documenting 'binary' seems
better.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
{
> + $$ = makeDefElem($1, (Node *)
> makeString("binary"));
> + }
So, no that doesn't work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
n for that suggestion is that nobody ever
reported this bug, so either few people use binary mode or they use
the old syntax. Of course, that is not a normal suggestion, so feel
free to walk up and down my spine with boots on for suggesting it.
Thoughts?
--
Simon Riggs http://
an take some time till we reach consistency it seems rather plausible
> that there now will be a gap in initilized pages. From
> checkPoint.oldestActiveXid to running->nextXid if there are pages
> inbetween.
That was an old bug.
StartupSUBTRANS() now explicitly fills th
st simply mistyped the coordinates...
sriggs=# select point( polygon '((0,0),(0,1),(1,1),(1,0))');
point
---
(0.5,0.5)
(1 row)
Your last point is a duplicate of the 2nd point, so you have a
4-pointed triangle and hence a strange centre.
--
Simon Riggs http://
; NOREPLICATION allows neither option
>>
> Someone is working for it already ?
> If not yet, may I try to implement it ?
Please do. It looks fairly short.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-
nly
NOREPLICATION allows neither option
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> this.
Connection from a standby is disabled by default. Don't enable it...
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make cha
initdb install:
>
> shared_buffers = 8GB
> work_mem = 64MB
> maintenance_work_mem = 256MB
> max_stack_depth = 8MB
> wal_level = hot_standby
> synchronous_commit = off
> wal_buffers = 64MB
> checkpoint_segments = 10
> checkpoint_completion_target = 0
> max_wal_senders =
ackup_label, that prevents normal
> startup before the issue is resolved?
Yes, I've thought about allowing recovery to skip corrupt indexes, but
that feature hasn't been implemented yet.
We'd need to track such things as recovery proceeds and then mark them
as invalid
ely that we'd find out it is significant than
> that we'd find out anybody could detect the lack of a memory barrier
> there.
Agreed. And any future logic to stop at a specific point will be
exactly precise because the decision and action will be taken in same
process.
Patch l
On 5 December 2012 21:15, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 December 2012 18:48, Tom Lane wrote:
>>> On further thought, it seems like recovery_pause_at_target is rather
>>> misdesigned anyway, and taking recovery target parameters from
>>> recov
On 5 December 2012 18:48, Tom Lane wrote:
> I wrote:
>> Andres Freund writes:
>>> On 2012-12-05 17:24:42 +, Simon Riggs wrote:
>>>> So ISTM that we should make recoveryStopsHere() return false while we
>>>> are inconsistent. Problems solved.
>
On 5 December 2012 17:17, Simon Riggs wrote:
> The recovery target and the consistency point are in some ways in
> conflict. If the recovery target is before the consistency point there
> is no point in stopping there, whether or not we pause. What we should
> do is say "recove
n about whether to continue applying WAL. As Simon
> mentioned, we seem to be lacking some infrastructure that would let
> the user adjust the recovery_target parameters before resuming WAL
> processing. But, assuming for the moment that our workaround for
> that is "shutdown t
with things.
You can, but by shutting down server, updating recovery target, then
restarting server.
That's not a beautiful design, its just waiting for someone to make
recovery targets changeable, which is best done when recovery.conf
parameters are in postgresql.conf
--
Simon Riggs
On 5 December 2012 13:34, Simon Riggs wrote:
> Aboriginal bug extends back to 9.0.
I don't see any bug in 9.0 and 9.1, just 9.2+
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs
ke the attached.
I've reworked pause logic along the lines you suggest. Attached here
for further discussion.
> This is not a regression because the pause logic is broken this same
> way since 9.1. So I no longer think that we need a rewrap.
I think we do need a rewrap, si
So there's
> something wrong/incomplete about that fix.
>
> This is a bit urgent since we now have to consider whether to withdraw
> 9.2.2 and issue a hasty 9.2.3. Do we have a regression here since
> 9.2.1, and if so how bad is it?
I'll look at this now.
--
Si
On 2 December 2012 16:44, Tom Lane wrote:
> Simon Riggs writes:
>> On 2 December 2012 15:25, Tom Lane wrote:
>>> This coding was ill-considered from the word go.
>
>> Agreed, but then I don't have a clear reason why it is that way and
>> yet I'm sur
t it needs to
> change.
OK. At least we have the minimal coding to fall back on if need be.
> This coding was ill-considered from the word go.
Agreed, but then I don't have a clear reason why it is that way and
yet I'm sure I did it for some reason.
--
Simon Riggs
On 2 December 2012 12:51, Simon Riggs wrote:
> On 1 December 2012 22:56, Tom Lane wrote:
>> tar...@gmail.com writes:
>>> [ txid_current can show a bogus value near XID wraparound ]
>>> This happens only if wal_level=hot_standby.
>>
>> I bel
ed to
be solved in the right way, not by having a too-far-forwards nextxid
on the checkpoint record. Having said that, I can't see any bugs that
would be caused by this.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Servi
t particular coding was pretty weird. Please change.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 27 September 2012 22:29, Simon Riggs wrote:
> On 26 September 2012 22:33, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7572
>> Logged by: Daniele Varrazzo
>> Email address: daniele.varra...@gmail
scanning N rows with LIMIT M we must assume that the action
relates in some way to N, rather than assuming the LIMIT is more and
more effective as N/M increases.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s the reported lag in flush location merely an artifact
> of timing in the query, or is there something else going on? [1]
The writing of new WAL is independent of the wait that occurs on
commit, so it is entirely possible, even desirable, that the observed
effect occurs.
--
Simon Rigg
swapping the
> table in the system catalog but I'm not sure about that yet.
This one is mine I don't think its important we hold that lock,
but will check.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & S
build farm that anybody can join, no fees,
no restrictions.
http://www.pgbuildfarm.org/cgi-bin/register-form.pl
Community assistance would be available to help.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent vi
e a popular question. OTOH, we don't mention "tuned for the
Linux 3 kernel", but then perhaps we should be doing that as well...
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
#x27;s something badly wrong with your WAL records.
I'd suggest you move to a later version of 9.1 and retry.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
ported until end of recovery. That has now been changed to be
reported earlier, so its clearer that this situation exists.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (
So I can confirm the above patch fixes at least that bug.
>
> Andres
Committed, with minor changes in wording of comments and error messages.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 7 June 2012 17:49, Andres Freund wrote:
> A patch implementing that is attached. Unfortunately not really tested yet
> because its kinda hard to hit that code-path.
>
> Valentine, can you test that patch?
Patch looks good, so as soon as we confirm it we can apply.
--
On 11 May 2012 17:48, Heikki Linnakangas
wrote:
> On 11.05.2012 18:18, Simon Riggs wrote:
>>
>> On 11 May 2012 15:14, Heikki Linnakangas
>> wrote:
>>>
>>> On 11.05.2012 16:56, Simon Riggs wrote:
>>>>
>>>>
>>>> On 11 M
On 11 May 2012 15:14, Heikki Linnakangas
wrote:
> On 11.05.2012 16:56, Simon Riggs wrote:
>>
>> On 11 May 2012 11:07, Heikki Linnakangas
>> wrote:
>>
>>> I wonder if we should reserve a few of the lwlock "slots" for critical
>>> section
ivial
> to reserve a few slots.
Why reserve them solely for critical sections?
What is the downside from having >100 slots for general use.
ISTM we should have 250 slots and log a warning if we ever hit 50 or more.
--
Simon Riggs http://www.2ndQuadrant.com/
Postgr
Run REINDEX on the primary server.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mething on the master is a little
misleading with respect to timing. However, if the master and the
standby aren't even connected and you know that, how did you expect
there to be a causal link between the setting on the master and the
state of the standby?
What do you suggest the messages say?
--
s is really good news.
Thank you.
Simon
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-6204-Using-plperl-functions-generate-crash-tp4802111p5652595.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
--
Sent via pgsql-bugs mai
2 bit - Enterprise DB download
ActiveState version string: This is perl 5, version 14, subversion 2
(v5.14.2) built for MSWin32-x86-multi-thread
Is there a recommended way to solve this issue, has it been fixed in a later
release?
Simon Willett
--
View this message in context:
http://postgresql.10456
is entitled to keep accessing
> that tuple with only a buffer pin. So the existing code transiently
> wipes the data from underneath the other backend's pin.
>
> It's clear how this explains the symptoms
Yes, that looks like the murder weapon.
--
Simon Riggs
ug, since that allows the messages to appear
in the PG log when the utility is used as an archive_cleanup_command.
If you'd like to submit a patch to allow -s mode (silent) or similar,
we'd be happy to receive it.
--
Simon Riggs http://www.2ndQuadrant.com/
Postgre
defined in access/htup.h...should it be?
IMHO comment is wrong, code is in the right place.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make change
types of GIN indexes. Will fix.
Great detective work Tom as ever, much appreciated.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
good to get more info on this before I start investigating. Thanks
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
h results to be reproduced. If problems do
exist, we will be very interested.
There are many people here that would be happy to help if you find
problems, so please don't be put off by these responses to your work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Dev
.
>
> This part I agree with - it makes sense for ALTER to set both flags
> when it enables superuser.
+1
Change the behaviour to match the docs makes most sense to me.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, Oct 17, 2011 at 8:31 AM, Susanne Ebrecht
wrote:
> PostgreSQL isn't supporting CHAR(0).
What does the SQL Standard say?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing
ing related to how we
navigate hot chains with/without killed tuples. i.e. the bug is not
actually HS related, but is only observed under conditions typical in
HS.
HS touches almost nothing else in user space, apart from snapshots. So
there could be a bug there also, maybe in CopySnapshot().
--
with the attempt to dump the table.
Exclude the tables you don't wish to have dumped using command line options.
I don't think we will put in an option to silently exclude missing
tables, not least because it would be technically difficult.
--
Simon Riggs http:/
On Mon, Aug 1, 2011 at 8:25 AM, simon wrote:
> Could be that its storing the wrong kind of plan on the RI trigger for PK.
No, not that. Will look elsewhere.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
S
ings - nothing helped, only drop
> helps.
Sounds weird. Looking at this now.
Could be that its storing the wrong kind of plan on the RI trigger for PK.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
r error. If
you can provide a more isolated bug report we may be able to
investigate.
This is being discussed in a thread on the General list and there is
no reason to post twice.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Train
ven manage to read out the old contents (modulo
> any fun and exciting XID wraparound issues). But the problem is of
> course more noticeable for unlogged tables since they're not hidden
> away in a special funny schema.
Seems like you're trying to fix the problem direct
of robustness.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ks clear from here. What I'm stunned about is that we've
not had a report about this before now. (You replied there had been one).
ProcSendSignal() doesn't do anything at all when called with the
Startup proc's pid, because BackendPidGetProc() returns NULL.
The root cause appears t
get a rating so we know what we're dealing with
The problem is that the password is disclosed in a surprising way.
.pgpass files are explicitly put there by a user, so they know what
they've done.
Putting a password in cleartext somewhere is an issue if people don't
out of range 0..1
> > >
> > > results in:
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> Ok, found the bug, simple oversight in invalid foreign key patch.
>
> Andres
Thanks, will apply.
--
Simon Riggs http://www
I'm seeing this problem too, so I might be able to shed some light on it.
Here's exactly what I did:
> cd /usr/src/postgresql-9.0.2
> tar -xjvf postgresql-9.0.2.tar.bz2
> mv postgresql-9.0.2 src
> mkdir obj-x86_64
> cd obj-x86_64
> /usr/src/postgresql-9.0.2/src/configure
> '--prefix=/usr/local/p
FW
Forwarded Message
From: H.Merijn Brand
To: DBI Developers Mailing List , Simon Riggs
Subject: DBD::Pg on HP-UX 11.31 64bit
Date: Tue, 14 Dec 2010 13:35:49 +0100
I have postgres running on most my HP-UX varieties, ranging from HP-UX
10.20/32bit through 11.31/64bit. It works
The following bug has been logged online:
Bug reference: 5759
Logged by: Simon Poole
Email address: postgre...@simon.themalago.net
PostgreSQL version: 8.4.4
Operating system: RHEL5.3
Description:Autovacuum cost limit trends to 1, using default config
Details:
With
x would still be broken after the slave exits hot
> standby and becomes live; so that hack didn't cure the problem anyway.
OK, that's a good argument.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via
The following bug has been logged online:
Bug reference: 5664
Logged by: simon
Email address: xuboc...@163.com
PostgreSQL version: 8.3.11
Operating system: suse 10 Linux omu 2.6.16.60-0.54.5-bigsmp #1 SMP Fri Sep
Description:index "idx000_mytable19"
() on master, remember LSN
2. copy backup_label from master to standby
3. wait for starting LSN to be applied on standby
4. run backup on standby
5. run pg_stop_backup() on master
That ensures we don't run without full page writes during backup and
that we have an explicit consistency poin
etween two halves of an index split record, which will never be
corrected during HS. What I find surprising is that the technique the OP
describes should be safe, assuming step 5 waits for the correct point of
consistency before attempting to run queries.
--
Simon Riggs www.2ndQuadran
?
Patch looks OK, though IMHO wouldn't be looking to backpatch this.
I'll look at this in more detail next week, unless others wish to.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pg
a kluge, that's why.
It's also my 3rd choice of solution behind fine-grained lock conflicts
(1st) which would avoid many issues and master/standby in lock step
(2nd).
Having said that I'm much in favour of providing a range of options and
then letting users tell us what w
On Wed, 2010-03-10 at 17:12 -0800, Josh Berkus wrote:
> On 3/10/10 3:26 PM, Simon Riggs wrote:
> > OK, that's enough to not remove it. I was aware of more negative
> > thoughts and conscious of my own feelings about it being a kluge.
>
> Well, it *is* a kludge, but
On Wed, 2010-03-10 at 17:55 -0500, Tom Lane wrote:
> Simon Riggs writes:
> >>> Time to remove vacuum_defer_cleanup_age, I think.
> >>
> >> Umm, so what's the bug?
>
> > Whether you call it a bug or just an annoyance is debatable, but the
> &
, I propose
removing it.
Would you agree or disagree with the suggested removal?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
gt; WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation
> "pgbench_tellers" page 0
> WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation
> "pgbench_tellers" page 1
Understandable.
Time to remove vacuum_defer_cleanup_age, I think.
--
Simon R
gadmin.org/support/list.php
I think we need to work on a distribution mechanism for such requests,
rather than trouble bug reporters with our bureaucracy. pgAdmin has been
bundled with Postgres for some time now.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailin
The following bug has been logged online:
Bug reference: 5344
Logged by: Simon Ng
Email address: simon94...@yahoo.com
PostgreSQL version: 8.1.11
Operating system: RedHat Linux
Description:pg_restore some foreign keys missing
Details:
from server1 with Postgres
tion test for use in
superuser().
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, 2009-09-15 at 12:09 -0400, Tom Lane wrote:
> I'm working on this now.
Thanks to you and Heikki for fixing this while I worked around it.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
> >> I've pointed out before that the regression tests are not particularly
> >> meant to provide an exhaustive test of WAL recovery.
On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
> >> This means that the WAL replay of that record type has never been tested
> >> correctly :-(.
>
> > This must have b
On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > In recovery of GIN operations using CVS HEAD I see consistently
> >
> > TRAP: FailedAssertion("!(((bool) ((spcNode) != ((Oid) 0", File:
> > "tablespace.c",
that the value of the node is unset.
That means XLOG_GIN_INSERT_LISTPAGE always has specNode == 0 and so
triggers the assertion failure.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www
gt; This doesn't matter too much yet but it will for hot standby.
IIUC you think it is safest to *not* write hint bits during Hot Standby?
So we would treat all commits as async commits?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent vi
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 s
> of the standby server, because that affects the failover time, for example.
An important point.
The update rate "should" be once per clock cycle at most and should
occur in bgwriter not startup. If there is evidence of a problem then I
would support reducing the update rate. The pur
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&#x
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 m
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
hy any of this has been done.
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.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailin
e its way to disk. The code in 8.4
does a few things to improve that but the base problem persists and
revoking code won't change that. We should describe the issue in the
docs and leave it at that - there is no particular reason to believe
anybody would want to do such a thing.
--
Simon Riggs
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 sol
r point of how we code the fix
to the bug we do have.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ecovery can also be replaced by
RecoveryIsInProgress()
So, yes, there are some places where InRecovery is used in code executed
by the bgwriter, but the correct fix is to use RecoveryIsInProgress().
It is a hack to try to set the InRecovery state flag in bgwriter and one
that would change the clea
n accumulating such requests.
> * need to do something about IsRecovery tests that will now be executed
> in bgwriter
Yes
> * need to fix mistaken code in FinishPreparedTransaction
Yes
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent vi
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-b
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,
eems we
should correct the caller rather than change the API and potentially
effect all callers.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
ily true for some reason, but it doesn't sound
like it is a safe assumption. I would guess it's using isRedo as an
implicit override rather than using the correct meaning of the variable.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
1 - 100 of 233 matches
Mail list logo
