On Sat, May 4, 2024 at 7:36 AM Joe Conway wrote:
>
> On 5/3/24 11:44, Peter Eisentraut wrote:
> > On 03.05.24 16:13, Tom Lane wrote:
> >> Peter Eisentraut writes:
> >>> On 30.04.24 19:29, Tom Lane wrote:
> Also, the bigger picture here is the seeming assumption that "if
> we change
On Tue, May 14, 2024 at 10:07:14AM +, Bertrand Drouvot wrote:
> 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]
On Wed, May 15, 2024 at 03:03:00PM +1200, David Rowley wrote:
> On Tue, 9 Apr 2024 at 15:26, Michael Paquier wrote:
>> I would suggest to also wait until we're clearer with the situation
>> for all these mechanical changes, which I suspect is going to take 1~2
>> weeks at least.
>
> Since the
On 14.05.24 19:33, Nathan Bossart wrote:
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
On 15.05.24 06:21, Thomas Munro wrote:
And as I'm looking up how this was previously handled, I notice that
this list of clang-NN versions was last updated equally sneakily as part
of your patch to trim off LLVM <10 (820b5af73dc). I wonder if the
original intention of that configure code was
On Tue, May 14, 2024 at 10:03 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Peter,
>
...
> > 4.11.
> >
> > +# Alter the two_phase with the force_alter option. Apart from the the last
> > +# ALTER SUBSCRIPTION command, the command will abort the prepared
> > transaction
> > +# and succeed.
> >
> >
On Wed, May 15, 2024 at 03:24:05AM +, Imseih (AWS), Sami wrote:
>> I think we should generally report it when the backend executes a job
>> related to the query with that queryId. This means it would reset the
>> queryId at the end of the query execution.
>
> When the query completes
Hi Kuroda-san. Here are my review comments for latest v10* patches.
//
patch v10-0001
//
No changes. No comments.
//
patch v10-0002
//
==
Commit message
2.1.
Regarding the false->true case, the backend process alters the subtwophase to
Hi Thomas,
> This obviously fixed itself automatically soon after this message, but
> I figured out what happened: I had not actually fixed that referenced
> bug in cfbot :-(. It was checking for HTTP error codes correctly in
> the place that reads emails from the archives, but not the place
On Wed, 15 May 2024 at 15:40, jian he wrote:
> I am looking for an example where this information under json key
> "Serialization" is not zero.
> So far I have tried:
Something that requires detoasting.
> create table s(a text);
> insert into s select repeat('a', 1024) from
On Tue, May 14, 2024 at 06:07:51PM +0200, Erik Wienhold wrote:
> I split the change in two independent patches:
The split makes sense to me.
> Patch 0001 changes rules param and param_junk to only accept digits 0-9.
-param \${decinteger}
-param_junk
On Mon, May 13, 2024 at 2:33 AM Peter Eisentraut wrote:
> These patches look fine to me. The new cut-off makes sense, and it does
> save quite a bit of code. We do need to get the Cirrus CI Debian images
> updated first, as you had already written.
Thanks for looking!
> As part of this patch,
On Tue, May 14, 2024 at 10:22:29AM +, Ilyasov Ian wrote:
> 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
>
On Wed, May 15, 2024 at 10:13 AM David Rowley wrote:
>
> 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,
> >
> I discovered the current state of queryId reporting and found that it
> may be unlogical: Postgres resets queryId right before query execution
> in simple protocol and doesn't reset it at all in extended protocol and
> other ways to execute queries.
In exec_parse_message, exec_bind_message and
On Tue, 9 Apr 2024 at 15:26, Michael Paquier wrote:
> I would suggest to also wait until we're clearer with the situation
> for all these mechanical changes, which I suspect is going to take 1~2
> weeks at least.
Since the Oid resequencing and pgindent run is now done, I've pushed this patch.
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
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 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 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,
>
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
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
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
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:
> >
> >
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
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,
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
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
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
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
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 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 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
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
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 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 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 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
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
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
>
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
> 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
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
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
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)
> *
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: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:
+.
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
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
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
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 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 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
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
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
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
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
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 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
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 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
>>
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
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
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
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
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 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
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
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
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
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
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
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
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 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 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
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
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
>
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
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
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
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
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
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
>>>
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
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
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
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, 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)
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
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
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
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
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
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:
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
>
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
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
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
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
1 - 100 of 123 matches
Mail list logo
