On 01/08/2014 07:29 AM, Greg Stark wrote:
On Tue, Jan 7, 2014 at 11:36 AM, Heikki Linnakangas
wrote:
Hmm. The xlogdump indeed shows that the order of 'clean' and 'visible' is
incorrect, but I don't immediately see how that could cause the PANIC. Why
is the page uninitialized in the standby? If
On 2014-01-07 22:42:59 -0200, Matheus de Oliveira wrote:
> @andres, if it is really removing backup_label it could also cause that
> other issue we saw on Monday, right? (yes I did run the same script).
It might be in your case since that's an easy to way to generate that
situation, but there have
On 2014-01-08 14:37:34 +0200, Heikki Linnakangas wrote:
> That seems to be a very common mistake to make. I wish we could do something
> about it. Do you think it would've helped in your case if there was a big
> fat warning in the beginning of backup_label, along the lines of: "# DO NOT
> REMOVE T
On 01/08/2014 02:32 PM, Matheus de Oliveira wrote:
On Tue, Jan 7, 2014 at 10:42 PM, Matheus de Oliveira <
matioli.math...@gmail.com> wrote:
How did you set up the standby? Did you initialize it from an offline
backup of the master's data directory, perhaps? The log shows that the
startup took
On Tue, Jan 7, 2014 at 10:42 PM, Matheus de Oliveira <
matioli.math...@gmail.com> wrote:
> How did you set up the standby? Did you initialize it from an offline
>> backup of the master's data directory, perhaps? The log shows that the
>> startup took the the "crash recovery first, then start archi
On Tue, Jan 7, 2014 at 11:36 AM, Heikki Linnakangas
wrote:
> Hmm. The xlogdump indeed shows that the order of 'clean' and 'visible' is
> incorrect, but I don't immediately see how that could cause the PANIC. Why
> is the page uninitialized in the standby? If VACUUM is removing some dead
> tuples f
On Tue, Jan 7, 2014 at 5:36 PM, Heikki Linnakangas
wrote:
> On 01/07/2014 07:15 PM, Matheus de Oliveira wrote:
>
>> Hi folks,
>>
>>
>> On Fri, Dec 13, 2013 at 9:47 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com
>>
>>> wrote:
>>>
>>
>> lazy_vacuum_page() does this:
>>>
>>> 1. START_CRIT_SECTI
On 2014-01-07 21:36:31 +0200, Heikki Linnakangas wrote:
> >2088220 ... Heap2 ... 24/ 192, ... lsn: 2BC/46AB8B20 ... desc: clean:
> >rel 1663/883916/151040222; blk 1073 remxid 107409880
> >2088221 ... Heap2 ... 20/52, ... lsn: 2BC/46AB8BE0 ... desc: visible:
> >rel 1663/883916/151040222; blk
On 01/07/2014 07:15 PM, Matheus de Oliveira wrote:
Hi folks,
On Fri, Dec 13, 2013 at 9:47 AM, Heikki Linnakangas
wrote:
lazy_vacuum_page() does this:
1. START_CRIT_SECTION()
2. Remove dead tuples from the page, marking the itemid's unused.
3. MarkBufferDirty
4. if all remaining tuples on t
Hi folks,
On Fri, Dec 13, 2013 at 9:47 AM, Heikki Linnakangas wrote:
> lazy_vacuum_page() does this:
>
> 1. START_CRIT_SECTION()
> 2. Remove dead tuples from the page, marking the itemid's unused.
> 3. MarkBufferDirty
> 4. if all remaining tuples on the page are visible to everyone, set the
> a
lazy_vacuum_page() does this:
1. START_CRIT_SECTION()
2. Remove dead tuples from the page, marking the itemid's unused.
3. MarkBufferDirty
4. if all remaining tuples on the page are visible to everyone, set the
all-visible flag on the page, and call visibilitymap_set() to set the VM
bit.
5 visi
11 matches
Mail list logo
