On Thu, Jun 7, 2012 at 12:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> Updated patch attached.
>
> The comments need a pass of copy-editing, eg here and here:
>
>> + * so somebody else could be change the bit just after we look at it. In
>> fact,
> ^^^
>
>>
Robert Haas writes:
> Updated patch attached.
The comments need a pass of copy-editing, eg here and here:
> + * so somebody else could be change the bit just after we look at it. In
> fact,
^^^
> + * got cleared after we checked it and before we got
On Thursday, June 07, 2012 06:23:58 PM Robert Haas wrote:
> On Thu, Jun 7, 2012 at 12:19 PM, Andres Freund
wrote:
> > You could do a visibilitymap_pin outside, but I don't really see the
> > point as the page is already locked. There might be some slight benefit
> > in doing so in multi_insert bu
On Thu, Jun 7, 2012 at 12:19 PM, Andres Freund wrote:
> You could do a visibilitymap_pin outside, but I don't really see the point as
> the page is already locked. There might be some slight benefit in doing so in
> multi_insert but that would be more complicated. And of doubtful benefit.
Doesn't
On Thursday, June 07, 2012 06:08:34 PM Robert Haas wrote:
> On Thu, Jun 7, 2012 at 11:04 AM, Andres Freund
wrote:
> > On Thursday, June 07, 2012 04:27:32 PM Robert Haas wrote:
> >> On Thu, Jun 7, 2012 at 9:41 AM, Andres Freund
> >
> > wrote:
> >> >> Proposed patch attached. This adds some more
On Thu, Jun 7, 2012 at 11:04 AM, Andres Freund wrote:
> On Thursday, June 07, 2012 04:27:32 PM Robert Haas wrote:
>> On Thu, Jun 7, 2012 at 9:41 AM, Andres Freund
> wrote:
>> >> Proposed patch attached. This adds some more comments in various
>> >> places, and implements your suggestion of retes
On Thursday, June 07, 2012 04:27:32 PM Robert Haas wrote:
> On Thu, Jun 7, 2012 at 9:41 AM, Andres Freund
wrote:
> >> Proposed patch attached. This adds some more comments in various
> >> places, and implements your suggestion of retesting the visibility-map
> >> bit when we detect a possible mi
On Thu, Jun 7, 2012 at 9:41 AM, Andres Freund wrote:
>> Well, one, commits are irrelevant; the page ceases to be all-visible
>> as soon as the delete happens.
> Its not irrelevant for the code as it stands if non-mvcc snapshots were
> allowed. Unless I miss something, even disregarding memory orde
On Thursday, June 07, 2012 03:20:50 PM Robert Haas wrote:
> On Wed, Jun 6, 2012 at 3:07 PM, Andres Freund
wrote:
> > Hm. For a short while I thought there would be an issue with heap_delete
> > and IOS because the deleting transaction can commit without any barriers
> > happening on the IOS side.
On Wed, Jun 6, 2012 at 3:07 PM, Andres Freund wrote:
> Hm. For a short while I thought there would be an issue with heap_delete and
> IOS because the deleting transaction can commit without any barriers happening
> on the IOS side. But that only seems to be possible with non MVCC snapshots
> which
On Wednesday, June 06, 2012 08:19:15 PM Robert Haas wrote:
> On Wed, Jun 6, 2012 at 1:46 PM, Andres Freund
wrote:
> > On a cursory lock it might just be a race condition in
> > vacuumlazy.c:lazy_scan_heap. If scan_all is set, which it has to be for
> > the warning to be visible, all_visible_accor
On Wed, Jun 6, 2012 at 1:46 PM, Andres Freund wrote:
> On a cursory lock it might just be a race condition in
> vacuumlazy.c:lazy_scan_heap. If scan_all is set, which it has to be for the
> warning to be visible, all_visible_according_to_vm is determined before we
> loop over all blocks. At the po
On Tuesday, June 05, 2012 04:18:44 PM Tom Lane wrote:
> Andres Freund writes:
> > On Tuesday, June 05, 2012 03:32:08 PM Tom Lane wrote:
> >> I got this last night in a perfectly standard build of HEAD:
> >> + WARNING: page is not marked all-visible but visibility map bit is set
> >> in relation "
Andres Freund writes:
> On Tuesday, June 05, 2012 03:32:08 PM Tom Lane wrote:
>> I got this last night in a perfectly standard build of HEAD:
>> + WARNING: page is not marked all-visible but visibility map bit is set in
>> relation "pg_db_role_setting" page 0 --
> I have seen that twice just yes
On Tuesday, June 05, 2012 03:32:08 PM Tom Lane wrote:
> I got this last night in a perfectly standard build of HEAD:
>
> *** /home/tgl/pgsql/src/test/regress/expected/sanity_check.outThu Jan
> 12
> 14:06:14 2012 ---
> /home/tgl/pgsql/src/test/regress/results/sanity_check.out Mon Jun
I got this last night in a perfectly standard build of HEAD:
*** /home/tgl/pgsql/src/test/regress/expected/sanity_check.out Thu Jan 12
14:06:14 2012
--- /home/tgl/pgsql/src/test/regress/results/sanity_check.out Mon Jun 4
20:28:39 2012
***
*** 1,4
--- 1,5
VACUUM;
+ WAR
16 matches
Mail list logo
