Simon Riggs writes:
> On 2 December 2012 16:44, Tom Lane wrote:
>> As far as the concern about new bugs is concerned: if we start replay
>> from this checkpoint, we will certainly not consider that the DB is
>> consistent until we reach the checkpoint's physical position. And by
>> that point we
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 sure I did it for some reason.
>
> I think you jus
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 sure I did it for some reason.
I think you just did it because it looked easy, and you didn't think
On 2 December 2012 15:25, Tom Lane wrote:
> I can point right now to one misbehavior this causes: if you run a
> point-in-time recovery with a stop point somewhere in the middle of the
> checkpoint, you should end up with a nextXid corresponding to the stop
> point. This hack in LogStandbySnapsh
Simon Riggs writes:
> I've applied an absolutely minimal fix on this, which introduces no
> other changes that could cause unforeseen consequences.
This is not what we'd agreed to do, I thought.
Now that I've thought more about this bug, the existing coding is flat
out wrong, with or without cor
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 believe what is happening here is
>>
>> (1) CreateCheckPoint
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 believe what is happening here is
>
> (1) CreateCheckPoint sets up checkPoint.nextXid and
> checkPoint.nextXidEpo
On 1 December 2012 23:10, Andres Freund wrote:
>> So barring objections, I'm going to remove LogStandbySnapshot's behavior
>> of returning the updated nextXid.
>
> I don't see any reason why it would be bad to remove this. I think the
> current behaviour could actually even delay getting to an ac
On 2012-12-02 00:10:22 +0100, Andres Freund wrote:
> On 2012-12-01 17:56:33 -0500, Tom Lane wrote:
> > So barring objections, I'm going to remove LogStandbySnapshot's behavior
> > of returning the updated nextXid.
>
> I don't see any reason why it would be bad to remove this. I think the
> current
On 2012-12-01 17:56:33 -0500, 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 believe what is happening here is
Hrmpf. You had to report the fix for that three minutes before
me. ;)
>
Hi all,
On 2012-11-27 19:52:09 +, tar...@gmail.com wrote:
> This happens only if wal_level=hot_standby.
>
>
> Here are the steps to reproduce this issue.
Oh. Fucking. Wow.
I think this tiny comment just helped me find the bug. After previously
having looked for it without success for some ti
tar...@gmail.com writes:
> [ txid_current can show a bogus value near XID wraparound ]
> This happens only if wal_level=hot_standby.
I believe what is happening here is
(1) CreateCheckPoint sets up checkPoint.nextXid and
checkPoint.nextXidEpoch, near xlog.c line 7070 in HEAD. At this point,
next
Hi all.
We also have reproduced this behaviour of txid wraparound. pg version 9.0.5.
We have done some test.
We are using hot standby and our chekpoint interval is closly to one
hour (actually, our pg does chekpoints all time). So probability of
intersection active chekpoint and getting max txid
The following bug has been logged on the website:
Bug reference: 7710
Logged by: Tarvi Pillessaar
Email address: tar...@gmail.com
PostgreSQL version: 9.1.6
Operating system: linux
Description:
This happens only if wal_level=hot_standby.
Here are the steps to reprodu
14 matches
Mail list logo
