On 14.10.24 11:28, Peter Eisentraut wrote:
On 03.10.24 23:13, Nathan Bossart wrote:
On Tue, Oct 01, 2024 at 11:15:02AM -0400, Peter Eisentraut wrote:
I have committed 0001 (the new option) and 0004 (the docs tweak). I
think
there is consensus for the rest, too, but I'll leave it for a few
mor
On Wed, Oct 16, 2024, at 05:31, jian he wrote:
> Hi.
> I only checked 0001, 0002, 0003.
> the raw format patch is v9-0016.
> 003-0016 is a lot of small patches, maybe you can consolidate it to
> make the review more easier.
Thanks for reviewing.
OK, I've consolidated the v9 0003-0016 into a singl
> On 16 Oct 2024, at 06:57, David G. Johnston
> wrote:
> I’m for the status-quo. We don’t imply removal when we say deprecated, only
> that (usually) a better alternative exists. This setup meets our existing
> standards.
The status-quo is inconsistency, we sometimes remove features we've m
On 2024/10/16 14:18, Michael Paquier wrote:
On Tue, Oct 15, 2024 at 08:26:06PM -0500, Nathan Bossart wrote:
Well, the point is that you can't use "postgres -C" to view this GUC while
the server is running. I can see how the present wording might be
misinterpreted, though. Perhaps we should
On Sun, Aug 04, 2024 at 03:50:37PM +0500, Andrey M. Borodin wrote:
> There was a bug: when time was not moving on, I was updating used
> time by a nanosecond, instead of 1/4096 of millisecond.
> V27 fixes that.
+static uint64 get_real_time_ns()
+{
+ struct timespec tmp;
+
+ clock_gett
Hey Tomas,
Would you be interested in registering the patch for CF 2024-11?
Please let us know if there is anything we can do to help with additional review
or testing.
Regards,
Soumyadeep & Shirisha
Broadcom
>Hmm, I'm not sure we want that, because if we do this, then
>ECPGget_sqlca() gets run with the debug_mutex held. In the original
>coding, it's run without the mutex.
Thank you for pointing that out. I agree with your observation. But there is
another room for improvement - we can avoid unnecessa
On Sat, Oct 12, 2024 at 01:48:15AM +0200, Joel Jacobson wrote:
> In passing, consistently use "stdin" for COPY FROM and "stdout" for COPY TO,
> even though it has no effect on the tests per se, it seems
> better to be consistent, to avoid confusion.
(Looking at v2.)
-COPY x to stdin (format BINAR
On Tue, Oct 15, 2024 at 08:26:06PM -0500, Nathan Bossart wrote:
> Well, the point is that you can't use "postgres -C" to view this GUC while
> the server is running. I can see how the present wording might be
> misinterpreted, though. Perhaps we should change this sentence to
> something like:
>
Hi,
Thank you for your comment.
Regarding the first patch, I believe it works correctly when
consume_xids(1) is called. This is because the lastxid variable in the
consume_xids_common function is initialized as lastxid =
ReadNextFullTransactionId(), where the ReadNextFullTransactionId
funct
On Wednesday, October 9, 2024, Daniel Gustafsson wrote:
> > On 9 Oct 2024, at 19:15, Nathan Bossart
> wrote:
>
> > Another problem is that "deprecated" may or may not imply that the
> feature
> > will be removed in the future. IMHO we should be clear about that when
> we
> > intend to remove so
On 10/12/24 21:25, Alexander Korotkov wrote:
I forgot to specify (COSTS OFF) for EXPLAINs in regression tests. Fixed in v42.
I've passed through the patch set.
Let me put aside the v42-0003 patch—it looks debatable, and I need time
to analyse the change in regression tests caused by this pat
On Tue, Oct 15, 2024 at 11:15 PM Masahiko Sawada wrote:
>
> On Sun, Oct 13, 2024 at 11:00 PM Amit Kapila wrote:
> >
> > On Fri, Oct 11, 2024 at 3:40 AM Masahiko Sawada
> > wrote:
> > >
> > > Please find the attached patches.
> > >
>
> Thank you for reviewing the patch!
>
> >
> > @@ -343,9 +343,
On Tue, Oct 15, 2024 at 8:50 PM Joel Jacobson wrote:
>
Hi.
I only checked 0001, 0002, 0003.
the raw format patch is v9-0016.
003-0016 is a lot of small patches, maybe you can consolidate it to
make the review more easier.
-COPY x to stdin (format TEXT, force_quote(a));
+COPY x to stdout (format
Hello Tom,
14.10.2024 21:25, Tom Lane wrote:
Attached are rebased and renumbered 0006-0008, mostly to keep the
cfbot happy. We could actually stop here, if we were feeling lazy,
but now that I've done the work I'm inclined to push forward with
the rest.
The rest is just memory leak removal, an
On Wed, 16 Oct 2024 at 14:22, Alena Rybakina wrote:
> I haven't noticed anything wrong yet. I think it's worth adding a test
> to regression tests, isn't it?
Here's a patch including a test this time.
I had imagined that it would be hard to make the same mistake again...
David
v1-0001-Don-t-s
On Friday, October 11, 2024, Seino Yuki wrote:
>
>
> The current documentation explains the use of the postgres -C command,
> but this method may be limited in DBaaS or managed service environments.
> In particular, CloudNativePG does not allow the server to be stopped,
> making the execution of
On Wed, Oct 16, 2024 at 09:31:49AM +0900, Michael Paquier wrote:
> I am not sure that neither mentioning nor recommending SHOW for this
> area is a good idea, the point being to encourage its use before the
> server is running as we don't want to allocate anything when tuning
> it.
Agreed.
> Poin
On Tue, Oct 15, 2024 at 08:20:17PM -0500, Nathan Bossart wrote:
> On Wed, Oct 16, 2024 at 09:12:31AM +0900, Michael Paquier wrote:
> > - if (!ctx->rel->rd_rel->reltoastrelid)
> > + if (!OidIsValid(RelationGetToastRelid(ctx->rel)))
> >
> > This set of diffs in 0002 is a nice cleanup. I'd wish
Hi!
On 16.10.2024 04:10, David Rowley wrote:
Yesterday Andres mentioned to me that he's getting wrong results with
TPCH-Q02. Andres did the analysis to figure out that this was caused
by adf97c156 due to how I chose to store intermediate hash values when
the Hash Join has multiple join keys.
Pe
On Wed, Oct 16, 2024 at 09:12:31AM +0900, Michael Paquier wrote:
> - if (!ctx->rel->rd_rel->reltoastrelid)
> + if (!OidIsValid(RelationGetToastRelid(ctx->rel)))
>
> This set of diffs in 0002 is a nice cleanup. I'd wish for relying
> less on zero comparitons when assuming that InvalidOid is in
Yesterday Andres mentioned to me that he's getting wrong results with
TPCH-Q02. Andres did the analysis to figure out that this was caused
by adf97c156 due to how I chose to store intermediate hash values when
the Hash Join has multiple join keys.
Per Andres' investigation, it seems what's going o
On Fri, Oct 11, 2024 at 08:18:58AM +, Bertrand Drouvot wrote:
> On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote:
>> Unfortunately not, we are running 15.4 and planning to upgrade very soon.
>> Is the patch mentioned already merged in PostgreSQL 16?
>
> Yes, as of 16.4.
Right.
On Fri, Oct 11, 2024 at 05:25:04PM +0900, Seino Yuki wrote:
> Alternatively, the "SHOW" command can be used, though the documentation
> states,
> "Note that the server must be shut down to view this runtime-computed
> parameter.[1]"
> This wording could be misunderstood to imply that the parameter
On Mon, Oct 14, 2024 at 03:02:22PM -0500, Nathan Bossart wrote:
> Here is a reorganized patch set. 0001 would be back-patched, but the
> others would only be applied to v18.
Right.
- if (!ctx->rel->rd_rel->reltoastrelid)
+ if (!OidIsValid(RelationGetToastRelid(ctx->rel)))
This set of diffs
On Tue, Oct 15, 2024 at 05:59:05PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
> >> That policy would cause substantial problems with contributor names
> >> in the release notes. I agree with Peter that we don't need this.
> >> Catc
On Tue, Oct 15, 2024 at 2:50 PM Corey Huinker
wrote:
>
> Oh, I see. It appears that there's a special case for partitioned
>> tables that sets relpages=-1 in do_analyze_rel() around line 680. It's
>> a bit inconsistent, though, because even partitioned indexes have
>> relpages=0. Furthermore, the
On Wed, 16 Oct 2024 at 03:40, Robert Haas wrote:
>
> On Sat, Oct 12, 2024 at 5:56 AM Shayon Mukherjee wrote:
> > Thank you for sharing this Robert. I like the idea behind "allowing
> > extensions to control planner behavior” overall and I think it does help
> > towards a powerful extension ecos
On Sat, 12 Oct 2024 at 22:41, Vinícius Abrahão wrote:
> You are going to disable the index but not the update of it? Why? Does it
> imply that when you are going to re-enable it you are going to recreate it?
It might be worth you reading the discussion and proposed patches. I
think either of tho
Hi,
Thank you for the report.
On Mon, Oct 14, 2024 at 6:51 PM Yushi Ogiwara
wrote:
>
> Hi,
>
> I found that the consume_xids function incorrectly advances XIDs as
> shown:
>
> postgres=# select txid_current();
> txid_current
> --
> 746
> (1 row)
>
> postgres=# select consu
Bruce Momjian writes:
> On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
>> That policy would cause substantial problems with contributor names
>> in the release notes. I agree with Peter that we don't need this.
>> Catching otherwise-invisible characters seems sufficient.
> Uh, why can
On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, we can only use Latin-1, so the idea is that we will be explicit
> > about specifying Latin-1 only as HTML entities, rather than letting
> > non-Latin-1 creep in as UTF8. We can exclude certain UTF8 or SGM
On Tue, Oct 15, 2024 at 11:08:15PM +0200, Peter Eisentraut wrote:
> On 15.10.24 22:37, Bruce Momjian wrote:
> > > I don't understand the point of this. Maybe it's okay to try to detect
> > > certain "hidden" whitespace characters, like in the case that started this
> > > thread. But I don't see t
Bruce Momjian writes:
> Well, we can only use Latin-1, so the idea is that we will be explicit
> about specifying Latin-1 only as HTML entities, rather than letting
> non-Latin-1 creep in as UTF8. We can exclude certain UTF8 or SGML files
> if desired.
That policy would cause substantial problem
Committed.
--
nathan
On 15.10.24 22:37, Bruce Momjian wrote:
I don't understand the point of this. Maybe it's okay to try to detect
certain "hidden" whitespace characters, like in the case that started this
thread. But I don't see the value in prohibiting all non-ASCII characters,
as is being proposed here.
Well,
On 09.10.24 20:30, Daniel Gustafsson wrote:
On 9 Oct 2024, at 19:15, Nathan Bossart wrote:
Another problem is that "deprecated" may or may not imply that the feature
will be removed in the future. IMHO we should be clear about that when we
intend to remove something down the road (e.g., "thi
On Tue, Oct 15, 2024, at 19:30, Jacob Champion wrote:
> Hi,
>
> Idle thoughts from a design perspective -- feel free to ignore, since
> I'm not the target audience for the feature:
Many thanks for looking at this!
> - If the column data stored in Postgres contains newlines, it seems
> like COPY T
On Tue, Oct 15, 2024 at 10:34:16PM +0200, Peter Eisentraut wrote:
> On 15.10.24 18:54, Bruce Momjian wrote:
> > > I agree with encoding non-Latin1 characters and disallowing non-ASCII
> > > characters totally.
> > >
> > > I found your patch includes fixes in *.svg files, so how about checking
> >
On 15.10.24 18:54, Bruce Momjian wrote:
I agree with encoding non-Latin1 characters and disallowing non-ASCII
characters totally.
I found your patch includes fixes in *.svg files, so how about checking
also them by check-non-ascii? Also, I think it is better to use perl instead
of grep because n
On Tue, Oct 15, 2024 at 02:23:15PM -0400, Bruce Momjian wrote:
> On Tue, Oct 15, 2024 at 02:21:31PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>> > On Tue, Oct 15, 2024 at 11:04:50AM -0700, Jacob Champion wrote:
>> >> Maybe plus-minus (±), to represent the diff?
>>
>> > Uh, that might make s
> Oh, I see. It appears that there's a special case for partitioned
> tables that sets relpages=-1 in do_analyze_rel() around line 680. It's
> a bit inconsistent, though, because even partitioned indexes have
> relpages=0. Furthermore, the parameter is of type BlockNumber, so
> InvalidBlockNumber w
On Tue, Oct 15, 2024 at 02:21:31PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Oct 15, 2024 at 11:04:50AM -0700, Jacob Champion wrote:
> >> Maybe plus-minus (±), to represent the diff?
>
> > Uh, that might make sense to people who vie diffs often, but not the
> > average reader of
Bruce Momjian writes:
> On Tue, Oct 15, 2024 at 11:04:50AM -0700, Jacob Champion wrote:
>> Maybe plus-minus (±), to represent the diff?
> Uh, that might make sense to people who vie diffs often, but not the
> average reader of the document.
Well, the § symbol hasn't got that much mnemonic value
On Mon, 2024-10-14 at 21:46 -0400, Corey Huinker wrote:
> It seems that partitioned tables have a relpages of -1
Oh, I see. It appears that there's a special case for partitioned
tables that sets relpages=-1 in do_analyze_rel() around line 680. It's
a bit inconsistent, though, because even partiti
On Tue, Oct 15, 2024 at 11:04:50AM -0700, Jacob Champion wrote:
> On Tue, Oct 15, 2024 at 11:01 AM Tom Lane wrote:
> >
> > Sticking to LATIN-1 is not such a bad idea from this perspective.
>
> Maybe plus-minus (±), to represent the diff?
Uh, that might make sense to people who vie diffs often, b
On Tue, Oct 15, 2024 at 11:00 AM Alexander Lakhin wrote:
> I've discovered that starting from 0785d1b8b,
> make check -C src/bin/pg_combinebackup
> fails under Valgrind, with the following diagnostics:
Yep, sorry for that (and thanks for the report!). It's currently
tracked over at [1], but I sho
On Tue, Oct 15, 2024 at 11:01 AM Tom Lane wrote:
>
> Sticking to LATIN-1 is not such a bad idea from this perspective.
Maybe plus-minus (±), to represent the diff?
--Jacob
On Tue, Oct 15, 2024 at 02:01:05PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I thought we were restricted to Latin-1 characters, because those are
> > the only characters that the PDF output supports.
>
> > However, since we decided not to have the commit detail links in the PDF
> > outp
Bruce Momjian writes:
> I thought we were restricted to Latin-1 characters, because those are
> the only characters that the PDF output supports.
> However, since we decided not to have the commit detail links in the PDF
> output, it is actually safe to use _any_ Unicode character as the commit
>
Hello Peter,
11.09.2024 10:37, Peter Eisentraut wrote:
This has been committed.
I've discovered that starting from 0785d1b8b,
make check -C src/bin/pg_combinebackup
fails under Valgrind, with the following diagnostics:
2024-10-15 14:29:52.883 UTC [3338981] 002_compare_backups.pl STATEMENT:
On Sun, Oct 13, 2024 at 11:00 PM Amit Kapila wrote:
>
> On Fri, Oct 11, 2024 at 3:40 AM Masahiko Sawada wrote:
> >
> > Please find the attached patches.
> >
Thank you for reviewing the patch!
>
> @@ -343,9 +343,9 @@ ReorderBufferAllocate(void)
> */
> buffer->tup_context = GenerationContextC
Hi,
Idle thoughts from a design perspective -- feel free to ignore, since
I'm not the target audience for the feature:
- If the column data stored in Postgres contains newlines, it seems
like COPY TO won't work "correctly". Is that acceptable?
- RAW seems like an okay-ish label, but for something
On Tue, Oct 15, 2024 at 01:25:07PM -0400, Greg Sabino Mullane wrote:
> On Tue, Oct 15, 2024 at 12:25 PM Bruce Momjian wrote:
>
> Does anyone have suggestions on a character?
>
>
> I poked around with a bunch and the scroll character seems to be the most
> appropriate and visibly pleasing.
On Tue, Oct 15, 2024 at 12:25 PM Bruce Momjian wrote:
> Does anyone have suggestions on a character?
I poked around with a bunch and the scroll character seems to be the most
appropriate and visibly pleasing.
See my posted-before-yours blog post :)
https://www.crunchydata.com/blog/enhanced-po
On Tue, Oct 15, 2024 at 10:10:36AM +0900, Yugo NAGATA wrote:
> Hi Bruce,
>
> On Mon, 14 Oct 2024 16:31:11 -0400
> Bruce Momjian wrote:
>
> > On Mon, Oct 14, 2024 at 03:05:35PM -0400, Bruce Momjian wrote:
> > > I did some more research and we able to clarify our behavior in
> > > release.sgml:
>
>
> >It adds docbook function, that generates anchor links ("#" symbol
> >related to any refsect1/2/3).
>
Hi there! It looks good to me that you've made some changes. Anchors are a
great addition for direct linking. I hope this update will make it easier
to write the documentation.
Best regards, St
I have some good news. Many of you did not like the use of the section
symbol as a marker for links from the release notes items to the commit
details.
I thought we were restricted to Latin-1 characters, because those are
the only characters that the PDF output supports.
However, since we decide
Robert Haas writes:
> On Fri, Oct 11, 2024 at 3:30 AM Amit Langote wrote:
>> Maybe just "relids" suffices with a comment updated like this:
>>
>> * relids RelOptInfo.relids of the parent plan node (e.g. Append
>> * or MergeAppend) to which his PartitionPruneInf
Peter Eisentraut writes:
> but after the recent improvements to pg_locale_t handling, we don't need
> all three anymore. All the information we have is contained in
> pg_locale_t, so we just need to keep that one. This allows us to
> structure the locale-using regular expression code more sim
Alvaro Herrera writes:
> Hmm, is it valid to make pg_regex_locale point to a function-local
> static here? The lifetime of this static is not clear to me, and I
> think this pattern works with at least some compilers, but I remember
> comments on previous patch review threads that this pattern is
On Tue, Oct 15, 2024 at 09:02:48AM +0200, Peter Eisentraut wrote:
> On 14.10.24 23:28, Nathan Bossart wrote:
>> On Mon, Oct 14, 2024 at 09:47:59AM +0200, Peter Eisentraut wrote:
>> > But we can do this better by using an incomplete struct, like
>> >
>> > struct Query *viewQuery ...;
>> >
On Sat, Oct 12, 2024 at 5:56 AM Shayon Mukherjee wrote:
> Thank you for sharing this Robert. I like the idea behind "allowing
> extensions to control planner behavior” overall and I think it does help
> towards a powerful extension ecosystem too. I wonder if there is a reality
> where we can ac
On Fri, Oct 11, 2024 at 3:30 AM Amit Langote wrote:
> Maybe just "relids" suffices with a comment updated like this:
>
> * relids RelOptInfo.relids of the parent plan node (e.g. Append
> * or MergeAppend) to which his PartitionPruneInfo node
> *
14.10.2024 19:21, Alena Rybakina wrote:
To be honest, I'm not sure this change is necessary. Looking at the code, I see
that in ExecMaterial it is possible to handle a tuplestorestate of NULL, and
this error can be accessed if the flags are not zero, but I think these cases
have been worked
On 15.10.24 12:08, Alvaro Herrera wrote:
On 2024-Oct-15, Peter Eisentraut wrote:
@@ -253,8 +241,9 @@ pg_set_regex_collation(Oid collation)
* catalog access is available, so we can't call
* pg_newlocale_from_collation().
*/
+ stati
hi.
explain(verbose) SELECT 1, 2, 3\; explain SELECT 1, 2, 3, 4;
will transformed to
explain(verbose) SELECT 1, 2, 3; explain SELECT 1, 2, 3, 4;
it seems to me your patch care about following position.
explain(verbose) SELECT 1, 2, 3; explain SELECT 1, 2, 3,
On 08.10.24 18:40, Ashutosh Bapat wrote:
On Tue, Oct 8, 2024 at 7:57 PM Julien Rouhaud wrote:
I was looking at the CREATE FOREIGN TABLE documentation to see if IDENTITY
columns were supported, and according to the doc they're not: only GENERATED
ALWAYS AS ( expr ) STORED is supported.
However,
On Tue, 15 Oct 2024 at 11:50, jian he wrote:
> based on above information, i am still confused with
> cleanup_in_progress_typentries, in_progress_list_len
> is there any simple sql example to demo
> cleanup_in_progress_typentries, in_progress_list_len> 0.
AFAIK to reproduce cases when `in_progr
Hello.
There is small patch for documentation. Some extend of "Make HTML ids
discoverable" by Brar Piening.
Discussion:
https://www.postgresql.org/message-id/flat/CAB8KJ=jpuQU9QJe4+RgWENrK5g9jhoysMw2nvTN_esoOU0=a_w@mail
It adds docbook function, that generates anchor links ("#" symbol
relate
Em ter., 15 de out. de 2024 às 09:00, Alexander Lakhin
escreveu:
> Hello Ranier and Peter,
>
> 15.10.2024 14:44, Ranier Vilela wrote:
>
>
>
> Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut <
> pe...@eisentraut.org> escreveu:
>
>>
>> Thanks for the analysis. I think moreover we *only* nee
Hello Ranier and Peter,
15.10.2024 14:44, Ranier Vilela wrote:
Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut
escreveu:
Thanks for the analysis. I think moreover we *only* need to check the
"stringp" for NULL, not the return value of strsep(), which would never
be NULL
Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut
escreveu:
> On 10.10.24 14:59, Ranier Vilela wrote:
> > Please look at the SCRAM secret, which breaks parse_scram_secret(),
> > perhaps because strsep() doesn't return NULL where strtok() did:
> >
> > CREATE ROLE r PASSWORD
> >
On Mon, Oct 14, 2024 at 9:09 AM Zhijie Hou (Fujitsu)
wrote:
>
> While reviewing the patch, I noticed that the current design could not work in
> a non-bidirectional cluster (publisher -> subscriber) when the publisher is
> also a physical standby. (We supported logical decoding on a physical stand
On Mon, Oct 14, 2024 at 6:30 PM Ilia Evdokimov
wrote:
>
>
> On 14.08.2024 09:32, Steven Niu wrote:
> > Hi, Kirill, Junwang,
> >
> > I made this patch to address the refactor issue in our previous email
> > discussion.
> > https://www.postgresql.org/message-id/flat/CABBtG=cdtcbdcbk7mcsy6bjr3s5xutog
On Thu, 29 Aug 2024 at 05:39, Andy Fan wrote:
>
> Yes, that's a valid usage. the new vesion is attached. I have changed
> the the commit entry [1] from "Waiting on Author" to "Needs review".
>
Note that this needs a rebase, following commit 4681ad4b2f.
Here are a few more review comments:
1).
> On 14 Oct 2024, at 15:08, Peter Eisentraut wrote:
>
> On 26.09.24 11:01, Daniel Gustafsson wrote:
>> Attached is a v7 which address a test failure in the CI. It turns out that
>> the
>> test_misc module gather GUC names using the :alpha: character class which
>> only
>> allows alphabetic whe
> On 3 Oct 2024, at 01:20, Jacob Champion
> wrote:
>
> On Wed, Oct 2, 2024 at 11:33 AM Daniel Gustafsson wrote:
>>> If I migrate a server to a different machine that doesn't support my
>>> groups, I don't know that this would give me enough information to fix
>>> the configuration.
>>
>> Fair
On 2024-Oct-15, Peter Eisentraut wrote:
> @@ -253,8 +241,9 @@ pg_set_regex_collation(Oid collation)
>* catalog access is available, so we can't call
>* pg_newlocale_from_collation().
>*/
> + static struct pg_locale_struct dummy_locale = {
On Tue, Oct 15, 2024 at 4:09 PM Alexander Korotkov wrote:
>
> Hi, Jian!
>
> Thank you for your review.
>
> On Tue, Oct 15, 2024 at 10:34 AM jian he wrote:
> > I don't fully understand all of it. but I did some tests anyway.
> >
> > static void
> > cleanup_in_progress_typentries(void)
> > {
> >
Peter Eisentraut 于2024年10月15日周二 15:02写道：
> On 14.10.24 23:28, Nathan Bossart wrote:
> > On Mon, Oct 14, 2024 at 09:47:59AM +0200, Peter Eisentraut wrote:
> >> But we can do this better by using an incomplete struct, like
> >>
> >> struct Query *viewQuery ...;
> >>
> >> That way, everythi
On Tue, 15 Oct 2024 at 10:09, Alexander Korotkov wrote:
> > /* Call check_delete_rel_type_cache() if we actually cleared something
> > */
> > if (hadTupDescOrOpclass)
> > delete_rel_type_cache_if_needed(typentry);
> >
> > /*
> > * Call check_delete_rel_type_cache(
Hi all.
I've been back to this patch for a while recently. I witness that if a WAL
writer works fast, the already flushed WAL buffers will be zeroed out and
re-initialized for future use by AdvanceXLInsertBuffer in
XLogBackgroundFlush, so that WALReadFromBuffers will miss even though the
space of
On Fri, 11 Oct 2024 at 04:25, James Hunter wrote:
> Moved into restrictinfo.h, instead, in next revision.
Thanks. Pushed.
> > (I really wonder how much the inlining is giving us given that the
> > function itself calls other non-inlineable functions)
>
> I wondered the same! But, at least the br
Hi, Jian!
Thank you for your review.
On Tue, Oct 15, 2024 at 10:34 AM jian he wrote:
> I don't fully understand all of it. but I did some tests anyway.
>
> static void
> cleanup_in_progress_typentries(void)
> {
> inti;
> if (in_progress_list_len > 1)
> elog(INFO, "%s:
On 10/14/24 22:42, Alena Rybakina wrote:
Attached is the correct version of the patch.
Thank you, it's a lot cleaner that way.
I'll add this asap.
--
Benoit Lobréau
Consultant
http://dalibo.com
On Sun, Oct 13, 2024 at 8:09 PM Alexander Korotkov wrote:
>
hi. Alexander.
I don't fully understand all of it. but I did some tests anyway.
static void
cleanup_in_progress_typentries(void)
{
inti;
if (in_progress_list_len > 1)
elog(INFO, "%s:%d in_progress_list_len >
On Tue, Oct 15, 2024 at 12:45 AM Tom Lane wrote:
>
> jian he writes:
> > On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
> >> Right, but we might not have entered either of those previous
> >> if-blocks.
>
> > in src/backend/parser/gram.y
> > your makeRawStmt changes (v4) seem to guarantee that
On 14.10.24 23:28, Nathan Bossart wrote:
On Mon, Oct 14, 2024 at 09:47:59AM +0200, Peter Eisentraut wrote:
But we can do this better by using an incomplete struct, like
struct Query *viewQuery ...;
That way, everything has the correct type and fewer casts are required. This
technique
Hi Ajin/Nisha -- Here are my review comments for patch v15-0001 (code).
(AFAIK v16-0001 is the same as v15-0001, so this review is up to date)
Please also see the "nits" attachment to this post, which has many
more review comments of a more cosmetic nature.
==
src/backend/replication/logical
90 matches
Mail list logo
