On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan wrote:
> On Thu, Dec 29, 2022 at 12:00 PM Andres Freund wrote:
> > > I could just move the same tests from heap_prepare_freeze_tuple() to
> > > heap_freeze_execute_prepared(), without changing any of the details.
> >
> > That might work, yes.
>
> A
On Thu, Dec 29, 2022 at 12:50 PM Peter Geoghegan wrote:
> On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan wrote:
> > > It seems somewhat wrong that we discard all the work that
> > > heap_prepare_freeze_tuple() did. Yes, we force freezing to actually
> > > happen in
> > > a bunch of important c
On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan wrote:
> > It seems somewhat wrong that we discard all the work that
> > heap_prepare_freeze_tuple() did. Yes, we force freezing to actually happen
> > in
> > a bunch of important cases (e.g. creating a new multixact), but even so,
> > e.g. GetMult
On Thu, Dec 29, 2022 at 12:00 PM Andres Freund wrote:
> > I could just move the same tests from heap_prepare_freeze_tuple() to
> > heap_freeze_execute_prepared(), without changing any of the details.
>
> That might work, yes.
Attached patch shows how that could work.
> It seems somewhat wrong th
Hi,
On 2022-12-29 09:43:39 -0800, Peter Geoghegan wrote:
> On Thu, Dec 29, 2022 at 9:21 AM Andres Freund wrote:
> > I do think we wanted to avoid reviving actually-dead tuples (present due to
> > the multixact and related bugs). And I'm worried about giving that checking
> > up, I've seen it hit
On Thu, Dec 29, 2022 at 9:21 AM Andres Freund wrote:
> I do think we wanted to avoid reviving actually-dead tuples (present due to
> the multixact and related bugs). And I'm worried about giving that checking
> up, I've seen it hit too many times. Both in the real world and during
> development.
Andres Freund writes:
> Somewhat of a tangent: I've previously wondered if we should have a small
> hash-table based clog cache. The current one-element cache doesn't suffice in
> a lot of scenarios, but it wouldn't take a huge cache to end up filtering most
> clog accesses.
I've wondered about t
Hi,
On 2022-12-28 22:36:53 -0800, Peter Geoghegan wrote:
> On Wed, Dec 28, 2022 at 4:43 PM Andres Freund wrote:
> > > > Hm. I dimply recall that we had repeated cases where the hint bits were
> > > > set
> > > > wrongly due to some of the multixact related bugs. I think I was trying
> > > > to
On Wed, Dec 28, 2022 at 4:43 PM Andres Freund wrote:
> > > Hm. I dimply recall that we had repeated cases where the hint bits were
> > > set
> > > wrongly due to some of the multixact related bugs. I think I was trying
> > > to be
> > > paranoid about not freezing stuff in those situations, sinc
On 2022-12-28 16:37:27 -0800, Peter Geoghegan wrote:
> On Wed, Dec 28, 2022 at 4:20 PM Andres Freund wrote:
> > > Theoretically this is an old issue that dates back to commit
> > > 699bf7d05c, as opposed to an issue in the page-level freezing patch.
> > > But that's not really true in a real pract
On Wed, Dec 28, 2022 at 4:20 PM Andres Freund wrote:
> > Theoretically this is an old issue that dates back to commit
> > 699bf7d05c, as opposed to an issue in the page-level freezing patch.
> > But that's not really true in a real practical sense. In practice the
> > calls to TransactionIdDidComm
Hi,
On 2022-12-28 15:24:28 -0800, Peter Geoghegan wrote:
> I took another look at the code coverage situation around freezing
> following pushing the page-level freezing patch earlier today. I
> spotted an issue that I'd missed up until now: certain sanity checks
> in heap_prepare_freeze_tuple() c
I took another look at the code coverage situation around freezing
following pushing the page-level freezing patch earlier today. I
spotted an issue that I'd missed up until now: certain sanity checks
in heap_prepare_freeze_tuple() call TransactionIdDidCommit() more
often than really seems necessar
13 matches
Mail list logo
