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
On Thu, Oct 20, 2022 at 12:51 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-10-17 17:14:21 -0400, Robert Haas wrote:
> > I have to admit that I worried about the same thing that Matthias
> > raises, more or less. But I don't know whether I'm right to be
> > worried. A variable-length representation
Hi,
On 2022-10-17 17:14:21 -0400, Robert Haas wrote:
> I have to admit that I worried about the same thing that Matthias
> raises, more or less. But I don't know whether I'm right to be
> worried. A variable-length representation of any kind is essentially a
> gamble that values requiring fewer by
On Wed, Oct 12, 2022 at 5:13 PM Andres Freund wrote:
> > I think a signficant part of this improvement comes from the premise
> > of starting with a fresh database. tablespace OID will indeed most
> > likely be low, but database OID may very well be linearly distributed
> > if concurrent workloads
On Wed, 12 Oct 2022 at 23:13, Andres Freund wrote:
>
> Hi,
>
> On 2022-10-12 22:05:30 +0200, Matthias van de Meent wrote:
> > On Wed, 5 Oct 2022 at 01:50, Andres Freund wrote:
> > > I light dusted off my old varint implementation from [1] and converted the
> > > RelFileLocator and BlockNumber fro
Hi,
On 2022-10-12 22:05:30 +0200, Matthias van de Meent wrote:
> On Wed, 5 Oct 2022 at 01:50, Andres Freund wrote:
> > On 2022-10-03 10:01:25 -0700, Andres Freund wrote:
> > > On 2022-10-03 08:12:39 -0400, Robert Haas wrote:
> > > > On Fri, Sep 30, 2022 at 8:20 PM Andres Freund
> > > > wrote:
>
On Mon, Oct 10, 2022 at 5:40 PM Robert Haas wrote:
>
> On Mon, Oct 10, 2022 at 5:16 AM Dilip Kumar wrote:
> > I have also executed my original test after applying these patches on
> > top of the 56 bit relfilenode patch. So earlier we saw the WAL size
> > increased by 11% (66199.09375 kB to 7390
Hi,
On 2022-10-10 08:10:22 -0400, Robert Haas wrote:
> On Mon, Oct 10, 2022 at 5:16 AM Dilip Kumar wrote:
> > I have also executed my original test after applying these patches on
> > top of the 56 bit relfilenode patch. So earlier we saw the WAL size
> > increased by 11% (66199.09375 kB to 7390
On Mon, Oct 10, 2022 at 5:16 AM Dilip Kumar wrote:
> I have also executed my original test after applying these patches on
> top of the 56 bit relfilenode patch. So earlier we saw the WAL size
> increased by 11% (66199.09375 kB to 73906.984375 kB) and after this
> patch now the WAL generated is 5
On Wed, Oct 5, 2022 at 5:19 AM Andres Freund wrote:
>
> I light dusted off my old varint implementation from [1] and converted the
> RelFileLocator and BlockNumber from fixed width integers to varint ones. This
> isn't meant as a serious patch, but an experiment to see if this is a path
> worth p
Hi,
On 2022-10-03 10:01:25 -0700, Andres Freund wrote:
> On 2022-10-03 08:12:39 -0400, Robert Haas wrote:
> > On Fri, Sep 30, 2022 at 8:20 PM Andres Freund wrote:
> > I thought about trying to buy back some space elsewhere, and I think
> > that would be a reasonable approach to getting this commi
On Tue, Oct 4, 2022 at 2:30 PM Andres Freund wrote:
> Consider the following sequence:
>
> 1) we write WAL like this:
>
> [record A][tear boundary][record B, prev A_lsn][tear boundary][record C, prev
> B_lsn]
>
> 2) crash, the sectors with A and C made it to disk, the one with B didn't
>
> 3) We
Hi,
On 2022-10-04 13:36:33 -0400, Robert Haas wrote:
> On Tue, Oct 4, 2022 at 11:34 AM Andres Freund wrote:
> > > Example: Page { [ record A ] | tear boundary | [ record B ] } gets
> > > recycled and receives a new record C at the place of A with the same
> > > length.
> > >
> > > With your propo
On Tue, Oct 4, 2022 at 11:34 AM Andres Freund wrote:
> > Example: Page { [ record A ] | tear boundary | [ record B ] } gets
> > recycled and receives a new record C at the place of A with the same
> > length.
> >
> > With your proposal, record B would still be a valid record when it
> > follows C;
Hi,
On 2022-10-04 15:05:47 +0200, Matthias van de Meent wrote:
> On Mon, 3 Oct 2022 at 23:26, Andres Freund wrote:
> > On 2022-10-03 19:40:30 +0200, Matthias van de Meent wrote:
> > > On Mon, 3 Oct 2022, 19:01 Andres Freund, wrote:
> > > > Random idea: xl_prev is large. Store a full xl_prev in t
On Mon, 3 Oct 2022 at 23:26, Andres Freund wrote:
>
> Hi,
>
> On 2022-10-03 19:40:30 +0200, Matthias van de Meent wrote:
> > On Mon, 3 Oct 2022, 19:01 Andres Freund, wrote:
> > > Random idea: xl_prev is large. Store a full xl_prev in the page header,
> > > but
> > > only store a 2 byte offset fr
Hi,
On 2022-10-03 19:40:30 +0200, Matthias van de Meent wrote:
> On Mon, 3 Oct 2022, 19:01 Andres Freund, wrote:
> > Random idea: xl_prev is large. Store a full xl_prev in the page header, but
> > only store a 2 byte offset from the page header xl_prev within each record.
>
> With that small xl_
On Mon, 3 Oct 2022, 19:01 Andres Freund, wrote:
>
> Hi,
>
> On 2022-10-03 08:12:39 -0400, Robert Haas wrote:
> > On Fri, Sep 30, 2022 at 8:20 PM Andres Freund wrote:
> > > I think it'd be interesting to look at per-record-type stats between two
> > > equivalent workload, to see where practical wo
Hi,
On 2022-10-03 08:12:39 -0400, Robert Haas wrote:
> On Fri, Sep 30, 2022 at 8:20 PM Andres Freund wrote:
> > I think it'd be interesting to look at per-record-type stats between two
> > equivalent workload, to see where practical workloads suffer the most
> > (possibly with fpw=off, to make th
On Fri, Sep 30, 2022 at 8:20 PM Andres Freund wrote:
> I think it'd be interesting to look at per-record-type stats between two
> equivalent workload, to see where practical workloads suffer the most
> (possibly with fpw=off, to make things more repeatable).
I would expect, and Dilip's results se
On Sat, Oct 1, 2022 at 5:50 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-09-30 15:36:11 +0530, Dilip Kumar wrote:
> > I have done some testing around this area to see the impact on WAL
> > size especially when WAL sizes are smaller, with a very simple test
> > with insert/update/delete I can see ar
On Fri, Sep 30, 2022 at 5:20 PM Andres Freund wrote:
> I think it'd be an OK tradeoff to optimize WAL usage for a few of the worst to
> pay off for 56bit relfilenodes. The class of problems foreclosed is large
> enough to "waste" "improvement potential" on this.
I agree overall.
A closely relate
Hi,
On 2022-09-30 15:36:11 +0530, Dilip Kumar wrote:
> I have done some testing around this area to see the impact on WAL
> size especially when WAL sizes are smaller, with a very simple test
> with insert/update/delete I can see around an 11% increase in WAL size
> [1] then I did some more test w
On Thu, Sep 29, 2022 at 2:36 AM Robert Haas wrote:
> 2. WAL Size. Block references in the WAL are by RelFileLocator, so if
> you make RelFileLocators bigger, WAL gets bigger. We'd have to test
> the exact impact of this, but it seems a bit scary
I have done some testing around this area to see t
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
On Thu, Sep 29, 2022 at 12:24 PM Matthias van de Meent
wrote:
> Currently, our minimal WAL record is exactly 24 bytes: length (4B),
> TransactionId (4B), previous record pointer (8B), flags (1B), redo
> manager (1B), 2 bytes of padding and lastly the 4-byte CRC. Of these
> fields, TransactionID co
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, 29 Sep 2022, 00:06 Robert Haas, wrote:
>
> 2. WAL Size. Block references in the WAL are by RelFileLocator, so if
> you make RelFileLocators bigger, WAL gets bigger. We'd have to test
> the exact impact of this, but it seems a bit scary: if you have a WAL
> stream with few FPIs doing DML on
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 4:08 PM Tom Lane wrote:
> As far as that goes, I'm entirely prepared to accept a conclusion
> that the benefits of widening relfilenodes justify whatever space
> or speed penalties may exist there. However, we cannot honestly
> make that conclusion if we haven't measured s
Robert Haas writes:
> 3. Sinval Message Size. Sinval messages are 16 bytes right now.
> They'll have to grow to 20 bytes if we do this. There's even less room
> for bit-squeezing here than there is for the WAL stuff. I'm skeptical
> that this really matters, but Tom seems concerned.
As far as tha
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
OK, so the recent commit and revert of the 56-bit relfilenode patch
revealed a few issues that IMHO need design-level input. Let me try to
surface those here, starting a new thread to separate this discussion
from the clutter:
1. Commit Record Alignment. ParseCommitRecord() and ParseAbortRecord()
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
1 - 100 of 156 matches
Mail list logo
