Hello Andres,
12.03.2023 02:41, Andres Freund wrote:
CI now finished the tests as well:
https://cirrus-ci.com/build/6675457702100992
So I'll go ahead and push that.
As I mentioned at [1], `meson test` fails on Windows x86 platform during
the test pg_amcheck/004_verify_heapam (I'm using VS 202
On 10.05.23 20:04, Andres Freund wrote:
This commit adds a test
is(scalar @lp_off, $ROWCOUNT, "acquired row offsets");
*before* that skip_all call. This appears to be invalid. If the skip_all
happens, you get a complaint like
t/004_verify_heapam.pl (Wstat: 0 Tests: 1 Failed: 0)
Parse erro
Hi,
On 2023-05-10 17:44:07 +0200, Peter Eisentraut wrote:
> On 12.03.23 00:41, Andres Freund wrote:
> > Hi,
> >
> > On 2023-03-11 15:34:55 -0800, Mark Dilger wrote:
> > > > On Mar 11, 2023, at 3:22 PM, Andres Freund wrote:
> > > >
> > > > Something like the attached.
> > >
> > > I like that yo
On 12.03.23 00:41, Andres Freund wrote:
Hi,
On 2023-03-11 15:34:55 -0800, Mark Dilger wrote:
On Mar 11, 2023, at 3:22 PM, Andres Freund wrote:
Something like the attached.
I like that your patch doesn't make the test longer. I assume you've already
run the tests and that it works.
I did
Hi,
On 2023-03-11 15:34:55 -0800, Mark Dilger wrote:
> > On Mar 11, 2023, at 3:22 PM, Andres Freund wrote:
> >
> > Something like the attached.
>
> I like that your patch doesn't make the test longer. I assume you've already
> run the tests and that it works.
I did check that, yes :). My pro
> On Mar 11, 2023, at 3:22 PM, Andres Freund wrote:
>
> Something like the attached.
I like that your patch doesn't make the test longer. I assume you've already
run the tests and that it works.
> I don't know enough perl to know how to interpolate something like
> use constant ROWCOUNT =>
Hi,
On 2023-03-09 12:15:16 -0800, Mark Dilger wrote:
> > Somewhat random note:
> >
> > Is it intentional that we VACUUM FREEZE test ROWCOUNT times? That's
> > effectively O(ROWCOUNT^2), albeit with small enough constants to not really
> > matter. I don't think we need to insert the rows one-by-on
> On Mar 8, 2023, at 4:15 PM, Andres Freund wrote:
>
> I worked some more on the fixes for amcheck, and fixes for amcheck.
>
> The second amcheck fix ends up correcting some inaccurate output in the tests
> - previously xids from before xid 0 were reported to be in the future.
>
> Previously
Hi,
On 2023-02-06 13:02:05 -0800, Andres Freund wrote:
> I didn't quite feel confident pushing a fix for this just before a minor
> release, so I'll push once the minor releases are tagged. A quite minimal fix
> to GetFullRecentGlobalXmin() in 12-13 (returning FirstNormalTransactionId if
> epoch =
Hi,
On 2023-02-04 11:10:55 -0800, Peter Geoghegan wrote:
> On Sat, Feb 4, 2023 at 2:57 AM Andres Freund wrote:
> > Is there a good way to make breakage in the page recycling mechanism
> > visible with gist? I guess to see corruption, I'd have to halt a scan
> > before a page is visited with gdb,
On Sat, Feb 4, 2023 at 2:57 AM Andres Freund wrote:
> Is there a good way to make breakage in the page recycling mechanism
> visible with gist? I guess to see corruption, I'd have to halt a scan
> before a page is visited with gdb, then cause the page to be recycled
> prematurely in another sessio
On Sat, Feb 4, 2023 at 2:57 AM Andres Freund wrote:
>
> Is there a good way to make breakage in the page recycling mechanism
> visible with gist? I guess to see corruption, I'd have to halt a scan
> before a page is visited with gdb, then cause the page to be recycled
> prematurely in another sess
Hello, Andres.
> Not sure I like TransactionIdRetreatSafely() as a name. Maybe
> TransactionIdRetreatClamped() is better?
I think it is better to just replace TransactionIdRetreatedBy.
It is not used anymore after
`v3-0001-WIP-Fix-corruption-due-to-vacuum_defer_cleanup_ag.patch` -
so, it is bette
Hi,
Heikki, Andrey, CCing you because you wrote
commit 6655a7299d835dea9e8e0ba69cc5284611b96f29
Author: Heikki Linnakangas
Date: 2019-07-24 20:24:07 +0300
Use full 64-bit XID for checking if a deleted GiST page is old enough.
On 2023-01-07 19:09:56 -0800, Andres Freund wrote:
> I haven'
On Tue, 31 Jan 2023 at 23:48, Andres Freund wrote:
>
> Hi,
>
> On 2023-01-31 15:05:17 +0100, Matthias van de Meent wrote:
> > If TransactionIdRetreatSafely will be exposed outside procarray.c,
> > then I think the xid pointer should be replaced with normal
> > arguments/returns; both for parity wi
Hi,
On 2023-01-31 15:05:17 +0100, Matthias van de Meent wrote:
> On Mon, 30 Jan 2023 at 21:19, Andres Freund wrote:
> > In an earlier, not posted, version I had an vacuum_defer_cleanup_age
> > specific
> > helper function for this, but it seems likely we'll need it in other places
> > too. So I
On Mon, 30 Jan 2023 at 21:19, Andres Freund wrote:
> On 2023-01-10 21:32:54 +0100, Matthias van de Meent wrote:
> > On Tue, 10 Jan 2023 at 20:14, Andres Freund wrote:
> > > On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> > > What precisely do you mean with "skew" here? Do you just me
Hi,
On 2023-01-10 21:32:54 +0100, Matthias van de Meent wrote:
> On Tue, 10 Jan 2023 at 20:14, Andres Freund wrote:
> > On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> > What precisely do you mean with "skew" here? Do you just mean that it'd
> > take a
> > long time until vacuum_def
Hello.
I have registered it as patch in the commit fest:
https://commitfest.postgresql.org/42/4138/
Best regards,
Michail.
On Tue, 10 Jan 2023 at 20:14, Andres Freund wrote:
>
> Hi,
>
> On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> > On Mon, 9 Jan 2023 at 20:34, Andres Freund wrote:
> > > It's not too hard to fix in individual places, but I suspect that we'll
> > > introduce the bug in future places wi
Hi,
On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> On Mon, 9 Jan 2023 at 20:34, Andres Freund wrote:
> > On 2023-01-09 17:50:10 +0100, Matthias van de Meent wrote:
> > > Wouldn't it be enough to only fix the constructions in
> > > FullXidRelativeTo() and widen_snapshot_xid() (as att
On Mon, 9 Jan 2023 at 20:34, Andres Freund wrote:
> On 2023-01-09 17:50:10 +0100, Matthias van de Meent wrote:
> > Wouldn't it be enough to only fix the constructions in
> > FullXidRelativeTo() and widen_snapshot_xid() (as attached, $topic does
> > not occur with the patch), and (optionally) bump
> On Jan 9, 2023, at 2:07 PM, Andres Freund wrote:
>
> The tests encounter the issue today. If you add
> Assert(TransactionIdIsValid(ctx->next_xid));
> Assert(FullTransactionIdIsValid(ctx->next_fxid));
> early in FullTransactionIdFromXidAndCtx() it'll be hit in the
> amcheck/pg_amcheck tests.
Hi,
On 2023-01-09 13:55:02 -0800, Mark Dilger wrote:
> > On Jan 9, 2023, at 11:34 AM, Andres Freund wrote:
> >
> > 1) Because ctx->next_xid is set after the XidFromFullTransactionId() call in
> > update_cached_xid_range(), we end up using the xid 0 (or an outdated value
> > in
> > subsequent ca
> On Jan 9, 2023, at 11:34 AM, Andres Freund wrote:
>
> 1) Because ctx->next_xid is set after the XidFromFullTransactionId() call in
> update_cached_xid_range(), we end up using the xid 0 (or an outdated value in
> subsequent calls) to determine whether epoch needs to be reduced.
Can you say
On Tue, Jan 10, 2023 at 8:34 AM Andres Freund wrote:
> A different approach would be to represent fxids as *signed* 64bit
> integers. That'd of course loose more range, but could represent everything
> accurately, and would have a compatible on-disk representation on two's
> complement platforms (
Hi,
Robert, Mark, CCing you because of the amcheck aspect (see below).
On 2023-01-09 17:50:10 +0100, Matthias van de Meent wrote:
> On Sun, 8 Jan 2023 at 04:09, Andres Freund wrote:
> > > For a bit I was thinking that we should introduce the notion that a
> > > FullTransactionId can be from the
On Sun, 8 Jan 2023 at 04:09, Andres Freund wrote:
>
> Hi,
>
> On 2023-01-07 16:29:23 -0800, Andres Freund wrote:
> > It's probably not too hard to fix specifically in this one place - we could
> > just clamp vacuum_defer_cleanup_age to be smaller than latest_completed, but
> > it strikes me as as
Hi,
On 2023-01-07 16:29:23 -0800, Andres Freund wrote:
> It's probably not too hard to fix specifically in this one place - we could
> just clamp vacuum_defer_cleanup_age to be smaller than latest_completed, but
> it strikes me as as a somewhat larger issue for the 64it xid infrastructure. I
> sus
Hi,
On 2023-01-07 21:06:06 +0300, Michail Nikolaev wrote:
> 2) It is not an issue at table creation time. Issue is reproducible if
> vacuum_defer_cleanup_age set after table preparation.
>
> 3) To reproduce the issue, vacuum_defer_cleanup_age should flip xid
> over zero (be >= txid_current()).
>
Hi,
Thomas, CCing you because of the 64bit xid representation aspect.
On 2023-01-06 00:39:44 +0300, Michail Nikolaev wrote:
> I apologize for the direct ping, but I think your snapshot scalability
> work in PG14 could be related to the issue.
Good call!
> The TransactionIdRetreatedBy implemen
Hello.
The few things I have got so far:
1) It is not required to order by random() to reproduce the issue - it
could be done using queries like:
BEGIN;
SELECT omg.*
FROM something_is_wrong_here AS omg
ORDER BY value -- change is here
LIMIT 1
FOR U
Hello!
Thanks for checking the issue!
> FWIW, I find that the "Assert(ItemIdIsNormal(lp));" at the top of
> heap_lock_tuple() is the first thing that fails on my assert-enabled
> build.
Yes, the same for me:
TRAP: failed Assert("ItemIdIsNormal(lp)"), File: "heapam.c",
Line: 4292, PID:
On Thu, Jan 5, 2023 at 3:27 PM Peter Geoghegan wrote:
> This particular error message is from the hardening added to Postgres
> 15 in commit e7428a99. So it's not surprising that Michail didn't see
> the same error on 14.
Reproduced this on HEAD locally (no docker), without any difficulty.
FWIW,
On Thu, Jan 5, 2023 at 1:49 PM Matthias van de Meent
wrote:
> client 29 script 0 aborted in command 2 query 0: ERROR: heap tid from index
> tuple (111,1) points past end of heap page line pointer array at offset 262
> of block 1 in index "something_is_wrong_here_pkey"
This particular error mes
On Thu, 5 Jan 2023 at 14:12, Michail Nikolaev
wrote:
>
> Hello, hackers.
>
> It seems like PG 14 works incorrectly with vacuum_defer_cleanup_age
> (or just not cleared rows, not sure) and SELECT FOR UPDATE + UPDATE.
> I am not certain, but hot_standby_feedback probably able to cause the
> same iss
Hello, Andres.
I apologize for the direct ping, but I think your snapshot scalability
work in PG14 could be related to the issue.
The TransactionIdRetreatedBy implementation looks correct... But with
txid_current=212195 I see errors like "could not access status of
transaction 58643736"...
So, ma
Hello, hackers.
It seems like PG 14 works incorrectly with vacuum_defer_cleanup_age
(or just not cleared rows, not sure) and SELECT FOR UPDATE + UPDATE.
I am not certain, but hot_standby_feedback probably able to cause the
same issues.
Steps to reproduce:
1) Start Postgres like this:
dock
38 matches
Mail list logo
