On Wed, Jan 4, 2023 at 5:45 PM vignesh C wrote:
>
> On Fri, 21 Oct 2022 at 11:31, Michael Paquier wrote:
> >
> > On Thu, Sep 29, 2022 at 09:23:38PM -0400, Tom Lane wrote:
> > > Hmmm ... I'd tend to do SELECT COUNT(*) FROM. But can't we provide
> > > any actual checks on the sanity of the output?
On Fri, 21 Oct 2022 at 11:31, Michael Paquier wrote:
>
> On Thu, Sep 29, 2022 at 09:23:38PM -0400, Tom Lane wrote:
> > Hmmm ... I'd tend to do SELECT COUNT(*) FROM. But can't we provide
> > any actual checks on the sanity of the output? I realize that the
> > output's far from static, but still
On Thu, Sep 29, 2022 at 09:23:38PM -0400, Tom Lane wrote:
> Hmmm ... I'd tend to do SELECT COUNT(*) FROM. But can't we provide
> any actual checks on the sanity of the output? I realize that the
> output's far from static, but still ...
Honestly, checking all the fields is not that exciting, but
Michael Paquier writes:
> While passing by, I have noticed this thread. We don't really care
> about the contents returned by these functions, and one simple trick
> to check their execution is SELECT FROM. Like in the attached, for
> example.
Hmmm ... I'd tend to do SELECT COUNT(*) FROM. But
On Thu, Sep 29, 2022 at 02:39:44PM -0400, Tom Lane wrote:
> The assertions in TupleDescInitEntry would have caught that,
> if only utils/misc/pg_controldata.c had more than zero test coverage.
> Seems like somebody ought to do something about that.
While passing by, I have noticed this thread. We
Robert Haas writes:
> On Thu, Sep 29, 2022 at 10:50 AM Maxim Orlov wrote:
>> In other words, we have 19 attributes. But tupdesc here is constructed for
>> 18 elements:
>> tupdesc = CreateTemplateTupleDesc(18);
> I think that's a mistake. Thanks for the report.
The assertions in TupleDescInitEn
On Thu, Sep 29, 2022 at 10:50 AM Maxim Orlov wrote:
> In other words, we have 19 attributes. But tupdesc here is constructed for 18
> elements:
> tupdesc = CreateTemplateTupleDesc(18);
>
> Is that normal or not? Again, I'm not in this thread and if that is
> completely ok, I'm sorry about the no
Hi!
I'm not in the context of this thread, but I've notice something strange by
attempting to rebase my patch set from 64XID thread.
As far as I'm aware, this patch set is adding "relfilenumber". So, in
pg_control_checkpoint, we have next changes:
diff --git a/src/backend/utils/misc/pg_controldat
On Wed, Sep 28, 2022 at 9:40 PM Dilip Kumar wrote:
> Thanks, Thomas, these all look fine to me. So far we have committed
> the patch to make relfilenode 56 bits wide. The Tombstone file
> removal patch is still pending to be committed, so when I will rebase
> that patch I will accommodate all th
On Wed, Sep 28, 2022 at 9:23 AM Thomas Munro wrote:
>
> Hi Dilip,
>
> I am very happy to see these commits. Here's some belated review for
> the tombstone-removal patch.
>
> > v7-0004-Don-t-delay-removing-Tombstone-file-until-next.patch
>
> More things you can remove:
>
> * sync_unlinkfiletag in
Hi Dilip,
I am very happy to see these commits. Here's some belated review for
the tombstone-removal patch.
> v7-0004-Don-t-delay-removing-Tombstone-file-until-next.patch
More things you can remove:
* sync_unlinkfiletag in struct SyncOps
* the macro UNLINKS_PER_ABSORB
* global variable pend
On Tue, Sep 27, 2022 at 2:33 AM Dilip Kumar wrote:
> Looks fine to me.
OK, committed. I also committed the 0002 patch with some wordsmithing,
and I removed a < 0 test an an unsigned value because my compiler
complained about it. 0001 turned out to make headerscheck sad, so I
just pushed a fix for
On Wed, Sep 21, 2022 at 6:09 AM Dilip Kumar wrote:
> Yeah you are right we can make it uint64. With respect to this, we
> can not directly use uint64 because that is declared in c.h and that
> can not be used in
> postgres_ext.h IIUC.
Ugh.
> Can we move the existing definitions from
> c.h file
On Tue, Sep 20, 2022 at 7:46 PM Amul Sul wrote:
>
Thanks for the review
> Here are a few minor suggestions I came across while reading this
> patch, might be useful:
>
> +#ifdef USE_ASSERT_CHECKING
> +
> + {
>
> Unnecessary space after USE_ASSERT_CHECKING.
Changed
>
> + return
On Tue, Sep 20, 2022 at 10:44 PM Robert Haas wrote:
Thanks for the review, please see my response inline for some of the
comments, rest all are accepted.
> On Fri, Sep 9, 2022 at 6:02 AM Dilip Kumar wrote:
> > [ new patch ]
>
> +typedef pg_int64 RelFileNumber;
>
> This seems really random to me
On Fri, Sep 9, 2022 at 6:02 AM Dilip Kumar wrote:
> [ new patch ]
+typedef pg_int64 RelFileNumber;
This seems really random to me. First, why isn't this an unsigned
type? OID is unsigned and I don't see a reason to change to a signed
type. But even if we were going to change to a signed type, wh
On Fri, Sep 9, 2022 at 3:32 PM Dilip Kumar wrote:
>
> On Thu, Sep 8, 2022 at 4:10 PM Dilip Kumar wrote:
>
> > On a separate note, while reviewing the latest patch I see there is some
> > risk of using the unflushed relfilenumber in GetNewRelFileNumber()
> > function. Basically, in the current
On Thu, Sep 8, 2022 at 4:10 PM Dilip Kumar wrote:
> On a separate note, while reviewing the latest patch I see there is some risk
> of using the unflushed relfilenumber in GetNewRelFileNumber() function.
> Basically, in the current code, the flushing logic is tightly coupled with
> the loggin
On Tue, Sep 6, 2022 at 11:07 PM Robert Haas wrote:
> On Tue, Sep 6, 2022 at 4:40 AM Dilip Kumar wrote:
> > I have explored this area more and also tried to come up with a
> > working prototype, so while working on this I realized that we would
> > have almost to execute all the code which is get
On Tue, Sep 6, 2022 at 4:40 AM Dilip Kumar wrote:
> I have explored this area more and also tried to come up with a
> working prototype, so while working on this I realized that we would
> have almost to execute all the code which is getting generated as part
> of the dumpDatabase() and dumpACL()
On Sun, Sep 4, 2022 at 9:27 AM Dilip Kumar wrote:
>
> On Sat, Sep 3, 2022 at 5:11 PM Amit Kapila wrote:
> > Isn't this happening because we are passing "--clean
> > --create"/"--create" options to pg_restore in create_new_objects()? If
> > so, then I think one idea to decouple would be to not us
On Sat, Sep 3, 2022 at 5:11 PM Amit Kapila wrote:
> > I have found one more issue with this approach of rewriting the
> > conflicting table. Earlier I thought we could do the conflict
> > checking and rewriting inside create_new_objects() right before the
> > restore command. But after implemen
On Tue, Aug 30, 2022 at 6:15 PM Dilip Kumar wrote:
>
> On Fri, Aug 26, 2022 at 9:33 PM Robert Haas wrote:
> >
> > On Fri, Aug 26, 2022 at 7:01 AM Dilip Kumar wrote:
> > > While working on this solution I noticed one issue. Basically, the
> > > problem is that during binary upgrade when we try to
On Sat, Sep 3, 2022 at 1:50 PM Dilip Kumar wrote:
>
> On Tue, Aug 30, 2022 at 9:23 PM Robert Haas wrote:
>
> > Well, that's very awkward. It doesn't seem like it would be very
> > difficult to teach pg_upgrade to call pg_restore without --clean and
> > just do the drop database itself, but that d
On Tue, Aug 30, 2022 at 9:23 PM Robert Haas wrote:
> Well, that's very awkward. It doesn't seem like it would be very
> difficult to teach pg_upgrade to call pg_restore without --clean and
> just do the drop database itself, but that doesn't really help,
> because pg_restore will in any event be
On Tue, Aug 30, 2022 at 8:45 AM Dilip Kumar wrote:
> I have found one more issue with this approach of rewriting the
> conflicting table. Earlier I thought we could do the conflict
> checking and rewriting inside create_new_objects() right before the
> restore command. But after implementing (wh
On Fri, Aug 26, 2022 at 9:33 PM Robert Haas wrote:
>
> On Fri, Aug 26, 2022 at 7:01 AM Dilip Kumar wrote:
> > While working on this solution I noticed one issue. Basically, the
> > problem is that during binary upgrade when we try to rewrite a heap we
> > would expect that “binary_upgrade_next_he
On Fri, Aug 26, 2022 at 7:01 AM Dilip Kumar wrote:
> While working on this solution I noticed one issue. Basically, the
> problem is that during binary upgrade when we try to rewrite a heap we
> would expect that “binary_upgrade_next_heap_pg_class_oid” and
> “binary_upgrade_next_heap_pg_class_relf
On Thu, Aug 25, 2022 at 5:26 PM Dilip Kumar wrote:
> I agree on this that this system is easy to explain that we just
> rewrite anything that conflicts so looks more future-proof. Okay, I
> will try this solution and post the patch.
While working on this solution I noticed one issue. Basically,
On Tue, Aug 23, 2022 at 8:00 PM Robert Haas wrote:
>
> On Tue, Aug 23, 2022 at 2:06 AM Dilip Kumar wrote:
> > OTOH, if we keep the two separate ranges for the user and system table
> > then we don't need all this complex logic of conflict checking.
>
> True. That's the downside. The question is w
On Mon, Aug 1, 2022 at 7:57 AM Dilip Kumar wrote:
> I have fixed other comments, and also fixed comments from Alvaro to
> use %lld instead of INT64_FORMAT inside the ereport and wherever he
> suggested.
Notwithstanding the ongoing discussion about the exact approach for
the main patch, it seemed
On Tue, Aug 23, 2022 at 3:28 PM Dilip Kumar wrote:
>
> On Tue, Aug 23, 2022 at 3:16 PM Amit Kapila wrote:
>
> > One more thing we may want to think about is what if there are tables
> > created by extension? For example, I think BDR creates some tables
> > like node_group, conflict_history, etc.
On Tue, Aug 23, 2022 at 8:00 PM Robert Haas wrote:
>
> On Tue, Aug 23, 2022 at 2:06 AM Dilip Kumar wrote:
> > OTOH, if we keep the two separate ranges for the user and system table
> > then we don't need all this complex logic of conflict checking.
>
> True. That's the downside. The question is w
On Tue, Aug 23, 2022 at 2:06 AM Dilip Kumar wrote:
> OTOH, if we keep the two separate ranges for the user and system table
> then we don't need all this complex logic of conflict checking.
True. That's the downside. The question is whether it's worth adding
some complexity to avoid needing separ
On Tue, Aug 23, 2022 at 3:16 PM Amit Kapila wrote:
>
> > OTOH, if we keep the two separate ranges for the user and system table
> > then we don't need all this complex logic of conflict checking. From
> > the old cluster, we can just remember the relfilenumbr of the
> > pg_largeobject, and in the
On Tue, Aug 23, 2022 at 11:36 AM Dilip Kumar wrote:
>
> On Tue, Aug 23, 2022 at 8:33 AM Dilip Kumar wrote:
> >
> > On Tue, Aug 23, 2022 at 1:46 AM Robert Haas wrote:
> > >
> > > On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila
> > > wrote:
> > > > To solve that problem, how about rewriting the syst
On Tue, Aug 23, 2022 at 8:33 AM Dilip Kumar wrote:
>
> On Tue, Aug 23, 2022 at 1:46 AM Robert Haas wrote:
> >
> > On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila wrote:
> > > To solve that problem, how about rewriting the system table in the new
> > > cluster which has a conflicting relfilenode? I t
On Tue, Aug 23, 2022 at 1:46 AM Robert Haas wrote:
>
> On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila wrote:
> > To solve that problem, how about rewriting the system table in the new
> > cluster which has a conflicting relfilenode? I think we can probably
> > do this conflict checking before proces
On Mon, Aug 22, 2022 at 3:55 AM Amit Kapila wrote:
> To solve that problem, how about rewriting the system table in the new
> cluster which has a conflicting relfilenode? I think we can probably
> do this conflict checking before processing the tables from the old
> cluster.
Thanks for chiming in
On Mon, Aug 22, 2022 at 1:25 PM Amit Kapila wrote:
>
> On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
> >
> > On Wed, Jul 20, 2022 at 7:27 AM Dilip Kumar wrote:
> > > There was also an issue where the user table from the old cluster's
> > > relfilenode could conflict with the system table of
On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
>
> On Wed, Jul 20, 2022 at 7:27 AM Dilip Kumar wrote:
> > There was also an issue where the user table from the old cluster's
> > relfilenode could conflict with the system table of the new cluster.
> > As a solution currently for system table o
On Thu, Aug 11, 2022 at 10:58 AM Dilip Kumar wrote:
>
> On Tue, Aug 9, 2022 at 8:51 PM Robert Haas wrote:
> >
> > On Fri, Aug 5, 2022 at 3:25 AM Dilip Kumar wrote:
> > > I think even if we start the range from the 4 billion we can not avoid
> > > keeping two separate ranges for system and user t
On Tue, Aug 9, 2022 at 8:51 PM Robert Haas wrote:
>
> On Fri, Aug 5, 2022 at 3:25 AM Dilip Kumar wrote:
> > I think even if we start the range from the 4 billion we can not avoid
> > keeping two separate ranges for system and user tables otherwise the
> > next upgrade where old and new clusters b
On Fri, Aug 5, 2022 at 3:25 AM Dilip Kumar wrote:
> I think even if we start the range from the 4 billion we can not avoid
> keeping two separate ranges for system and user tables otherwise the
> next upgrade where old and new clusters both have 56 bits
> relfilenumber will get conflicting files.
On Thu, Aug 4, 2022 at 5:01 PM Dilip Kumar wrote:
>
> On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
>
> > One solution to all this is to do as Dilip proposes here: for system
> > relations, keep assigning the OID as the initial relfilenumber.
> > Actually, we really only need to do this for
On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
> One solution to all this is to do as Dilip proposes here: for system
> relations, keep assigning the OID as the initial relfilenumber.
> Actually, we really only need to do this for pg_largeobject; all the
> other relfilenumber values could be
On Fri, Jul 29, 2022 at 10:55 PM Robert Haas wrote:
>
> On Thu, Jul 28, 2022 at 10:29 AM Robert Haas wrote:
> > > I have done some cleanup in 0002 as well, basically, earlier we were
> > > storing the result of the BufTagGetRelFileLocator() in a separate
> > > variable which is not required every
On Sat, Jul 30, 2022 at 1:35 AM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2022-Jul-29, Robert Haas wrote:
> >> Yeah, if we think it's OK to pass around structs, then that seems like
> >> the right solution. Otherwise functions that take RelFileLocator
> >> should be changed to take const
On 2022-Jul-30, Dilip Kumar wrote:
> On Thu, Jul 28, 2022 at 9:29 PM Alvaro Herrera
> wrote:
> > Please don't do this; rather use %llu and cast to (long long).
> > Otherwise the string becomes mangled for translation.
>
> Okay, actually I did not understand the clear logic of when to use
> %ll
On Thu, Jul 28, 2022 at 9:29 PM Alvaro Herrera wrote:
>
> Not a full review, just a quick skim of 0003.
Thanks for the review
> > + if (!shutdown)
> > + {
> > + if (ShmemVariableCache->loggedRelFileNumber <
> > checkPoint.nextRelFileNumber)
> > + elog(ERR
On Sat, Jul 30, 2022 at 9:11 AM Thomas Munro wrote:
> on all modern Unix-y systems,
(I meant to write AMD64 there)
On Sat, Jul 30, 2022 at 8:08 AM Tom Lane wrote:
> Robert Haas writes:
> > I was taught that when programming in C one should avoid returning a
> > struct type, as BufTagGetRelFileLocator does.
>
> FWIW, I think that was invalid pre-ANSI-C, and maybe even in C89.
> C99 and later requires it. But
On Wed, Jul 20, 2022 at 7:27 AM Dilip Kumar wrote:
> There was also an issue where the user table from the old cluster's
> relfilenode could conflict with the system table of the new cluster.
> As a solution currently for system table object (while creating
> storage first time) we are keeping the
Robert Haas writes:
> I was taught that when programming in C one should avoid returning a
> struct type, as BufTagGetRelFileLocator does.
FWIW, I think that was invalid pre-ANSI-C, and maybe even in C89.
C99 and later requires it. But it is pass-by-value and you have
to think twice about whethe
Alvaro Herrera writes:
> On 2022-Jul-29, Robert Haas wrote:
>> Yeah, if we think it's OK to pass around structs, then that seems like
>> the right solution. Otherwise functions that take RelFileLocator
>> should be changed to take const RelFileLocator * and we should adjust
>> elsewhere accordingl
On Fri, Jul 29, 2022 at 3:18 PM Alvaro Herrera wrote:
> On 2022-Jul-29, Robert Haas wrote:
> > Yeah, if we think it's OK to pass around structs, then that seems like
> > the right solution. Otherwise functions that take RelFileLocator
> > should be changed to take const RelFileLocator * and we sho
On 2022-Jul-29, Robert Haas wrote:
> Yeah, if we think it's OK to pass around structs, then that seems like
> the right solution. Otherwise functions that take RelFileLocator
> should be changed to take const RelFileLocator * and we should adjust
> elsewhere accordingly.
We do that in other place
On Fri, Jul 29, 2022 at 2:12 PM Alvaro Herrera wrote:
> On 2022-Jul-29, Robert Haas wrote:
> > I was taught that when programming in C one should avoid returning a
> > struct type, as BufTagGetRelFileLocator does.
>
> Doing it like that helps RelFileLocatorSkippingWAL, which takes a bare
> RelFile
On 2022-Jul-29, Robert Haas wrote:
> I was taught that when programming in C one should avoid returning a
> struct type, as BufTagGetRelFileLocator does.
Doing it like that helps RelFileLocatorSkippingWAL, which takes a bare
RelFileLocator as argument. With this coding you can call one function
On Thu, Jul 28, 2022 at 10:29 AM Robert Haas wrote:
> > I have done some cleanup in 0002 as well, basically, earlier we were
> > storing the result of the BufTagGetRelFileLocator() in a separate
> > variable which is not required everywhere. So wherever possible I
> > have avoided using the inter
On Wed, Jul 27, 2022 at 6:02 PM Dilip Kumar wrote:
>
> On Wed, Jul 27, 2022 at 3:27 PM vignesh C wrote:
> >
>
> > Thanks for the updated patch, Few comments:
> > 1) The format specifier should be changed from %u to INT64_FORMAT
> > autoprewarm.c -> apw_load_buffers
> > ...
> > if (fsc
On Fri, Jul 29, 2022 at 6:26 PM Ashutosh Sharma
wrote:
> On Thu, Jul 28, 2022 at 5:02 PM Dilip Kumar wrote:
>
> +/* --
> + * RelFileNumber zero is InvalidRelFileNumber.
> + *
> + * For the system tables (OID < FirstNormalObjectId) the initial storage
>
> Above comment says that RelFileNu
On Thu, Jul 28, 2022 at 5:02 PM Dilip Kumar wrote:
+/* --
+ * RelFileNumber zero is InvalidRelFileNumber.
+ *
+ * For the system tables (OID < FirstNormalObjectId) the initial storage
Above comment says that RelFileNumber zero is invalid which is technically
correct because we don't have
On 2022-Jul-28, Robert Haas wrote:
> On Thu, Jul 28, 2022 at 11:59 AM Alvaro Herrera
> wrote:
> > I do wonder why do we keep relfilenodes limited to decimal digits. Why
> > not use hex digits? Then we know the limit is 14 chars, as in
> > 0x00FF in the MAX_RELFILENUMBER definition.
On Thu, Jul 28, 2022 at 9:52 AM Robert Haas wrote:
> On Thu, Jul 28, 2022 at 11:59 AM Alvaro Herrera
> wrote:
> > I do wonder why do we keep relfilenodes limited to decimal digits. Why
> > not use hex digits? Then we know the limit is 14 chars, as in
> > 0x00FF in the MAX_RELFILENU
On Thu, Jul 28, 2022 at 11:59 AM Alvaro Herrera wrote:
> I do wonder why do we keep relfilenodes limited to decimal digits. Why
> not use hex digits? Then we know the limit is 14 chars, as in
> 0x00FF in the MAX_RELFILENUMBER definition.
Hmm, but surely we want the error messages to
Not a full review, just a quick skim of 0003.
On 2022-Jul-28, Dilip Kumar wrote:
> + if (!shutdown)
> + {
> + if (ShmemVariableCache->loggedRelFileNumber <
> checkPoint.nextRelFileNumber)
> + elog(ERROR, "nextRelFileNumber can not go backward from
> " INT
On Thu, Jul 28, 2022 at 7:32 AM Dilip Kumar wrote:
> Thanks, I have rebased other patches, actually, there is a new 0001
> patch now. It seems during renaming relnode related Oid to
> RelFileNumber, some of the references were missed and in the last
> patch set I kept it as part of main patch 00
On Wed, Jul 27, 2022 at 12:37 PM Dilip Kumar wrote:
> Just realised that this should have been BufferTagsEqual instead of
> BufferTagEqual
>
> I will modify this and send an updated patch tomorrow.
I changed it and committed.
What was formerly 0002 will need minor rebasing.
--
Robert Haas
EDB
On Wed, 27 Jul 2022 at 9:49 PM, Dilip Kumar wrote:
> On Wed, Jul 27, 2022 at 12:07 AM Robert Haas
> wrote:
> >
> > On Tue, Jul 26, 2022 at 2:07 AM Dilip Kumar
> wrote:
> > > I have thought about it while doing so but I am not sure whether it is
> > > a good idea or not, because before my change
On Tue, Jul 26, 2022 at 1:32 PM Dilip Kumar wrote:
>
> On Thu, Jul 21, 2022 at 9:53 AM Thomas Munro wrote:
> >
> > On Wed, Jul 20, 2022 at 11:27 PM Dilip Kumar wrote:
> > > [v10 patch set]
> >
> > Hi Dilip, I'm experimenting with these patches and will hopefully have
> > more to say soon, but I
On Wed, Jul 27, 2022 at 1:24 PM Ashutosh Sharma wrote:
>
> Some more comments:
Note: Please don't top post.
> ==
>
> Shouldn't we retry for the new relfilenumber if
> "ShmemVariableCache->nextRelFileNumber > MAX_RELFILENUMBER". There can be a
> cases where some of the tables are dropped by the
Some more comments:
==
Shouldn't we retry for the new relfilenumber if
"ShmemVariableCache->nextRelFileNumber > MAX_RELFILENUMBER". There can be a
cases where some of the tables are dropped by the user and relfilenumber of
those tables can be reused for which we would need to find the
relfilenumb
On Tue, Jul 12, 2022 at 4:35 PM Robert Haas wrote:
> > Very minor nitpick: To me REPLACE would be a bit more accurate than RENAME,
> > since it includes fsync etc?
>
> Sure, I had it that way for a while and changed it at the last minute.
> I can change it back.
Committed that way, also with the
On Tue, Jul 26, 2022 at 2:07 AM Dilip Kumar wrote:
> I have thought about it while doing so but I am not sure whether it is
> a good idea or not, because before my change these all were macros
> with 2 naming conventions so I just changed to inline function so why
> to change the name.
Well, the
Thanks Dilip. Here are few comments that could find upon quickly reviewing
the v11 patch:
/*
+ * Similar to the XLogPutNextOid but instead of writing NEXTOID log record
it
+ * writes a NEXT_RELFILENUMBER log record. If '*prevrecptr' is a valid
+ * XLogRecPtrthen flush the wal upto this record p
On Tue, Jul 26, 2022 at 6:06 PM Ashutosh Sharma wrote:
Hi,
Note: please avoid top posting.
> /*
> * If relfilenumber is unspecified by the caller then create storage
> -* with oid same as relid.
> +* with relfilenumber same as relid if it is a system table otherw
/*
* If relfilenumber is unspecified by the caller then create storage
-* with oid same as relid.
+* with relfilenumber same as relid if it is a system table
otherwise
+* allocate a new relfilenumber. For more details read comments
atop
+* FirstNorm
On Tue, Jul 26, 2022 at 10:05 AM Amul Sul wrote:
>
> Few more typos in 0004 patch as well:
>
> the a value
> interger
> previosly
> currenly
>
Thanks for the review, I will fix it in the next version.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jul 22, 2022 at 4:21 PM vignesh C wrote:
>
> On Wed, Jul 20, 2022 at 4:57 PM Dilip Kumar wrote:
> >
> Thanks for the patch, my comments from the initial review:
> 1) Since we have changed the macros to inline functions, should we
> change the function names similar to the other inline fu
On Thu, Jul 21, 2022 at 9:53 AM Thomas Munro wrote:
>
> On Wed, Jul 20, 2022 at 11:27 PM Dilip Kumar wrote:
> > [v10 patch set]
>
> Hi Dilip, I'm experimenting with these patches and will hopefully have
> more to say soon, but I just wanted to point out that this builds with
> warnings and failed
On Mon, Jul 25, 2022 at 9:51 PM Ashutosh Sharma wrote:
>
> Hi,
>
> As oid and relfilenumber are linked with each other, I still see that if the
> oid value reaches the threshold limit, we are unable to create a table with
> storage. For example I set FirstNormalObjectId to 4294967294 (one value
On Fri, Jul 22, 2022 at 4:21 PM vignesh C wrote:
>
> On Wed, Jul 20, 2022 at 4:57 PM Dilip Kumar wrote:
> >
> > On Mon, Jul 18, 2022 at 4:51 PM Dilip Kumar wrote:
> > >
> > > I was doing some more testing by setting the FirstNormalRelFileNumber
> > > to a high value(more than 32 bits) I have not
Hi,
As oid and relfilenumber are linked with each other, I still see that if
the oid value reaches the threshold limit, we are unable to create a table
with storage. For example I set FirstNormalObjectId to 4294967294 (one
value less than the range limit of 2^32 -1 = 4294967295). Now when I try to
On Wed, Jul 20, 2022 at 4:57 PM Dilip Kumar wrote:
>
> On Mon, Jul 18, 2022 at 4:51 PM Dilip Kumar wrote:
> >
> > I was doing some more testing by setting the FirstNormalRelFileNumber
> > to a high value(more than 32 bits) I have noticed a couple of problems
> > there e.g. relpath is still using
On Wed, Jul 20, 2022 at 11:27 PM Dilip Kumar wrote:
> [v10 patch set]
Hi Dilip, I'm experimenting with these patches and will hopefully have
more to say soon, but I just wanted to point out that this builds with
warnings and failed on 3/4 of the CI OSes on cfbot's last run. Maybe
there is the go
On Thu, Jul 14, 2022 at 5:18 PM Dilip Kumar wrote:
> Apart from this I have fixed all the pending issues that includes
>
> - Change existing macros to inline functions done in 0001.
> - Change pg_class index from (tbspc, relfilenode) to relfilenode and
> also change RelidByRelfilenumber(). In Re
On Tue, Jul 12, 2022 at 7:21 PM Robert Haas wrote:
>
> In this version, I also removed the struct padding, changed the limit
> on the number of entries to a nice round 64, and made some comment
> updates. I considered trying to go further and actually make the file
> variable-size, so that we nev
On Tue, Jul 12, 2022 at 6:02 PM Andres Freund wrote:
> MAX_FORKNUM is way lower right now. And hardcoded. So this doesn't imply a new
> restriction. As we iterate over 0..MAX_FORKNUM in a bunch of places (with
> filesystem access each time), it's not feasible to make that number large.
Yeah. TBH,
Hi,
Please don't top quote - as mentioned a couple times recently.
On 2022-07-12 23:00:22 +0200, Hannu Krosing wrote:
> Re: staticAssertStmt(MAX_FORKNUM <= INT8_MAX);
>
> Have you really thought through making the ForkNum 8-bit ?
MAX_FORKNUM is way lower right now. And hardcoded. So this doesn'
Re: staticAssertStmt(MAX_FORKNUM <= INT8_MAX);
Have you really thought through making the ForkNum 8-bit ?
For example this would limit a columnar storage with each column
stored in it's own fork (which I'd say is not entirely unreasonable)
to having just about ~250 columns.
And there can easily
On Tue, Jul 12, 2022 at 1:09 PM Andres Freund wrote:
> What does currently happen if we exceed that?
elog
> > diff --git a/src/include/utils/wait_event.h b/src/include/utils/wait_event.h
> > index b578e2ec75..5d3775ccde 100644
> > --- a/src/include/utils/wait_event.h
> > +++ b/src/include/utils/
Hi,
On 2022-07-12 09:51:12 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 7:22 PM Andres Freund wrote:
> > I guess I'm not enthused in duplicating the necessary knowledge in evermore
> > places. We've forgotten one of the magic incantations in the past, and
> > needing
> > to find all the p
On Mon, Jul 11, 2022 at 9:49 PM Robert Haas wrote:
>
> It also makes me wonder why we're using macros rather than static
> inline functions in buf_internals.h. I wonder whether we could do
> something like this, for example, and keep InvalidForkNumber as -1:
>
> static inline ForkNumber
> BufTagG
On Mon, Jul 11, 2022 at 7:22 PM Andres Freund wrote:
> I guess I'm not enthused in duplicating the necessary knowledge in evermore
> places. We've forgotten one of the magic incantations in the past, and needing
> to find all the places that need to be patched is a bit bothersome.
>
> Perhaps we c
On 2022-07-11 16:11:53 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 3:34 PM Andres Freund wrote:
> > Seems pretty simple to do. Have write_relmapper_file() write to a .tmp file
> > first (likely adding O_TRUNC to flags), use durable_rename() to rename it
> > into
> > place. The tempfile s
On Mon, Jul 11, 2022 at 3:34 PM Andres Freund wrote:
> Seems pretty simple to do. Have write_relmapper_file() write to a .tmp file
> first (likely adding O_TRUNC to flags), use durable_rename() to rename it into
> place. The tempfile should probably be written out before the XLogInsert(),
> the d
Hi,
On 2022-07-11 15:08:57 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 2:57 PM Andres Freund wrote:
> > I don't know where we could fit a sanity check that connects to all
> > databases
> > and detects duplicates across all the pg_class instances. Perhaps
> > pg_amcheck?
>
> Unless we'
On Mon, Jul 11, 2022 at 2:57 PM Andres Freund wrote:
> ISTM that we should redefine pg_class_tblspc_relfilenode_index to only cover
> relfilenode - afaics there's no real connection to the tablespace
> anymore. That'd a) reduce the size of the index b) guarantee uniqueness across
> tablespaces.
S
Hi,
On 2022-07-07 13:26:29 -0400, Robert Haas wrote:
> We're trying to create a system where the relfilenumber counter is
> always ahead of all the relfilenumbers used on disk, but the coupling
> between the relfilenumber-advancement machinery and the
> make-files-on-disk machinery is pretty loose
1 - 100 of 127 matches
Mail list logo
