aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-06-02 15:30:56 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2011-06-02 15:32:21 -0400
commitea6eda64a6425923463d358e2915980e81280483 (patch)
treebdac54b726ca7b5e55cb265d0901a8b90d37cf71 /doc/src
parent5295fa8c0bb396bf2866205e093bc04d7a3394fe (diff)
downloadpostgresql-ea6eda64a6425923463d358e2915980e81280483.tar.gz
postgresql-ea6eda64a6425923463d358e2915980e81280483.zip
Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence.
My previous commit disallowed this operation, but did nothing about cleaning up the damage if one had already been done. With the operation disallowed, it's okay to just forcibly clear xmax in a sequence's tuple, since any value seen there could not represent a live transaction's lock. So, any sequence-specific operation will repair the problem automatically, whether or not the user has already seen "could not access status of transaction" failures.
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions