On Fri, Jul 29, 2022 at 8:31 AM Peter Smith wrote:
>
> Here are some comments for the patch v40-0001:
>
> ==
>
> 1. Commit message
>
> It might be better to always use 'copy_data = true' in favour of
> 'copy_data = on' just for consistency with all the docs and the error
> messages.
>
>
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 can be surely reproducible
by inserting
Amit Langote writes:
> On Thu, Jul 28, 2022 at 1:27 AM Robert Haas wrote:
>> I wonder whether it's really necessary to added the PartitionPruneInfo
>> objects to a list in PlannerInfo first and then roll them up into
>> PlannerGlobal later. I know we do that for range table entries, but
>> I've
PSA v2 of this patch, modified as suggested.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
v2-0001-Functions-is_publishable_class-and-is_publishable.patch
Description: Binary data
On Thu, Jul 28, 2022 at 1:27 AM Robert Haas wrote:
> On Tue, Jul 26, 2022 at 11:01 PM Amit Langote wrote:
> > Needed to be rebased again, over 2d04277121f this time.
Thanks for looking.
> 0001 adds es_part_prune_result but does not use it, so maybe the
> introduction of that field should be
On Fri, Jul 22, 2022 at 11:59 PM Juan José Santamaría Flecha
wrote:
> TL;DR; What I want to show through this example is that Windows ACP is not
> modified by setlocale(), it can only be done through the Windows registry and
> only in recent releases.
Thanks, that was helpful, and so was that
On Fri, Jul 29, 2022 at 8:26 AM Peter Smith wrote:
>
> On Fri, Jul 29, 2022 at 11:55 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Friday, July 29, 2022 7:17 AM Peter Smith wrote:
> > > During a recent review, I happened to notice that in the file
> > > src/backend/catalog/pg_publication.c the
On Thu, Jul 28, 2022 at 9:04 PM Zhang Mingli wrote:
> Assertions added.
>
Can we also add assertions to make sure force_quote, force_notnull and
force_null are available only in CSV mode?
Thanks
Richard
Here are some comments for the patch v40-0001:
==
1. Commit message
It might be better to always use 'copy_data = true' in favour of
'copy_data = on' just for consistency with all the docs and the error
messages.
==
2. doc/src/sgml/ref/create_subscription.sgml
@@ -386,6 +401,15 @@
On Fri, Jul 29, 2022 at 11:55 AM houzj.f...@fujitsu.com
wrote:
>
> On Friday, July 29, 2022 7:17 AM Peter Smith wrote:
> > During a recent review, I happened to notice that in the file
> > src/backend/catalog/pg_publication.c the two functions
> > 'is_publishable_class'
> > and
At Thu, 28 Jul 2022 22:03:13 +0800, Zhang Mingli wrote
in
> Hi,
>
> On Jul 28, 2022, 21:30 +0800, Reid Thompson ,
> wrote:
> > Attached is a patch to address this.
Good Catch!
> Codes seem good, my question is:
>
> Do auto vacuum processes need CacheMemoryContext?
pgstat_report_vacuum
On Friday, July 29, 2022 7:17 AM Peter Smith wrote:
> During a recent review, I happened to notice that in the file
> src/backend/catalog/pg_publication.c the two functions 'is_publishable_class'
> and 'is_publishable_relation' used to be [1] adjacent in the source code.
> This is
> also evident
Hi,
On Tue, Jan 12, 2021 at 09:04:51AM -0500, Andrew Dunstan wrote:
> On 1/5/21 11:19 PM, Thomas Munro wrote:
> >
> > It seems we can make our own, either on-the-fly with caching, or
> > hosted somewhere, like this:
> >
> >
On Thu, Jul 28, 2022 at 8:57 PM Amit Kapila wrote:
>
> On Thu, Jul 28, 2022 at 3:23 PM Amit Kapila wrote:
> >
> > On Tue, Jul 26, 2022 at 1:22 PM Masahiko Sawada
> > wrote:
> > >
> > > Okay, I've attached an updated patch that does the above idea. Could
> > > you please do the performance
Hello,
Part 2 should include entries four commitfests and older. (For the rest,
it's probably too early to call something "stalled", so I don't plan to
do any more triage there.) Patch authors CC'd.
= Stalled Patches, Recommend Return =
I plan to return these with a note saying "needs more
On Fri, Jul 29, 2022 at 9:57 AM Tom Lane wrote:
> Matthias van de Meent writes:
> > I'd like to bring to your attention that the test that was introduced
> > with 9e4f914b seem to be flaky in FreeBSD 13 in the CFBot builds: it
> > sometimes times out while waiting for the secondary to catch up.
During a recent review, I happened to notice that in the file
src/backend/catalog/pg_publication.c the two functions
'is_publishable_class' and 'is_publishable_relation' used to be [1]
adjacent in the source code. This is also evident in
'is_publishable_relation' because the wording of the
On Wed, Jul 27, 2022 at 5:09 AM Robert Haas wrote:
> On Tue, Jul 26, 2022 at 7:40 AM Tom Lane wrote:
> > I think maybe we should re-open the discussion. I've certainly
> > reached the stage of fed-up-ness. That platform seems seriously
> > broken, upstream is making no progress on fixing it,
On Mon, Jul 25, 2022 at 04:40:51PM +0200, Martin Kalcher wrote:
> +SELECT trim_array(ARRAY[]::int[], 1); -- fail
> +ERROR: number of elements to trim must be between 0 and 0
Can we improve the error message? Maybe it should look something like
ERROR: number of elements to trim must be
I think the "only_if" should allow separately running one but not both of the
windows instances, like:
+ only_if: $CIRRUS_CHANGE_MESSAGE !=~ '.*\nci-os-only:.*' ||
$CIRRUS_CHANGE_MESSAGE =~ '.*\nci-os-only:[^\n]*mingw64'
I'm not sure, but maybe this task should only run "by request", and omit
On Fri, Jul 29, 2022 at 10:23 AM Justin Pryzby wrote:
> On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > [04:33:55.234] Starting cygwin install, version 2.918
>
> Hm, I think that's the version of "cygwinsetup" but not cygwin..
> It also says this: [13:16:36.014] Cygwin
Note that this can currently exposes internal elog() errors to users:
postgres=# select pg_normalize_config_value('log_min_messages','abc');
WARNING: invalid value for parameter "log_min_messages": "abc"
HINT: Available values: debug5, debug4, debug3, debug2, debug1, info, notice,
warning,
On Tue, Jul 26, 2022 at 01:54:38PM -0400, Robert Haas wrote:
> I think we're down to 0 remaining now, so it'd be hard to justify
> consuming 2 of 0 remaining bits.
AFAICT there are 2 remaining. N_ACL_RIGHTS is only 14.
> However, I maintain that the solution
> to this is either (1) change the
On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> Thanks for working on this!
>
> Huh, that Cygwin being shipped by Choco is quite old, older than
> lorikeet's, but not old enough to not have the bug:
>
> [04:33:55.234] Starting cygwin install, version 2.918
Hm, I think that's the
On Wed, Jul 27, 2022 at 6:44 PM Justin Pryzby wrote:
> On Tue, Jul 26, 2022 at 04:24:25PM +1200, Thomas Munro wrote:
> > 3. You can't really run PostgreSQL on Cygwin for real, because its
> > implementation of signals does not have reliable signal masking, so
> > unsubtle and probably also
Matthias van de Meent writes:
> I'd like to bring to your attention that the test that was introduced
> with 9e4f914b seem to be flaky in FreeBSD 13 in the CFBot builds: it
> sometimes times out while waiting for the secondary to catch up. Or,
> at least I think it does, and I'm not too familiar
Jacob Champion writes:
> Next up is the large list of Needs Review. This part 1 should include
> entries as old or older than seven commitfests running.
I'm just commenting on a couple that I've been involved with.
> = Stalled Patches, Recommend Return =
> - Fix up partitionwise join on how
On Tue, Jul 26, 2022 at 11:19:06AM -0700, Andres Freund wrote:
> On 2022-07-25 12:04:19 -0700, Nathan Bossart wrote:
>> From the discussion thus far, it seems there is interest in optimizing
>> [sub]xip lookups, so I'd like to spend some time moving it forward. I
>> think the biggest open
Hi,
Next up is the large list of Needs Review. This part 1 should include
entries as old or older than seven commitfests running.
My heuristics for classifying these continue to evolve as I go, and
there's a lot to read, so please let me know if I've made any mistakes.
= Stalled Patches,
On Thu, Jul 28, 2022 at 12:09 PM Robert Haas wrote:
> On Tue, Jul 26, 2022 at 12:46 PM Robert Haas
> wrote:
> > I believe that these patches are mostly complete, but I think that
> > dumpRoleMembership() probably needs some more work. I don't know what
> > exactly, but there's nothing to cause
Kyotaro Horiguchi writes:
> - Simplified the implementation (by complexifying argument handling..).
> - REVOKEd EXECUTE from the new functions.
> - Edited the signature of the two functions.
>> - pg_read_file ( filename text [, offset bigint, length bigint [, missing_ok
>> boolean ]] ) $B"*(B
On Tue, Jul 26, 2022 at 9:09 PM Bruce Momjian wrote:
> This behavior is new in PG 15, and I would be worried to have one new
> behavior in PG 15 and another one in PG 16. Therefore, I would like to
> see it in PG 15 and master.
That's also my preference, so committed and back-patched to v15.
This needs a rebase, but after that I expect it to be RfC.
--Jacob
The new status of this patch is: Waiting on Author
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 potentially freeze those as well.
I have a big patch set pending
On Tue, Jul 26, 2022 at 12:46 PM Robert Haas wrote:
> I believe that these patches are mostly complete, but I think that
> dumpRoleMembership() probably needs some more work. I don't know what
> exactly, but there's nothing to cause it to dump the role grants in an
> order that will create
Simon Riggs writes:
> Thanks for the nudge. New version attached.
I also see a speed improvement from this, so pushed (after minor comment
editing). I notice though that if I feed it random data,
---
DROP TABLE IF EXISTS hash_speed;
CREATE unlogged TABLE hash_speed (x integer);
INSERT INTO
On Wed, 27 Jul 2022 at 15:16, Richard Guo wrote:
> That makes sense. The patch looks in a good shape to me in this part.
Thanks for giving it another look.
I'm also quite happy with the patch now. The 2 plan changes are
explained. I have a patch on another thread [1] for the change in the
Merge
On Wed, 27 Jul 2022 at 20:55, Alvaro Herrera wrote:
>
> Okay, I think I'm done with this. Here's v27 for the master branch,
> where I fixed some comments as well as thinkos in the test script.
> The ones on older branches aren't materially different, they just have
> tonnes of conflicts
On Thu, 28 Jul 2022 at 19:31, Andres Freund wrote:
>
> Hi,
>
> On July 28, 2022 7:29:43 PM GMT+02:00, Matthias van de Meent
> wrote:
> >On Thu, 28 Jul 2022 at 11:57, Andres Freund wrote:
> >>
> >> Hi,
> >>
> >> Freebsd 13.0, so far used by CI, is out of support. I've changed the
> >> image to
Hi,
On July 28, 2022 7:29:43 PM GMT+02:00, Matthias van de Meent
wrote:
>On Thu, 28 Jul 2022 at 11:57, Andres Freund wrote:
>>
>> Hi,
>>
>> Freebsd 13.0, so far used by CI, is out of support. I've changed the
>> image to be built against 13.1, so we can switch to that.
>>
>> I suspect it'd be
On Thu, 28 Jul 2022 at 11:57, Andres Freund wrote:
>
> Hi,
>
> Freebsd 13.0, so far used by CI, is out of support. I've changed the
> image to be built against 13.1, so we can switch to that.
>
> I suspect it'd be better to remove the minor version numbers from the
> image name, so that switches
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
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
I wrote:
> I've got no strong opinion about this bit:
>> As suggested upthread, returning a resultset would probably be better.
Actually, on further thought, I do like the resultset idea, because
it'd remove the need for a complex rewrite of nextval_internal.
Assuming the SRF is written in
On 7/28/22 8:03 PM, Robert Haas wrote:
No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ...
is intended to be a way of switching an option off.
Ok, Thanks, Robert. I tested with a couple of more scenarios like
pg_upgrade/pg_dumpall /grant/revoke .. with admin option/inherit
On 2022-Jun-30, Justin Pryzby wrote:
> I updated the language to say "values from". Is this better ?
>
> And rebased to include changes to 401f623c7.
Applied to 15 and master, thanks.
> BTW nobody complained about my "child child" typo.
:-(
BTW I didn't notice your annotation in the CF app
Ronan Dunklau writes:
> The problem the author wants to solve is the fact they don't have a way of
> returning the ids when using COPY FROM. Pre-allocating them and assigning
> them
> to the individual records before sending them via COPY FROM would solve that
> for them.
True.
I took a
On Thu, Jul 21, 2022 at 4:29 PM Jacob Champion wrote:
> v4 attempts to fix this by letting the check hooks pass
> MCXT_ALLOC_NO_OOM to pg_clean_ascii(). (It's ignored in the frontend,
> which just mallocs.)
Ping -- should I add an open item somewhere so this isn't lost?
--Jacob
>
> 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 done with syncing the table which the rep slot
belongs 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
> "
On Thu, Jul 28, 2022 at 4:46 AM Andrey Borodin wrote:
> Daniil is working on this, but currently he's on vacation.
> I think we should not mark patch as RwF and move it to next CF instead.
Is there a downside to marking it RwF, from your perspective? As
Robert pointed out upthread, it can be
On Wed, Jul 27, 2022 at 7:09 PM houzj.f...@fujitsu.com
wrote:
> Sorry, I think we don't enough time to work on this recently. So please mark
> it as RWF and
> we will get back to this in the future.
Done, thanks!
--Jacob
On Thu, Jul 28, 2022 at 8:43 AM Julien Rouhaud wrote:
> Could you send a rebased version? In the meantime I will switch the entry to
> Waiting on Author.
By request in [1] I'm marking this Returned with Feedback for now.
Whenever you're ready, you can resurrect the patch entry by visiting
Alvaro Herrera writes:
> In short, +1 to this patch.
Thanks for testing it. I think the only remaining concern is
Peter's objection that $(wildcard) might pick up random junk files
that end in ".c". That's true, but the backend's nls.mk also
picks up everything matching "*.c" (over the whole
On 2022-07-28 Th 10:55, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-07-28 Th 10:24, Tom Lane wrote:
>>> How can that be? Have we somehow broken SSPI authentication
>>> in HEAD?
>> Nothing is broken. On HEAD drongo uses Unix sockets.
> I see. Seems like we've created a gotcha for
On 2022-Jul-13, Tom Lane wrote:
> Actually, we can get rid of those easily enough anyway with $(sort).
> Here's a draft that might solve these problems. The idea is to use
> $(wildcard) for files in the srcdir, and manually enumerate only
> built files.
I checked the files in src/bin/scripts
On Thu, Jul 28, 2022 at 11:50 AM Harinath Kanchu wrote:
>
> Greetings,
>
>
> When we take backups from a synchronous standby replica, how can we get the
> accurate timestamp of the backup end time ? (As backup history files are not
> generated on standbys)For example:
> this is a part of
Andrew Dunstan writes:
> On 2022-07-28 Th 10:24, Tom Lane wrote:
>> How can that be? Have we somehow broken SSPI authentication
>> in HEAD?
> Nothing is broken. On HEAD drongo uses Unix sockets.
I see. Seems like we've created a gotcha for ourselves:
a test script can look perfectly fine in
On 2022-07-28 Th 10:24, Tom Lane wrote:
> In commits 7c34555f8/e1bd4990b, I added a new role used by a TAP
> script but neglected the auth_extra incantation needed to allow
> login as that role. This should have resulted in SSPI auth
> failures on certain Windows configurations, and indeed it
On Thu, Jul 28, 2022 at 10:16 AM tushar wrote:
> On 7/19/22 12:56 AM, Robert Haas wrote:
> > Another good catch. Here is v5 with a fix for that problem.
> Here is one scenario in which I have NOT granted (inherit false)
> explicitly but still revoke
> command is changing the current state
>
>
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
Julien Rouhaud writes:
> On Thu, Jul 28, 2022 at 10:04:12AM -0400, Tom Lane wrote:
>> If all supported versions do have home directories now, should we
>> instead think about aligning the Windows behavior with everywhere
>> else?
> As far as I know the expected usage on Windows is still
In commits 7c34555f8/e1bd4990b, I added a new role used by a TAP
script but neglected the auth_extra incantation needed to allow
login as that role. This should have resulted in SSPI auth
failures on certain Windows configurations, and indeed it did
on drongo's next run in the v15 branch:
On Thu, Jul 28, 2022 at 1:17 PM Harinath Kanchu wrote:
>
> Hello,
>
> Is there any way to get the timestamp of the transaction using LSN value ?
>
> For example:
> can we use the minimum recovery ending location in pg control file to get the
> minimum recovery timestamp ?
>
> Minimum recovery
On Thu, Jul 28, 2022 at 10:04:12AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Wed, Jul 27, 2022 at 02:42:11PM -0400, Robert Treat wrote:
> >> The attached patch tweaks the wording around finding the psqlrc file
> >> on windows, with the primary goal of removing the generally incorrect
On 7/19/22 12:56 AM, Robert Haas wrote:
Another good catch. Here is v5 with a fix for that problem.
Here is one scenario in which I have NOT granted (inherit false)
explicitly but still revoke
command is changing the current state
postgres=# create group foo;
CREATE ROLE
postgres=# create
Hi hackers,
I'm sharing the rebased version of this patch, if you're still interested.
I would appreciate any feedback or concerns.
Best,
Melih
Andrew Dunstan , 9 Nis 2022 Cmt, 19:34 tarihinde şunu
yazdı:
>
> On 4/8/22 21:02, Andres Freund wrote:
> > Hi,
> >
> > On 2022-04-08 19:27:58 -0500,
Hi,
Agree, FORCE_NULL(*) is useful as well as FORCE_NOT_NULL(*).
We can have them both.
They are useful when users copy tables that have many columns.
Regards,
Zhang Mingli
On Jul 25, 2022, 21:28 +0800, Andrew Dunstan , wrote:
>
> On 2022-07-25 Mo 00:18, jian he wrote:
> > Hi, there.
> >
> >
Julien Rouhaud writes:
> On Wed, Jul 27, 2022 at 02:42:11PM -0400, Robert Treat wrote:
>> The attached patch tweaks the wording around finding the psqlrc file
>> on windows, with the primary goal of removing the generally incorrect
>> statement that windows has no concept of a home directory.
>
On Thu, Jul 28, 2022 at 11:28 AM Peter Smith wrote:
>
> Hi Vignesh.
>
> FYI the v39* patch fails to apply [1]. Can you please rebase it?
>
>
> [1]
> === Applying patches on top of PostgreSQL commit ID
> 5f858dd3bebd1f3845aef2bff7f4345bfb7b74b3 ===
> === applying patch
>
Hi,
On Jul 28, 2022, 21:30 +0800, Reid Thompson ,
wrote:
> Hi,
>
> There are instances where pgstat_setup_memcxt() and
> pgstat_prep_pending_entry() are invoked before the CacheMemoryContext
> has been created. This results in PgStat* contexts being created
> without a parent context. Most
On Wed, Jul 27, 2022 at 3:56 PM Melih Mutlu wrote:
>
> Hi Amit,
>
> I updated the patch in order to prevent the problems that might be caused by
> using different replication slots for syncing a table.
> As suggested in previous emails, replication slot names are stored in the
> catalog. So
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.pgsql
> On Wed, 18 Nov 2020 at 02:04, Alvaro Herrera wrote:
> > On
Hi,
On Wed, Jul 27, 2022 at 02:42:11PM -0400, Robert Treat wrote:
>
> The attached patch tweaks the wording around finding the psqlrc file
> on windows, with the primary goal of removing the generally incorrect
> statement that windows has no concept of a home directory.
Windows only has a
Starting new thread with updated patch to avoid confusion, as
mentioned by David Steele on the original thread:
Original messageid: 20201118020418.GA13408@alvherre.pgsql
On Wed, 18 Nov 2020 at 02:04, Alvaro Herrera wrote:
> On 2020-Nov-17, Simon Riggs wrote:
>
> > As an additional optimization,
On Wed, Jul 27, 2022 at 1:27 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, July 27, 2022 1:29 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 27, 2022 at 10:06 AM Amit Kapila
> > >
> > > What kind of failure do you have in mind and how it can occur? The one
> > > way it can fail is if the
Hi, all
Assertions added.
Thanks for review.
Regards,
Zhang Mingli
Sent with a Spark
On Jul 27, 2022, 14:37 +0800, Richard Guo , wrote:
>
> > On Wed, Jul 27, 2022 at 12:55 PM Kyotaro Horiguchi
> > wrote:
> > > ProcessCopyOptions previously rejects force_quote_all for COPY FROM
> > > and
On Wed, 27 Jul 2022 at 19:22, Tom Lane wrote:
>
> Simon Riggs writes:
> > [ hash_sort_by_hash.v2.patch ]
>
> The cfbot says this no longer applies --- probably sideswiped by
> Korotkov's sorting-related commits last night.
Thanks for the nudge. New version attached.
--
Simon Riggs
On Thu, Jul 28, 2022 at 3:23 PM Amit Kapila wrote:
>
> On Tue, Jul 26, 2022 at 1:22 PM Masahiko Sawada wrote:
> >
> > Okay, I've attached an updated patch that does the above idea. Could
> > you please do the performance tests again to see if the idea can help
> > reduce the overhead, Shi yu?
>
> 27 июля 2022 г., в 00:26, Jacob Champion написал(а):
>
> - libpq compression
> https://commitfest.postgresql.org/38/3499/
>
> Needs a rebase and response to feedback; mostly quiet since January.
Daniil is working on this, but currently he's on vacation.
I think we should not mark patch
On Thu, Jul 28, 2022 at 11:28 AM Peter Smith wrote:
>
> Hi Vignesh.
>
> FYI the v39* patch fails to apply [1]. Can you please rebase it?
>
>
> [1]
> === Applying patches on top of PostgreSQL commit ID
> 5f858dd3bebd1f3845aef2bff7f4345bfb7b74b3 ===
> === applying patch
>
Hi,
Freebsd 13.0, so far used by CI, is out of support. I've changed the
image to be built against 13.1, so we can switch to that.
I suspect it'd be better to remove the minor version numbers from the
image name, so that switches from 13.0 -> 13.1 don't require CI
changes. Any argument against?
On Tue, Jul 26, 2022 at 1:22 PM Masahiko Sawada wrote:
>
> Okay, I've attached an updated patch that does the above idea. Could
> you please do the performance tests again to see if the idea can help
> reduce the overhead, Shi yu?
>
While reviewing the patch for HEAD, I have changed a few
> > To understand the performance effects of the above, I have taken the
> > average of five checkpoints with the patch and without the patch in my
> > environment. Here are the results.
> > With patch: 269.65 s
> > Without patch: 269.60 s
>
> Those look like timed checkpoints - if the checkpoints
Here's a better idea, now that I'm emboldened by having working CI for
Windows frankenbuilds, and since I broke some stuff in this area on
MSYS[1], which caused me to look more closely at this area.
Why don't we just nuke pgwin32_is_junction() from orbit, and teach
Windows how to lstat()? We're
Here are some review comments for the HEAD_v7-0001 patch:
==
1.
I have a fundamental question about this patch.
IIUC the purpose of this patch is to ensure that (when
publish_via_root = true) the copy of the partition data will happen
only once (e.g. from one parent table on one of the
On Thu, Jul 28, 2022 at 12:56 PM Masahiko Sawada wrote:
>
> On Thu, Jul 28, 2022 at 4:13 PM Amit Kapila wrote:
> >
> > >
> > > While editing back branch patches, I realized that the following
> > > (parsed->xinfo & XACT_XINFO_HAS_INVALS) and (parsed->nmsgs > 0) are
> > > equivalent:
> > >
> > >
On Thursday, July 28, 2022 10:59 AM David Rowley wrote:
> On Thu, 28 Jul 2022 at 00:50, Amit Langote
> wrote:
> > So, in a way the caching scheme works for LIST partitioning only if
> > the same value appears consecutively in the input set, whereas it does
> > not for *a set of* values belonging
Hi hackers,
I found that when wal_consistency_checking = brin is set, it may cause redo
abort, all the standby-nodes lost, and the primary node can not be restart.
This bug exists in all versions of PostgreSQL.
The operation steps are as follows:
1. Create a primary instance, set
Hello,
On 2022-Jun-29, Imseih (AWS), Sami wrote:
> > Would you mind trying the second attached to abtain detailed log on
> > your testing environment? With the patch, the modified TAP test yields
> > the log lines like below.
>
> Thanks for this. I will apply this to the testing environment and
Hello,
Is there any way to get the timestamp of the transaction using LSN value ?
For example:
can we use the minimum recovery ending location in pg control file to get the
minimum recovery timestamp ?
Minimum recovery ending location: 28/28000B68
Thanks in advance,
Best,
Harinath.
On Thu, Jul 28, 2022 at 11:59 AM David Rowley wrote:
> On Thu, 28 Jul 2022 at 00:50, Amit Langote wrote:
> > So, in a way the caching scheme works for
> > LIST partitioning only if the same value appears consecutively in the
> > input set, whereas it does not for *a set of* values belonging to
At Thu, 28 Jul 2022 15:53:33 +0900, Masahiko Sawada
wrote in
> >
> Do you mean that both could be true at the same time? If I read
> GetRunningTransactionData() correctly, that doesn't happen.
So, I wrote "since it is debugging output", and "fine if we asuume the
record is sound". Is it any
At Thu, 28 Jul 2022 15:26:42 +0900, Fujii Masao
wrote in
>
>
> On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
> > At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
> > wrote in
> > I didn't see it from that viewpoint but I don't think that
> > unconditionally justifies other refactoring. If we
On Thu, Jul 28, 2022 at 4:13 PM Amit Kapila wrote:
>
> On Thu, Jul 28, 2022 at 11:56 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Jul 28, 2022 at 12:21 PM Amit Kapila
> > wrote:
> > >
> > > On Thu, Jul 28, 2022 at 7:18 AM Masahiko Sawada
> > > wrote:
> > > >
> >
> > While editing back branch
On Thu, Jul 28, 2022 at 11:56 AM Masahiko Sawada wrote:
>
> On Thu, Jul 28, 2022 at 12:21 PM Amit Kapila wrote:
> >
> > On Thu, Jul 28, 2022 at 7:18 AM Masahiko Sawada
> > wrote:
> > >
>
> While editing back branch patches, I realized that the following
> (parsed->xinfo &
v10 is just a trivial rebase. No changes. Moved to next commitfest.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From 86655a0231e277c3f1bc907a0f0eb669943d4c71 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Tue, 2 Feb 2021 14:03:43 -0300
Subject:
On Thu, Jul 28, 2022 at 3:24 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 28 Jul 2022 09:56:33 +0530, Ashutosh Bapat
> wrote in
> > Thanks Masahiko for the updated patch. It looks good to me.
> >
> > I wonder whether the logic should be, similar
> > to ProcArrayApplyRecoveryInfo()
> > if
On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
wrote in
I'm not sure the two are similar with each other. The new function
pgfdw_exec_pre_commit() looks like a merger of two isolated code paths
intended to share a seven-line codelet. I feel
() an
On Thu, Jul 28, 2022 at 12:21 PM Amit Kapila wrote:
>
> On Thu, Jul 28, 2022 at 7:18 AM Masahiko Sawada wrote:
> >
> > On Wed, Jul 27, 2022 at 8:33 PM Amit Kapila wrote:
> > >
> >
> > > I have changed accordingly in the attached
> > > and apart from that slightly modified the comments
1 - 100 of 103 matches
Mail list logo
