Re: shared memory based stat collector (was: Sharing record typmods between backends)
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@enterprisedb.com>, Dilip Kumar <dilipbalaut@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-14T16:09:05Z
Lists: pgsql-hackers
Robert Haas wrote: > Actually, now that you mention it, I think it *is* broken already, or > more to the point, if you configure that value, the autovacuum > launcher hangs up, because of the AutovacuumWorkItem stuff that Alvaro > added. When I just tested it, the AV launcher somehow ended up > waiting for AutovacuumLock and I had to SIGQUIT the server to shut it > down. That's actually not really entirely the fault of > dynamic_shared_memory_type = none, though, because the code in > autovacuum.c does this: > > AutoVacuumDSA = dsa_create(AutovacuumLock->tranche); > /* make sure it doesn't go away even if we do */ > dsa_pin(AutoVacuumDSA); > dsa_pin_mapping(AutoVacuumDSA); > > Now, that's actually really broken because if dsa_create() throws an > error of any kind, you're going to have already assigned the value to > AutoVacuumDSA, but you will not have pinned the DSA or the DSA > mapping. There's evidently some additional bug here because I'd sorta > expect this code to just go into an infinite loop in this case, > failing over and over trying to reattach the segment, but evidently > something even worse happening - perhaps the ERROR isn't releasing > AutovacuumLock. Looking into this now. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Simplify autovacuum work-item implementation
- f2f9fcb3030b 10.0 landed
- 31ae1638ce35 11.0 landed
-
Fix error handling path in autovacuum launcher
- d9a622cee162 11.0 landed
- 870da1e1546c 10.0 landed
-
Dramatically reduce System V shared memory consumption.
- b0fc0df9364d 9.3.0 cited