freeze map open item

On Thu, Jul 21, 2016 at 9:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:

The open items list says this:

heap_update sets xmax and infomask without logging the changes or
clearing PD_ALL_VISIBLE or visibility map bits
* volunteer owner wanted
* This has been buggy essentially forever but the freeze map changes
give it new urgency.
* Andres working on committing patches

I believe this issue was fully resolved by
bfa2ab56bb8c512dc8613ee3ff0936568a1c8418. Is that correct?
Regardless, I'd like to extend sincere and heartfelt thanks to Andres
for handling this issue, because I was sure running out of steam (and
time).

Two other issues were discussed on that thread for which no open
issues were created. First, heap_lock_tuple failed to clear the
all-frozen status. I believe that
eca0f1db14ac92d91d54eca8eeff2d15ccd797fa substantially addressed that
issue and therefore it should be added to the list as a resolved
issue. But, second, as noted in further discussion on that thread and
in the commit message, there is an outstanding theoretical problem
which is non-critical but worthy of being fixed. I recommend we open
a new open issue for that, or at least fix it.

+1. I think, sometime needs to be spend to confirm if that
theoretical risk can practically cause any problem. I am planning to
spend some time on it in next week or so and will report my
observations on that thread.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2016-07-22 13:57:15 +0530, Amit Kapila wrote:

On Thu, Jul 21, 2016 at 9:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:

The open items list says this:

heap_update sets xmax and infomask without logging the changes or
clearing PD_ALL_VISIBLE or visibility map bits
* volunteer owner wanted
* This has been buggy essentially forever but the freeze map changes
give it new urgency.
* Andres working on committing patches

I believe this issue was fully resolved by
bfa2ab56bb8c512dc8613ee3ff0936568a1c8418. Is that correct?

Yes, I think so.

Regardless, I'd like to extend sincere and heartfelt thanks to Andres
for handling this issue, because I was sure running out of steam (and
time).

You're welcome.

Two other issues were discussed on that thread for which no open
issues were created. First, heap_lock_tuple failed to clear the
all-frozen status. I believe that
eca0f1db14ac92d91d54eca8eeff2d15ccd797fa substantially addressed that
issue and therefore it should be added to the list as a resolved
issue. But, second, as noted in further discussion on that thread and
in the commit message, there is an outstanding theoretical problem
which is non-critical but worthy of being fixed. I recommend we open
a new open issue for that, or at least fix it.

+1. I think, sometime needs to be spend to confirm if that
theoretical risk can practically cause any problem. I am planning to
spend some time on it in next week or so and will report my
observations on that thread.

I kind of doubt it's possible for existing users, given that the buffer
pretty much will have to be pinned at anything involving high
concurrency. That'll prevent cleanup locks concurrently being acquired,
before the lock is held. But yea, we should nail that door actually
shut.

Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers