On Thu, Jul 28, 2022 at 6:37 AM Masahiko Sawada wrote:
>
> On Wed, Jul 27, 2022 at 7:08 PM shiy.f...@fujitsu.com
> wrote:
>
> I've attached updated patches that incorporated the above comments as
> well as the comment from Amit.
>
> BTW regarding 0001 patch to remove the duplicated wait, should w
Hi Bharath,
There might be security concerns if the backup started by one user can be
stopped by another user.
This is because the user who stops the backup will get the backup_label or
table space map file contents of other user.
Isn't this a concern for non-exclusive backup?
I think there shoul
On Fri, Jul 29, 2022 at 11:35:36PM -0400, Tom Lane wrote:
> Hm. I considered reading PG_VERSION instead, or postmaster.pid.
> PG_VERSION would be a very boring test case, but it should certainly
> be present in $PGDATA.
PG_VERSION would be simpler. Looking at postmaster.pid would require
a looku
On Fri, Jul 29, 2022 at 07:16:34PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > wrasse just failed the new test:
>
> > [00:09:44.167](0.001s) not ok 16 - old and new horizons match after
> > pg_upgrade
> > [00:09:44.167](0.001s)
> > [00:09:44.167](0.000s) # Failed test 'old and new horizon
On Sat, Jul 30, 2022 at 12:02:02PM +0700, John Naylor wrote:
> On Fri, Jul 29, 2022 at 4:34 AM Nathan Bossart
> wrote:
>> * I borrowed USE_SSE2 from one of John Naylor's patches [0]. I'm not
> sure
>>whether this is committable,
>
> I'll be the first to say it's not committable and needs so
rebased
>From 1e560284832c157ca18a43f44b090e5b35b0cfb3 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subject: [PATCH v8 1/4] Add pg_am_size(), pg_namespace_size() ..
See also: 358a897fa, 528ac10c7
---
src/backend/utils/adt/dbsize.c | 130
On Fri, Jul 29, 2022 at 4:34 AM Nathan Bossart
wrote:
> * I briefly looked into seeing whether auto-vectorization was viable and
>concluded it was not for these loops.
>
> * I borrowed USE_SSE2 from one of John Naylor's patches [0]. I'm not
sure
>whether this is committable,
I'll be th
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
Michael Paquier writes:
> On Fri, Jul 29, 2022 at 03:44:25PM -0400, Tom Lane wrote:
>> Pushed after some fooling with the docs and test cases. (Notably,
>> I do not think we can assume that pg_hba.conf exists in $PGDATA; some
>> installations keep it elsewhere. I used postgresql.auto.conf instea
On Fri, Jul 29, 2022 at 03:44:25PM -0400, Tom Lane wrote:
> Pushed after some fooling with the docs and test cases. (Notably,
> I do not think we can assume that pg_hba.conf exists in $PGDATA; some
> installations keep it elsewhere. I used postgresql.auto.conf instead.)
Are you sure that this la
Robert Haas writes:
> Here's a patch that uses a variant of that approach: it just runs
> safe_psql straight up and gets the output, then writes it out to temp
> files if the output doesn't match and we need to run diff. Let me know
> what you think of this.
That looks good to me, although obviou
On Fri, Jul 29, 2022 at 8:02 PM Tom Lane wrote:
> Personally I'd try to replace the two horizon-collection steps with
> $newnode->psql calls, using extra_params to inject the '-o' and target
> filename command line words. But if you want to try adding -X as
> a quicker answer, maybe that will be
On Tue, Jul 26, 2022 at 5:50 PM David Steele wrote:
>
> >> I would prefer to have all the components of backup_label stored
> >> separately and then generate backup_label from them in pg_backup_stop().
> >
> > +1, because pg_backup_stop is the one that's returning backup_label
> > contents, so it
Robert Haas writes:
> On Fri, Jul 29, 2022 at 7:16 PM Tom Lane wrote:
>> I am suspicious that the problem stems from the nonstandard
>> way you've invoked psql to collect the horizon data.
> Well, I just copied the pg_dump block which occurs directly beforehand
> and modified it. I think that mu
On Fri, Jul 29, 2022 at 7:16 PM Tom Lane wrote:
> That's not the only thing weird about this printout: there should be
> three columns not two in that query's output, and what happened to
> the trailing newline? I don't think we're looking at desired
> output at all.
Well, that's an awfully good
Robert Haas writes:
> wrasse just failed the new test:
> [00:09:44.167](0.001s) not ok 16 - old and new horizons match after pg_upgrade
> [00:09:44.167](0.001s)
> [00:09:44.167](0.000s) # Failed test 'old and new horizons match
> after pg_upgrade'
> # at t/002_pg_upgrade.pl line 345.
> [00:09
Aleksander Alekseev writes:
> Personally I believe this change makes perfect sense. Although this is
> arguably not an ideal test for gistInitBuffering(), writing proper
> tests for `static` procedures is generally not an easy task. Executing
> the code at least once in order to make sure that it
On Fri, Jul 29, 2022 at 5:13 PM Robert Haas wrote:
> On Fri, Jul 29, 2022 at 4:00 PM Tom Lane wrote:
> > Looks plausible.
>
> Committed.
wrasse just failed the new test:
[00:09:44.167](0.001s) not ok 16 - old and new horizons match after pg_upgrade
[00:09:44.167](0.001s)
[00:09:44.167](0.000s)
On 2022-07-29 Fr 14:35, Robert Haas wrote:
> On Fri, Jul 29, 2022 at 1:49 PM Tom Lane wrote:
>> crake has been failing its cross-version-upgrade tests [1] since
>> this went in:
>>
>> log files for step xversion-upgrade-REL9_4_STABLE-HEAD:
>> ==~_~===-=-===~_~==
>> /home/andrew/bf/root/upgrade.
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 Wed, Jul 06, 2022 at 03:27:28PM +0900, Michael Paquier wrote:
> On Thu, Jun 09, 2022 at 04:49:01PM +0900, Michael Paquier wrote:
> > Rebased to cope with the recent changes in this area.
>
> Please find attached an updated version of this patch, where I have
> extended the support of the upgrad
On Fri, Jul 29, 2022 at 4:00 PM Tom Lane wrote:
> Looks plausible.
Committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
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 7/22/22 16:03, Jacob Champion wrote:
> On 7/15/22 16:42, Jacob Champion wrote:
>> On 7/8/22 16:42, Jacob Champion wrote:
>>> On 7/1/22 08:08, Jacob Champion wrote:
It's been July everywhere on Earth for a few hours, so the July
commitfest is now in progress:
https://commi
On Fri, 29 Jul 2022 at 16:38, Simon Riggs wrote:
>
> On Thu, 28 Jul 2022 at 14:55, Matthias van de Meent
> wrote:
> > Great idea, yet this patch seems to only freeze those tuples that are
> > located after the first to-be-frozen tuple. It should probably
> > re-visit earlier live tuples to potent
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
Alvaro Herrera writes:
> Yeah, I don't know about adding tons of values to that enum just so that
> we can use that to hide a boolean inside. Why not add a boolean to the
> containing struct? Something like the attached.
I do not think it's a great idea to have ALTER TABLE scribbling on
the sou
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
Robert Haas writes:
> On Fri, Jul 29, 2022 at 3:10 PM Robert Haas wrote:
>> However, the catalogs show the relfilenode being correct, and the
>> relfrozenxid set to a larger value. I suspect the problem here is that
>> this needs to be done in the other order, with the TRUNCATE first and
>> the u
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 Fri, Jul 29, 2022 at 3:10 PM Robert Haas wrote:
> However, the catalogs show the relfilenode being correct, and the
> relfrozenxid set to a larger value. I suspect the problem here is that
> this needs to be done in the other order, with the TRUNCATE first and
> the update to the pg_class colum
Kyotaro Horiguchi writes:
> Please find the attached. I added some regression tests for both
> pg_read_file() and pg_read_binary_file().
Yeah, I definitely find this way cleaner even if it's a bit more verbose.
I think that the PG_RETURN_NULL code paths are not reachable in the
wrappers that do
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 7/29/22 20:23, Nathan Bossart wrote:
> On Fri, Jul 29, 2022 at 01:55:10PM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>>> On Fri, Jul 29, 2022 at 12:43:45PM -0400, Reid Thompson wrote:
slab.c
does not in SlabContextCreate(). Is this intentional, it seems to be an
oversigh
On Fri, Jul 29, 2022 at 2:35 PM Robert Haas wrote:
> But what exactly is this test case testing? I've previously complained
> about buildfarm outputs not being as labelled as well as they need to
> be in order to be easily understood by, well, me anyway. It'd sure
> help if the commands that led u
On Fri, Jul 29, 2022 at 5:55 AM Simon Riggs
wrote:
> > I should be able to post something in a couple of weeks.
>
> How do you see that affecting this thread?
Well, it's clearly duplicative, at least in part. That in itself
doesn't mean much, but there are some general questions (that apply to
an
pá 29. 7. 2022 v 18:35 odesílatel napsal:
> On 2022-07-28 01:51, Pavel Stehule wrote:
> >> Would it be clearer to say:
> >>
> >> It also contains the OID of the intended procedural language and
> >> whether
> >> that procedural language is declared as TRUSTED.
> >> While these values are redundan
On 2022-May-24, Amit Langote wrote:
> So, I think we should do something like the attached. A lot of
> boilerplate is needed given that the various enable/disable trigger
> variants are represented as separate sub-commands (AlterTableCmd
> subtypes), which can perhaps be avoided by inventing a
>
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 Fri, Jul 29, 2022 at 1:49 PM Tom Lane wrote:
> crake has been failing its cross-version-upgrade tests [1] since
> this went in:
>
> log files for step xversion-upgrade-REL9_4_STABLE-HEAD:
> ==~_~===-=-===~_~==
> /home/andrew/bf/root/upgrade.crake/HEAD/REL9_4_STABLE-amcheck-1.log
> ==~_~===-=-
On 2022-07-27 We 04:01, Amit Langote wrote:
> On Fri, Jul 22, 2022 at 2:49 PM Amit Langote wrote:
>> On Fri, Jul 22, 2022 at 1:13 PM David Rowley wrote:
>>> BTW, I was working on code inside llvm_compile_expr() a few days ago
>>> and I thought I'd gotten the new evaluation steps I was adding co
On Fri, Jul 29, 2022 at 01:55:10PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Fri, Jul 29, 2022 at 12:43:45PM -0400, Reid Thompson wrote:
>>> slab.c
>>> does not in SlabContextCreate(). Is this intentional, it seems to be an
>>> oversight to me.
>
>> IIUC this is because the header is
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
Nathan Bossart writes:
> On Fri, Jul 29, 2022 at 12:43:45PM -0400, Reid Thompson wrote:
>> slab.c
>> does not in SlabContextCreate(). Is this intentional, it seems to be an
>> oversight to me.
> IIUC this is because the header is tracked separately from the first
> regular block, unlike aset.c.
On 2022-Jul-29, torikoshia wrote:
> Statistics collector has been removed since 5891c7a8ed8f2d3d5, but there was
> a comment referring 'statistics collector' in pg_statistic.h.
>
> > Note that since the arrays are variable-size, K may be chosen by the
> > statistics collector.
>
> Should it be
Robert Haas writes:
> That's also my preference, so committed and back-patched to v15.
crake has been failing its cross-version-upgrade tests [1] since
this went in:
log files for step xversion-upgrade-REL9_4_STABLE-HEAD:
==~_~===-=-===~_~==
/home/andrew/bf/root/upgrade.crake/HEAD/REL9_4_STABLE
On Fri, Jul 29, 2022 at 12:43:45PM -0400, Reid Thompson wrote:
> slab.c
> does not in SlabContextCreate(). Is this intentional, it seems to be an
> oversight to me.
>
> /* Finally, do the type-independent part of context creation */
> MemoryContextCreate((MemoryContext) slab,
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
Hello.
Thanks to everyone for the review.
> It seems to me storing the index itself is simpler and maybe faster by
> the cycles to perform addition.
Yes, first version used 1-byte for offset with maximum value of 255.
Agreed, looks like there is no sense to store offsets now.
> A simple patch l
Hi Jacob,
On Fri, Jul 29, 2022 at 10:08:08AM -0700, Jacob Champion wrote:
>
> On Thu, Jul 28, 2022 at 11:38 PM Julien Rouhaud wrote:
> > > - Add extra statistics to explain for Nested Loop
> > > https://commitfest.postgresql.org/38/2765/
> > >
> > > [...]
> >
> > As I mentioned in [1], this pa
Hi Julien,
On Thu, Jul 28, 2022 at 11:38 PM Julien Rouhaud wrote:
> > - Add extra statistics to explain for Nested Loop
> > https://commitfest.postgresql.org/38/2765/
> >
> > [...]
>
> As I mentioned in [1], this patch breaks the current assumption that
> INSTRUMENT_ALL will lead to statement-l
On Thu, Jul 28, 2022 at 2:51 PM Tom Lane wrote:
> > - Fix behavior of geo_ops when NaN is involved
> > https://commitfest.postgresql.org/38/2710/
>
> > Stuck in a half-committed state, which is tricky. Could maybe use a
> > reframing or recap (or a new thread?).
>
> We fixed a couple of easy cas
On Fri, Jul 29, 2022 at 12:47 PM Tom Lane wrote:
> > I'm just uncertain whether what Amit has implemented is the
> > least-annoying way to go about it... any thoughts on that,
> > specifically as it pertains to this patch?
>
> I haven't looked at this patch at all. I'll try to make some
> time fo
On Fri, Jul 29, 2022 at 11:36 AM Antonin Houska wrote:
> Attached is a new version. It allows the user to set "elevel" (i.e. ERROR is
> not necessarily thrown on I/O failure, if the user prefers to check the number
> of bytes read/written) and to specify the buffer size. Also, 0015 adds a
> functi
Robert Haas writes:
> ... it's
> always struck me as a little unfortunate that we basically test
> whether a var is equal by testing whether the varno and varlevelsup
> are equal. That only works if you assume that you can never end up
> comparing two vars from thoroughly unrelated parts of the tr
Hi,
Both aset.c and generation.c populate mem_allocated in
AllocSetContextCreateInternal(), GenerationContextCreate()
respectively.
aset.c
/* Finally, do the type-independent part of context creation */
MemoryContextCreate(
On 2022-07-28 01:51, Pavel Stehule wrote:
Would it be clearer to say:
It also contains the OID of the intended procedural language and
whether
that procedural language is declared as TRUSTED.
While these values are redundant if the inline handler is serving only
a single procedural language, t
On Fri, Jul 29, 2022 at 11:04 AM Tom Lane wrote:
> We could probably make that work, but I'm skeptical that it would
> really be an improvement overall, for a couple of reasons.
>
> (1) The need for merge-rangetables-and-renumber-Vars logic doesn't
> go away. It just moves from setrefs.c to the r
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
Antonin Houska wrote:
> Peter Eisentraut wrote:
>
> > On 04.07.22 18:35, Antonin Houska wrote:
> > >> Attached is a new version of the patch, to evaluate what the API use in
> > >> the
> > >> backend could look like. I haven't touched places where the file is
> > >> accessed
> > >> in a non-t
On Wed, 27 Jul 2022 at 08:08, Kyotaro Horiguchi wrote:
>
> At Tue, 26 Jul 2022 23:09:16 +0500, Andrey Borodin
> wrote in
> >
> >
> > > On 20 Jul 2022, at 02:12, Michail Nikolaev
> > > wrote:
> > >
> > >> I've looked into v5.
> > > Thanks!
> > >
> > > Patch is updated accordingly your remarks.
> Any luck with this?
Apologies for the delay, as I have been away.
I will test this next week and report back my findings.
Thanks
Sami Imseih
Amazon Web Services (AWS)
On 6/28/22, 2:10 AM, "Kyotaro Horiguchi" wrote:
CAUTION: This email originated from outside of the organization. Do n
Robert Haas writes:
> That's not quite my question, though. Why do we ever build a non-flat
> range table in the first place? Like, instead of assigning indexes
> relative to the current subquery level, why not just assign them
> relative to the whole query from the start?
We could probably make
Hi,
2.
>> @@ -57,9 +60,6 @@ build_replindex_scan_key(ScanKey skey, Relation rel,
>> Relation idxrel,
>> int2vector *indkey = &idxrel->rd_index->indkey;
>> bool hasnulls = false;
>>
>> - Assert(RelationGetReplicaIndex(rel) == RelationGetRelid(idxrel) ||
>> -RelationGetPrimaryKeyIndex(rel) =
On Thu, 28 Jul 2022 at 14:55, Matthias van de Meent
wrote:
>
> On Thu, 28 Jul 2022 at 15:36, Simon Riggs
> wrote:
> >
> > Starting new thread with updated patch to avoid confusion, as
> > mentioned by David Steele on the original thread:
> > Original messageid: 20201118020418.GA13408@alvherre.pg
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
Hi,
El lun, 25 jul 2022 a la(s) 14:19, Anthony Sotolongo (asotolo...@gmail.com)
escribió:
> On 23-07-22 00:03, Julien Rouhaud wrote:
> > Hi,
> >
> > On Fri, Jul 22, 2022 at 02:11:35PM -0400, Anthony Sotolongo wrote:
> >> On 22-07-22 12:08, Julien Rouhaud wrote:
> >>> With your current patch it on
On Thu, Jul 28, 2022 at 06:30:26PM +0200, Alvaro Herrera wrote:
> BTW I didn't notice your annotation in the CF app until I had already
> pushed it and went there to update the status.
Hmmm and I didn't see that you'd updated the status ... so done.
Thanks for rebasifying it.
--
Justin
Hi,
Statistics collector has been removed since 5891c7a8ed8f2d3d5, but there
was a comment referring 'statistics collector' in pg_statistic.h.
Note that since the arrays are variable-size, K may be chosen by the
statistics collector.
Should it be modified to 'cumulative statistics system'
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 Thu, 28 Jul 2022 at 20:57, Peter Geoghegan wrote:
>
> On Thu, Jul 28, 2022 at 6:56 AM Matthias van de Meent
> wrote:
> > Great idea, yet this patch seems to only freeze those tuples that are
> > located after the first to-be-frozen tuple. It should probably
> > re-visit earlier live tuples to
On Thu, 28 Jul 2022 at 19:50, Tom Lane wrote:
>
> Simon Riggs writes:
> > Thanks for the nudge. New version attached.
>
> I also see a speed improvement from this, so pushed (after minor comment
> editing).
Thanks
> I notice though that if I feed it random data,
>
> ---
> DROP TABLE IF EXISTS h
On Thu, Jul 28, 2022 at 5:17 PM David G. Johnston
wrote:
> I suggest changing \du memberof to output something like this:
>
> rolname | memberof
> -+
> vagrant | {}
> r | {q:admin/vagrant}
> t | {q:admin/vagrant,s:member/vagr
On Fri, Jul 29, 2022 at 12:55 AM Tom Lane wrote:
> It would not be profitable to flatten the range table before we've
> done remove_useless_joins. We'd end up with useless entries from
> subqueries that ultimately aren't there. We could perhaps do it
> after we finish that phase, but I don't rea
On 2022-Jul-29, Kyotaro Horiguchi wrote:
> At Fri, 29 Jul 2022 11:27:01 +1200, Thomas Munro
> wrote in
> > Maybe it just needs a replication slot? I see:
> >
> > ERROR: requested WAL segment 00010003 has already been
> > removed
>
> Agreed, I see the same. The same failure
On Wed, Feb 16, 2022 at 10:07 AM Heikki Linnakangas wrote:
> On 27/09/2021 14:59, Aleksander Alekseev wrote:
> > Hi hackers,
> >
> >> As a matter of fact, I think the patch I suggested is the right
> approach:
> >> let me elaborate on why.
> >> [...]
> >> It is straightforward to replace it by im
On Fri, Jul 29, 2022 at 3:29 PM Alvaro Herrera wrote:
>
> On 2022-Jul-29, Peter Smith wrote:
>
> > On Fri, Jul 29, 2022 at 7:36 PM Alvaro Herrera
> > wrote:
> > >
> > > I don't object to doing this, but I think these two functions should
> > > stay together nonetheless.
> >
> > If you believe th
On Thu, Jul 28, 2022 at 9:32 PM Melih Mutlu wrote:
>>
>> Why after step 4, do you need to drop the replication slot? Won't just
>> clearing the required info from the catalog be sufficient?
>
>
> The replication slots that we read from the catalog will not be used for
> anything else after we're
Hi Michael,
Not sure if this email went through previously but thank you for your feedback,
I've incorporated your suggestions by scanning the logs produced from pg_rewind
when asserting that certain WAL segment files were skipped from being copied
over to the target server.
I've also updated
On 2022-Jul-29, Peter Smith wrote:
> On Fri, Jul 29, 2022 at 7:36 PM Alvaro Herrera
> wrote:
> >
> > I don't object to doing this, but I think these two functions should
> > stay together nonetheless.
>
> If you believe there is still a problem after applying the patch
> please explicitly name
On Fri, Jul 29, 2022 at 7:36 PM Alvaro Herrera wrote:
>
> On 2022-Jul-29, Peter Smith wrote:
>
> > PSA v2 of this patch, modified as suggested.
>
> I don't object to doing this, but I think these two functions should
> stay together nonetheless.
Hmm, I think there is some confusion because diffe
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 2022-Jul-29, Peter Smith wrote:
> PSA v2 of this patch, modified as suggested.
I don't object to doing this, but I think these two functions should
stay together nonetheless.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Y una voz del caos me habló y me dij
Hi, Pavel!
On Fri, Jul 29, 2022 at 11:12 AM Pavel Borisov wrote:
> I ran the following benchmark on master branch (15) vs patch (15-lock):
>
> On the 36-vcore AWS server, I've run an UPDATE-only pgbench script with 50
> connections on pgbench_tellers with 100 rows. The idea was to introduce as
Thanks for taking a look!
At Thu, 28 Jul 2022 16:22:17 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > - Simplified the implementation (by complexifying argument handling..).
> > - REVOKEd EXECUTE from the new functions.
> > - Edited the signature of the two functions.
>
> >> - pg_rea
86 matches
Mail list logo
