Bruce Momjian 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 cluster at
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 s
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 of
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
> TwoPh
Alex Shulgin writes:
>
> Bruce Momjian 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 attachment, which was
Bruce Momjian 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
From: Ale
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:
>
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.
>
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. Re
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 wr
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 th
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 maili
12 matches
Mail list logo
