pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

Started by Simon Riggsover 9 years ago5 messages
#1Simon Riggs
simon@2ndQuadrant.com

Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

lazy_truncate_heap() was waiting for
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds
not milliseconds as originally intended.

Found by code inspection.

Simon Riggs

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/dcb12ce8d8691e0e526d3f38d14c4d7fc9c664f5

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

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

#2Fujii Masao
masao.fujii@gmail.com
In reply to: Simon Riggs (#1)
Re: [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

lazy_truncate_heap() was waiting for
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds
not milliseconds as originally intended.

Don't we need to back-patch this?

Regards,

--
Fujii Masao

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

#3Simon Riggs
simon@2ndquadrant.com
In reply to: Fujii Masao (#2)
Re: [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

On 7 September 2016 at 13:47, Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

lazy_truncate_heap() was waiting for
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds
not milliseconds as originally intended.

Don't we need to back-patch this?

If we do then a database-wide VACUUM on a busy database will take
substantially longer than it does now.

That may not be perceived as a "fix" by everybody, so we should not do
it without an explicit agreement by many.

Thoughts?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Simon Riggs (#3)
Re: [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

Simon Riggs <simon@2ndquadrant.com> writes:

On 7 September 2016 at 13:47, Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

lazy_truncate_heap() was waiting for
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds
not milliseconds as originally intended.

Don't we need to back-patch this?

If we do then a database-wide VACUUM on a busy database will take
substantially longer than it does now.

On the other hand, it's also more likely to successfully perform desired
truncations.

That may not be perceived as a "fix" by everybody, so we should not do
it without an explicit agreement by many.

Agreed, but I vote with Fujii-san for back-patching.

regards, tom lane

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

#5Simon Riggs
simon@2ndquadrant.com
In reply to: Tom Lane (#4)
Re: [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

On 7 September 2016 at 14:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:

That may not be perceived as a "fix" by everybody, so we should not do
it without an explicit agreement by many.

Agreed, but I vote with Fujii-san for back-patching.

No problem with backpatching, just wanted some +1s before I did it.

Will do that tomorrow.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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