Hi,
ReorderBufferTupleBuf is defined as follow:
/* an individual tuple, stored in one chunk of memory */
typedef struct ReorderBufferTupleBuf
{
/* position in preallocated list */
slist_node node;
/* tuple header, the interesting bit for users of logical decoding */
On Wed, Jul 26, 2023 at 10:10 AM Peter Smith wrote:
>
> Here are some comments for patch v22-0001.
>
> ==
> 1. General -- naming conventions
>
> There is quite a lot of inconsistency with variable/parameter naming
> styles in this patch. I understand in most cases the names are copied
>
On 2023/7/26 11:16, Michael Paquier wrote> The performance numbers
presented upthread for the CRC computations
are kind of nice in this environment, but honestly I have no idea how
much this architecture is used. Perhaps that's only something in
China? I am not seeing much activity around that
On Mon, Jul 24, 2023 at 9:00 AM Amit Kapila wrote:
>
> On Mon, Jul 24, 2023 at 8:03 AM Bharath Rupireddy
> wrote:
> >
> > On Fri, Jul 21, 2023 at 5:16 PM shveta malik wrote:
> > >
> > > Thanks Bharat for letting us know. It is okay to split the patch, it
> > > may definitely help to understand
Here are some comments for patch v22-0001.
==
1. General -- naming conventions
There is quite a lot of inconsistency with variable/parameter naming
styles in this patch. I understand in most cases the names are copied
unchanged from the original functions. Still, since this is a big
refactor
On Wed, Jul 26, 2023 at 12:16:28PM +0900, Michael Paquier wrote:
> On Wed, Jul 05, 2023 at 02:11:02PM +0700, John Naylor wrote:
>> Before I look at this again: Are there any objections to another CRC
>> implementation for the reason of having no buildfarm member?
>
> [ ... ]
>
> Anyway, based on
I took a look at this patch and changed a couple things:
* I made a similar adjustment to a few lines that seem to have been
missed.
* I removed a couple of asterisks from the adjusted lines in order to
maintain the existing line lengths.
Barring additional feedback, I think this is
On Tue, Jul 25, 2023 at 10:33 PM Andres Freund wrote:
>
> On 2023-07-25 14:31:00 +0530, Amit Kapila wrote:
> > To ensure that all the data has been sent during the upgrade, we can
> > ensure that each logical slot's confirmed_flush_lsn (position in the
> > WAL till which subscriber has confirmed
On Tue, Jul 25, 2023 at 5:29 PM Tomas Vondra
wrote:
>
> On 7/25/23 08:28, Amit Kapila wrote:
> > On Mon, Jul 24, 2023 at 9:32 PM Tomas Vondra
> > wrote:
> >>
> >> On 7/24/23 12:40, Amit Kapila wrote:
> >>> On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
> >>> wrote:
> >>>
> >>> Even after that,
While chatting to Robert and Andres about all this, a new idea came
up. Or, rather, one of the first ideas that was initially rejected,
now resurrected to try out a suggestion of Andres’s on how to
de-pessimise it. Unfortunately, it also suffers from Windows-specific
problems that I originally
On Wed, Jul 26, 2023 at 09:02:54AM +0900, Michael Paquier wrote:
> I've been sleeping on that a bit more, and I'd still go with the
> refactoring where we initialize one cluster and have all the tests
> done by TAP, for the sake of being much cheaper without changing the
> coverage, while being
On Tue, Jul 25, 2023 at 05:16:56PM -0700, Nathan Bossart wrote:
> On Tue, Jul 25, 2023 at 04:24:26PM -0700, Nathan Bossart wrote:
>> I started taking a look at this and ended up adding to_binary() and a
>> bigint version of to_oct() for completeness. While I was at it, I moved
>> the
On Wed, Jul 05, 2023 at 02:11:02PM +0700, John Naylor wrote:
> Also, please don't top-post (which means: quoting an entire message, with
> new text at the top) -- it clutters our archives.
>
> Before I look at this again: Are there any objections to another CRC
> implementation for the reason of
Many thanks to huchangqi. Now we have loongarch64 support for both old
world ABI and new world ABI on the buildfarm!
Forwarded Message
Subject: Re: [PATCH] Add loongarch native checksum implementation.
Date: Tue, 25 Jul 2023 15:51:43 +0800
From: huchangqi
To: YANG Xudong
On Wed, Jul 05, 2023 at 10:14:22AM -0400, Greg Sabino Mullane wrote:
> Would like to hear others weigh in, I think it's still only three states
> plus a default, so I'm not convinced it warrants multiple statements yet. :)
I find that hard to parse, so having more lines to get a better idea
of
Hi,
On 2023-07-25 20:10:06 -0400, Tom Lane wrote:
> grassquit has been failing to run the regression tests for the last
> few days, since [1]:
>
> # +++ regress check in src/test/regress +++
> # using temp instance on port 6880 with PID 766305
> ERROR: stack depth limit exceeded
> HINT:
On Tue, Jul 25, 2023 at 04:24:26PM -0700, Nathan Bossart wrote:
> I started taking a look at this and ended up adding to_binary() and a
> bigint version of to_oct() for completeness. While I was at it, I moved
> the base-conversion logic out to a separate static function that
> to_binary/oct/hex
On Tue, Jun 27, 2023 at 09:19:26PM +1200, David Rowley wrote:
> Because of all of what is mentioned above about the current state of
> tuplesort, there does not really seem to be much need to have chunk
> headers in memory we allocate for tuples at all. Not having these
> saves us a further 8
grassquit has been failing to run the regression tests for the last
few days, since [1]:
# +++ regress check in src/test/regress +++
# using temp instance on port 6880 with PID 766305
ERROR: stack depth limit exceeded
HINT: Increase the configuration parameter "max_stack_depth" (currently
On Mon, Jul 24, 2023 at 05:38:45PM +0900, Michael Paquier wrote:
> Which is basically the same thing with TAP except that these are
> grouped now? The value of a few raw SQL queries with a
> NO_INSTALLCHECK does not strike me as enough on top of having to
> maintain two different sets of tests.
On Tue, Jul 25, 2023 at 04:34:47PM +0800, jian he wrote:
> so T_ReindexStmt should only be in ProcessUtilitySlow, if you want
> to create an event trigger on reindex?
>
> regression tests work fine. I even play with partitions.
It would be an idea to have some regression tests for partitions,
On Thu, Jun 29, 2023 at 2:32 AM Alena Rybakina wrote:
> Hi! I'm sorry I didn't answer you right away, I was too busy with work.
Same for me, this time. I was busy working on my patch, which I
finally posted yesterday.
> To be honest, I didn't think about the fact that my optimization can help
On Tue, Jul 25, 2023 at 02:35:31PM +0300, Aleksander Alekseev wrote:
>> - Assert(cacheinfo[cacheId].reloid != 0);
>> + Assert(cacheinfo[cacheId].reloid != InvalidOid);
>> + Assert(cacheinfo[cacheId].indoid != InvalidOid);
>> No objections about checking for the index OID given
On Tue, Apr 04, 2023 at 08:45:36PM -0400, Kirk Wolak wrote:
> Marked Ready for Committer.
I started taking a look at this and ended up adding to_binary() and a
bigint version of to_oct() for completeness. While I was at it, I moved
the base-conversion logic out to a separate static function that
On Mon, Jul 10, 2023 at 10:29 PM Peter Geoghegan wrote:
> > Let's add a src/backend/access/rmgrdesc/README file. We don't currently
> > have any explanation anywhere why the rmgr desc functions are in a
> > separate directory. The README would be a good place to explain that,
> > and to have the
On Tue, Jul 25, 2023 at 12:37:18PM -0400, Greg Sabino Mullane wrote:
> Yes, it should. I had some trouble getting it to work that way in the first
> place, but now I realize it was just my unfamiliarity with this part of the
> code. So thanks for the hint: v2 of the patch is much simplified by
Hi,
On 2023-07-26 07:40:31 +0900, Michael Paquier wrote:
> On Tue, Jul 25, 2023 at 09:49:01AM -0700, Andres Freund wrote:
> > FWIW, I'm working on a patch that replaces WAL insert locks as a whole,
> > because they don't scale all that well.
>
> What were you looking at here? Just wondering.
On Tue, Jul 25, 2023 at 09:49:01AM -0700, Andres Freund wrote:
> FWIW, I'm working on a patch that replaces WAL insert locks as a whole,
> because they don't scale all that well.
What were you looking at here? Just wondering.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 25, 2023 at 12:57:37PM -0700, Andres Freund wrote:
> I just rebased my aio tree over the commit and promptly, on the first run, saw
> a hang. I did some debugging on that. Unfortunately repeated runs haven't
> repeated that hang, despite quite a bit of trying.
>
> The symptom I was
On Fri, Jul 21, 2023 at 7:17 PM Dean Rasheed wrote:
>
> On Mon, 17 Jul 2023 at 20:43, Jeff Davis wrote:
> >
> > > > Maybe instead of a function it could be a special table reference
> > > > like:
> > > >
> > > > MERGE ... RETURNING MERGE.action, MERGE.action_number, id, val?
> > > >
> > The
On Tue, Jul 25, 2023 at 3:07 PM Isaac Morland wrote:
> OK, I suppose ALTER CONSTRAINT to change the deferrable status and validity
> (that is why we're doing this, right?) needs the constraint name. But the
> constraint name is formulaic by default, and my proposal is to suppress it
> only
Hi,
On 2023-07-25 16:43:16 +0900, Michael Paquier wrote:
> On Sat, Jul 22, 2023 at 01:08:49PM +0530, Bharath Rupireddy wrote:
> > Yes, it looks safe to me too.
>
> 0001 has been now applied. I have done more tests while looking at
> this patch since yesterday and was surprised to see higher TPS
On Tue, 25 Jul 2023 at 14:59, Robert Haas wrote:
> On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland
> wrote:
> > My suggestion is for \d+ to show NOT NULL constraints only if there is
> something weird going on (wrong name, duplicate constraints, …). If there
> is nothing weird about the
On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland wrote:
> My suggestion is for \d+ to show NOT NULL constraints only if there is
> something weird going on (wrong name, duplicate constraints, …). If there is
> nothing weird about the constraint then explicitly listing it provides
> absolutely no
On Mon, Jul 24, 2023 at 12:00:15PM -0700, Nathan Bossart wrote:
> Here is a sketch of this approach. It required fewer #ifdefs than I was
> expecting. At the moment, this one seems like the winner to me.
Here is a polished patch set for this approach. I've also added a 0004
that replaces the
On Tue, 25 Jul 2023 at 12:24, Alvaro Herrera
wrote:
> On 2023-Jul-25, Isaac Morland wrote:
>
> > I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> > cluttering up displays. Can we legislate that all NOT NULL implementing
> > constraints are named by mashing together the
Hi,
On 2023-07-25 14:31:00 +0530, Amit Kapila wrote:
> To ensure that all the data has been sent during the upgrade, we can
> ensure that each logical slot's confirmed_flush_lsn (position in the
> WAL till which subscriber has confirmed that it has applied the WAL)
> is the same as
Hi,
On 2023-07-25 16:43:16 +0900, Michael Paquier wrote:
> On Sat, Jul 22, 2023 at 01:08:49PM +0530, Bharath Rupireddy wrote:
> > Yes, it looks safe to me too.
>
> 0001 has been now applied. I have done more tests while looking at
> this patch since yesterday and was surprised to see higher TPS
On Mon, Jul 24, 2023 at 6:46 PM Michael Paquier wrote:
> Shouldn't this new field be marked as query_jumble_location
>
Yes, it should. I had some trouble getting it to work that way in the first
place, but now I realize it was just my unfamiliarity with this part of the
code. So thanks for the
On 7/24/23 14:57, Ashutosh Bapat wrote:
> ...
>
>>
>>
>> 2) Currently, the sequences hash table is in reorderbuffer, i.e. global.
>> I was thinking maybe we should have it in the transaction (because we
>> need to do cleanup at the end). It seem a bit inconvenient, because then
>> we'd need to
On 2023-Jul-25, Isaac Morland wrote:
> I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> cluttering up displays. Can we legislate that all NOT NULL implementing
> constraints are named by mashing together the table name, column name, and
> something to identify it as a
Hi,
On 2023-07-25 08:50:19 -0700, Andres Freund wrote:
> One idea I had was to add a fastpath that won't parse all strings, but will
> parse the strings that we would generate, and fall back to the more general
> variant if it fails. See the attached, rough, prototype:
>
> fix_COPY_DEFAULT.patch
On Tue, 25 Jul 2023 at 11:39, Robert Haas wrote:
>
> I'm not really thrilled with the idea of every not-null constraint
> having a name, to be honest. Of all the kinds of constraints that we
> have in the system, NOT NULL constraints are probably the ones where
> naming them is least likely to
Hi,
On 2023-07-25 23:37:08 +1200, David Rowley wrote:
> On Tue, 25 Jul 2023 at 17:34, Andres Freund wrote:
> I've not really studied the fix_COPY_DEFAULT.patch patch. Is there a
> reason to delay committing that? It would be good to eliminate that
> as a variable for the current performance
On Tue, Jul 25, 2023 at 8:36 AM Alvaro Herrera wrote:
> Okay then, I've made these show up in the footer of \d+. This is in
> patch 0003 here. Please let me know what do you think of the regression
> changes.
Seems OK.
I'm not really thrilled with the idea of every not-null constraint
having
Hi Alvaro,
Thanks for your feedback.
> Hmm, this *Extended function looks a bit funny, and I think it's because
> it's part of a backpatched bugfix that didn't want to modify ABI. If
> we're modifying this code, maybe we should get rid of the shim, that is,
> move the boolean argument to
Hi,
Melih Mutlu , 21 Tem 2023 Cum, 12:47 tarihinde şunu
yazdı:
> I did not realize the order is the same with .c files. Good to know. I'll
> fix it along with other comments.
>
Addressed the recent reviews and attached the updated patches.
Thanks,
--
Melih Mutlu
Microsoft
> On 25 Jul 2023, at 16:31, Ranier Vilela wrote:
> rmtree function can leak 64 bytes per call,
> when it can't open a directory.
Skimming the tree there doesn't seem to be any callers which aren't exiting or
ereporting on failure so the real-world impact seems low. That being said,
silencing
On 2023-Jul-25, Aleksander Alekseev wrote:
> Hi,
>
> The proposed patch is a small refactoring of inval.{c,h}:
>
> """
> The "public functions" separator comment doesn't reflect reality anymore.
> We could rearrange the order of the functions. However, this would
> complicate
>
Hi,
Per Coverity.
rmtree function can leak 64 bytes per call,
when it can't open a directory.
patch attached.
best regards,
Ranier Vilela
0003-Avoid-possible-memory-leak-64-bytes-per-rmtree-call-.patch
Description: Binary data
> On 20 Jul 2023, at 17:24, Daniel Gustafsson wrote:
>
>> On 17 Jul 2023, at 20:26, Cary Huang wrote:
>
Perhaps calling "tm2timestamp(_time, 0, NULL, )" without checking
the return code would be just fine. I see some other usages of
tm2timstamp() in other code areas also skip
Hi,
The proposed patch is a small refactoring of inval.{c,h}:
"""
The "public functions" separator comment doesn't reflect reality anymore.
We could rearrange the order of the functions. However, this would
complicate
back-porting of the patches, thus removing the comment instead.
On Tue, Jul 25, 2023 at 5:29 PM Tomas Vondra
wrote:
>
> Right. I think the important detail is that during sync we have three
> important LSNs
>
> - LSN1 where the slot is created
> - LSN2 where the copy happens
> - LSN3 where we consider the sync completed
>
> For tables, LSN1 == LSN2, because
Hi,
> diff --git a/src/test/regress/expected/rpr.out
> b/src/test/regress/expected/rpr.out
> index 6bf8818911..f3fd22de2a 100644
> --- a/src/test/regress/expected/rpr.out
> +++ b/src/test/regress/expected/rpr.out
> @@ -230,6 +230,79 @@ SELECT company, tdate, price, rpr(price) OVER w FROM
>
On Tue, 25 Jul 2023 at 20:45, Mr.Bim wrote:
> Partition pruning is not working on the updates query, am I missing something?
In PG13, partition pruning for UPDATE and DELETE only works during
query planning. Because you're using CURRENT_TIMESTAMP, that's not an
immutable expression which can be
On 7/25/23 08:28, Amit Kapila wrote:
> On Mon, Jul 24, 2023 at 9:32 PM Tomas Vondra
> wrote:
>>
>> On 7/24/23 12:40, Amit Kapila wrote:
>>> On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
>>> wrote:
>>>
>>> Even after that, see below the value of the sequence is still not
>>> caught up. Later,
On Tue, 25 Jul 2023 at 17:34, Andres Freund wrote:
> prep:
> COPY (SELECT generate_series(1, 200) a, (random() * 10 - 5)::int
> b, 3243423 c) TO '/tmp/lotsaints.copy';
> DROP TABLE lotsaints; CREATE UNLOGGED TABLE lotsaints(a int, b int, c int);
>
> benchmark:
> psql -qX -c 'truncate
Hi Michael,
> - Assert(cacheinfo[cacheId].reloid != 0);
> + Assert(cacheinfo[cacheId].reloid != InvalidOid);
> + Assert(cacheinfo[cacheId].indoid != InvalidOid);
> No objections about checking for the index OID given out to catch
> any failures at an early stage before doing an
On Tue, Jul 25, 2023 at 01:56:41PM +0530, Bharath Rupireddy wrote:
> I've observed the following failure once in one of my Cirrus CI runs
> on Windows Server on HEAD:
>
> timed out waiting for match: (?^:User was holding shared buffer pin
> for too long) at
>
On Mon, Jul 24, 2023 at 6:14 PM Ashutosh Bapat
wrote:
>
> On Sat, Jul 22, 2023 at 10:18 AM Amit Kapila wrote:
>
> > Right. I'll push and backpatch this till 15 by Tuesday unless you guys
> > think otherwise.
>
> WFM.
>
Pushed.
--
With Regards,
Amit Kapila.
On Mon, Jul 24, 2023 at 4:22 PM Tomas Vondra
wrote:
>
> On 7/24/23 12:40, Amit Kapila wrote:
> > On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
> > wrote:
> >>
> >> 0005, 0006 and 0007 are all related to the initial sequence sync. [3]
> >> resulted in 0007 and I think we need it. That leaves 0005
Hi Anthonin,
> I have a working prototype of a pg_tracing extension and wanted some feedback
> on the design and architecture.
The patch looks very interesting, thanks for working on it and for
sharing. The facts that the patch doesn't change the core except for
two lines in instrument.{c.h}
Currently, we don't perform $SUBJECT at the time of shutdown of the
server. I think currently it will only have a minor impact that after
restart subscribers will ask to start processing before the
XLOG_CHECKPOINT_SHUTDOWN or maybe after the switchover the old
publisher will have an extra WAL
Hello,
Partition pruning is not working on the updates query, am I missing something?
Able get around this by manually pinning the table partition to the date
partition but, it's a manual process.
PostgreSQL 13.8 on AWS
Partition table using pg_partman v4.5.1Each daily partition contains about
On Fri, Jul 21, 2023 at 12:47 PM Garrett Thornburg wrote:
>
> Added my v1 patch to add REINDEX to event triggers.
>
> I originally built this against pg15 but rebased to master for the patch to
> hopefully make it easier for maintainers to merge. The rebase was automatic
> so it should be easy
On 25.07.2023 06:24, Andres Freund wrote:
Thanks Anton / Victoria for the report and fix. Pushed.
Thanks!
Have a nice day!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi,
I've observed the following failure once in one of my Cirrus CI runs
on Windows Server on HEAD:
timed out waiting for match: (?^:User was holding shared buffer pin
for too long) at
C:/cirrus/src/test/recovery/t/031_recovery_conflict.pl line 318.
# Postmaster PID for node "primary" is 696
Start of forwarded message
From: huchangqi
To: YANG Xudong
Subject: Re: [PATCH] Add loongarch native checksum implementation.
Date: Tue, 25 Jul 2023 15:51:43 +0800
Both cisticola and nuthatch are on the buildfarm now。
cisticola is "old world ABI".
On Mon, Jul 24, 2023 at 12:05 PM Amit Kapila wrote:
>
> On Mon, Jul 24, 2023 at 6:39 AM Masahiko Sawada wrote:
> >
> > On Sat, Jul 22, 2023 at 7:32 PM Amit Kapila wrote:
> > >
> > >
> > > You have moved most of the comments related to the restriction of
> > > which index can be picked atop
On Sat, Jul 22, 2023 at 01:08:49PM +0530, Bharath Rupireddy wrote:
> Yes, it looks safe to me too.
0001 has been now applied. I have done more tests while looking at
this patch since yesterday and was surprised to see higher TPS numbers
on HEAD with the same tests as previously, and the patch
When forming an outer join's joinrel, we have the is_pushed_down flag in
RestrictInfo nodes to distinguish those quals that are in that join's
JOIN/ON condition from those that were pushed down to the joinrel and
thus act as filter quals. Since now we have the outer-join-aware-Var
infrastructure,
On Wed, Jul 19, 2023 at 09:31:35PM +0800, 赵锐(惜元) wrote:
> Recently I encountered an issue: pg_rewind fails when dealing with
> in-place tablespace. The problem seems to be that pg_rewind is
> treating in-place tablespace as symbolic link, while in fact it
> should be treated as directory.
>
On Mon, Jul 24, 2023 at 07:40:04PM +, Imseih (AWS), Sami wrote:
> WaitForOlderSnapshots is used here to ensure that snapshots older than
> the start of the ALTER TABLE DETACH CONCURRENTLY are completely removed
> to guarantee consistency, however it does seem to cause deadlocks for at
> least
On Thu, Jul 20, 2023 at 10:47:00PM -0600, Garrett Thornburg wrote:
> Added my v1 patch to add REINDEX to event triggers.
>
> I originally built this against pg15 but rebased to master for the patch
> to hopefully make it easier for maintainers to merge. The rebase was
> automatic so it should be
On Mon, Jul 24, 2023 at 9:32 PM Tomas Vondra
wrote:
>
> On 7/24/23 12:40, Amit Kapila wrote:
> > On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
> > wrote:
> >
> > Even after that, see below the value of the sequence is still not
> > caught up. Later, when the apply worker processes all the WAL,
75 matches
Mail list logo
