On Fri, 21 Mar 2025 at 17:14, Matthias van de Meent
wrote:
> Attached is v10, which polishes the previous patches, and adds a patch
> for nbtree to use the new visibility checking strategy so that it too
> can release its index pages much earlier, and adds a similar
> visibility check test to nbtr
On Sun, 16 Mar 2025 at 13:58, vignesh C wrote:
>
> On Sat, 8 Mar 2025 at 08:06, Matthias van de Meent
> wrote:
> >
> > Here's a patchset that uses that approach. Naming of functions, types,
> > fields and arguments TBD. The patch works and passes the new
> > VACUUM-conflict tests, though I suspec
On Sat, 8 Mar 2025 at 08:06, Matthias van de Meent
wrote:
>
> Here's a patchset that uses that approach. Naming of functions, types,
> fields and arguments TBD. The patch works and passes the new
> VACUUM-conflict tests, though I suspect the SP-GIST tests to have
> bugs, as an intermediate version
Hello, Mathias!
> though I suspect the SP-GIST tests to have
> bugs, as an intermediate version of my 0003 patch didn't trigger the
> tests to fail
It all fails on master - could you please detail what is "intermediate" in
that case? Also, I think it is a good idea to add the same type of test t
(tableslot);
+/* We don't actually need the heap tuple for anything */
+ExecClearTuple(tableslot);
- /*
- * We don't care whether there's more than one visible tuple in
- * the HOT chain; if any are visible, that's good enough.
- */
+/*
+ * We don'
On Wed, 5 Mar 2025 at 10:04, Heikki Linnakangas wrote:
>
> On 28/02/2025 03:53, Peter Geoghegan wrote:
> > On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
> > wrote:
> >> Just some commit messages + few cleanups.
> >
> > I'm worried about this:
> >
> > +These longer pin lifetimes can cause buffer
On 28/02/2025 03:53, Peter Geoghegan wrote:
On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
wrote:
Just some commit messages + few cleanups.
I'm worried about this:
+These longer pin lifetimes can cause buffer exhaustion with messages like "no
+unpinned buffers available" when the index has
On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
wrote:
> Just some commit messages + few cleanups.
I'm worried about this:
+These longer pin lifetimes can cause buffer exhaustion with messages like "no
+unpinned buffers available" when the index has many pages that have similar
+ordering; but fu
Hello, everyone!
Just some commit messages + few cleanups.
Best regards,
Mikhail.
v8-0002-Fix-index-only-scan-race-condition-in-GiST-implem.patch
Description: Binary data
v8-0003-Improve-buffer-handling-for-killed-items-in-GiST-.patch
Description: Binary data
v8-0004-Fix-index-only-scan-rac
Ooops, missed one commit - fixed (logic related to LP_DEAD in GIST
extracted to separate commit).
Also, commitfest entry is here - https://commitfest.postgresql.org/52/5542/
>
v7-0004-This-should-fix-issues-with-incorrect-results-whe.patch
Description: Binary data
v7-0002-This-should-fix-issu
Hello everyone, and Mathias!
I have fixed sp-gist related crash and a few issues in implementation.
Now it passes tests and (in my opinion) feels simpler.
I'll register that thread in commitfest to honor the bureaucracy.
Best regards,
Mikhail.
v6-0003-This-should-fix-issues-with-incorrect-resu
2_mod:
+ DELETE FROM ios_needs_cleanup_lock WHERE a != point '(1,1)';
+
+step s1_begin: BEGIN;
+step s1_prepare_unsorted:
+ DECLARE foo NO SCROLL CURSOR FOR SELECT a FROM ios_needs_cleanup_lock WHERE box '((-100,-100),(100,100))' @> a;
+
+step s1_fetch_1:
+ FETCH FROM
Hello!
Sorry, I should have expressed my thoughts in more detail, as they don't
matter as much as the time you took to answer.
>I don't quite read it as covering IOS. To me, the comment is more
> along the lines of (extensively extended):
My idea was just to add a few more details about the lock
On Thu, 9 Jan 2025 at 22:00, Michail Nikolaev
wrote:
>
> Hello.
>
> One thing I think we could add to the patches is to adapt the 10-years-old
> comment below with notice about IOS:
>
> /*
> * We save the LSN of the page as we read it, so that we know whether it
> * safe to apply LP_DEAD hints to
Hello.
One thing I think we could add to the patches is to adapt the 10-years-old
comment below with notice about IOS:
/*
* We save the LSN of the page as we read it, so that we know whether it
* safe to apply LP_DEAD hints to the page later. This allows us to drop
* the pin for MVCC scans, which
On Sat, 4 Jan 2025 at 02:00, Matthias van de Meent
wrote:
>
> On Tue, 3 Dec 2024 at 17:21, Peter Geoghegan wrote:
> >
> > On Mon, Dec 2, 2024 at 8:18 PM Peter Geoghegan wrote:
> > > Attached is a refined version of a test case I posted earlier on [2],
> > > decisively proving that GiST index-onl
On Tue, 3 Dec 2024 at 17:21, Peter Geoghegan wrote:
>
> On Mon, Dec 2, 2024 at 8:18 PM Peter Geoghegan wrote:
> > Attached is a refined version of a test case I posted earlier on [2],
> > decisively proving that GiST index-only scans are in fact subtly
> > broken. Right now it fails, showing a wr
On Mon, Dec 2, 2024 at 8:18 PM Peter Geoghegan wrote:
> Attached is a refined version of a test case I posted earlier on [2],
> decisively proving that GiST index-only scans are in fact subtly
> broken. Right now it fails, showing a wrong answer to a query. The
> patch adds an isolationtest test c
gist, based on a test
case of Andres'.
Offhand, I think that the only way to fix this is to bring GiST in
line with nbtree: we ought to teach GiST VACUUM to start acquiring
cleanup locks (previously known as super-exclusive locks), and then
teach GiST index-only scans to hold onto a leaf pag
On Tue, Nov 30, 2021 at 5:09 PM Peter Geoghegan wrote:
> Attached draft patch attempts to explain things in this area within
> the nbtree README. There is a much shorter comment about it within
> vacuumlazy.c. I am concerned about GiST index-only scans themselves,
> of course, but I discovered thi
On Tue, Nov 30, 2021 at 5:09 PM Peter Geoghegan wrote:
> I believe that there have been several historic reasons why we need a
> cleanup lock during nbtree VACUUM, and that there is only one
> remaining reason for it today. So the history is unusually complicated.
Minor correction: we actually al
On Fri, Nov 5, 2021 at 3:26 AM Andrey Borodin wrote:
> > 4 нояб. 2021 г., в 20:58, Peter Geoghegan написал(а):
> > That's a pretty unlikely scenario. And even
> > if it happened it would only happen once (until the next time we get
> > unlucky). What are the chances of somebody noticing a more or
> 4 нояб. 2021 г., в 20:58, Peter Geoghegan написал(а):
> That's a pretty unlikely scenario. And even
> if it happened it would only happen once (until the next time we get
> unlucky). What are the chances of somebody noticing a more or less
> once-off, slightly wrong answer?
I'd say next to i
On Thu, Nov 4, 2021 at 8:52 AM Andrey Borodin wrote:
> Let's enumerate steps how things can go wrong.
>
> Backend1: Index-Only scan returns tid and xs_hitup with index_tuple1 on
> index_page1 pointing to heap_tuple1 on page1
>
> Backend2: Remove index_tuple1 and heap_tuple1
>
> Backend3: Mark pag
04.11.2021, 04:33, "Peter Geoghegan" :But what about index-only scans, which GiST also supports? I thinkthat the rules are different there, even though index-only scans usean MVCC snapshot.Let's enumerate steps how things can go wrong.Backend1: Index-Only scan returns tid and xs_hitup with index_
The code in gistvacuum.c is closely based on similar code in nbtree.c,
except that it only acquires an exclusive lock -- not a
super-exclusive lock. I suspect that that's because it seemed
unnecessary; nbtree plain index scans have their own special reasons
for this, that don't apply to GiST. Namel
On Thu, Jan 9, 2020 at 4:41 PM Mahendra Singh Thalor wrote:
>
> On Mon, 9 Dec 2019 at 14:37, Amit Kapila wrote:
> >
> > On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila wrote:
> > >
> > > I have modified the patch for the above points and additionally ran
> > > pgindent. Let me know what you think ab
On Mon, 9 Dec 2019 at 14:37, Amit Kapila wrote:
>
> On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila
wrote:
> >
> > I have modified the patch for the above points and additionally ran
> > pgindent. Let me know what you think about the attached patch?
> >
>
> A new version with a slightly modified comm
On Mon, Dec 9, 2019 at 2:37 PM Amit Kapila wrote:
>
> On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila wrote:
> >
> > I have modified the patch for the above points and additionally ran
> > pgindent. Let me know what you think about the attached patch?
> >
>
> A new version with a slightly modified co
On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila wrote:
>
> I have modified the patch for the above points and additionally ran
> pgindent. Let me know what you think about the attached patch?
>
A new version with a slightly modified commit message.
--
With Regards,
Amit Kapila.
EnterpriseDB: http:/
On Fri, Oct 25, 2019 at 9:22 PM Masahiko Sawada wrote:
>
> On Wed, Oct 23, 2019 at 8:14 PM Amit Kapila wrote:
> >
> > On Tue, Oct 22, 2019 at 2:17 PM Dilip Kumar wrote:
> > >
> > > On Tue, Oct 22, 2019 at 10:53 AM Amit Kapila
> > > wrote:
> > >
> > > I have modified as we discussed. Please ta
On Wed, Oct 23, 2019 at 8:14 PM Amit Kapila wrote:
>
> On Tue, Oct 22, 2019 at 2:17 PM Dilip Kumar wrote:
> >
> > On Tue, Oct 22, 2019 at 10:53 AM Amit Kapila
> > wrote:
> > >
> > > > Basically, only IndexBulkDeleteResult is now shared across the stage
> > > > so we can move all members to Gist
On Tue, Oct 22, 2019 at 2:17 PM Dilip Kumar wrote:
>
> On Tue, Oct 22, 2019 at 10:53 AM Amit Kapila wrote:
> >
> > > Basically, only IndexBulkDeleteResult is now shared across the stage
> > > so we can move all members to GistVacState and completely get rid of
> > > GistBulkDeleteResult?
> > >
>
On Tue, Oct 22, 2019 at 10:53 AM Amit Kapila wrote:
>
> On Tue, Oct 22, 2019 at 10:50 AM Dilip Kumar wrote:
> >
> > On Tue, Oct 22, 2019 at 9:10 AM Amit Kapila wrote:
> > >
> > > On Fri, Oct 18, 2019 at 4:51 PM Dilip Kumar wrote:
> > > >
> > > > I have prepared a first version of the patch. Cu
On Tue, Oct 22, 2019 at 10:50 AM Dilip Kumar wrote:
>
> On Tue, Oct 22, 2019 at 9:10 AM Amit Kapila wrote:
> >
> > On Fri, Oct 18, 2019 at 4:51 PM Dilip Kumar wrote:
> > >
> > > I have prepared a first version of the patch. Currently, I am
> > > performing an empty page deletion for all the cas
On Tue, Oct 22, 2019 at 9:10 AM Amit Kapila wrote:
>
> On Fri, Oct 18, 2019 at 4:51 PM Dilip Kumar wrote:
> >
> > I have prepared a first version of the patch. Currently, I am
> > performing an empty page deletion for all the cases.
> >
>
> Few comments:
> --
> 1.
> -/*
> - *
On Fri, Oct 18, 2019 at 4:51 PM Dilip Kumar wrote:
>
> I have prepared a first version of the patch. Currently, I am
> performing an empty page deletion for all the cases.
>
Few comments:
--
1.
-/*
- * State kept across vacuum stages.
- */
typedef struct
{
- IndexBulkDelete
On Mon, Oct 21, 2019 at 2:58 PM Andrey Borodin wrote:
>
>
>
> > 21 окт. 2019 г., в 11:12, Dilip Kumar написал(а):
> >
> > On Mon, Oct 21, 2019 at 2:30 PM Andrey Borodin wrote:
> >>
> >> I've took a look into the patch, and cannot understand one simple thing...
> >> We should not call gistvacuum_
> 21 окт. 2019 г., в 11:12, Dilip Kumar написал(а):
>
> On Mon, Oct 21, 2019 at 2:30 PM Andrey Borodin wrote:
>>
>> I've took a look into the patch, and cannot understand one simple thing...
>> We should not call gistvacuum_delete_empty_pages() for same gist_stats twice.
>> Another way once
On Mon, Oct 21, 2019 at 2:30 PM Andrey Borodin wrote:
>
> Hi!
>
> > 18 окт. 2019 г., в 13:21, Dilip Kumar написал(а):
> >
> > On Fri, Oct 18, 2019 at 10:55 AM Amit Kapila
> > wrote:
> >>
> >>
> >> I think we can do it in general as adding some check for parallel
> >> vacuum there will look bit
Hi!
> 18 окт. 2019 г., в 13:21, Dilip Kumar написал(а):
>
> On Fri, Oct 18, 2019 at 10:55 AM Amit Kapila wrote:
>>
>>
>> I think we can do it in general as adding some check for parallel
>> vacuum there will look bit hackish.
> I agree with that point.
> It is not clear if we get enough
>> be
On Mon, Oct 21, 2019 at 11:23 AM Amit Kapila wrote:
>
> On Fri, Oct 18, 2019 at 10:48 AM Amit Kapila wrote:
> >
> > Thanks for the test. It shows that prior to patch the memory was
> > getting leaked in TopTransactionContext during multi-pass vacuum and
> > after patch, there is no leak. I will
On Fri, Oct 18, 2019 at 10:48 AM Amit Kapila wrote:
>
> Thanks for the test. It shows that prior to patch the memory was
> getting leaked in TopTransactionContext during multi-pass vacuum and
> after patch, there is no leak. I will commit the patch early next
> week unless Heikki or someone want
On Fri, Oct 18, 2019 at 10:55 AM Amit Kapila wrote:
>
> On Fri, Oct 18, 2019 at 9:41 AM Dilip Kumar wrote:
> >
> > On Wed, Oct 16, 2019 at 7:22 PM Heikki Linnakangas wrote:
> > >
> > > On 16 October 2019 12:57:03 CEST, Amit Kapila
> > > wrote:
> > > >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linn
On Fri, Oct 18, 2019 at 9:41 AM Dilip Kumar wrote:
>
> On Wed, Oct 16, 2019 at 7:22 PM Heikki Linnakangas wrote:
> >
> > On 16 October 2019 12:57:03 CEST, Amit Kapila
> > wrote:
> > >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
> > >wrote:
> > >> All things
> > >> considered, I'm not sur
On Fri, Oct 18, 2019 at 9:34 AM Dilip Kumar wrote:
>
> On Thu, Oct 17, 2019 at 6:32 PM Dilip Kumar wrote:
> >
> > On Thu, 17 Oct 2019, 14:59 Amit Kapila, wrote:
> >>
> >> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
> >> >
> >> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas
> >>
On Wed, Oct 16, 2019 at 7:22 PM Heikki Linnakangas wrote:
>
> On 16 October 2019 12:57:03 CEST, Amit Kapila wrote:
> >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
> >wrote:
> >> All things
> >> considered, I'm not sure which is better.
> >
> >Yeah, this is a tough call to make, but if we c
Context using the MemoryContextStats function from gdb.
For testing this, in gistvacuumscan every time, after it resets the
page_set_context, I have collected the sample. I have collected 3
samples for both the head and the patch. We can clearly see that on
the head the memory is getting accumulated
On Thu, 17 Oct 2019, 14:59 Amit Kapila, wrote:
> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
> >
> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas
> wrote:
> > >
> > > On 17/10/2019 05:31, Amit Kapila wrote:
> > > >
> > > > The patch looks good to me. I have slightly modified the
On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
>
> On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas wrote:
> >
> > On 17/10/2019 05:31, Amit Kapila wrote:
> > >
> > > The patch looks good to me. I have slightly modified the comments and
> > > removed unnecessary initialization.
> > >
> >
On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas wrote:
>
> On 17/10/2019 05:31, Amit Kapila wrote:
> > On Wed, Oct 16, 2019 at 11:20 AM Dilip Kumar wrote:
> >>
> >> On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
> >>>
> >>> On 15/10/2019 09:37, Amit Kapila wrote:
> While revi
On 17/10/2019 05:31, Amit Kapila wrote:
On Wed, Oct 16, 2019 at 11:20 AM Dilip Kumar wrote:
On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
On 15/10/2019 09:37, Amit Kapila wrote:
While reviewing a parallel vacuum patch [1], we noticed a few things
about $SUBJECT implemented in c
On Thu, Oct 17, 2019 at 9:15 AM Amit Kapila wrote:
>
> On Wed, Oct 16, 2019 at 7:21 PM Heikki Linnakangas wrote:
> >
> > On 16 October 2019 12:57:03 CEST, Amit Kapila
> > wrote:
> > >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
> > >wrote:
> > >> All things
> > >> considered, I'm not sur
On Wed, Oct 16, 2019 at 7:21 PM Heikki Linnakangas wrote:
>
> On 16 October 2019 12:57:03 CEST, Amit Kapila wrote:
> >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
> >wrote:
> >> All things
> >> considered, I'm not sure which is better.
> >
> >Yeah, this is a tough call to make, but if we c
On Wed, Oct 16, 2019 at 11:20 AM Dilip Kumar wrote:
>
> On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
> >
> > On 15/10/2019 09:37, Amit Kapila wrote:
> > > While reviewing a parallel vacuum patch [1], we noticed a few things
> > > about $SUBJECT implemented in commit -
> > > 7df159a62
On 16 October 2019 12:57:03 CEST, Amit Kapila wrote:
>On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
>wrote:
>> All things
>> considered, I'm not sure which is better.
>
>Yeah, this is a tough call to make, but if we can allow it to delete
>the pages in bulkdelete conditionally for parallel v
On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
>
> On 15/10/2019 09:37, Amit Kapila wrote:
> > 2. Right now, in gistbulkdelete we make a note of empty leaf pages and
> > internals pages and then in the second pass during gistvacuumcleanup,
> > we delete all the empty leaf pages. I was
On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
>
> On 15/10/2019 09:37, Amit Kapila wrote:
> > While reviewing a parallel vacuum patch [1], we noticed a few things
> > about $SUBJECT implemented in commit -
> > 7df159a620b760e289f1795b13542ed1b3e13b87.
> >
> > 1. A new memory context Gi
On 15/10/2019 09:37, Amit Kapila wrote:
While reviewing a parallel vacuum patch [1], we noticed a few things
about $SUBJECT implemented in commit -
7df159a620b760e289f1795b13542ed1b3e13b87.
1. A new memory context GistBulkDeleteResult->page_set_context has
been introduced, but it doesn't seem to
While reviewing a parallel vacuum patch [1], we noticed a few things
about $SUBJECT implemented in commit -
7df159a620b760e289f1795b13542ed1b3e13b87.
1. A new memory context GistBulkDeleteResult->page_set_context has
been introduced, but it doesn't seem to be used.
2. Right now, in gistbulkdelete
On Wed, Jul 24, 2019 at 11:33 AM Heikki Linnakangas wrote:
> That's probably how it's going to go, but hey, doesn't hurt to ask :-).
I think that it would be fine to be conservative with nbtree, and only
target the master branch. The problem is annoying, certainly, but it's
not likely to make a h
On 24/07/2019 21:02, Peter Geoghegan wrote:
On Wed, Jul 24, 2019 at 10:30 AM Heikki Linnakangas wrote:
Pushed this now, to master and REL_12_STABLE.
Now, B-tree indexes still have the same problem, in all versions. Any
volunteers to write a similar fix for B-trees?
I was hoping that you'd wo
On Wed, Jul 24, 2019 at 10:30 AM Heikki Linnakangas wrote:
> Pushed this now, to master and REL_12_STABLE.
>
> Now, B-tree indexes still have the same problem, in all versions. Any
> volunteers to write a similar fix for B-trees?
I was hoping that you'd work on it. :-)
Any reason to think that
On 22/07/2019 16:09, Heikki Linnakangas wrote:
Unless something comes up, I'll commit this tomorrow.
Pushed this now, to master and REL_12_STABLE.
Now, B-tree indexes still have the same problem, in all versions. Any
volunteers to write a similar fix for B-trees?
- Heikki
e that there'll hopefully be a fxid horizon available in a
later release?
I came up with the attached. Instead of having a general purpose "widen"
function, it adds GetFullRecentGlobalXmin(), to return a 64-bit version
of RecentGlobalXmin. That's enough for this Gist
On Fri, Jun 28, 2019 at 3:32 AM Thomas Munro wrote:
>
> On Thu, Jun 27, 2019 at 11:38 PM Heikki Linnakangas wrote:
> > * I moved the logic to extend a 32-bit XID to 64-bits to a new helper
> > function in varsup.c.
>
> I'm a bit uneasy about making this into a generally available function
> for r
On Thu, Apr 4, 2019 at 8:15 AM Heikki Linnakangas wrote:
> I think we should fix this in a similar manner in B-tree, too, but that
> can be done separately. For B-tree, we need to worry about
> backwards-compatibility, but that seems simple enough; we just need to
> continue to understand old dele
On Thu, Jun 27, 2019 at 11:38 PM Heikki Linnakangas wrote:
> * I moved the logic to extend a 32-bit XID to 64-bits to a new helper
> function in varsup.c.
I'm a bit uneasy about making this into a generally available function
for reuse. I think we should instead come up with a very small number
On 27/06/2019 20:15, Andrey Borodin wrote:
But I have stupid question again, about this code:
https://github.com/x4m/postgres_g/commit/096d5586537d29ff316ca8ce074bbe1b325879ee#diff-754126824470cb8e68fd5e32af6d3bcaR417
nextFullXid = ReadNextFullTransactionId();
> 27 июня 2019 г., в 16:38, Heikki Linnakangas написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an
> environment ready to test this?
Patches do not deadlock and delete pages on "rescan test" - setup that we used
to detect "left jumps" in during develo
> 27 июня 2019 г., в 16:38, Heikki Linnakangas написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an
> environment ready to test this?
Thanks!
I will do some testing this evening (UTC+5). But I'm not sure I can reliably
test wraparound of xids...
I wil
On 26/06/2019 06:07, Thomas Munro wrote:
On Wed, Jun 26, 2019 at 2:33 PM Michael Paquier wrote:
On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote:
I feel a little uncomfortable with number 0x7fff right in code.
PG_INT32_MAX...
MaxTransactionId / 2?
Yeah, that makes sense
On Wed, Jun 26, 2019 at 2:33 PM Michael Paquier wrote:
> On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote:
> > I feel a little uncomfortable with number 0x7fff right in code.
>
> PG_INT32_MAX...
MaxTransactionId / 2?
--
Thomas Munro
https://enterprisedb.com
On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote:
> I feel a little uncomfortable with number 0x7fff right in code.
PG_INT32_MAX...
--
Michael
signature.asc
Description: PGP signature
Hi!
Thanks for clarification, now I understand these patches better.
> 25 июня 2019 г., в 13:10, Heikki Linnakangas написал(а):
>
>> Also, I did not understand this optimization:
>> +/*
>> + * We can skip this if the page was deleted so long ago, that no scan
>> can possibly
>> + *
(Thanks for the reminder on this, Michael!)
On 05/04/2019 08:39, Andrey Borodin wrote:
4 апр. 2019 г., в 20:15, Heikki Linnakangas написал(а):
I suggest that we do the attached. It fixes this for GiST. The
patch changes expands the "deletion XID" to 64-bits, and changes
where it's stored. Inst
Heikki,
On Thu, Apr 04, 2019 at 06:15:21PM +0300, Heikki Linnakangas wrote:
> I think we should fix this in a similar manner in B-tree, too, but that can
> be done separately. For B-tree, we need to worry about
> backwards-compatibility, but that seems simple enough; we just need to
> continue to
Hi!
> 4 апр. 2019 г., в 20:15, Heikki Linnakangas написал(а):
>
> On 25/03/2019 15:20, Heikki Linnakangas wrote:
>> On 24/03/2019 18:50, Andrey Borodin wrote:
>>> I was working on new version of gist check in amcheck and understand one
>>> more thing:
>>>
>>> /* Can this page be recycled yet?
On 25/03/2019 15:20, Heikki Linnakangas wrote:
On 24/03/2019 18:50, Andrey Borodin wrote:
I was working on new version of gist check in amcheck and understand one more
thing:
/* Can this page be recycled yet? */
bool
gistPageRecyclable(Page page)
{
return PageIsNew(page) ||
(Gi
On 24/03/2019 18:50, Andrey Borodin wrote:
I was working on new version of gist check in amcheck and understand one more
thing:
/* Can this page be recycled yet? */
bool
gistPageRecyclable(Page page)
{
return PageIsNew(page) ||
(GistPageIsDeleted(page) &&
TransactionIdPr
> 22 марта 2019 г., в 17:03, Heikki Linnakangas написал(а):
>
I was working on new version of gist check in amcheck and understand one more
thing:
/* Can this page be recycled yet? */
bool
gistPageRecyclable(Page page)
{
return PageIsNew(page) ||
(GistPageIsDeleted(page) &&
> 22 марта 2019 г., в 19:37, Heikki Linnakangas написал(а):
>
> On 21/03/2019 19:04, Heikki Linnakangas wrote:
>> Attached is the latest patch version, to be applied on top of the
>> IntegerSet patch.
>
> And committed. Thanks Andrey!
>
> - Heikki
Cool! Thank you very much! At the beginning
On 22/03/2019 13:37, Heikki Linnakangas wrote:
On 21/03/2019 19:04, Heikki Linnakangas wrote:
Attached is the latest patch version, to be applied on top of the
IntegerSet patch.
And committed. Thanks Andrey!
This caused the buildfarm to go pink... I was able to reproduce it, by
running the
On 21/03/2019 19:04, Heikki Linnakangas wrote:
Attached is the latest patch version, to be applied on top of the
IntegerSet patch.
And committed. Thanks Andrey!
- Heikki
On 22/03/2019 10:00, Andrey Borodin wrote:
22 марта 2019 г., в 1:04, Heikki Linnakangas
написал(а):
PS. for Gist, we could almost use the LSN / NSN mechanism to detect
the case that a deleted page is reused: Add a new field to the GiST
page header, to store a new "deleteNSN" field. When a page
> 22 марта 2019 г., в 1:04, Heikki Linnakangas написал(а):
> ...
> When I started testing this, I quickly noticed that empty pages were not
> being deleted nearly as much as I expected. I tracked it to this check in
> gistdeletepage:
>
>> + if (GistFollowRight(leafPage)
>> +
that would require adding a new field to the
gist page header/footer, which requires upgrade work :-(. Maybe one day,
we'll bite the bullet. Something to keep in mind, if we have to change
the page format anyway, for some reason.
- Heikki
>From d7a77ad483251b62514778d2235516f6f9237ad7
> 21 марта 2019 г., в 2:30, Heikki Linnakangas написал(а):
> one remaining issue that needs to be fixed:
>
> During Hot Standby, the B-tree code writes a WAL reord, when a deleted
> page is recycled, to prevent the deletion from being replayed too early
> in the hot standby. See _bt_getbuf()
set is implemented as a B-tree, with a compact representation at leaf
items, using Simple-8b algorithm, so that clusters of nearby values take
less space.
This doesn't include any use of the code yet, but we have two patches in
the works that would benefit from this:
* the GiST vacuum patch
set is implemented as a B-tree, with a compact representation at leaf
items, using Simple-8b algorithm, so that clusters of nearby values take
less space.
This doesn't include any use of the code yet, but we have two patches in
the works that would benefit from this:
* the GiST vacuum patch
On Tue, Mar 5, 2019 at 8:21 AM Heikki Linnakangas wrote:
> On 05/03/2019 02:26, Andrey Borodin wrote:
> >> I also tried your amcheck tool with this. It did not report any
> >> errors.
> >>
> >> Attached is also latest version of the patch itself. It is the
> >> same as your latest patch v19, exce
te a messy rebase.
BTW, you deleted numEmptyPages, this makes code cleaner, but this variable
could stop gistvacuum_recycle_pages() when everything is recycled already.
Thanks!
Best regards, Andrey Borodin.
0001-Add-block-set-data-structure-v22.patch
Description: Binary data
0002-Delet
ock set did agree with bitmapset item %X"
+ " test_limit %d, point index %d",
+ blockno, test_limit, point_index);
+ }
+ }
+
+ blockset_free(bs);
+ bms_free(bms);
+}
diff --git a/src/test/modules/test_blockset/test_blockset.control b/src/test/modules/test_blockset/test_block
> 5 марта 2019 г., в 18:21, Heikki Linnakangas написал(а):
>
> On 05/03/2019 02:26, Andrey Borodin wrote:
>>
>> That's cool! I'll work on 2nd step of these patchset to make
>> blockset data structure prettier and less hacky.
>
> Committed the first patch. Thanks for the patch!
That's cool! Th
On 05/03/2019 02:26, Andrey Borodin wrote:
I also tried your amcheck tool with this. It did not report any
errors.
Attached is also latest version of the patch itself. It is the
same as your latest patch v19, except for some tiny comment
kibitzing. I'll mark this as Ready for Committer in the c
Hi!
Thanks for fixing gist amcheck! The idea of using these two patches together
seems so obvious now, but never actually visited my mind before.
> 4 марта 2019 г., в 18:04, Heikki Linnakangas написал(а):
> Thanks! As I noted at
> https://www.postgresql.org/message-id/2ff57b1f-01b4-eacf-36a2-4
s Ready for Committer in the commitfest app, and will try to
commit it in the next couple of days.
- Heikki
gist-vacuum-test.sh
Description: application/shellscript
diff --git a/src/backend/access/gist/gist.c b/src/backend/access/gist/gist.c
index 3f52b8f4dc..cad4a2a46e 100644
--- a/src/bac
On 04/01/2019 21:26, Andrey Borodin wrote:
3 янв. 2019 г., в 23:47, Andrey Borodin
написал(а):
* Bitmapset stores 32 bit signed integers, but BlockNumber is
unsigned. So this will fail with an index larger than 2^31
blocks. That's perhaps academical, I don't think anyone will try
to create a
On Fri, Jan 04, 2019 at 06:26:18PM +0500, Andrey Borodin wrote:
> Heikki, how do you think, is implementing our own radix tree for
> this is viable solution?
> I've written working implementation with 4-level statically typed
> tree. If we follow this route, probably, there must be tests for
> thi
3 янв. 2019 г., в 23:47, Andrey Borodin написал(а):
>
>> * Bitmapset stores 32 bit signed integers, but BlockNumber is unsigned. So
>> this will fail with an index larger than 2^31 blocks. That's perhaps
>> academical, I don't think anyone will try to create a 16 TB GiST index any
>> time soon
1 - 100 of 159 matches
Mail list logo
