On Mon, Sep 21, 2020 at 1:11 PM Andres Freund wrote:
> > I'm not sure I really understand how that's happening, because surely
> > HOT chains and non-HOT chains are pruned by the same code, but it
> > doesn't sound good.
>
> Not necessarily, unfortunately:
>
> case HEAPTUPLE_DEAD:
> So if
Hi,
On 2020-10-15 01:37:35 -0700, Andres Freund wrote:
> Attached is a *prototype* implemention of this concept, which clearly is
> lacking some comment work (and is intentionally lacking some
> re-indentation).
>
> I described my thoughts about how to limit the horizons for temp tables in
> http
Hi,
On 2020-10-27 20:51:10 -0700, Andres Freund wrote:
> On 2020-10-15 01:37:35 -0700, Andres Freund wrote:
> > Attached is a *prototype* implemention of this concept, which clearly is
> > lacking some comment work (and is intentionally lacking some
> > re-indentation).
> >
> > I described my tho
On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> Just pushed this. Let's see what the BF says...
It says that apparently something is unstable about my new test. It
first passed on a few animals, but then failed a lot in a row. Looking.
Hi,
On 2020-10-28 19:09:14 -0700, Andres Freund wrote:
> On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> > Just pushed this. Let's see what the BF says...
>
> It says that apparently something is unstable about my new test. It
> first passed on a few animals, but then failed a lot in a row.
Hi,
On 2020-10-28 21:00:30 -0700, Andres Freund wrote:
> On 2020-10-28 19:09:14 -0700, Andres Freund wrote:
> > On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> > > Just pushed this. Let's see what the BF says...
> >
> > It says that apparently something is unstable about my new test. It
> >
Hi hackers!
Does anyone maintain opensource pg_surgery analogs for released versions of PG?
It seems to me I'll have to use something like this and I just though that I
should consider pg_surgery in favour of our pg_dirty_hands.
Thanks!
Best regards, Andrey Borodin.
On Sat, Jan 16, 2021 at 10:41 AM Andrey Borodin wrote:
> Does anyone maintain opensource pg_surgery analogs for released versions of
> PG?
> It seems to me I'll have to use something like this and I just though that I
> should consider pg_surgery in favour of our pg_dirty_hands.
I do not. I'm s
On Mon, Jan 18, 2021 at 08:54:10AM -0500, Robert Haas wrote:
> On Sat, Jan 16, 2021 at 10:41 AM Andrey Borodin wrote:
> > Does anyone maintain opensource pg_surgery analogs for released
> > versions of PG? It seems to me I'll have to use something like this
> > and I just though that I should con
On Mon, Jan 18, 2021 at 9:25 AM Michael Banck wrote:
> One other possiblity would be to push a version of pg_surgery that is
> compatible with the back-branches somewhere external (e.g. either
> git.postgresql.org and/or Github), so that it can be picked up by
> distributions and/or individual use
> 18 янв. 2021 г., в 18:54, Robert Haas написал(а):
>
> On Sat, Jan 16, 2021 at 10:41 AM Andrey Borodin wrote:
>> Does anyone maintain opensource pg_surgery analogs for released versions of
>> PG?
>> It seems to me I'll have to use something like this and I just though that I
>> should cons
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> - Do people think it would me smart/good/useful to include something
> like this in PostgreSQL?
Absolutely, yes.
> - If so, how? I would propose a new contrib module that we back-patch
> all the way, because the VACUUM errors were back-pa
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> - If so, how? I would propose a new contrib module that we back-patch
>> all the way, because the VACUUM errors were back-patched all the way,
>> and there seems to be no advantage in making people wait 5 years for a
>> new ve
On Mon, Jul 13, 2020 at 2:12 PM Robert Haas wrote:
> 1. There's nothing to identify the tuple that has the problem, and no
> way to know how many more of them there might be. Back-patching
> b61d161c146328ae6ba9ed937862d66e5c8b035a would help with the first
> part of this.
I am in favor of backpa
Hi,
On 2020-07-13 17:12:18 -0400, Robert Haas wrote:
> 1. There's nothing to identify the tuple that has the problem, and no
> way to know how many more of them there might be. Back-patching
> b61d161c146328ae6ba9ed937862d66e5c8b035a would help with the first
> part of this.
Not fully, I'm afraid
On Mon, Jul 13, 2020 at 6:15 PM Tom Lane wrote:
> Yeah, I don't care for that either. That's a pretty huge violation of our
> normal back-patching rules, and I'm not convinced that it's justified.
I think that our normal back-patching rules are based primarily on the
risk of breaking things, and
On Mon, Jul 13, 2020 at 6:38 PM Andres Freund wrote:
> Not fully, I'm afraid. Afaict it doesn't currently tell you the item
> pointer offset, just the block numer, right? We probably should extend
> it to also include the offset...
Oh, I hadn't realized that limitation. That would be good to fix.
Robert Haas writes:
> Oh, I hadn't realized that limitation. That would be good to fix. It
> would be even better, I think, if we could have VACUUM proceed with
> the rest of vacuuming the table, emitting warnings about each
> instance, instead of blowing up when it hits the first bad tuple, but
>
On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote:
> Robert Haas writes:
> > Oh, I hadn't realized that limitation. That would be good to fix. It
> > would be even better, I think, if we could have VACUUM proceed with
> > the rest of vacuuming the table, emitting warnings about each
> > instance, in
Hi,
On 2020-07-13 20:47:10 -0400, Robert Haas wrote:
> On Mon, Jul 13, 2020 at 6:38 PM Andres Freund wrote:
> > Not fully, I'm afraid. Afaict it doesn't currently tell you the item
> > pointer offset, just the block numer, right? We probably should extend
> > it to also include the offset...
>
>
On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote:
> The more that I think about it, the more I think that the proposed
> functions are tools for wizards only, and so I'm getting hesitant
> about having them in contrib at all. We lack a better place to
> put them, but that doesn't mean they should b
On Mon, Jul 13, 2020 at 9:10 PM Andres Freund wrote:
> > What if clog has been truncated so that the xmin can't be looked up?
>
> That's possible, but probably only in cases where xmin actually
> committed.
Isn't that the normal case? I'm imagining something like:
- Tuple gets inserted. Transact
Robert Haas writes:
> On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote:
>> The more that I think about it, the more I think that the proposed
>> functions are tools for wizards only, and so I'm getting hesitant
>> about having them in contrib at all. We lack a better place to
>> put them, but that
On 2020/07/14 9:41, Robert Haas wrote:
On Mon, Jul 13, 2020 at 6:15 PM Tom Lane wrote:
Yeah, I don't care for that either. That's a pretty huge violation of our
normal back-patching rules, and I'm not convinced that it's justified.
I think that our normal back-patching rules are based pri
Hi!
> 14 июля 2020 г., в 02:12, Robert Haas написал(а):
>
> So I have these questions:
>
> - Do people think it would me smart/good/useful to include something
> like this in PostgreSQL?
>
> - If so, how? I would propose a new contrib module that we back-patch
> all the way
My 0.05₽.
At Yan
On Tue, Jul 14, 2020 at 3:26 AM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote:
> >> The more that I think about it, the more I think that the proposed
> >> functions are tools for wizards only, and so I'm getting hesitant
> >> about having them in cont
On Tue, Jul 14, 2020 at 3:26 AM Tom Lane wrote:
> I think you're attacking a straw man. I'm well aware of how open source
> works, thanks. What I'm saying is that contrib is mostly seen to be
> reasonably harmless stuff. Sure, you can overwrite data you didn't want
> to with adminpack's pg_file
On 2020-07-14 02:41, Robert Haas wrote:
I think that our normal back-patching rules are based primarily on the
risk of breaking things, and a new contrib module carries a pretty
negligible risk of breaking anything that works today.
I think that all feature code ought to go through a beta cycle
On Tue, Jul 14, 2020 at 3:08 AM Peter Eisentraut
wrote:
> In the meantime, if you're wizard enough to deal with this kind of
> thing, you could also clone the module from the PG14 tree and build it
> against older versions manually.
But what if you are NOT a wizard, and a wizard is giving you
dir
On Tue, Jul 14, 2020 at 4:59 AM Magnus Hagander wrote:
> The countersable of this is pg_resetwal. The number of people who have broken
> their database with that tool is not small.
Very true.
> That said, we could have a separate "class" of extensions/tools in the
> distribution, and encourage
On Tue, Jul 14, 2020 at 1:52 PM Robert Haas wrote:
> On Tue, Jul 14, 2020 at 4:59 AM Magnus Hagander
> wrote:
> > The countersable of this is pg_resetwal. The number of people who have
> broken their database with that tool is not small.
>
> Very true.
>
> > That said, we could have a separate "
On Mon, Jul 13, 2020 at 9:29 PM Fujii Masao wrote:
> But updating this tool can fit to the release schedule and
> policy of PostgreSQL?
>
> While investigating the problem by using this tool, we may want to
> add new feature into the tool because it's necessary for the investigation.
> But users w
On Tue, Jul 14, 2020 at 8:25 AM Magnus Hagander wrote:
> I don't think that it necessarily has to be. As long as we're talking about
> adding something and not actually changing their existing packages, getting
> this into both yum and apt shouldn't be *that* hard, if it's coordinated well
> wi
On Tue, Jul 14, 2020 at 4:09 PM Robert Haas wrote:
> On Tue, Jul 14, 2020 at 8:25 AM Magnus Hagander
> wrote:
> > I don't think that it necessarily has to be. As long as we're talking
> about adding something and not actually changing their existing packages,
> getting this into both yum and apt
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jul 14, 2020 at 4:09 PM Robert Haas wrote:
> > On Tue, Jul 14, 2020 at 8:25 AM Magnus Hagander
> > wrote:
> > > I don't think that it necessarily has to be. As long as we're talking
> > about adding something and not actually ch
On 2020-Jul-13, Andres Freund wrote:
> Hi,
>
> On 2020-07-13 17:12:18 -0400, Robert Haas wrote:
> > 1. There's nothing to identify the tuple that has the problem, and no
> > way to know how many more of them there might be. Back-patching
> > b61d161c146328ae6ba9ed937862d66e5c8b035a would help wit
Hi,
On 2020-07-13 21:18:10 -0400, Robert Haas wrote:
> On Mon, Jul 13, 2020 at 9:10 PM Andres Freund wrote:
> > > What if clog has been truncated so that the xmin can't be looked up?
> >
> > That's possible, but probably only in cases where xmin actually
> > committed.
>
> Isn't that the normal
Hi,
On 2020-07-14 13:20:25 -0400, Alvaro Herrera wrote:
> On 2020-Jul-13, Andres Freund wrote:
>
> > Hi,
> >
> > On 2020-07-13 17:12:18 -0400, Robert Haas wrote:
> > > 1. There's nothing to identify the tuple that has the problem, and no
> > > way to know how many more of them there might be. Ba
Hi,
On 2020-07-14 07:51:27 -0400, Robert Haas wrote:
> On Tue, Jul 14, 2020 at 3:08 AM Peter Eisentraut
> wrote:
> > In the meantime, if you're wizard enough to deal with this kind of
> > thing, you could also clone the module from the PG14 tree and build it
> > against older versions manually.
>
On 2020-Jul-14, Andres Freund wrote:
> Hi,
>
> On 2020-07-14 13:20:25 -0400, Alvaro Herrera wrote:
> > Just having the block number is already a tremendous step forward; with
> > that you can ask the customer to set a pageinspect dump of tuple
> > headers, and then the problem is obvious. Now i
On Tue, Jul 14, 2020 at 3:42 PM Andres Freund wrote:
> The "found xmin ... from before relfrozenxid ..." cases should all be
> fixable without needing such a function, and without it making fixing
> them significantly easier, no? As far as I understand your suggested
> solution, you need the tid(s
Hi,
On 2020-07-14 15:59:21 -0400, Robert Haas wrote:
> On Tue, Jul 14, 2020 at 3:42 PM Andres Freund wrote:
> > The "found xmin ... from before relfrozenxid ..." cases should all be
> > fixable without needing such a function, and without it making fixing
> > them significantly easier, no? As far
On Wed, Jul 15, 2020 at 11:41 AM Andres Freund wrote:
> > Do you have a reason for believing that INSERT ... DELETE is going to
> > be better than UPDATE? It seems to me that either way you can end up
> > with a deleted and thus invisible tuple that you still can't get rid
> > of.
>
> None of the
On Thu, Jul 16, 2020 at 10:00 AM Robert Haas wrote:
> I see your point, though: the tuple has to be able to survive
> HOT-pruning in order to cause a problem when we check whether it needs
> freezing.
Here's an example where the new sanity checks fail on an invisible
tuple without any concurrent
Hi All,
Attached is the patch that adds heap_force_kill(regclass, tid[]) and
heap_force_freeze(regclass, tid[]) functions which Robert mentioned in the
first email in this thread. The patch basically adds an extension named
pg_surgery that contains these functions. Please have a look and let me
k
> 24 июля 2020 г., в 14:05, Ashutosh Sharma написал(а):
>
> Attached is the patch that adds heap_force_kill(regclass, tid[]) and
> heap_force_freeze(regclass, tid[]) functions which Robert mentioned in the
> first email in this thread. The patch basically adds an extension named
> pg_surger
Hi,
Thanks for sharing your thoughts. Please find my comments inline below:
>
> I think here we should report that we haven't done what was asked.
> + /* Nothing to do if the itemid is unused or
> already dead. */
> + if (!ItemIdIsUsed(itemid) || ItemI
> 27 июля 2020 г., в 09:36, Ashutosh Sharma написал(а):
>
> > Also, should we try to fix VM along the way?
>
> I think we should let VACUUM do that.
Sometimes VACUUM will not get to these pages, because they are marked All
Frozen.
An possibly some tuples will get stale on this page again
>
Hello Ashutosh,
On Fri, 24 Jul 2020 at 14:35, Ashutosh Sharma wrote:
>
> Hi All,
>
> Attached is the patch that adds heap_force_kill(regclass, tid[]) and
> heap_force_freeze(regclass, tid[]) functions which Robert mentioned in the
> first email in this thread. The patch basically adds an extens
> > I think we should let VACUUM do that.
> Sometimes VACUUM will not get to these pages, because they are marked All
> Frozen.
> An possibly some tuples will get stale on this page again
>
Hmm, okay, will have a look into this. Thanks.
>
> > > Are there any caveats with concurrent VACUUM? (I do
Hi Beena,
Thanks for the review.
1. We would be marking buffer dirty and writing wal even if we have
> not done any changes( ex if we pass invalid/dead tids). Maybe we can
> handle this better?
>
Yeah, we can skip this when nothing has changed. Will take care of it in
the next version of patch.
On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> A number of EDB customers have had this error crop on their tables for
> reasons that we have usually not been able to determine. In many
Do you happen to know if they ever used the
snapshot-too-old feature?
On Wed, Jul 29, 2020 at 3:23 AM Thomas Munro wrote:
> On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> > A number of EDB customers have had this error crop on their tables for
> > reasons that we have usually not been able to determine. In many
>
> Do you happen to know if they ever used the
On Thu, Jul 30, 2020 at 1:36 AM Robert Haas wrote:
> On Wed, Jul 29, 2020 at 3:23 AM Thomas Munro wrote:
> > On Tue, Jul 14, 2020 at 9:12 AM Robert Haas wrote:
> > > A number of EDB customers have had this error crop on their tables for
> > > reasons that we have usually not been able to determi
On Wed, Jul 29, 2020 at 9:58 AM Ashutosh Sharma
wrote:
>
> > I think we should let VACUUM do that.
>> Sometimes VACUUM will not get to these pages, because they are marked All
>> Frozen.
>> An possibly some tuples will get stale on this page again
>>
>
> Hmm, okay, will have a look into this. Tha
Attached is the new version of patch that addresses the comments from
Andrey and Beena.
On Wed, Jul 29, 2020 at 10:07 AM Ashutosh Sharma
wrote:
> Hi Beena,
>
> Thanks for the review.
>
> 1. We would be marking buffer dirty and writing wal even if we have
>> not done any changes( ex if we pass in
> 31 июля 2020 г., в 17:32, Ashutosh Sharma написал(а):
>
>
> On Wed, Jul 29, 2020 at 9:58 AM Ashutosh Sharma wrote:
>
> > I think we should let VACUUM do that.
> Sometimes VACUUM will not get to these pages, because they are marked All
> Frozen.
> An possibly some tuples will get stale on
On Fri, Jul 31, 2020 at 8:52 AM Ashutosh Sharma wrote:
> Attached is the new version of patch that addresses the comments from Andrey
> and Beena.
+PGFILEDESC = "pg_surgery - perform surgery on the damaged heap table"
the -> a
I also suggest: heap table -> relation, because we might want to
ex
Hi Robert,
Thanks for the review.
I've gone through all your review comments and understood all of them
except this one:
You really cannot
> modify the buffer like this and then decide, oops, never mind, I think
> I won't mark it dirty or write WAL for the changes. If you do that,
> the buffer i
On Mon, Aug 3, 2020 at 5:05 AM Ashutosh Sharma wrote:
> Could you please explain this point once more in detail? I am not quite able
> to understand under what circumstances a buffer would be modified, but won't
> be marked as dirty or a WAL won't be written for it.
Whenever this branch is take
On Mon, Aug 3, 2020 at 7:06 PM Robert Haas wrote:
>
> On Mon, Aug 3, 2020 at 5:05 AM Ashutosh Sharma wrote:
> > Could you please explain this point once more in detail? I am not quite
> > able to understand under what circumstances a buffer would be modified, but
> > won't be marked as dirty or
Hi Robert,
Thanks for the review. Please find my comments inline:
On Sat, Aug 1, 2020 at 12:18 AM Robert Haas wrote:
>
> On Fri, Jul 31, 2020 at 8:52 AM Ashutosh Sharma wrote:
> > Attached is the new version of patch that addresses the comments from
> > Andrey and Beena.
>
> +PGFILEDESC = "pg_
On Mon, Aug 3, 2020 at 12:13 PM Ashutosh Sharma wrote:
> If the above path is taken that means none of the items in the page
> got changed.
Oops. I didn't realize that, sorry. Maybe it would be a little more
clear if instead of "int nSkippedItems" you had "bool
did_modify_page"? Then you could in
On Wed, Aug 5, 2020 at 9:42 AM Ashutosh Sharma wrote:
> Yeah, it's being tested on the main table, not on a toast table. I've
> removed this test-case and also restricted direct access to the toast
> table using heap_force_kill/freeze functions. I think we shouldn't be
> using these functions to d
On Thu, Aug 6, 2020 at 1:04 AM Robert Haas wrote:
>
> On Mon, Aug 3, 2020 at 12:13 PM Ashutosh Sharma wrote:
> > If the above path is taken that means none of the items in the page
> > got changed.
>
> Oops. I didn't realize that, sorry. Maybe it would be a little more
> clear if instead of "int
On Thu, Aug 6, 2020 at 1:29 AM Robert Haas wrote:
>
> On Wed, Aug 5, 2020 at 9:42 AM Ashutosh Sharma wrote:
> > Yeah, it's being tested on the main table, not on a toast table. I've
> > removed this test-case and also restricted direct access to the toast
> > table using heap_force_kill/freeze fu
On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
>
> Hi Robert,
>
> Thanks for the review. Please find my comments inline:
>
> On Sat, Aug 1, 2020 at 12:18 AM Robert Haas wrote:
> >
> > On Fri, Jul 31, 2020 at 8:52 AM Ashutosh Sharma
> > wrote:
> > > Attached is the new version of patch that
I have been doing some user-level testing of this feature, apart from
sanity test for extension and it's functions
I have tried to corrupt tuples and then able to fix it using
heap_force_freeze/kill functions.
--corrupt relfrozenxid, cause vacuum failed.
update pg_class set relfrozenxid = (relf
Hello Masahiko-san,
Thanks for looking into the patch. Please find my comments inline below:
On Thu, Aug 6, 2020 at 1:42 PM Masahiko Sawada
wrote:
>
> On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
> > Please check the attached patch for the changes.
>
> I also looked at this version patch
On Thu, 6 Aug 2020 at 18:05, Ashutosh Sharma wrote:
>
> Hello Masahiko-san,
>
> Thanks for looking into the patch. Please find my comments inline below:
>
> On Thu, Aug 6, 2020 at 1:42 PM Masahiko Sawada
> wrote:
> >
> > On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
> > > Please check the
Attached v4 patch fixes the latest comments from Robert and Masahiko-san.
Changes:
1) Let heap_force_kill and freeze functions to be used with toast tables.
2) Replace "int nskippedItems" with "bool did_modify_page" flag to
know if any modification happened in the page or not.
3) Declare some of t
On Thu, Aug 6, 2020 at 2:11 AM Ashutosh Sharma wrote:
> Okay, If you want I can remove the restriction on a toast table, but,
> then that means a user can directly remove the data chunks from the
> toast table without changing anything in the main table. This means we
> won't be able to query the
On Thu, Aug 6, 2020 at 9:19 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 2:11 AM Ashutosh Sharma wrote:
> > Okay, If you want I can remove the restriction on a toast table, but,
> > then that means a user can directly remove the data chunks from the
> > toast table without changing anything i
Thanks Rajkumar for testing the patch.
Here are some of the additional test-cases that I would suggest you to
execute, if possible:
1) You may try running the test-cases that you have executed so far
with SR setup and see if the changes are getting reflected on the
standby.
2) You may also try r
On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote:
> Attached v4 patch fixes the latest comments from Robert and Masahiko-san.
Compiler warning:
heap_surgery.c:136:13: error: comparison of unsigned expression < 0 is
always false [-Werror,-Wtautological-compare]
if (blkno < 0 |
On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote:
> There's a certain inconsistency to these messages:
>
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# insert into foo values (1);
> INSERT 0 1
> rhaas=# select heap_force_kill
On Tue, Aug 11, 2020 at 3:39 AM Ashutosh Sharma wrote:
> The other two messages for reporting unused items and dead items
> remain the same. Hence, with above change, we would be reporting the
> following 4 messages:
>
> NOTICE: skipping all the tids in block %u for relation "%s" because
> the bl
On Tue, Aug 11, 2020 at 7:33 PM Robert Haas wrote:
>
> On Tue, Aug 11, 2020 at 3:39 AM Ashutosh Sharma wrote:
> > The other two messages for reporting unused items and dead items
> > remain the same. Hence, with above change, we would be reporting the
> > following 4 messages:
> >
> > NOTICE: sk
Thanks Robert for the review. Please find my comments inline below:
On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote:
> > Attached v4 patch fixes the latest comments from Robert and Masahiko-san.
>
> Compiler warning:
>
> heap_surgery.c:1
Hi Ashutosh
I stumbled upon this thread today, went through your patch and it looks good.
A minor suggestion in sanity_check_relation():
if (rel->rd_rel->relam != HEAP_TABLE_AM_OID)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Hi Asim,
Thanks for having a look into the patch and for sharing your feedback.
Please find my comments inline below:
On Thu, Aug 13, 2020 at 12:36 PM Asim Praveen wrote:
>
> Hi Ashutosh
>
> I stumbled upon this thread today, went through your patch and it looks good.
> A minor suggestion in s
On Thu, Aug 13, 2020 at 3:52 AM Ashutosh Sharma wrote:
> This looks like a very good suggestion to me. I will do this change in
> the next version. Just wondering if we should be doing similar changes
> in other contrib modules (like pgrowlocks, pageinspect and
> pgstattuple) as well?
It seems li
On Wed, 12 Aug 2020 at 22:27, Ashutosh Sharma wrote:
>
> Thanks Robert for the review. Please find my comments inline below:
>
> On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote:
> >
> > On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma
> > wrote:
> > > Attached v4 patch fixes the latest comments
Hello Masahiko-san,
Thanks for the review. Please check the comments inline below:
On Fri, Aug 14, 2020 at 10:07 AM Masahiko Sawada
wrote:
> Thank you for updating the patch! Here are my comments on v5 patch:
>
> --- a/contrib/Makefile
> +++ b/contrib/Makefile
> @@ -35,6 +35,7 @@ SUBDIRS = \
>
Hello Masahiko-san,
I've spent some more time trying to understand the code in
lazy_scan_heap function to know under what all circumstances a VACUUM
can fail with "found xmin ... before relfrozenxid ..." error for a
tuple whose xmin is behind relfrozenxid. Here are my observations:
1) It can fail
Attached is the new version of patch that addresses the comments from
Asim Praveen and Masahiko-san. It also improves the documentation to
some extent.
On Tue, Aug 18, 2020 at 1:46 PM Ashutosh Sharma wrote:
>
> Hello Masahiko-san,
>
> I've spent some more time trying to understand the code in
>
On Tue, Jul 14, 2020 at 12:28 AM Peter Geoghegan wrote:
> On Mon, Jul 13, 2020 at 2:12 PM Robert Haas wrote:
> > 1. There's nothing to identify the tuple that has the problem, and no
> > way to know how many more of them there might be. Back-patching
> > b61d161c146328ae6ba9ed937862d66e5c8b035a
Thanks for suggestion Ashutosh, I have done testing around these suggestion
and found no issues. I will continue testing same with updated patch posted
on this thread.
On Fri, Aug 7, 2020 at 12:45 PM Ashutosh Sharma
wrote:
> Thanks Rajkumar for testing the patch.
>
> Here are some of the additio
On 2020-Aug-17, Ashutosh Sharma wrote:
> > + if (heap_force_opt == HEAP_FORCE_KILL)
> > + ItemIdSetDead(itemid);
> >
> > I think that if the page is an all-visible page, we should clear an
> > all-visible bit on the visibility map corresponding to the page and
> > PD_ALL_VI
On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma wrote:
>
> Hello Masahiko-san,
>
> Thanks for the review. Please check the comments inline below:
>
> On Fri, Aug 14, 2020 at 10:07 AM Masahiko Sawada
> wrote:
>
> > Thank you for updating the patch! Here are my comments on v5 patch:
> >
> > --- a/con
On Tue, Aug 18, 2020 at 9:44 PM Alvaro Herrera wrote:
>
> On 2020-Aug-17, Ashutosh Sharma wrote:
>
> > > + if (heap_force_opt == HEAP_FORCE_KILL)
> > > + ItemIdSetDead(itemid);
> > >
> > > I think that if the page is an all-visible page, we should clear an
> > > all-visible
On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
wrote:
>
> On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma wrote:
> >
> > > pg_force_freeze() can revival a tuple that is already deleted but not
> > > vacuumed yet. Therefore, the user might need to reindex indexes after
> > > using that function. Fo
On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
>
> On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma wrote:
> > >
> > > > pg_force_freeze() can revival a tuple that is already deleted but not
> > > > vacuumed yet. Therefore, the
On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
wrote:
>
> On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
> >
> > On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, 17 Aug 2020 at 15:05, Ashutosh Sharma
> > > wrote:
> > > >
> > > > > pg_force_freeze() can revi
On Wed, 19 Aug 2020 at 20:45, Ashutosh Sharma wrote:
>
> On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
> wrote:
> >
> > On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma wrote:
> > >
> > > On Wed, Aug 19, 2020 at 9:27 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, 17 Aug 2020 at 15:05, A
On Thu, Aug 20, 2020 at 11:04 AM Masahiko Sawada
wrote:
>
> On Wed, 19 Aug 2020 at 20:45, Ashutosh Sharma wrote:
> >
> > On Wed, Aug 19, 2020 at 3:55 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, 19 Aug 2020 at 15:09, Ashutosh Sharma
> > > wrote:
> > > >
> > > > On Wed, Aug 19, 2020 at 9:2
Hi Masahiko-san,
Please find the updated patch with the following new changes:
1) It adds the code changes in heap_force_kill function to clear an
all-visible bit on the visibility map corresponding to the page that
is marked all-visible. Along the way it also clears PD_ALL_VISIBLE
flag on the pa
On Tue, Aug 18, 2020 at 12:14 PM Alvaro Herrera
wrote:
> It makes sense to recommend VACUUM after fixing the page, but I agree
> with Sawada-san that it would be sensible to reset the VM bit while
> doing surgery, since that's the state that the page would be in. We
> should certainly *strongly r
Hi!
> 21 авг. 2020 г., в 18:24, Ashutosh Sharma написал(а):
>
> Please find the updated patch with the following new changes:
Do you have plans to support pg_surgery as external extension? For example for
earlier versions of Postgres and for new features, like amcheck_next is
maintained.
ISTM
On Mon, Aug 24, 2020 at 7:15 PM Robert Haas wrote:
>
> On Tue, Aug 18, 2020 at 12:14 PM Alvaro Herrera
> wrote:
> > It makes sense to recommend VACUUM after fixing the page, but I agree
> > with Sawada-san that it would be sensible to reset the VM bit while
> > doing surgery, since that's the sta
1 - 100 of 153 matches
Mail list logo
