On 12/10/2014 03:04 AM, Alvaro Herrera wrote:
Alex Shulgin wrote:
The 2PC part requires extending bool flag to fit the trunc flag, is this
approach sane? Given that 2PC transaction should survive server
restart, it's reasonable to expect it to also survive the upgrade, so I
see no clean way
On Wed, Dec 10, 2014 at 10:32:42AM +0200, Heikki Linnakangas wrote:
I don't think we need to have 2PC files survive a pg_upgrade. It seems
perfectly okay to remove them from the new cluster at some appropriate
time, *if* they are copied from the old cluster at all (I don't think
they should
Bruce Momjian br...@momjian.us writes:
On Wed, Dec 10, 2014 at 10:32:42AM +0200, Heikki Linnakangas wrote:
I don't think we need to have 2PC files survive a pg_upgrade. It seems
perfectly okay to remove them from the new cluster at some appropriate
time, *if* they are copied from the old
Bruce Momjian br...@momjian.us writes:
Added to TODO:
o Clear table counters on TRUNCATE
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
Hello,
Attached is a WIP patch for this TODO.
From 97665ef1ca7d1847e90d4dfab38562135f01fb2b Mon Sep 17 00:00:00 2001
Alex Shulgin a...@commandprompt.com writes:
Bruce Momjian br...@momjian.us writes:
Added to TODO:
o Clear table counters on TRUNCATE
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
Hello,
Attached is a WIP patch for this TODO.
This part went as an
Alex Shulgin wrote:
The 2PC part requires extending bool flag to fit the trunc flag, is this
approach sane? Given that 2PC transaction should survive server
restart, it's reasonable to expect it to also survive the upgrade, so I
see no clean way of adding another bool field to the
Added to TODO:
o Clear table counters on TRUNCATE
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Just
Just noticed that TRUNCATE fails to clear the stats collector's counts
for the table. I am not sure if it should reset the event counts or
not (any thoughts?) but surely it is wrong to not zero the live/dead
tuple counts.
regards, tom lane
--
Sent via pgsql-hackers
On Thu, Apr 03, 2008 at 11:58:11AM -0400, Tom Lane wrote:
Just noticed that TRUNCATE fails to clear the stats collector's counts
for the table. I am not sure if it should reset the event counts or
not (any thoughts?) but surely it is wrong to not zero the live/dead
tuple counts.
Wern't there
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Thu, Apr 03, 2008 at 11:58:11AM -0400, Tom Lane wrote:
Just noticed that TRUNCATE fails to clear the stats collector's counts
for the table. I am not sure if it should reset the event counts or
not (any thoughts?) but surely it is wrong to
Tom Lane wrote:
Just noticed that TRUNCATE fails to clear the stats collector's counts
for the table. I am not sure if it should reset the event counts or
not (any thoughts?) but surely it is wrong to not zero the live/dead
tuple counts.
Agreed, the live/dead counters should be reset.
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Just noticed that TRUNCATE fails to clear the stats collector's counts
for the table. I am not sure if it should reset the event counts or
not (any thoughts?) but surely it is wrong to not zero the live/dead
tuple counts.
Agreed, the
12 matches
Mail list logo
