"ERROR: could not read block 6 ...: read only 0 of 8192 bytes" after autovacuum cancelled

[Alvaro Herrera-7]

A customer of ours recently hit a problem where after an autovacuum was
cancelled on a table, the app started getting the message in $subject:

ERROR:  could not read block 6 of relation 1663/35078/1761966: read only 0 of 8192 bytes

(block numbers vary from 1 to 6).  Things remained in this state until
another autovacuum came along and cleaned up the table, 4 minutes later
(this is a high traffic table; there are several inserts per second).

The log looks like this:

2009-10-20 04:02:07 PDT [27396]: [1-1]  LOG:  automatic vacuum of table "database.public.tabname": index scans: 1
        pages: 6 removed, 1 remain
        tuples: 755 removed, 2 remain
        system usage: CPU 0.00s/0.00u sec elapsed 1.42 sec
2009-10-20 04:02:07 PDT [27396]: [2-1]  ERROR:  canceling autovacuum task
2009-10-20 04:02:07 PDT [27396]: [3-1]  CONTEXT:  automatic vacuum of table "database.public.tabname"

What I thought could have happened is that the table was truncated, and
then the sinval message telling that to other backends was not sent due
to the rollback.  When they tried to insert to the page they had
recorded as rd_targblock, they try to read the page but it's no longer
there.

I can reproduce this by adding a sleep and CHECK_FOR_INTERRUPTS after
lazy_vacuum_rel() returns, and before CommitTransactionCommand.

So far as I can see, what we need is to make sure the sinval message is
sent regardless of transaction commit/abort.  How can that be done?  It
is quite ugly to have an untimely autovacuum cancel disrupt the ability
to insert into a table.

Thoughts?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

[Tom Lane-2]

Alvaro Herrera <alvherre@...> writes:
> What I thought could have happened is that the table was truncated, and
> then the sinval message telling that to other backends was not sent due
> to the rollback.

Hmm.

> So far as I can see, what we need is to make sure the sinval message is
> sent regardless of transaction commit/abort.  How can that be done?

I would argue that once we've truncated, it's too late to abort.  The
interrupt facility should be disabled from just before issuing the
truncate till after commit.  It would probably be relatively painless to
do that with some manipulation of the interrupt holdoff stuff.

                        regards, tom lane

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

[Alvaro Herrera-7]

Tom Lane wrote:
> Alvaro Herrera <alvherre@...> writes:

> > So far as I can see, what we need is to make sure the sinval message is
> > sent regardless of transaction commit/abort.  How can that be done?
>
> I would argue that once we've truncated, it's too late to abort.  The
> interrupt facility should be disabled from just before issuing the
> truncate till after commit.  It would probably be relatively painless to
> do that with some manipulation of the interrupt holdoff stuff.

That cures my (admittedly simplistic) testcase.  The patch is a bit ugly
because the interrupts are held off in lazy_vacuum_rel and need to be
released by its caller.  I don't see any other way around the problem
though.

The attached patch is for 8.4; back branches all need a bit of editing.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---

Index: src/backend/commands/vacuum.c
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/commands/vacuum.c,v
retrieving revision 1.389.2.1
diff -c -p -r1.389.2.1 vacuum.c
*** src/backend/commands/vacuum.c 24 Aug 2009 02:18:40 -0000 1.389.2.1
--- src/backend/commands/vacuum.c 6 Nov 2009 14:01:04 -0000
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 1023,1028 ****
--- 1023,1029 ----
  Oid toast_relid;
  Oid save_userid;
  bool save_secdefcxt;
+ bool heldoff;
 
  if (scanned_all)
  *scanned_all = false;
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 1189,1197 ****
  * Do the actual work --- either FULL or "lazy" vacuum
  */
  if (vacstmt->full)
  full_vacuum_rel(onerel, vacstmt);
  else
! lazy_vacuum_rel(onerel, vacstmt, vac_strategy, scanned_all);
 
  /* Restore userid */
  SetUserIdAndContext(save_userid, save_secdefcxt);
--- 1190,1201 ----
  * Do the actual work --- either FULL or "lazy" vacuum
  */
  if (vacstmt->full)
+ {
  full_vacuum_rel(onerel, vacstmt);
+ heldoff = false;
+ }
  else
! heldoff = lazy_vacuum_rel(onerel, vacstmt, vac_strategy, scanned_all);
 
  /* Restore userid */
  SetUserIdAndContext(save_userid, save_secdefcxt);
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 1205,1210 ****
--- 1209,1218 ----
  PopActiveSnapshot();
  CommitTransactionCommand();
 
+ /* now we can allow interrupts again, if disabled */
+ if (heldoff)
+ RESUME_INTERRUPTS();
+
  /*
  * If the relation has a secondary toast rel, vacuum that too while we
  * still hold the session lock on the master table.  Note however that
Index: src/backend/commands/vacuumlazy.c
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/commands/vacuumlazy.c,v
retrieving revision 1.121.2.1
diff -c -p -r1.121.2.1 vacuumlazy.c
*** src/backend/commands/vacuumlazy.c 24 Aug 2009 02:18:40 -0000 1.121.2.1
--- src/backend/commands/vacuumlazy.c 6 Nov 2009 14:00:11 -0000
*************** static int vac_cmp_itemptr(const void *l
*** 140,147 ****
   *
   * At entry, we have already established a transaction and opened
   * and locked the relation.
   */
! void
  lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt,
  BufferAccessStrategy bstrategy, bool *scanned_all)
  {
--- 140,151 ----
   *
   * At entry, we have already established a transaction and opened
   * and locked the relation.
+  *
+  * The return value indicates whether this function has held off
+  * interrupts -- caller must call RESUME_INTERRUPTS() after commit if
+  * it is true.
   */
! bool
  lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt,
  BufferAccessStrategy bstrategy, bool *scanned_all)
  {
*************** lazy_vacuum_rel(Relation onerel, VacuumS
*** 153,158 ****
--- 157,163 ----
  TimestampTz starttime = 0;
  bool scan_all;
  TransactionId freezeTableLimit;
+ bool heldoff;
 
  pg_rusage_init(&ru0);
 
*************** lazy_vacuum_rel(Relation onerel, VacuumS
*** 194,205 ****
--- 199,220 ----
  *
  * Don't even think about it unless we have a shot at releasing a goodly
  * number of pages.  Otherwise, the time taken isn't worth it.
+ *
+ * Note that after we've truncated the heap, it's too late to abort the
+ * transaction; doing so would lose the sinval messages needed to tell
+ * the other backends about the table being shrunk.  We hold off interrupts
+ * in that case; the caller is responsible for releasing them after
+ * committing the transaction.
  */
  possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages;
  if (possibly_freeable > 0 &&
  (possibly_freeable >= REL_TRUNCATE_MINIMUM ||
  possibly_freeable >= vacrelstats->rel_pages / REL_TRUNCATE_FRACTION))
+ {
+ HOLD_INTERRUPTS();
+ heldoff = true;
  lazy_truncate_heap(onerel, vacrelstats);
+ }
 
  /* Vacuum the Free Space Map */
  FreeSpaceMapVacuum(onerel);
*************** lazy_vacuum_rel(Relation onerel, VacuumS
*** 246,251 ****
--- 261,268 ----
 
  if (scanned_all)
  *scanned_all = vacrelstats->scanned_all;
+
+ return heldoff;
  }
 
 
Index: src/include/commands/vacuum.h
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/commands/vacuum.h,v
retrieving revision 1.85
diff -c -p -r1.85 vacuum.h
*** src/include/commands/vacuum.h 11 Jun 2009 14:49:11 -0000 1.85
--- src/include/commands/vacuum.h 6 Nov 2009 13:54:43 -0000
*************** extern bool vac_is_partial_index(Relatio
*** 146,152 ****
  extern void vacuum_delay_point(void);
 
  /* in commands/vacuumlazy.c */
! extern void lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt,
  BufferAccessStrategy bstrategy, bool *scanned_all);
 
  /* in commands/analyze.c */
--- 146,152 ----
  extern void vacuum_delay_point(void);
 
  /* in commands/vacuumlazy.c */
! extern bool lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt,
  BufferAccessStrategy bstrategy, bool *scanned_all);
 
  /* in commands/analyze.c */

---

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

[Tom Lane-2]

Alvaro Herrera <alvherre@...> writes:
> Tom Lane wrote:
>> I would argue that once we've truncated, it's too late to abort.  The
>> interrupt facility should be disabled from just before issuing the
>> truncate till after commit.  It would probably be relatively painless to
>> do that with some manipulation of the interrupt holdoff stuff.

> That cures my (admittedly simplistic) testcase.  The patch is a bit ugly
> because the interrupts are held off in lazy_vacuum_rel and need to be
> released by its caller.  I don't see any other way around the problem
> though.

I wonder whether we shouldn't extend this into VACUUM FULL too, to
prevent cancel once it's done that internal commit.  It would fix
the "PANIC: can't abort a committed transaction" problem V.F. has.

                        regards, tom lane

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

[Alvaro Herrera-7]

Tom Lane wrote:

> Alvaro Herrera <alvherre@...> writes:
> > Tom Lane wrote:
> >> I would argue that once we've truncated, it's too late to abort.  The
> >> interrupt facility should be disabled from just before issuing the
> >> truncate till after commit.  It would probably be relatively painless to
> >> do that with some manipulation of the interrupt holdoff stuff.
>
> > That cures my (admittedly simplistic) testcase.  The patch is a bit ugly
> > because the interrupts are held off in lazy_vacuum_rel and need to be
> > released by its caller.  I don't see any other way around the problem
> > though.
>
> I wonder whether we shouldn't extend this into VACUUM FULL too, to
> prevent cancel once it's done that internal commit.  It would fix
> the "PANIC: can't abort a committed transaction" problem V.F. has.

Hmm, it seems to work.  The attached is for 8.1.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---

Index: src/backend/commands/vacuum.c
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/commands/vacuum.c,v
retrieving revision 1.317.2.7
diff -c -p -r1.317.2.7 vacuum.c
*** src/backend/commands/vacuum.c 11 Feb 2008 19:14:45 -0000 1.317.2.7
--- src/backend/commands/vacuum.c 6 Nov 2009 17:15:40 -0000
*************** static void vac_update_dbstats(Oid dbid,
*** 206,215 ****
  static void vac_truncate_clog(TransactionId vacuumXID,
   TransactionId frozenXID);
  static bool vacuum_rel(Oid relid, VacuumStmt *vacstmt, char expected_relkind);
! static void full_vacuum_rel(Relation onerel, VacuumStmt *vacstmt);
  static void scan_heap(VRelStats *vacrelstats, Relation onerel,
   VacPageList vacuum_pages, VacPageList fraged_pages);
! static void repair_frag(VRelStats *vacrelstats, Relation onerel,
  VacPageList vacuum_pages, VacPageList fraged_pages,
  int nindexes, Relation *Irel);
  static void move_chain_tuple(Relation rel,
--- 206,215 ----
  static void vac_truncate_clog(TransactionId vacuumXID,
   TransactionId frozenXID);
  static bool vacuum_rel(Oid relid, VacuumStmt *vacstmt, char expected_relkind);
! static bool full_vacuum_rel(Relation onerel, VacuumStmt *vacstmt);
  static void scan_heap(VRelStats *vacrelstats, Relation onerel,
   VacPageList vacuum_pages, VacPageList fraged_pages);
! static bool repair_frag(VRelStats *vacrelstats, Relation onerel,
  VacPageList vacuum_pages, VacPageList fraged_pages,
  int nindexes, Relation *Irel);
  static void move_chain_tuple(Relation rel,
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 963,968 ****
--- 963,969 ----
  bool result;
  Oid save_userid;
  bool save_secdefcxt;
+ bool heldoff;
 
  /* Begin a transaction for vacuuming this relation */
  StartTransactionCommand();
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 1085,1093 ****
  * Do the actual work --- either FULL or "lazy" vacuum
  */
  if (vacstmt->full)
! full_vacuum_rel(onerel, vacstmt);
  else
! lazy_vacuum_rel(onerel, vacstmt);
 
  result = true; /* did the vacuum */
 
--- 1086,1094 ----
  * Do the actual work --- either FULL or "lazy" vacuum
  */
  if (vacstmt->full)
! heldoff = full_vacuum_rel(onerel, vacstmt);
  else
! heldoff = lazy_vacuum_rel(onerel, vacstmt);
 
  result = true; /* did the vacuum */
 
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 1103,1108 ****
--- 1104,1113 ----
  StrategyHintVacuum(false);
  CommitTransactionCommand();
 
+ /* now we can allow interrupts again, if disabled */
+ if (heldoff)
+ RESUME_INTERRUPTS();
+
  /*
  * If the relation has a secondary toast rel, vacuum that too while we
  * still hold the session lock on the master table.  Note however that
*************** vacuum_rel(Oid relid, VacuumStmt *vacstm
*** 1141,1148 ****
   *
   * At entry, we have already established a transaction and opened
   * and locked the relation.
   */
! static void
  full_vacuum_rel(Relation onerel, VacuumStmt *vacstmt)
  {
  VacPageListData vacuum_pages; /* List of pages to vacuum and/or
--- 1146,1157 ----
   *
   * At entry, we have already established a transaction and opened
   * and locked the relation.
+  *
+  * The return value indicates whether this function has held off
+  * interrupts -- caller must call RESUME_INTERRUPTS() after commit if
+  * it is true.
   */
! static bool
  full_vacuum_rel(Relation onerel, VacuumStmt *vacstmt)
  {
  VacPageListData vacuum_pages; /* List of pages to vacuum and/or
*************** full_vacuum_rel(Relation onerel, VacuumS
*** 1153,1158 ****
--- 1162,1168 ----
  int nindexes,
  i;
  VRelStats  *vacrelstats;
+ bool heldoff = false;
 
  vacuum_set_xid_limits(vacstmt, onerel->rd_rel->relisshared,
   &OldestXmin, &FreezeLimit);
*************** full_vacuum_rel(Relation onerel, VacuumS
*** 1194,1201 ****
  if (fraged_pages.num_pages > 0)
  {
  /* Try to shrink heap */
! repair_frag(vacrelstats, onerel, &vacuum_pages, &fraged_pages,
! nindexes, Irel);
  vac_close_indexes(nindexes, Irel, NoLock);
  }
  else
--- 1204,1211 ----
  if (fraged_pages.num_pages > 0)
  {
  /* Try to shrink heap */
! heldoff = repair_frag(vacrelstats, onerel, &vacuum_pages, &fraged_pages,
!    nindexes, Irel);
  vac_close_indexes(nindexes, Irel, NoLock);
  }
  else
*************** full_vacuum_rel(Relation onerel, VacuumS
*** 1218,1223 ****
--- 1228,1235 ----
  /* report results to the stats collector, too */
  pgstat_report_vacuum(RelationGetRelid(onerel), onerel->rd_rel->relisshared,
  vacstmt->analyze, vacrelstats->rel_tuples);
+
+ return heldoff;
  }
 
 
*************** scan_heap(VRelStats *vacrelstats, Relati
*** 1637,1644 ****
   * for them after committing (in hack-manner - without losing locks
   * and freeing memory!) current transaction. It truncates relation
   * if some end-blocks are gone away.
   */
! static void
  repair_frag(VRelStats *vacrelstats, Relation onerel,
  VacPageList vacuum_pages, VacPageList fraged_pages,
  int nindexes, Relation *Irel)
--- 1649,1660 ----
   * for them after committing (in hack-manner - without losing locks
   * and freeing memory!) current transaction. It truncates relation
   * if some end-blocks are gone away.
+  *
+  * The return value indicates whether this function has held off
+  * interrupts -- caller must call RESUME_INTERRUPTS() after commit if
+  * it is true.
   */
! static bool
  repair_frag(VRelStats *vacrelstats, Relation onerel,
  VacPageList vacuum_pages, VacPageList fraged_pages,
  int nindexes, Relation *Irel)
*************** repair_frag(VRelStats *vacrelstats, Rela
*** 1662,1667 ****
--- 1678,1684 ----
  vacuumed_pages;
  int keep_tuples = 0;
  PGRUsage ru0;
+ bool heldoff = false;
 
  pg_rusage_init(&ru0);
 
*************** repair_frag(VRelStats *vacrelstats, Rela
*** 2374,2379 ****
--- 2391,2398 ----
  * For now, a quick hack: record status of current transaction as
  * committed, and continue.
  */
+ HOLD_INTERRUPTS();
+ heldoff = true;
  RecordTransactionCommit();
  }
 
*************** repair_frag(VRelStats *vacrelstats, Rela
*** 2563,2568 ****
--- 2582,2589 ----
  pfree(vacrelstats->vtlinks);
 
  ExecContext_Finish(&ec);
+
+ return heldoff;
  }
 
  /*
Index: src/backend/commands/vacuumlazy.c
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/commands/vacuumlazy.c,v
retrieving revision 1.61.2.7
diff -c -p -r1.61.2.7 vacuumlazy.c
*** src/backend/commands/vacuumlazy.c 6 Jan 2009 14:55:56 -0000 1.61.2.7
--- src/backend/commands/vacuumlazy.c 6 Nov 2009 16:03:37 -0000
*************** static int vac_cmp_page_spaces(const voi
*** 134,141 ****
   *
   * At entry, we have already established a transaction and opened
   * and locked the relation.
   */
! void
  lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt)
  {
  LVRelStats *vacrelstats;
--- 134,145 ----
   *
   * At entry, we have already established a transaction and opened
   * and locked the relation.
+  *
+  * The return value indicates whether this function has held off
+  * interrupts -- caller must call RESUME_INTERRUPTS() after commit if
+  * it is true.
   */
! bool
  lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt)
  {
  LVRelStats *vacrelstats;
*************** lazy_vacuum_rel(Relation onerel, VacuumS
*** 143,148 ****
--- 147,153 ----
  int nindexes;
  bool hasindex;
  BlockNumber possibly_freeable;
+ bool heldoff;
 
  if (vacstmt->verbose)
  elevel = INFO;
*************** lazy_vacuum_rel(Relation onerel, VacuumS
*** 173,184 ****
--- 178,199 ----
  *
  * Don't even think about it unless we have a shot at releasing a goodly
  * number of pages.  Otherwise, the time taken isn't worth it.
+ *
+ * Note that after we've truncated the heap, it's too late to abort the
+ * transaction; doing so would lose the sinval messages needed to tell
+ * the other backends about the table being shrunk.  We hold off interrupts
+ * in that case; the caller is responsible for releasing them after
+ * committing the transaction.
  */
  possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages;
  if (possibly_freeable > 0 &&
  (possibly_freeable >= REL_TRUNCATE_MINIMUM ||
  possibly_freeable >= vacrelstats->rel_pages / REL_TRUNCATE_FRACTION))
+ {
+ HOLD_INTERRUPTS();
+ heldoff = true;
  lazy_truncate_heap(onerel, vacrelstats);
+ }
 
  /* Update shared free space map with final free space info */
  lazy_update_fsm(onerel, vacrelstats);
*************** lazy_vacuum_rel(Relation onerel, VacuumS
*** 192,197 ****
--- 207,214 ----
  /* report results to the stats collector, too */
  pgstat_report_vacuum(RelationGetRelid(onerel), onerel->rd_rel->relisshared,
  vacstmt->analyze, vacrelstats->rel_tuples);
+
+ return heldoff;
  }
 
 
Index: src/include/commands/vacuum.h
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/commands/vacuum.h,v
retrieving revision 1.62
diff -c -p -r1.62 vacuum.h
*** src/include/commands/vacuum.h 15 Oct 2005 02:49:44 -0000 1.62
--- src/include/commands/vacuum.h 6 Nov 2009 14:21:04 -0000
*************** extern bool vac_is_partial_index(Relatio
*** 125,131 ****
  extern void vacuum_delay_point(void);
 
  /* in commands/vacuumlazy.c */
! extern void lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt);
 
  /* in commands/analyze.c */
  extern void analyze_rel(Oid relid, VacuumStmt *vacstmt);
--- 125,131 ----
  extern void vacuum_delay_point(void);
 
  /* in commands/vacuumlazy.c */
! extern bool lazy_vacuum_rel(Relation onerel, VacuumStmt *vacstmt);
 
  /* in commands/analyze.c */
  extern void analyze_rel(Oid relid, VacuumStmt *vacstmt);

---

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

[Tom Lane-2]

Alvaro Herrera <alvherre@...> writes:
> Tom Lane wrote:
>> I wonder whether we shouldn't extend this into VACUUM FULL too, to
>> prevent cancel once it's done that internal commit.  It would fix
>> the "PANIC: can't abort a committed transaction" problem V.F. has.

> Hmm, it seems to work.  The attached is for 8.1.

Looks OK, but please update the comment right before the
RecordTransactionCommit, along the lines of "We prevent cancel
interrupts after this point to mitigate the problem that you
can't abort the transaction now".

                        regards, tom lane

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

[Alvaro Herrera-7]

Tom Lane wrote:

> Alvaro Herrera <alvherre@...> writes:
> > Tom Lane wrote:
> >> I wonder whether we shouldn't extend this into VACUUM FULL too, to
> >> prevent cancel once it's done that internal commit.  It would fix
> >> the "PANIC: can't abort a committed transaction" problem V.F. has.
>
> > Hmm, it seems to work.  The attached is for 8.1.
>
> Looks OK, but please update the comment right before the
> RecordTransactionCommit, along the lines of "We prevent cancel
> interrupts after this point to mitigate the problem that you
> can't abort the transaction now".

BTW I'm thinking in backpatching this all the way back to 7.4 -- are
we agreed on that?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

[Tom Lane-2]

Alvaro Herrera <alvherre@...> writes:
>> Looks OK, but please update the comment right before the
>> RecordTransactionCommit, along the lines of "We prevent cancel
>> interrupts after this point to mitigate the problem that you
>> can't abort the transaction now".

> BTW I'm thinking in backpatching this all the way back to 7.4 -- are
> we agreed on that?

Yeah, I would think the problems can manifest all the way back.

                        regards, tom lane

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

[Alvaro Herrera-7]

Tom Lane wrote:

> Alvaro Herrera <alvherre@...> writes:
> >> Looks OK, but please update the comment right before the
> >> RecordTransactionCommit, along the lines of "We prevent cancel
> >> interrupts after this point to mitigate the problem that you
> >> can't abort the transaction now".
>
> > BTW I'm thinking in backpatching this all the way back to 7.4 -- are
> > we agreed on that?
>
> Yeah, I would think the problems can manifest all the way back.

Done, thanks for the discussion.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

[Pavel Stehule]

2009/11/10 Alvaro Herrera <alvherre@...>:

> Tom Lane wrote:
>> Alvaro Herrera <alvherre@...> writes:
>> >> Looks OK, but please update the comment right before the
>> >> RecordTransactionCommit, along the lines of "We prevent cancel
>> >> interrupts after this point to mitigate the problem that you
>> >> can't abort the transaction now".
>>
>> > BTW I'm thinking in backpatching this all the way back to 7.4 -- are
>> > we agreed on that?
>>
>> Yeah, I would think the problems can manifest all the way back.
>
> Done, thanks for the discussion.

Hello

do you have a idea abou lazy vacuum lockinkg problem?

any plans?

Regards
Pavel Stehule

>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

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

[Alvaro Herrera-7]

Pavel Stehule escribió:

> Hello
>
> do you have a idea abou lazy vacuum lockinkg problem?
>
> any plans?

Well, I understand the issue and we have an idea on how to attack it,
but I have no concrete plans to fix it ATM ...

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

[Pavel Stehule]

2009/11/10 Alvaro Herrera <alvherre@...>:

> Pavel Stehule escribió:
>
>> Hello
>>
>> do you have a idea abou lazy vacuum lockinkg problem?
>>
>> any plans?
>
> Well, I understand the issue and we have an idea on how to attack it,
> but I have no concrete plans to fix it ATM ...

ok
Pavel
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

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