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 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 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
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 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:
> 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 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 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
Jeff Janes writes:
> On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane wrote:
>> I'm confused. Are you now saying that this problem only exists in
>> 9.1.x? I tested current HEAD because you indicated the problem was
>> still there.
> No, I'm saying the problem exists both in 9.1.x and in hypothetical
The following bug has been logged on the website:
Bug reference: 7722
Logged by: Artem Anisimov
Email address: aanisi...@inbox.ru
PostgreSQL version: 9.2.1
Operating system: Slackware Linux 14.0/amd64
Description:
The following to queries give the same result (first a
aanisi...@inbox.ru wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7722
> Logged by: Artem Anisimov
> Email address: aanisi...@inbox.ru
> PostgreSQL version: 9.2.1
> Operating system: Slackware Linux 14.0/amd64
> Description:
>
> The foll
11 matches
Mail list logo
