On Thu, 22 Sept 2022 at 15:16, Alvaro Herrera wrote:
>
> On 2022-Sep-22, Simon Riggs wrote:
>
> > On Mon, 19 Sept 2022 at 00:16, Greg Stark wrote:
>
> > > VACUUM was willing to remove a committed-dead tuple immediately if it
> > > was
> > > deleted by the same transaction that inserted i
On 2022-Sep-22, Simon Riggs wrote:
> On Mon, 19 Sept 2022 at 00:16, Greg Stark wrote:
> > VACUUM was willing to remove a committed-dead tuple immediately if it
> > was
> > deleted by the same transaction that inserted it. The idea is that
> > such a
> > tuple could never have been
On Mon, 19 Sept 2022 at 00:16, Greg Stark wrote:
>
> On Fri, 16 Sept 2022 at 10:27, Tom Lane wrote:
> >
> > Simon Riggs writes:
> > > A user asked me whether we prune never visible changes, such as
> > > BEGIN;
> > > INSERT...
> > > UPDATE.. (same row)
> > > COMMIT;
> >
> > Didn't we just have t
On Mon, 19 Sept 2022 at 01:16, Greg Stark wrote:
>
> On Fri, 16 Sept 2022 at 10:27, Tom Lane wrote:
> >
> > Simon Riggs writes:
> > > A user asked me whether we prune never visible changes, such as
> > > BEGIN;
> > > INSERT...
> > > UPDATE.. (same row)
> > > COMMIT;
> >
> > Didn't we just have t
On Fri, 16 Sept 2022 at 10:27, Tom Lane wrote:
>
> Simon Riggs writes:
> > A user asked me whether we prune never visible changes, such as
> > BEGIN;
> > INSERT...
> > UPDATE.. (same row)
> > COMMIT;
>
> Didn't we just have this discussion in another thread?
Well. not "just" :)
commit 44e4
On Fri, 16 Sept 2022 at 18:37, Tom Lane wrote:
>
> Simon Riggs writes:
> > On Fri, 16 Sept 2022 at 15:26, Tom Lane wrote:
> >> You cannot
> >> do that, at least not without checking that the originating
> >> transaction has no snapshots that could see the older row version.
>
> > I'm saying this
On Fri, 16 Sept 2022 at 21:07, Laurenz Albe wrote:
>
> On Fri, 2022-09-16 at 10:26 -0400, Tom Lane wrote:
> > Simon Riggs writes:
> > > A user asked me whether we prune never visible changes, such as
> > > BEGIN;
> > > INSERT...
> > > UPDATE.. (same row)
> > > COMMIT;
> >
> > Didn't we just have
On Fri, 2022-09-16 at 10:26 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > A user asked me whether we prune never visible changes, such as
> > BEGIN;
> > INSERT...
> > UPDATE.. (same row)
> > COMMIT;
>
> Didn't we just have this discussion in another thread?
For reference: that was
https://pos
Simon Riggs writes:
> On Fri, 16 Sept 2022 at 15:26, Tom Lane wrote:
>> You cannot
>> do that, at least not without checking that the originating
>> transaction has no snapshots that could see the older row version.
> I'm saying this is possible only AFTER the end of the originating
> xact, so t
On Fri, 16 Sept 2022 at 15:26, Tom Lane wrote:
>
> Simon Riggs writes:
> > A user asked me whether we prune never visible changes, such as
> > BEGIN;
> > INSERT...
> > UPDATE.. (same row)
> > COMMIT;
>
> Didn't we just have this discussion in another thread?
Not that I was aware of, but it sound
Simon Riggs writes:
> A user asked me whether we prune never visible changes, such as
> BEGIN;
> INSERT...
> UPDATE.. (same row)
> COMMIT;
Didn't we just have this discussion in another thread? You cannot
do that, at least not without checking that the originating
transaction has no snapshots th
A user asked me whether we prune never visible changes, such as
BEGIN;
INSERT...
UPDATE.. (same row)
COMMIT;
Once committed, the original insert is no longer visible to anyone, so
"ought to be able to be pruned", sayeth the user. And they also say
that changing the app is much harder, as ever.
A
12 matches
Mail list logo
