On 13.05.2024 11:24, Matthias van de Meent wrote:
On Mon, 13 May 2024 at 10:42, Artur Formella wrote:
Motivation:
Commas of this type are allowed in many programming languages, in some
it is even recommended to use them at the ends of lists or objects.
Single trailing commas are a feature that
On 13.05.24 17:43, Alvaro Herrera wrote:
On 2024-May-13, Nathan Bossart wrote:
If we want to enhance the GitHub experience, we can also add these files to
the organization instead:
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-commu
On Tue, 20 Feb 2024 at 06:38, David Rowley wrote:
>
> On Tue, 20 Feb 2024 at 18:31, Tom Lane wrote:
> > FWIW, I seriously doubt that an extra walk of the plan tree is even
> > measurable compared to the number of cycles JIT compilation will
> > expend if it's called. So I don't buy your argument
On 13.05.24 17:26, Nathan Bossart wrote:
On Sun, May 12, 2024 at 05:17:42PM +0200, Peter Eisentraut wrote:
I don't know, I find these files kind of "yelling". It's fine to have a
couple, but now it's getting a bit much, and there are more that could be
added.
I'm not sure what you mean by thi
On Tue, 14 May 2024 at 19:56, Jelte Fennema-Nio wrote:
> I'm not saying I'd prefer the extra walk, but I don't think you'd need
> to do this extra walk for all plans. Afaict you could skip the extra
> walk when top_plan->total_cost < jit_above_cost. i.e. only doing the
> extra walk to determine wh
On 10.05.24 14:23, Alvaro Herrera wrote:
On 2024-May-10, Alvaro Herrera wrote:
Not sure what's going on here, or why it fails for me while the
buildfarm is all happy.
Ah, I ran 'git clean -dfx' and now it works correctly. I must have had
an incomplete rebuild.
I saw the same thing. The pr
13.05.2024 23:17, Tom Lane wrote:
3. We don't know exactly why hamerkop suddenly started seeing these
failures, but a plausible theory emerges after noting that its
reported time for the successful "make check" step dropped pretty
substantially right when this started. In the v13 branch, "make
c
> On 14 May 2024, at 07:12, Michael Paquier wrote:
> Hence, no objections to clean up that now. Thanks for asking.
Thanks for verifying, I've pushed this now.
--
Daniel Gustafsson
On Tue, 14 May 2024 at 07:43, Michael Paquier wrote:
>
> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> > Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> > the parameter number with atol which stops at the underscore. That's a
> > regression in faff8f8e4
On 2024-May-13, Robert Haas wrote:
> It seems to me that the practical thing to do about this problem is
> just decide not to solve it. I mean, it's currently the case that if
> you establish a PRIMARY KEY when you create a table, the columns of
> that key are marked NOT NULL and remain NOT NULL e
Hi hackers,
While resuming the work on refilenode stats (mentioned in [1] but did not share
the patch yet), I realized that my current POC patch is buggy enough to produce
things like:
024-05-14 09:51:14.783 UTC [1788714] FATAL: can only drop stats once
While the CONTEXT provides the list of dr
Hi Peter!
On Sun, May 12, 2024 at 10:33 PM Peter Eisentraut wrote:
>
> On 07.05.24 09:43, Jakub Wartak wrote:
> > NOTE: in case one will be testing this: one cannot ./configure with
> > --enable-debug as it prevents the compiler optimizations that actually
> > end up with the ".cold" branch optim
> On 14 May 2024, at 08:03, Michael Paquier wrote:
>
> On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
>>> Any chance we'll have these fixes in v17?
>>
>> Nice timing, I was actually rebasing them today to get them committed.
>
> Looks sensible seen from here, as these paths
Hello, hackers!
Recently I've been building postgres with different cflags and cppflags.
And suddenly on REL_15_STABLE, REL_16_STABLE and master
I faced a failure of a src/test/subscription/t/029_on_error.pl test when
CPPFLAGS="-DWAL_DEBUG"
and
printf "wal_debug = on\n" >> "${TEMP_CONF
On Tue, 14 May 2024 at 18:16, David Rowley wrote:
> I think for v17, we should consider adding a macro to explain.c to
> calculate the KB from bytes. There are other inconsistencies that it
> would be good to address. We normally round up to the nearest kilobyte
> with (bytes + 1023) / 1024, but
Hi everybody,
Being a technical writer, I attached a small patch that fixes minor
language stuff.
Thank you.
Elena Indrupskaya
Postgres Professional Company
Moscow, Russia
On 09.05.2024 07:03, Bruce Momjian wrote:
I have committed the first draft of the PG 17 release notes; you can
se
On Fri, 3 May 2024 at 16:03, David Rowley wrote:
> I'm trying to figure out why BufFileSize() Asserts that file->fileset
> isn't NULL, per 1a990b207.
I was hoping to get some feedback here.
Here's a patch to remove the Assert(). Changing it to
Assert(file->files != NULL); doesn't do anything us
Em ter., 14 de mai. de 2024 às 07:21, Daniel Gustafsson
escreveu:
> > On 14 May 2024, at 08:03, Michael Paquier wrote:
> >
> > On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
> >>> Any chance we'll have these fixes in v17?
> >>
> >> Nice timing, I was actually rebasing them to
David, Peter,
> > The actual parameter is "config_file", so apparently we are supposed to
> > either convert underscores to hyphens or we have a typo.
>
> We convert '-' to '_' when parsing long options (see ParseLongOption()
> in guc.c). So writing the long options with hyphens should generally
On Tue, 14 May 2024 at 10:19, David Rowley wrote:
> Here's a plan where the total cost of a subnode is greater than the
> total cost of the top node:
Ah I didn't realize it was possible for that to happen. **reads up on
plan costs**
This actually makes me think that using total_cost of the sub-n
On 2024-May-14, Jakub Wartak wrote:
> On Sun, May 12, 2024 at 10:33 PM Peter Eisentraut
> wrote:
> > Don't production builds use debug
> > symbols nowadays as well?
>
> Reality is apparently mixed,at least from what I have checked :
> - all RHEL 7.x/8.x (PGDG and our forks) do NOT come with
>
Hi Bertrand,
09.05.2024 15:20, Bertrand Drouvot wrote:
Oh I see, your test updates an existing dependency. v4 took care about brand new
dependencies creation (recordMultipleDependencies()) but forgot to take care
about changing an existing dependency (which is done in another code path:
changeDe
Hi,
> Thanks for all your great input. Here is the updated patch.
Here is the patch v4 with fixed typo ("geoq"). Per off-list feedback
from Alvaro - thanks!
--
Best regards,
Aleksander Alekseev
v4-0001-Clarify-error-message-about-specifying-config-fil.patch
Description: Binary data
Dear Peter,
Thanks for reviewing! New patch is available in [1].
> I'm having second thoughts about how these patches mention the option
> values "on|off". These are used in the ALTER SUBSCRIPTION document
> page for 'two_phase' and 'failover' parameters, and then those
> "on|off" get propagated
On Tue, 14 May 2024 at 02:56, Bruce Momjian wrote:
>
> On Sat, May 11, 2024 at 10:24:39AM -0400, Joe Conway wrote:
> > On 5/11/24 09:57, Jelte Fennema-Nio wrote:
> > > The buffering change improved performance up to ~40% in some of the
> > > benchmarks. The case it improves mostly is COPY of large
On Tue, May 14, 2024 at 6:33 PM David Rowley wrote:
>
> On Tue, 14 May 2024 at 18:16, David Rowley wrote:
> > I think for v17, we should consider adding a macro to explain.c to
> > calculate the KB from bytes. There are other inconsistencies that it
> > would be good to address. We normally roun
Hi,
We are down to three open items, all of which have proposed fixes.
That is great, but we need to keep things moving along, because
according to https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items
we are due to release beta1 on May 23. That means that a release
freeze will be in effect fr
On Thu, May 9, 2024 at 5:03 AM Bruce Momjian wrote
>
>
> I welcome feedback. For some reason it was an easier job than usual.
This looks better if "more case" -> "more cases" :
> Allow query nodes to be run in parallel in more case (Tom Lane)
On Wed, 15 May 2024 at 01:18, jian he wrote:
> else
> {
> ExplainPropertyInteger("Memory Used", "bytes",
>mem_counters->totalspace - mem_counters->freespace,
>es);
> ExplainPropertyInteger("Memory Allocated", "bytes",
>mem_counters->totalspace, es);
> }
> }
>
> the "else" branch, also
On Thu, Mar 7, 2024 at 12:32 PM Alvaro Herrera wrote:
> On 2024-Mar-07, Alvaro Herrera wrote:
> > Maybe we can add a flag RelationData->rd_ispkdeferred, so that
> > RelationGetPrimaryKeyIndex returned InvalidOid for deferrable PKs; then
> > logical replication would continue to not know about this
On Mon, Jan 29, 2024 at 2:32 AM Kyotaro Horiguchi
wrote:
> [ new patch set ]
Hi,
I think it would be helpful to make it more clear exactly what's going
on here. It looks 0001 is intended to revert
21ef4d4d897563adb2f7920ad53b734950f1e0a4, which was itself a revert of
728f86fec65537eade8d9e751961
Alexander Lakhin writes:
> 13.05.2024 23:17, Tom Lane wrote:
>> 3. We don't know exactly why hamerkop suddenly started seeing these
>> failures, but a plausible theory emerges after noting that its
>> reported time for the successful "make check" step dropped pretty
>> substantially right when thi
Dean Rasheed writes:
> On Tue, 14 May 2024 at 07:43, Michael Paquier wrote:
>> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
>>> Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
>>> the parameter number with atol which stops at the underscore. That's a
>>>
On 2024-May-14, Robert Haas wrote:
> On Thu, Mar 7, 2024 at 12:32 PM Alvaro Herrera
> wrote:
> > On 2024-Mar-07, Alvaro Herrera wrote:
> > > Maybe we can add a flag RelationData->rd_ispkdeferred, so that
> > > RelationGetPrimaryKeyIndex returned InvalidOid for deferrable PKs; then
> > > logical
On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > However, parent's table extended statistics already covers all its
> > > children.
> >
> > => That's the wrong explanation. It's not that "stats on the parent
> > table cover its children". It's that there are two types of
Heikki Linnakangas writes:
> On 13/05/2024 16:01, Juan Hernández wrote:
>> Do you consider useful to add a parameter (for example,
>> --separatetables) so when used the exporting file process can create a
>> different tablename.sql file for each table in database automatically?
> It'd be tricky
On Tue, May 14, 2024 at 10:42 AM Alvaro Herrera wrote:
> This had already been committed as 270af6f0df76 (the day before it was
> sent to the next commitfest). This commit wasn't included in the
> reverted set, though, so you still get deferrable PKs from
> RelationGetIndexList. I don't think th
14.05.2024 17:38, Tom Lane wrote:
As I mentioned in our off-list discussion, I have a lingering feeling
that this v14 commit could be affecting the results somehow:
Author: Tom Lane
Branch: master Release: REL_14_BR [d5a9a661f] 2020-10-18 12:56:43 -0400
Update the Winsock API version requ
Alvaro Herrera writes:
> On 2024-May-14, Jakub Wartak wrote:
>> Reality is apparently mixed,at least from what I have checked :
>> - all RHEL 7.x/8.x (PGDG and our forks) do NOT come with
>> --enable-debug according to pg_config.
> Ooh, yeah, that's true according to
> https://git.postgresql.org
On Tue, Apr 9, 2024 at 8:44 PM Thomas Munro wrote:
> I pushed the illegal attribute fix though. Thanks for the detective work!
This was commit 53c8d6c9f157f2bc8211b8de02417e55fefddbc7 and as I
understand it that fixed the issue originally reported on this thread.
Therefore, I have marked https:
On 2024-May-14, Robert Haas wrote:
> On Tue, May 14, 2024 at 10:42 AM Alvaro Herrera
> wrote:
> > This had already been committed as 270af6f0df76 (the day before it was
> > sent to the next commitfest). This commit wasn't included in the
> > reverted set, though, so you still get deferrable PKs
On Tue, May 14, 2024 at 11:11 AM Alvaro Herrera wrote:
> > So, are you saying this should be marked Committed in the commitfest?
>
> Yeah. I've done so.
Great, thanks.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, May 14, 2024 at 6:13 AM Jakub Wartak
wrote:
> OK I'll try to explain using assembly, but I'm not an expert on this.
> Let's go to the 1st post, assume we run with backtrace_function set:
I feel like this explanation doesn't really explain very much. I mean,
the question is not "how is it
On Fri, Feb 16, 2024 at 3:14 PM Melanie Plageman
wrote:
> [ review comments ]
Since there has been no response to these review comments for more
than 3 months, I have set https://commitfest.postgresql.org/48/4679/
to Returned with Feedback. Please feel free to update the status when
there is a ne
On Tue, May 14, 2024 at 10:05:01AM +0200, Peter Eisentraut wrote:
> On 13.05.24 17:26, Nathan Bossart wrote:
>> On Sun, May 12, 2024 at 05:17:42PM +0200, Peter Eisentraut wrote:
>> > I don't know, I find these files kind of "yelling". It's fine to have a
>> > couple, but now it's getting a bit muc
On Tue, Apr 16, 2024 at 3:06 AM Pavel Luzanov wrote:
> As for the Login column and its values.
> I'm not sure about using "Can" instead of "yes" to represent true.
> In other psql commands, boolean values are always shown as yes/no.
> NULL instead of false might be possible, but I'd rather check i
Nathan Bossart writes:
> On Tue, May 14, 2024 at 10:05:01AM +0200, Peter Eisentraut wrote:
>> My point is, in order to get that enhanced GitHub experience, you don't
>> actually have to commit these files into the individual source code
>> repository. You can add them to the organization and they
On 2024-05-14 16:40 +0200, Tom Lane wrote:
> Dean Rasheed writes:
> > On Tue, 14 May 2024 at 07:43, Michael Paquier wrote:
> >> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
> >>> Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
> >>> the parameter number wi
On Fri, Jan 12, 2024 at 4:11 PM Robert Haas wrote:
> I think that would definitely be better than "compress" and
> "decompress," but I was worried that it might be unclear to the user
> whether the parameter that they specified was from the point of view
> of the client or the server. Perhaps that
On 2024-May-14, Tom Lane wrote:
> I don't have a position on whether we want
> these additional files or not; but if we do, I think the best answer
> is to stick 'em under .github/ where they are out of the way but yet
> updatable by any committer.
+1 for .github/, that was my first reaction as w
On Tue, May 14, 2024 at 9:03 AM Robert Haas wrote:
> On Tue, Apr 16, 2024 at 3:06 AM Pavel Luzanov
> wrote:
> > As for the Login column and its values.
> > I'm not sure about using "Can" instead of "yes" to represent true.
> > In other psql commands, boolean values are always shown as yes/no.
>
On Tue, May 14, 2024 at 11:08 AM Robert Haas wrote:
>
> According to https://commitfest.postgresql.org/48/4746/ this patch set
> needs review, but:
>
> 1. Considering that there have been no updates for 5 months, maybe
> it's actually dead?
I've withdrawn this patch from the commitfest. I had be
On Mon, Jan 22, 2024 at 11:15 AM Tom Lane wrote:
> > Introduction of \gedit is interesting idea, but in this form it looks too
> > magic
>
> Yeah, I don't like it either --- it feels like something that belongs
> in an ETL tool not psql. The sheer size of the patch shows how far
> afield it is fr
On Mon, Dec 4, 2023 at 3:42 AM Richard Guo wrote:
> Then here is a trivial patch to adjust the comment, which should get
> reverted along with 867be9c07.
Richard, since you're a committer now, maybe you'd like to commit
this. I don't really understand the portion of your commit message
inside the
On Mon, Apr 29, 2024 at 11:04 AM Jacob Champion
wrote:
> On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
> > Unfortunately the error message you got in the client with that was
> > horrible (I modified the server to not accept the 'postgresql' protocol):
> >
> > psql "dbname=postgres ss
On Tue, May 14, 2024 at 06:12:26PM +0200, Alvaro Herrera wrote:
> On 2024-May-14, Tom Lane wrote:
>
>> I don't have a position on whether we want
>> these additional files or not; but if we do, I think the best answer
>> is to stick 'em under .github/ where they are out of the way but yet
>> updat
On Tue, May 14, 2024 at 2:18 AM Michael Paquier wrote:
>
> On Mon, May 13, 2024 at 10:05:03AM -0400, Melanie Plageman wrote:
> > Remove the assert and reset the field on which it previously asserted to
> > avoid incorrectly emitting NULL-filled tuples from a previous scan on
> > rescan.
>
> > -
On Wed, Apr 3, 2024 at 4:59 AM Jakub Wartak
wrote:
> Yes; I've forgotten about this one and clearly I had problems
> formulating it in proper shape to be accepted. I've moved it to the
> next CF now as this is not critical and I would prefer to help current
> timesenistive CF. Anyone is welcome to
On 5/14/24 19:42, Melanie Plageman wrote:
> On Tue, May 14, 2024 at 2:18 AM Michael Paquier wrote:
>>
>> On Mon, May 13, 2024 at 10:05:03AM -0400, Melanie Plageman wrote:
>>> Remove the assert and reset the field on which it previously asserted to
>>> avoid incorrectly emitting NULL-filled tuples
On Tue, May 14, 2024 at 12:30 PM Jacob Burroughs
wrote:
> I've withdrawn this patch from the commitfest. I had been waiting for
> some resolution on "Add new protocol message to change GUCs for usage
> with future protocol-only GUCs" before I rebased/refactored this one,
> because this would be i
On Tue, May 14, 2024 at 2:33 PM Tomas Vondra
wrote:
>
> On 5/14/24 19:42, Melanie Plageman wrote:
> > I've fixed this. I've also set enable_material off as I mentioned I
> > might in my earlier mail.
> >
>
> I'm not sure this (setting more and more GUCs to prevent hypothetical
> plan changes) is a
On 5/14/24 20:40, Melanie Plageman wrote:
> On Tue, May 14, 2024 at 2:33 PM Tomas Vondra
> wrote:
>>
>> On 5/14/24 19:42, Melanie Plageman wrote:
>>> I've fixed this. I've also set enable_material off as I mentioned I
>>> might in my earlier mail.
>>>
>>
>> I'm not sure this (setting more and more
On Fri, May 3, 2024 at 1:35 PM Phil Eaton wrote:
> Happy for feedback. Updated patch is attached.
I took a look at this patch and I don't think this is a very good
idea, for two reasons:
1. We change the table access method interface definitions not all
that infrequently, so I think this will be
On Wed, Feb 21, 2024 at 6:42 PM Thomas Munro wrote:
> Yeah, right. I will aim to get this into the tree next week. First,
> there are a couple of minor issues to resolve around freeing that
> Heikki mentioned. Then there is the question of whether we think this
> might be a candidate for back-pa
> I took a look at this patch and I don't think this is a very good
> idea,
No problem! I've dropped the v2 code additions and stuck with the v1
attempt plus feedback.
Thank you!
Phil
v3-0001-Add-minimal-C-example-and-SQL-registration-exampl.patch
Description: Binary data
On Tue, May 14, 2024 at 2:44 PM Tomas Vondra
wrote:
>
> On 5/14/24 20:40, Melanie Plageman wrote:
> > On Tue, May 14, 2024 at 2:33 PM Tomas Vondra
> > wrote:
> >>
> >> On 5/14/24 19:42, Melanie Plageman wrote:
> >>> I've fixed this. I've also set enable_material off as I mentioned I
> >>> might i
On Tue, May 14, 2024 at 1:35 PM Robert Haas wrote:
>
> Well, in my last response before the thread died, I complained that
> libpq_compression=gzip:compress=off was confusing, and I stand by
> that, because "compress" is used both in the name of the parameter and
> as an option within the value of
On Thu, May 9, 2024 at 12:04 AM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
I had two comments:
I think the read stream item:
"Allow the grouping of file
On 2024-May-14, Tomas Vondra wrote:
> On 5/14/24 19:42, Melanie Plageman wrote:
>
> >>> +SET enable_indexonlyscan = off;
> >>> +set enable_indexscan = off;
> >>> +SET enable_seqscan = off;
> >>
> >> Nit: adjusting the casing of the second SET here.
> >
> > I've fixed this. I've also set enable_m
On Tue, May 14, 2024 at 3:02 PM Phil Eaton wrote:
> > I took a look at this patch and I don't think this is a very good
> > idea,
>
> No problem! I've dropped the v2 code additions and stuck with the v1
> attempt plus feedback.
That looks more reasonable. I'd like to quibble with this text:
+. H
On 2024-May-14, Alvaro Herrera wrote:
> BTW, I was running the explain while desultorily enabling and disabling
> these GUCs and hit this assertion failure:
>
> #4 0x55e6c72afe28 in ExceptionalCondition
> (conditionName=conditionName@entry=0x55e6c731a928
> "scan->rs_empty_tuples_pending =
On Tue, May 14, 2024 at 3:22 PM Jacob Burroughs
wrote:
> What if we went with:
> Server side:
> * `libpq_compression=on` (I just want everything the server supports
> available; probably the most common case)
> * `libpq_compression=off` (I don't want any compression ever with this server)
> * `lib
On Tue, May 14, 2024 at 4:05 PM Alvaro Herrera wrote:
>
> On 2024-May-14, Tomas Vondra wrote:
>
> I wonder why it resets enable_indexscan at all. I see that this query
> first tries a seqscan, then if you disable that it tries an index only
> scan, and if you disable that you get the expected bit
On Tue, May 14, 2024 at 3:24 PM Robert Haas wrote:
>
> IMHO, that's a HUGE improvement. But:
>
> * I would probably change is the name "libpq_compression", because
> even though we have src/backend/libpq, we typically use libpq to refer
> to the client library, not the server's implementation of t
> You should add a test that creates a table with a very low fillfactor,
> low enough so only 1 tuple can fit on each page and insert a few dozen
> tuples. The test would do SELECT COUNT(*) to ensure you find the
> correct subset of tuples. You'd maybe want MIN(ctid) and MAX(ctid) in
> there too fo
On Tue, May 14, 2024 at 9:00 PM Alexander Lakhin wrote:
> 14.05.2024 03:38, Thomas Munro wrote:
> > I was beginning to suspect that lingering odour myself. I haven't
> > look at the GSS code but I was imagining that what we have here is
> > perhaps not unsent data dropped on the floor due to ling
On Tue, May 14, 2024 at 10:39:36AM +0200, Peter Eisentraut wrote:
> I saw the same thing. The problem is that there is incomplete dependency
> information in the makefiles (not meson) between src/common/ and what is
> using it. So whenever anything changes in src/common/, you pretty much have
> t
On Tue, May 14, 2024 at 10:32:14AM +0800, Andy Fan wrote:
> Bruce Momjian writes:
> > It was unclear from the commit message exactly what user-visible
> > optimization this allowed. Do you have details?
>
> Yes, It allows the query like "SELECT * FROM t1 WHERE t1.a in (SELECT a
> FROM t2 WHERE t
On Sat, May 11, 2024 at 03:32:55PM -0400, Andrew Dunstan wrote:
>
> On 2024-05-09 Th 00:03, Bruce Momjian wrote:
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
> >
> > It will be improv
On Tue, May 14, 2024 at 01:34:56PM +0300, Elena Indrupskaya wrote:
> Being a technical writer, I attached a small patch that fixes minor language
> stuff.
You are absolutely correct. Patch applied, thanks.
--
Bruce Momjian https://momjian.us
EDB
On Tue, May 14, 2024 at 10:51:41AM +0100, Dean Rasheed wrote:
> I've moved this to "Older bugs affecting stable branches", since it
> came in with v16.
Oops, thanks for fixing. I've somewhat missed that b2d47928908d was
in REL_16_STABLE.
--
Michael
signature.asc
Description: PGP signature
On Tue, May 14, 2024 at 02:20:24PM +0200, Jelte Fennema-Nio wrote:
> On Tue, 14 May 2024 at 02:56, Bruce Momjian wrote:
> >
> > On Sat, May 11, 2024 at 10:24:39AM -0400, Joe Conway wrote:
> > > On 5/11/24 09:57, Jelte Fennema-Nio wrote:
> > > > The buffering change improved performance up to ~40%
On Tue, May 14, 2024 at 02:58:41PM +0100, Pantelis Theodosiou wrote:
> On Thu, May 9, 2024 at 5:03 AM Bruce Momjian wrote
> >
> >
> > I welcome feedback. For some reason it was an easier job than usual.
>
> This looks better if "more case" -> "more cases" :
> > Allow query nodes to be run in pa
On Wed, May 15, 2024 at 02:01:21AM +1200, David Rowley wrote:
> Yeah, I missed that. Here's another patch.
>
> Thanks for looking.
Thanks for bringing in a patch that makes the whole picture more
consistent across the board. When it comes to MEMORY, I can get
behind your suggestion to use kB and
On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> On Thu, May 9, 2024 at 12:04 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
>
> I had
On Thu, May 9, 2024 at 10:48 PM Bruce Momjian wrote:
>
> On Thu, May 9, 2024 at 02:17:12PM +0900, Masahiko Sawada wrote:
> > Hi,
> >
>
> > Also, please consider the following item:
> >
> > - Improve eviction algorithm in ReorderBuffer using max-heap for many
> > subtransactions (5bec1d6bc)
>
> I
On Thu, May 09, 2024 at 12:20:51PM +, Bertrand Drouvot wrote:
> Oh I see, your test updates an existing dependency. v4 took care about brand
> new
> dependencies creation (recordMultipleDependencies()) but forgot to take care
> about changing an existing dependency (which is done in another c
plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
DO $$
DECLARE
i int;
BEGIN
FOR i IN 1_000..1_000 LOOP
END LOOP;
END $$;
ERROR: syntax error at or near "1_000."
LINE 5: FOR i IN 1_000..1_000 LOOP
The scan.l defines rule "numeric
Michael Paquier writes:
> Perhaps Alvaro and Tom would like to chime in, as committers of
> respectively 5de890e3610d and 06286709ee06?
No objection here. In a green field I might argue for
round-to-nearest instead of round-up, but it looks like we
have several precedents for round-up, so let's
On Sun, May 12, 2024 at 04:56:09PM +0200, Álvaro Herrera wrote:
> On 2024-May-11, Alvaro Herrera wrote:
>
> > I have found two more problems that [] require some more work to fix,
> > so I've decided to cut my losses now and revert the whole.
>
> Here's the revert patch, which I intend to push ea
On Mon, May 13, 2024 at 09:00:28AM -0400, Robert Haas wrote:
> > Specifically, the problem is that I mentioned that we could restrict the
> > NOT NULL NO INHERIT addition in pg_dump for primary keys to occur only
> > in pg_upgrade; but it turns this is not correct. In normal
> > dump/restore, ther
explain (format json, analyze, wal, buffers, memory, serialize) insert
into tenk1 select * from tenk1 limit 1;
QUERY PLAN
---
[
{
"Plan": {
"Node Type": "ModifyTable",
"Operation": "Insert",
"Parallel Aware"
On Tue, May 14, 2024 at 10:22:35AM +0800, Tender Wang wrote:
>
>
> jian he 于2024年5月9日周四 18:00写道：
>
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> >
On Wed, 15 May 2024 at 13:00, Bruce Momjian wrote:
>
> On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> > "Reduce system calls by automatically merging reads up to io_combine_limit"
>
> Uh, as I understand it, the reduced number of system calls is not the
> value of the feature,
On Wed, May 15, 2024 at 02:03:32PM +1200, David Rowley wrote:
> On Wed, 15 May 2024 at 13:00, Bruce Momjian wrote:
> >
> > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> > > "Reduce system calls by automatically merging reads up to
> > > io_combine_limit"
> >
> > Uh, as I und
On Tue, May 14, 2024 at 03:03:58PM +0300, Aleksander Alekseev wrote:
> Here is the patch v4 with fixed typo ("geoq"). Per off-list feedback
> from Alvaro - thanks!
+ -c name=value command-line parameter, or its equivalent
+ --name=value variation. For example,
-postgres -c log_conne
On Wed, 15 May 2024 at 13:44, jian he wrote:
>"Shared Hit Blocks": 0,
>"Shared Read Blocks": 0,
>"Shared Dirtied Blocks": 0,
>"Shared Written Blocks": 0,
>"Local Hit Blocks": 0,
>"Local Read Blocks": 0,
>"Local Dirtied Blocks": 0,
>"L
On Wed, May 15, 2024 at 10:10:28AM +0900, Masahiko Sawada wrote:
> > I looked at that item and I don't have a generic "make logical
> > replication apply faster" item to merge it into, and many
> > subtransactions seemed like enough of an edge-case that I didn't think
> > mentioning it make sense.
On Wed, 15 May 2024 at 14:06, Bruce Momjian wrote:
> I can use your wording, but how much prefetching to we enable now?
I believe the read stream API is used for Seq Scan, ANALYZE and
pg_prewarm(). fadvise() is used when the next buffer that's required
is not in shared buffers on any build that
On Sun, May 12, 2024 at 10:11 PM Tatsuo Ishii wrote:
> > I am able to apply all your patches. I found that a similar thing
> > happened before [0] and I guess your case is similar. Adding Thomas to
> > CC, he may be able to help more.
>
> Ok. Thanks for the info.
This obviously fixed itself autom
1 - 100 of 119 matches
Mail list logo
