On Tue, 26 Mar 2024 at 10:05, Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 12:02 PM Masahiko Sawada
> wrote:
> >
> >
> > I've attached new version patches.
>
> Since the previous patch conflicts with the current HEAD, I've
> attached the rebased patches.
Thanks for the updated patch.
One
> Rest of patches, rebased.
Hello,
I read and tested only the first patch so far. Creation of temp
tables and rollback in your script work 3-4 times faster with
0001-type-cache.patch on my windows laptop.
In the patch I found a copy of the comment "If it's domain over
composite, reset
On 2024-03-29 04:27 +0100, Isaac Morland wrote:
> On Thu, 28 Mar 2024 at 20:38, Erik Wienhold wrote:
>
>
> > Of course the problem with using DROP and CREATE is that indexes and
> > privileges (anything else?) must also be restored. I haven't bothered
> > with that yet.
> >
>
> Not just those
On Wed, Mar 27, 2024 at 9:00 PM Bharath Rupireddy
wrote:
>
>
> Thanks. I'm attaching v29 patches. 0001 managing inactive_since on the
> standby for sync slots.
>
Commit message states: "why we can't just update inactive_since for
synced slots on the standby with the value received from remote
Dear Hou,
Thanks for updating the patch! Here is a comment for it.
```
+/*
+ * By advancing the restart_lsn, confirmed_lsn, and xmin using
+ * fast-forward logical decoding, we can verify whether a consistent
+ * snapshot can be built. This process also involves
On Fri, Mar 29, 2024 at 6:36 AM Zhijie Hou (Fujitsu)
wrote:
>
> Attach a new version patch which fixed an un-initialized variable issue and
> added some comments. Also, temporarily enable DEBUG2 for the 040 tap-test so
> that
> we can analyze the possible CFbot failures easily.
As suggested by
On Thu, Mar 28, 2024 at 11:22 PM Alvaro Herrera
wrote:
> On 2024-Mar-28, Ashutosh Bapat wrote:
>
> > LGTM.
> >
> > The commitfest entry is marked as RFC already.
> >
> > Thanks for taking care of the comments.
>
> Thanks for reviewing. I noticed a typo "seperate", fixed here.
Thanks for
Thomas Munro writes:
> Oh, sorry, I had missed the part where newer compilers fix the issue
> too. Old out-of-support versions of AIX running old compilers, what
> fun.
Indeed. One of the topics that needs investigation if you want to
pursue this is which AIX system and compiler versions still
On Thu, 28 Mar 2024 at 20:38, Erik Wienhold wrote:
> Of course the problem with using DROP and CREATE is that indexes and
> privileges (anything else?) must also be restored. I haven't bothered
> with that yet.
>
Not just those — also anything that depends on the matview, such as views
and
On Thu, Mar 28, 2024 at 1:23 PM Amit Langote wrote:
>
> On Wed, Mar 27, 2024 at 1:34 PM Amit Langote wrote:
> > On Wed, Mar 27, 2024 at 12:42 PM jian he
> > wrote:
> > > hi.
> > > I don't fully understand all the code in json_table patch.
> > > maybe we can split it into several patches,
> >
>
On Fri, Mar 29, 2024 at 4:00 PM Thomas Munro wrote:
> On Fri, Mar 29, 2024 at 3:48 PM Noah Misch wrote:
> > The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
> > You can get past the compiler bug by upgrading your compiler; both ibm-clang
> > 17.1.1.2 and gcc 13.2.0 are
Noah Misch writes:
> On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
>> Also, would like to know if we can access the buildfarm(power machines) to
>> run any of the specific tests to hit this assert.
> https://portal.cfarm.net/users/new/ is the form to request access. It lists
> the
On 2024-03-29 02:42 +0100, David G. Johnston wrote:
> For consideration for the doc portion. The existing wording is too
> imprecise for my liking and just tacking on "expects...create type" is
> jarring.
>
> """
> Creates a typed table, which takes it structure from an existing (name
>
On Fri, Mar 29, 2024 at 3:48 PM Noah Misch wrote:
> On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> > We are setting up the build environment and trying to build the source and
> > also trying to analyze the assert from the Aix point of view.
>
> The thread Alvaro and Tom cited
On 2024-03-28 21:54, Masahiko Sawada wrote:
On Thu, Mar 28, 2024 at 9:38 PM torikoshia
wrote:
On 2024-03-28 10:20, Masahiko Sawada wrote:
> Hi,
>
> On Thu, Jan 18, 2024 at 5:33 PM Masahiko Sawada
> wrote:
>>
>> On Thu, Jan 18, 2024 at 4:59 PM Alexander Korotkov
>> wrote:
>> >
>> > On Thu,
On Thu, Mar 28, 2024 at 11:09:43AM +, Sriram RK wrote:
> We are setting up the build environment and trying to build the source and
> also trying to analyze the assert from the Aix point of view.
The thread Alvaro and Tom cited contains an analysis. It's a compiler bug.
You can get past the
On Thu, Mar 7, 2024 at 9:29 PM Erik Wienhold wrote:
> I wrote:
> > The attached v2 is a simpler patch that instead modifies the existing
> > error message.
>
> Forgot to attach v2.
>
>
For consideration for the doc portion. The existing wording is too
imprecise for my liking and just tacking on
On Fri, Mar 29, 2024 at 10:43 AM Tomas Vondra
wrote:
> I think there's some sort of bug, triggering this assert in heapam
>
> Assert(BufferGetBlockNumber(hscan->rs_cbuf) == tbmres->blockno);
Thanks for the repro. I can't seem to reproduce it (still trying) but
I assume this is with Melanie's
On Thursday, March 28, 2024 10:02 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, March 28, 2024 7:32 PM Amit Kapila
> wrote:
> >
> > On Thu, Mar 28, 2024 at 10:08 AM Zhijie Hou (Fujitsu)
> >
> > wrote:
> > >
> > > When analyzing one BF error[1], we find an issue of slotsync: Since
> > > we
I wrote:
> On 2023-05-15 06:32 +0200, Kirk Wolak wrote:
> > Personally I would appreciate it if \sv actually showed you the DDL.
> > Oftentimes I will \ev something to review it, with syntax highlighting.
>
> +1. I was just reviewing some matviews and was surprised that psql
> lacks commands to
On Thu, Mar 28, 2024, at 9:39 AM, Alexander Korotkov wrote:
> Fixed along with other issues spotted by Alexander Lakhin.
[I didn't read the whole thread. I'm sorry if I missed something ...]
You renamed the function in a previous version but let me suggest another one:
pg_wal_replay_wait. It
On Fri, Mar 22, 2024 at 3:45 PM Kartyshov Ivan
wrote:
> On 2024-03-20 12:11, Alexander Korotkov wrote:
> > On Wed, Mar 20, 2024 at 12:34 AM Kartyshov Ivan
> > wrote:
> >> > 4.2 With an unreasonably high future LSN, BEGIN command waits
> >> > unboundedly, shouldn't we check if the specified LSN
On 2023-05-15 06:32 +0200, Kirk Wolak wrote:
> Personally I would appreciate it if \sv actually showed you the DDL.
> Oftentimes I will \ev something to review it, with syntax highlighting.
+1. I was just reviewing some matviews and was surprised that psql
lacks commands to show their
> -Original Message-
> From: Amonson, Paul D
> Sent: Thursday, March 28, 2024 3:03 PM
> To: Nathan Bossart
> ...
> I will review the new patch to see if there are anything that jumps out at me.
I see in the meson.build you added the new file twice?
@@ -7,6 +7,7 @@ pgport_sources = [
On 2024-Mar-28, Amonson, Paul D wrote:
> > -Original Message-
> > From: Nathan Bossart
> > Sent: Thursday, March 28, 2024 2:39 PM
> > To: Amonson, Paul D
> >
> > * The latest patch set from Paul Amonson appeared to support MSVC in the
> > meson build, but not the autoconf one. I
On 3/27/24 23:10, Dave Cramer wrote:
> Dave Cramer
>
>
> On Wed, 27 Mar 2024 at 17:57, David Rowley wrote:
>
>> On Thu, 28 Mar 2024 at 10:33, Dave Cramer wrote:
>>> There is a report on the pgjdbc github JDBC Driver shows erratic
>> behavior when filtering on CURRENT_DATE · pgjdbc/pgjdbc ·
> -Original Message-
> From: Nathan Bossart
> Sent: Thursday, March 28, 2024 2:39 PM
> To: Amonson, Paul D
>
> * The latest patch set from Paul Amonson appeared to support MSVC in the
> meson build, but not the autoconf one. I don't have much expertise here,
> so the v14 patch
On Thu, Mar 28, 2024 at 04:38:54PM -0500, Nathan Bossart wrote:
> Here is a v14 of the patch that I think is beginning to approach something
> committable. Besides general review and testing, there are two things that
> I'd like to bring up:
>
> * The latest patch set from Paul Amonson appeared
On 3/28/24 21:45, Robert Haas wrote:
> On Tue, Mar 26, 2024 at 2:09 PM Tomas Vondra
> wrote:
>> The patch I shared a couple minutes ago should fix this, effectively
>> restoring the original debug behavior. I liked the approach with calling
>> strategy_implementation a bit more, I wonder if
On 3/27/24 20:37, Melanie Plageman wrote:
> On Mon, Mar 25, 2024 at 12:07:09PM -0400, Melanie Plageman wrote:
>> On Sun, Mar 24, 2024 at 06:37:20PM -0400, Melanie Plageman wrote:
>>> On Sun, Mar 24, 2024 at 5:59 PM Tomas Vondra
>>> wrote:
BTW when you say "up to 'Make
Here is a v14 of the patch that I think is beginning to approach something
committable. Besides general review and testing, there are two things that
I'd like to bring up:
* The latest patch set from Paul Amonson appeared to support MSVC in the
meson build, but not the autoconf one. I don't
On Fri, Mar 29, 2024 at 7:01 AM Tomas Vondra
wrote:
> On 3/28/24 06:20, Thomas Munro wrote:
> > With the unexplained but apparently somewhat systematic regression
> > patterns on certain tests and settings, I wonder if they might be due
> > to read_stream.c trying to form larger reads, making it
jian he writes:
> trying to do it this way.
> not sure the following error message is expected.
> SELECT pg_basetype(-1);
> ERROR: cache lookup failed for type 4294967295
Yeah, that's not really OK. You could say it's fine for bogus input,
but we've found over the years that it's better for
On Tue, Mar 26, 2024 at 2:09 PM Tomas Vondra
wrote:
> The patch I shared a couple minutes ago should fix this, effectively
> restoring the original debug behavior. I liked the approach with calling
> strategy_implementation a bit more, I wonder if it'd be better to go
> back to that for the
On Thu, Mar 28, 2024 at 01:23:36PM +0100, Jelte Fennema-Nio wrote:
> +
> +Turning this setting off is intended for environments where the
> +configuration of PostgreSQL is managed by
> +some external tool.
> +In such environments, a well intentioned superuser
I wrote:
> David Rowley writes:
>> Maybe something with "Parameters" in the name?
> SubqueryParameters might be OK. Or SubqueryPlannerExtra?
> Since this is a bespoke struct that will probably only ever
> be used with subquery_planner, naming it after that function
> seems like a good idea.
On
On Wed, Mar 27, 2024 at 18:54 Robert Haas wrote:
> On Wed, Mar 27, 2024 at 7:39 AM David Rowley wrote:
> > Robert, I understand you'd like a bit more from this patch. I'm
> > wondering if you planning on blocking another committer from going
> > ahead with this? Or if you have a reason why the
On Wed, Mar 27, 2024 at 14:39 David Rowley wrote:
> On Fri, 22 Mar 2024 at 12:46, Melih Mutlu wrote:
> > I did all of the above changes and it seems like those resolved the
> regression issue.
>
> Thanks for adjusting the patch. The numbers do look better, but on
> looking at your test.sh
David Rowley writes:
> The problem is informing the UNION child query about what it is. I
> thought I could do root->parent_root->parse->setOperations for a UNION
> child to know what it is, but that breaks for a query such as:
Yeah, having grouping_planner poke into the parent level
doesn't
On Thu, Mar 28, 2024 at 02:43:38PM -0400, Robert Haas wrote:
> How would you like to proceed from here? I think that in addressing
> all of the comments given in the last few days, the documentation has
> gotten modestly worse. I think it was crisp and clear before, and now
> it feels a little ...
Hi Sami!
(v21)
First and foremost, thank you very much for the review.
> 1/ I looked through other psql-meta commands and the “+” adds details but
> does not change output format. In this patch, conninfo and conninfo+
> have completely different output. The former is a string with all the
On Thu, Mar 28, 2024 at 1:46 PM Bruce Momjian wrote:
> The concern about this patch is not its contents but because it is our
> first attempt at putting limits on the superuser for an external tool.
> If done improperly, this could open a flood of problems, including CVE
> and user confusion,
Jakub Wartak writes:
> While chasing some other bug I've learned that backtrace_functions
> might be misleading with top elog/ereport() address.
That was understood from the beginning: this type of backtrace is
inherently pretty imprecise, and I doubt there is much that can
be done to make it
Alvaro Herrera writes:
> On 2024-Mar-28, Tom Lane wrote:
>> If the test fails both when the machine is too slow and when it's
>> too fast, then there's zero hope of making it stable and we should
>> just remove it.
> It doesn't fail when it's too fast -- it's just that it doesn't cover
> the
On 3/28/24 06:20, Thomas Munro wrote:
> With the unexplained but apparently somewhat systematic regression
> patterns on certain tests and settings, I wonder if they might be due
> to read_stream.c trying to form larger reads, making it a bit lazier.
> It tries to see what the next block will be
On 2024-Mar-28, Tom Lane wrote:
> Jelte Fennema-Nio writes:
>
> > I think we don't really want to make the timeout too short. Otherwise
> > the query might get cancelled before we push any query down to the
> > FDW. I guess that means that for some slow machines even 10ms is not
> > enough to
On Thu, Mar 28, 2024 at 08:38:24AM -0400, Robert Haas wrote:
> Let's please, please stop pretending like this patch is somehow
> deserving of special scrutiny. There's barely even anything to
> scrutinize. It's literally if (!variable) ereport(...) plus some
> boilerplate and docs. I entirely
Jelte Fennema-Nio writes:
> On Thu, 28 Mar 2024 at 17:43, Alvaro Herrera wrote:
>> Hah, you're right, I can reproduce with a smaller timeout, and using SET
>> LOCAL works as a fix. If we're doing that, why not reduce the timeout
>> to 1ms? We don't need to wait extra 9ms ...
> I think we
Tomas Vondra writes:
> Yeah. I think it's good to design the data/queries in such a way that
> the behavior does not flip due to minor noise like in this case.
+1
> But I'm a bit confused - how come the estimates do change at all? The
> analyze simply fetches 30k rows, and tenk only has 10k of
On Thu, 28 Mar 2024 at 17:43, Alvaro Herrera wrote:
> Hah, you're right, I can reproduce with a smaller timeout, and using SET
> LOCAL works as a fix. If we're doing that, why not reduce the timeout
> to 1ms? We don't need to wait extra 9ms ...
I think we don't really want to make the timeout
On 2024-Mar-28, Amit Langote wrote:
> Here's patch 1 for the time being that implements barebones
> JSON_TABLE(), that is, without NESTED paths/columns and PLAN clause.
> I've tried to shape the interfaces so that those features can be added
> in future commits without significant rewrite of the
On 3/28/24 16:00, Alexander Lakhin wrote:
> ...
>
> Using the trick Thomas proposed in [1] (see my modification attached), I
> could reproduce the failure easily on my workstation with no specific
> conditions:
> 2024-03-28 14:05:13.792 UTC client backend[2358012]
> pg_regress/test_setup LOG:
On 2024-Mar-28, Jelte Fennema-Nio wrote:
> Ugh that's annoying, the RESET is timing out too I guess.
Hah, you're right, I can reproduce with a smaller timeout, and using SET
LOCAL works as a fix. If we're doing that, why not reduce the timeout
to 1ms? We don't need to wait extra 9ms ...
--
On Thu, 28 Mar 2024 at 17:34, Alvaro Herrera wrote:
>
> Eh, kestrel has also failed[1], apparently every query after the large
> JOIN that this commit added as test fails with a statement timeout error.
>
> [1]
>
Eh, kestrel has also failed[1], apparently every query after the large
JOIN that this commit added as test fails with a statement timeout error.
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kestrel=2024-03-28%2016%3A01%3A14
--
Álvaro Herrera 48°01'N 7°57'E —
On Thu, Mar 28, 2024 at 12:01 PM Tom Lane wrote:
> > Well, there's the abort case, too, which I think is almost equally
> > important.
>
> True, but in the abort case there probably *are* resources to be
> cleaned up, so I'm not seeing that the fast-path idea helps.
> Although maybe the idea of
Robert Haas writes:
> On Thu, Mar 28, 2024 at 11:50 AM Tom Lane wrote:
>> Yeah, I was thinking about that too. The normal case is that you
>> don't hold any releasable resources except locks when arriving at
>> CommitSubTransaction --- if you do, it's a bug and we're going to
>> print leak
On Thu, Mar 28, 2024 at 11:50 AM Tom Lane wrote:
> Yeah, I was thinking about that too. The normal case is that you
> don't hold any releasable resources except locks when arriving at
> CommitSubTransaction --- if you do, it's a bug and we're going to
> print leak warnings. Seems like maybe
On 2024-Mar-26, Justin Pryzby wrote:
> Looks right. That's how I originally wrote it, except for the
> "stmt->accessMethod != NULL" case.
>
> I prefered my way - the grammar should refuse to set stmt->accessMethod
> for inappropriate relkinds. And you could assert that.
Hmm, I didn't like
Robert Haas writes:
> Hmm, I wonder if that's actually where the cycles are going. There's
> an awful lot of separate function calls inside CommitSubTransaction(),
> and in the common case, each one of them has to individually decide
> that it doesn't need to do anything. Sure, they're all fast,
On Thu, Mar 28, 2024 at 10:59 AM Tom Lane wrote:
> Yeah. The whole ResourceOwner mechanism is not exactly lightweight,
> but it's hard to argue that we don't need it. I wonder whether we
> could get anywhere by deeming that a "small enough" subtransaction
> doesn't need to have its resources
On Thu, 28 Mar 2024 at 21:26, Alexander Korotkov wrote:
> Hi Pavel!
>
> Revised patchset is attached.
>
> On Thu, Mar 28, 2024 at 3:12 PM Pavel Borisov wrote:
>> The other extensibility that seems quite clear and uncontroversial to me is
>> 0006.
>>
>> It simply shifts the decision on whether
On Thu, Mar 28, 2024 at 4:49 AM Heikki Linnakangas wrote:
>
> On 28/03/2024 03:53, Melanie Plageman wrote:
> > On Thu, Mar 28, 2024 at 01:04:04AM +0200, Heikki Linnakangas wrote:
> >> One change with this is that live_tuples and many of the other fields are
> >> now again updated, even if the
Hello hackers,
When running multiple 027_stream_regress.pl test instances in parallel
(and with aggressive autovacuum) on a rather slow machine, I encountered
test failures due to the subselect test instability just as the following
failures on buildfarm:
1)
Robert Haas writes:
> I sort of assumed you were going to commit the patch as you had it.
OK, I will move ahead on that.
> I actually
> really wish we could find some way of making subtransactions
> significantly lighter-wait, because I think the cost of spinning up
> and tearing down a trivial
On Wed, Mar 27, 2024 at 5:28 PM Tom Lane wrote:
> After mulling it over for awhile, I still think the extra checking
> is appropriate, especially since this patch is enlarging the set of
> things that can happen in parallel mode. How do you want to proceed?
I sort of assumed you were going to
On Thursday, March 28, 2024 7:32 PM Amit Kapila wrote:
>
> On Thu, Mar 28, 2024 at 10:08 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > When analyzing one BF error[1], we find an issue of slotsync: Since we
> > don't perform logical decoding for the synced slots when syncing the
> > lsn/xmin of slot,
On Tue, Mar 19, 2024 at 7:17 AM Andrei Lepikhov
wrote:
> On 14/3/2024 16:31, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
> > As you can see this case is not related to partial indexes. Just no
> > index selective for the whole query. However, splitting scan by
Hi, Alexander!
The other extensibility that seems quite clear and uncontroversial to me is
0006.
It simply shifts the decision on whether tuple inserts should invoke
inserts to the related indices to the table am level. It doesn't change the
current heap insert behavior so it's safe for the
On Thu, Mar 28, 2024 at 5:28 PM Bharath Rupireddy
wrote:
>
> On Thu, Mar 28, 2024 at 1:43 PM torikoshia wrote:
> >
> > Attached patch fixes the doc,
>
> May I know which patch you are referring to? And, what do you mean by
> "fixes the doc"?
>
> > but I'm wondering perhaps it might be
> > better
On Thu, Mar 28, 2024 at 9:38 PM torikoshia wrote:
>
> On 2024-03-28 10:20, Masahiko Sawada wrote:
> > Hi,
> >
> > On Thu, Jan 18, 2024 at 5:33 PM Masahiko Sawada
> > wrote:
> >>
> >> On Thu, Jan 18, 2024 at 4:59 PM Alexander Korotkov
> >> wrote:
> >> >
> >> > On Thu, Jan 18, 2024 at 4:16 AM
On Thu, Mar 28, 2024 at 9:37 AM Thomas Munro wrote:
>
> > v12
>
> Hi all,
>
> I didn't review the patch but one thing jumped out: I don't think it's
> OK to hold a spinlock while (1) looping over an array of backends and
> (2) making system calls (SetLatch()).
Good catch, thank you.
Fixed along
On Wed, Mar 27, 2024 at 6:24 PM Bruce Momjian wrote:
> Please ignore my complaints, and my apologies.
>
> As far as the GUC change, let's just be careful since we have a bad
> history of pushing things near the end that we regret. I am not saying
> that would be this feature, but let's be
On 2024-03-28 10:20, Masahiko Sawada wrote:
Hi,
On Thu, Jan 18, 2024 at 5:33 PM Masahiko Sawada
wrote:
On Thu, Jan 18, 2024 at 4:59 PM Alexander Korotkov
wrote:
>
> On Thu, Jan 18, 2024 at 4:16 AM torikoshia wrote:
> > On 2024-01-18 10:10, jian he wrote:
> > > On Thu, Jan 18, 2024 at
On 28/03/2024 13:15, Matthias van de Meent wrote:
On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
some time rebase and fix various little things:
With the recent changes to backend startup committed by you, this
Hi,
On Thu, Mar 28, 2024 at 05:05:35PM +0530, Amit Kapila wrote:
> On Thu, Mar 28, 2024 at 3:34 PM Bertrand Drouvot
> wrote:
> >
> > On Thu, Mar 28, 2024 at 04:38:19AM +, Zhijie Hou (Fujitsu) wrote:
> >
> > > To fix this, we could use the fast forward logical decoding to advance
> > > the
On 2024-03-28 17:27, Bharath Rupireddy wrote:
On Thu, Mar 28, 2024 at 1:43 PM torikoshia
wrote:
Attached patch fixes the doc,
May I know which patch you are referring to? And, what do you mean by
"fixes the doc"?
Ugh, I replied to the wrong thread.
Sorry for making you confused and please
On Thu, Mar 28, 2024 at 8:16 AM Andrey M. Borodin wrote:
> > On 1 Dec 2023, at 19:00, Karl O. Pinc wrote:
> >
> > I won't be able to submit
> > new patches based on reviews for 2 weeks.
>
> Hi everyone!
>
> Is there any work going on? Maybe is someone interested in moving this
> forward?
>
>
On Thu, 28 Mar 2024 at 12:57, Robert Haas wrote:
> I disagree with a lot of these changes. I think the old version was
> mostly better. But I can live with a lot of it if it makes other
> people happy.
I'd have been fine with many of the previous versions of the docs too.
(I'm not a native
On 2024-Mar-28, Alvaro Herrera wrote:
> Undefined symbols for architecture arm64:
> "_libintl_gettext", referenced from:
> _libpqsrv_cancel in dblink.o
> _libpqsrv_cancel in dblink.o
> ld: symbol(s) not found for architecture arm64
> clang: error: linker command failed with exit
> On 29 Oct 2023, at 21:30, Denis Smirnov wrote:
>
> I have taken a look at this discussion, at the code and I am confused how we
> choose tuple table slot (TTS) type in PG.
After offline discussion with Denis, we decided to withdraw this patch from CF
for now. If anyone is willing to
> On 1 Dec 2023, at 19:00, Karl O. Pinc wrote:
>
> I won't be able to submit
> new patches based on reviews for 2 weeks.
Hi everyone!
Is there any work going on? Maybe is someone interested in moving this forward?
Thanks!
Best regards, Andrey Borodin.
> On 8 Aug 2023, at 12:31, John Naylor wrote:
>
> > > Also the shared counter is the cause of the slowdown, but not the reason
> > > for the numeric limit.
> >
> > Isn't it both? typedef Oid is unsigned int = 2^32, and according to
> > GetNewOidWithIndex() logic if we exhaust the whole OID
Alvaro Herrera 于2024年3月28日周四 17:18写道：
> On 2024-Mar-28, Tender Wang wrote:
>
> > RemoveConstraintById() should think recurse(e.g. partition table)? I'm
> not
> > sure now.
> > If we should think process recurse in RemoveConstraintById(), the
> > function will look complicated than before.
>
>
On Thu, Mar 28, 2024 at 5:31 PM Andrey M. Borodin wrote:
>
> This thread is registered on CF [0] but is not active since 2023. Is anyone
> working on this? I understand that this is a nice feature. Should we move it
> to next CF or withdraw CF entry?
>
At this stage, we should close either
Hi -hackers,
While chasing some other bug I've learned that backtrace_functions
might be misleading with top elog/ereport() address.
Reproducer:
# using Tom's reproducer on master:
wget
https://www.postgresql.org/message-id/attachment/112394/ri-collation-bug-example.sql
echo '' >>
> On 18 Jul 2023, at 12:09, Zhijie Hou (Fujitsu) wrote:
>
> Here is the POC patch(0004) for the second approach
Hi everyone!
This thread is registered on CF [0] but is not active since 2023. Is anyone
working on this? I understand that this is a nice feature. Should we move it to
next CF
On Thu, Mar 28, 2024 at 5:42 AM Jelte Fennema-Nio wrote:
> On Thu, 28 Mar 2024 at 10:24, Jelte Fennema-Nio wrote:
> > I addressed them all I think. Mostly the small changes that were
> > suggested, but I rewrote the sentence with "might be discarded". And I
> > added references to the new GUC in
Hm, indri failed:
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new
-Wendif-labels -Wmissing-format-attribute -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument
On Thu, Mar 28, 2024 at 3:34 PM Bertrand Drouvot
wrote:
>
> On Thu, Mar 28, 2024 at 04:38:19AM +, Zhijie Hou (Fujitsu) wrote:
>
> > To fix this, we could use the fast forward logical decoding to advance the
> > synced
> > slot's lsn/xmin when syncing these values instead of directly updating
Then I would make the trivial change to respect the new
io_combine_limit GUC that I'm gearing up to commit in another thread.
As attached.
From 7993cede8939cad9172867ccc690a44ea25d1ad6 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 29 Mar 2024 00:22:53 +1300
Subject: [PATCH] fixup:
On Thu, Mar 28, 2024 at 10:08 AM Zhijie Hou (Fujitsu)
wrote:
>
> When analyzing one BF error[1], we find an issue of slotsync: Since we don't
> perform logical decoding for the synced slots when syncing the lsn/xmin of
> slot, no logical snapshots will be serialized to disk. So, when user starts
Em qua., 27 de mar. de 2024 às 23:08, Euler Taveira
escreveu:
> On Wed, Mar 27, 2024, at 8:50 PM, Ranier Vilela wrote:
>
> Coverity has some reports in the new code
> pg_createsubscriber.c
> I think that Coverity is right.
>
>
> It depends on your "right" definition.
>
I do not think so.
If
On Fri, Mar 29, 2024 at 12:06 AM Thomas Munro wrote:
> Small bug fix: the condition in the final test at the end of
> read_stream_look_ahead() wasn't quite right. In general when looking
> ahead, we don't need to start a read just because the pending read
> would bring us up to stream->distance
On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
>
> I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
> some time rebase and fix various little things:
With the recent changes to backend startup committed by you, this
patchset has gotten major apply failures.
Could you
Hi Team,
We are setting up the build environment and trying to build the source and also
trying to analyze the assert from the Aix point of view.
Also, would like to know if we can access the buildfarm(power machines) to run
any of the specific tests to hit this assert.
Thanks & regards,
Small bug fix: the condition in the final test at the end of
read_stream_look_ahead() wasn't quite right. In general when looking
ahead, we don't need to start a read just because the pending read
would bring us up to stream->distance if submitted now (we'd prefer to
build it all the way up to
On 2024-Mar-28, Jelte Fennema-Nio wrote:
> Your changes look good, apart from the prverror stuff indeed. If you
> remove the prverror stuff again I think this is ready to commit.
Great, thanks for looking. Pushed now, I'll be closing the commitfest
entry shortly.
--
Álvaro Herrera
Hi,
Thanks for the review.
On Thu, Mar 28, 2024 at 4:07 AM Masahiko Sawada
wrote:
> As for the proposed patch, the following part should handle the temp
> tables too:
>
True, I've missed the local blocks. I've updated the patch:
- read_rate and write_rate now include local block usage
- I've
Hi,
On Thu, Mar 28, 2024 at 04:38:19AM +, Zhijie Hou (Fujitsu) wrote:
> Hi,
>
> When analyzing one BF error[1], we find an issue of slotsync: Since we don't
> perform logical decoding for the synced slots when syncing the lsn/xmin of
> slot, no logical snapshots will be serialized to disk.
1 - 100 of 118 matches
Mail list logo
