Hi,
Thank you for the patch!
On Mon, Jul 3, 2023 at 12:12 AM vignesh C wrote:
>
> Hi,
>
> Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE":
> 1) GRANT, REVOKE and FOR USER keyword was not displayed in tab
> completion of alter default privileges like the below statement:
>
> 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()).
On 2024-03-26 17:16, Masahiko Sawada wrote:
On Tue, Mar 26, 2024 at 3:04 PM Bharath Rupireddy
wrote:
On Tue, Mar 26, 2024 at 9:56 AM Masahiko Sawada
wrote:
>
> > > errmsg("data type incompatibility at line %llu for column %s: \"%s\"",
>
> > > I guess it would be better to make the log messa
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 to modify the codes to prohibit abbreviation of the value.
Please help me u
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
> >
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 caller doesn't need them. It was hard to skip
them in a way that would save an
On Thu, Mar 28, 2024 at 12:55 PM Masahiko Sawada wrote:
>
> Pushed the refactoring patch.
>
> I've attached the rebased vacuum improvement patch for cfbot. I
> mentioned in the commit message that this patch eliminates the 1GB
> limitation.
>
> I think the patch is in good shape. Do you have other
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.
No -- this function handles just a single constraint, as
On Thu, 28 Mar 2024 at 01:43, David G. Johnston
wrote:
>
> On Wed, Mar 27, 2024 at 5:17 PM Bruce Momjian 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 both p
On Wed, 27 Mar 2024 at 19:46, Alvaro Herrera wrote:
>
> On 2024-Mar-27, Alvaro Herrera wrote:
>
> > I changed it so that the error messages are returned as translated
> > phrases, and was bothered by the fact that if errors happen repeatedly,
> > the memory for them might be leaked. Maybe this is
On Wed, 27 Mar 2024 at 19:27, Alvaro Herrera wrote:
> I ended up reducing the two PG_TRY blocks to a single one. I see no
> reason to split them up, and this way it looks more legible.
I definitely agree this looks better. Not sure why I hadn't done that,
maybe it wasn't possible in one of the e
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 both places suggested by David.
Changed the error hint to use "ex
Hi,
On Wed, Mar 27, 2024 at 09:00:37PM +0530, Bharath Rupireddy wrote:
> standby for sync slots. 0002 implementing inactive timeout GUC based
> invalidation mechanism.
>
> Please have a look.
Thanks!
Regarding 0002:
Some testing:
T1 ===
When the slot is invalidated on the primary, then the r
Hi, Alexander!
Thank you for working on these patches.
On Thu, 28 Mar 2024 at 02:14, Alexander Korotkov
wrote:
> Hi, Pavel!
>
> Thank you for your feedback. The revised patch set is attached.
>
> I found that vacuum.c has a lot of heap-specific code. Thus, it
> should be OK for analyze.c to kee
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. So
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 a
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
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 siz
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,
Sri
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
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 i
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 your
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 t
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: respect
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
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 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
> 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 o
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 '' >> ri-collation-
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 Retu
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 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 s
> 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 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 revi
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 code
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 englis
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?
>
> Th
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
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 sy
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
patc
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 8:5
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 careful
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 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 tori
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
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 exist
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 t
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 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 co
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
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)
https://buildfarm.postgresql.org/cgi-
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 call
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 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 cle
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, b
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 this
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 it'd
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 warni
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 b
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&dt=2024-03-28%2016%3A01%3A14
--
Álvaro Herrera 48°01'N 7°57'E — ht
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]
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kestrel&dt=2024-03-28%2016%3
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 ...
--
Ál
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: !!!C
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 c
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 t
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 t
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 don't
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 agree
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 ma
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 be
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 case
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 bet
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, whic
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 det
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 ...
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 see
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 scri
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 c
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 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
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 "accel
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 ca
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 a
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 ha
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 table_scan_bitmap
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 it'
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 t
> -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 doesn
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 ·
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 don'
> -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 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 definitions
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 is
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 uses
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 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 do
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 v
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 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 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, Ja
1 - 100 of 123 matches
Mail list logo
