Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple

Yes, I’ve been testing 9.6.  I’ll try Alvaro’s patch today.

I would prefer to focus on either latest 9X or 11dev.  Does Alvaro’s patch presume any of the other patch to set
COMMITTEDin the freeze code?
 


On 10/4/17, 7:17 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
   On Thu, Oct 5, 2017 at 10:39 AM, Wood, Dan <hexpert@amazon.com> wrote:   > Whatever you do make sure to also test
250clients running lock.sql.  Even with the communities fix plus YiWen’s fix I can still get duplicate rows.  What
worksfor “in-block” hot chains may not work when spanning blocks.      Interesting. Which version did you test? Only
9.6?     > Once nearly all 250 clients have done their updates and everybody is waiting to vacuum which one by one will
takea while I usually just “pkill -9 psql”.  After that I have many of duplicate “id=3” rows.  On top of that I think
wemight have a lock leak.  After the pkill I tried to rerun setup.sql to drop/create the table and it hangs.  I see an
autovacuumprocess starting and existing every couple of seconds.  Only by killing and restarting PG can I drop the
table.     Yeah, that's more or less what I have been doing. My tests involve   using your initial script with way more
sessionstriggering lock.sql,   minus the kill-9 portion (good idea actually). I can of course see the   sessions
queuingfor VACUUM, still I cannot see duplicated rows, even   if I headshot Postgres in the middle of the VACUUM
waitingqueue. Note   that I have just tested Alvaro's patch on 9.3.   --    Michael      
 


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