> On Mar 7, 2024, at 03:09, Stephen Frost wrote:
>
> External Email
>
> From: Stephen Frost
> Subject: Re: Proposal to add page headers to SLRU pages
> Date: March 7, 2024 at 03:09:59 GMT+8
> To: Alvaro Herrera
> Cc: "Li, Yong" , Aleksander Alekseev
> , PostgreSQL Hackers
> , "Bagga,
>
>
>
> Having some discussion around that would be useful. Is it better to
> have a situation where there are stats for some columns but no stats for
> other columns? There would be a good chance that this would lead to a
> set of queries that were properly planned out and a set which end up
>
On Thu, Mar 07, 2024 at 11:39:39PM -0600, Tristan Partin wrote:
> It sounds like a legitimate issue. I have confirmed the issue exists with a
> pg_config compiled with Meson. I can also confirm that this issue exists in
> the autotools build.
First time I'm hearing about that, but I'll admit that
On Thu, 7 Mar 2024 16:56:17 -0600
Nathan Bossart wrote:
> On Mon, Feb 05, 2024 at 04:28:23PM +0900, Yugo NAGATA wrote:
> > On Thu, 1 Feb 2024 17:59:56 +0800
> > jian he wrote:
> >> v6 patch looks good.
> >
> > Thank you for your review and updating the status to RwC!
>
> I think this one
On Wed, Mar 6, 2024 at 12:41 AM Alvaro Herrera wrote:
>
> > I think we need to go a bit further and convert backtrace_functions of
> > type GUC_LIST_INPUT so that check_backtrace_functions can just use
> > SplitIdentifierString to parse the list of identifiers. Then, the
> > strspn can just be
>
>
> > BEGIN;
> > LOCK TABLE schema.relation IN SHARE UPDATE EXCLUSIVE MODE;
> > LOCK TABLE pg_catalog.pg_statistic IN ROW UPDATE EXCLUSIVE MODE;
> > SELECT pg_import_rel_stats('schema.relation', ntuples, npages);
> > SELECT pg_import_pg_statistic('schema.relation', 'id', ...);
> > SELECT
On Thu, Mar 7, 2024 at 11:02 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 Mon, Mar 04, 2024 at 09:29:03AM +0800, jian he wrote:
> On Fri, Mar 1, 2024 at 5:26 PM Peter Eisentraut wrote:
>> Oops, there was a second commit in my branch that I neglected to send
>> in. Here is my complete patch set.
Thanks for the new patch set. The gains are neat, giving nice
On Sun Jan 21, 2024 at 11:11 PM CST, Sutou Kouhei wrote:
Hi,
I'm an extension developer. If I use PostgreSQL built with
Meson, I get the following warning:
cc1: warning: '-Wformat-security' ignored without '-Wformat'
[-Wformat-security]
Because "pg_config --cflags" includes
Hi,
While looking ExecQueryAndProcessResults, I found the following code.
/*
* If SIGINT is sent while the query is processing, the interrupt will be
* consumed. The user's intention, though, is to cancel the entire watch
* process, so detect a sent cancellation request
On Wed, 06 Mar 2024 13:03:39 -0500
Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Mar 05, 2024 at 10:05:52PM +0900, Yugo NAGATA wrote:
> >> In the current code of do_watch(), sigsetjmp is called if WIN32
> >> is defined, but siglongjmp is not called in the signal handler
> >> in this
On Wed, Mar 06, 2024 at 08:24:09AM +0800, Japin Li wrote:
> On Wed, 06 Mar 2024 at 01:53, Jelte Fennema-Nio wrote:
>> I think if you remove the EEO_CASE(EEOP_LAST) block the warning should
>> go away. That block is clearly marked as unreachable, so it doesn't
>> really serve a purpose.
>
>
On Fri, Mar 8, 2024 at 1:22 AM Robert Haas wrote:
> On Thu, Mar 7, 2024 at 9:16 AM Robert Haas wrote:
> > It could. I just thought this was clearer. I agree that it's a bit
> > long, but I don't think this is worth bikeshedding very much. If at a
> > later time somebody feels strongly that it
On Thu, Mar 07, 2024 at 11:30:55AM +0530, shveta malik wrote:
> It slightly improves the chances. pgstat_fetch_replslot is only
> called from pg_stat_get_replication_slot(), I thought it might be
> better to acquire lock before we call pgstat_fetch_replslot and
> release once we are done copying
On Fri, Mar 8, 2024 at 9:56 AM Ajin Cherian wrote:
>
>> Pushed with minor modifications. I'll keep an eye on BF.
>>
>> BTW, one thing that we should try to evaluate a bit more is the
>> traversal of slots in StandbySlotsHaveCaughtup() where we verify if
>> all the slots mentioned in
Hi David,
On 2024-03-08 02:37 +0100, David E. Wheeler wrote:
> I’ve rebased the patch and, in an attempt to clarify this behavior,
> added a couple of examples to the docs for to_regtype. Updated patch
> attached.
On your latest addition:
> +). Failure to extract a valid potential
> +
On Thu, Mar 07, 2024 at 08:02:00PM -0600, Justin Pryzby wrote:
> As you wrote it, you pass the "defaultAccessMethod" bool to
> ATExecSetAccessMethodNoStorage(), which seems odd. Why not just pass
> the target amoid as newAccessMethod ?
+ /*
+* Check that the table access method
I wrote:
> The attached v2 is a simpler patch that instead modifies the existing
> error message.
Forgot to attach v2.
--
Erik
>From 9ab6b625e8f93ae2957144ec7f0ba32cf8a3bb5b Mon Sep 17 00:00:00 2001
From: Erik Wienhold
Date: Fri, 8 Mar 2024 04:21:56 +0100
Subject: [PATCH v2] Document that
On Fri, Mar 8, 2024 at 2:33 PM Amit Kapila wrote:
> On Thu, Mar 7, 2024 at 12:00 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Attach the V108 patch set which addressed above and Peter's comments.
> > I also removed the check for "*" in guc check hook.
> >
>
>
> Pushed with minor modifications.
I wrote:
> The attached patch fixes the error message and also documents that
> requirement.
On second thought, adding a separate error message doesn't really make
sense. The attached v2 is a simpler patch that instead modifies the
existing error message.
--
Erik
On 2024-03-08 01:12 +0100, Hannu Krosing wrote:
> I could not find any explanation of the following behaviour in docs -
>
>
> Our documentation for CREATE TABLE says:
>
> CREATE TABLE also automatically creates a data type that represents
> the composite type corresponding to one row of the
I looked at the documentation again.
one more changes for JSON_QUERY:
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 3e58ebd2..0c49b321 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -18715,8 +18715,8 @@ ERROR: jsonpath array subscript is out of bounds
On Thu, Mar 7, 2024 at 2:16 PM Masahiko Sawada wrote:
>
> On Tue, Mar 5, 2024 at 3:28 PM Peter Smith wrote:
> >
> > 4a.
> > The comment in simplehash.h says
> > * The following parameters are only relevant when SH_DEFINE is defined:
> > * - SH_KEY - ...
> > * - SH_EQUAL(table, a, b) -
On 2024-03-07 Th 10:28, Jacob Champion wrote:
Some more observations as I make my way through the patch:
In src/common/jsonapi.c,
+#define JSON_NUM_NONTERMINALS 6
Should this be 5 now?
Yep.
+ res = pg_parse_json_incremental(&(incstate->lex), &(incstate->sem),
+
On Thu, Mar 7, 2024 at 12:00 PM Zhijie Hou (Fujitsu)
wrote:
>
>
> Attach the V108 patch set which addressed above and Peter's comments.
> I also removed the check for "*" in guc check hook.
>
Pushed with minor modifications. I'll keep an eye on BF.
BTW, one thing that we should try to evaluate
On Fri, 8 Mar 2024 at 00:39, Richard Guo wrote:
> I would like to have another look, but it might take several days.
> Would that be too late?
Please look. Several days is fine. I'd like to start looking on Monday
or Tuesday next week.
Thanks
David
On Fri, Mar 8, 2024 at 9:53 AM John Naylor wrote:
>
> On Fri, Mar 8, 2024 at 8:09 AM Masahiko Sawada wrote:
> > Yesterday I've confirmed the something like the below fixes the
> > problem happened in Windows CI:
> >
> > --- a/src/test/modules/test_radixtree/meson.build
> > +++
On Fri, Mar 8, 2024 at 8:09 AM Masahiko Sawada wrote:
> Yesterday I've confirmed the something like the below fixes the
> problem happened in Windows CI:
>
> --- a/src/test/modules/test_radixtree/meson.build
> +++ b/src/test/modules/test_radixtree/meson.build
> @@ -12,6 +12,7 @@ endif
>
>
On Fri, 8 Mar 2024 at 00:54, Ashutosh Bapat
wrote:
>
> On Thu, Mar 7, 2024 at 4:39 PM David Rowley wrote:
>> I think the fix should go in appendOrderByClause(). It's at that
>> point we look for the EquivalenceMember for the relation and can
>> easily discover if the em_expr is a Const. I
On Mon, Mar 04, 2024 at 05:46:56PM +0900, Michael Paquier wrote:
> > Since InvalidOid is already taken, I guess you might need to introduce a
> > boolean flag, like set_relam, indicating that the statement has an
> > ACCESS METHOD clause.
>
> Yes, I don't see an alternative. The default needs a
Hello Hackers,
On Feb 25, 2024, at 13:00, David E. Wheeler wrote:
>> postgres=# SELECT to_regtypemod('timestamp(-4)');
>> ERROR: syntax error at or near "-"
>> LINE 1: SELECT to_regtypemod('timestamp(-4)');
>> ^
>> CONTEXT: invalid type name "timestamp(-4)"
>>
>> postgres=#
On Fri, Mar 8, 2024 at 8:09 AM Masahiko Sawada wrote:
>
> Yesterday I've confirmed the something like the below fixes the
> problem happened in Windows CI:
Glad you shared before I went and did it.
> --- a/src/test/modules/test_radixtree/meson.build
> +++
On Fri, Mar 8, 2024 at 10:04 AM John Naylor wrote:
>
> On Thu, Mar 7, 2024 at 11:15 PM Masahiko Sawada wrote:
> >
> > It looks like it requires a link with pgport_srv but I'm not sure. It
> > seems that the recent commit 1f1d73a8b breaks CI, Windows - Server
> > 2019, VS 2019 - Meson & ninja,
On Thu, Mar 7, 2024 at 11:15 PM Masahiko Sawada wrote:
>
> It looks like it requires a link with pgport_srv but I'm not sure. It
> seems that the recent commit 1f1d73a8b breaks CI, Windows - Server
> 2019, VS 2019 - Meson & ninja, too.
Unfortunately, none of the Windows animals happened to run
On Wed, Mar 06, 2024 at 10:00:23PM -0500, Melanie Plageman wrote:
> On Wed, Mar 06, 2024 at 09:55:21PM +0200, Heikki Linnakangas wrote:
> > I made some further changes. I kept them as separate commits for easier
> > review, see the commit messages for details. Any thoughts on those changes?
>
>
Daniel Gustafsson writes:
> On 7 Mar 2024, at 20:58, Tom Lane wrote:
>> This could probably do with a comment, and we need to propagate
>> the fix into libpq's copy of the function too. Barring objections,
>> I'll take care of that and push it later today.
> LGTM.
Done so far as
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 7 Mar 2024 15:32:01 +0900,
Michael Paquier wrote:
> While on it, here are some profiles based on HEAD and v17 with the
> previous tests (COPY TO /dev/null, COPY FROM data sent to the void).
>
...
>
I could not find any explanation of the following behaviour in docs -
Our documentation for CREATE TABLE says:
CREATE TABLE also automatically creates a data type that represents
the composite type corresponding to one row of the table. Therefore,
tables cannot have the same name as any
On Mon, Feb 05, 2024 at 04:28:23PM +0900, Yugo NAGATA wrote:
> On Thu, 1 Feb 2024 17:59:56 +0800
> jian he wrote:
>> v6 patch looks good.
>
> Thank you for your review and updating the status to RwC!
I think this one needs a (pretty trivial) rebase. I spent a few minutes
testing it out and
On Sun, Dec 10, 2023 at 12:00:01PM +0300, Alexander Lakhin wrote:
> So I would not say that it's a dominant failure for now, and given that
> 04a09ee lives in master only, maybe we can save two commits (Revert +
> Revert of revert) while moving to a more persistent solution.
I just checked in on
As promised...
> +# Check for Intel AVX512 intrinsics to do POPCNT calculations.
> +#
> +PGAC_AVX512_POPCNT_INTRINSICS([])
> +if test x"$pgac_avx512_popcnt_intrinsics" != x"yes"; then
> + PGAC_AVX512_POPCNT_INTRINSICS([-mavx512vpopcntdq -mavx512f])
> +fi
> +AC_SUBST(CFLAGS_AVX512_POPCNT)
I'm
On Wed, Mar 6, 2024 at 4:51 PM Matthias van de Meent
wrote:
> To clarify, what I mean here is that merging the changes of both the
> SAOPs changes and the removal of arrayKeyData seems to increase the
> patch size and increases the maximum complexity of each component
> patch's review.
Removing
On Wed, Mar 6, 2024 at 4:46 PM Matthias van de Meent
wrote:
> On Wed, 6 Mar 2024 at 01:50, Peter Geoghegan wrote:
> > I think that there is supposed to be a closing parenthesis here? So
> > "... (such as those described in ") might
> > perform...".
>
> Correct.
>
> > FWM, if that's what you
Hi!
On 07.03.2024 17:51, Alexander Korotkov wrote:
Hi!
On Tue, Mar 5, 2024 at 9:59 AM Andrei Lepikhov
wrote:
> On 5/3/2024 12:30, Andrei Lepikhov wrote:
> > On 4/3/2024 09:26, jian he wrote:
> ... and the new version of the patchset is attached.
I made some revisions for the patchset.
1)
> On 7 Mar 2024, at 20:58, Tom Lane wrote:
>
> I wrote:
>> Stephen Frost writes:
>>> Agreed that it doesn't seem well documented. I was trying to figure out
>>> what the 'right' answer here was myself and not having much success. If
>>> the above works, then +1 to that.
>
>> My reaction as
I wrote:
> Stephen Frost writes:
>> Agreed that it doesn't seem well documented. I was trying to figure out
>> what the 'right' answer here was myself and not having much success. If
>> the above works, then +1 to that.
> My reaction as well --- I was just gearing up to test this idea,
>
On Thu, Mar 7, 2024 at 9:16 AM Robert Haas wrote:
> It could. I just thought this was clearer. I agree that it's a bit
> long, but I don't think this is worth bikeshedding very much. If at a
> later time somebody feels strongly that it needs to be changed, so be
> it. Right now, getting on with
Hello!
> I'm not a fan of this approach. Changing visibility and cleanup
> semantics to only benefit R/CIC sounds like a pain to work with in
> essentially all visibility-related code. I'd much rather have to deal
> with another index AM, even if it takes more time: the changes in
> semantics
David Zhang writes:
> When configuring SSL on the Postgres server side with the following
> information:
> ssl = on
> ssl_ca_file = 'root_ca.crt'
> ssl_cert_file = 'server-cn-only.crt'
> ssl_key_file = 'server-cn-only.key'
> If a user makes a mistake, for example, accidentally using
On Thu, Mar 07, 2024 at 06:53:12PM +0100, Alvaro Herrera wrote:
> Really, I don't think this is very important as a review point, because
> if the configure.ac file is changed in the patch, it's best for the
> committer to run autoconf on their own, using a pristine GNU autoconf;
> the configure
On 2024-Feb-16, Antonin Houska wrote:
> BTW, I'm failing to understand why cluster_rel() has no argument of the
> BufferAccessStrategy type. According to buffer/README, the criterion for using
> specific strategy is that page "is unlikely to be needed again
> soon". Specifically for
On Wed, Mar 6, 2024 at 6:29 AM Alvaro Herrera wrote:
> On 2024-Mar-06, Thomas Munro wrote:
> > Even on the heap, 16GB is too much to assume we can allocate during a
> > base backup. I don't claim that's a real-world problem for
> > incremental backup right now in master, because I don't have any
On 2024-Mar-04, Amonson, Paul D wrote:
> > -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
> > +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31)
> > +<< 31))
> >
> > IME this means that the autoconf you are using has been patched. A
> > quick search on the
On Wed, Mar 6, 2024 at 12:44 AM Thomas Munro wrote:
> I'll have to move that sucker onto the heap (we banned C99 variable
> length arrays and we don't use nonstandard alloca()), but I think the
> coding in master is already a bit dodgy: that's 131072 *
> sizeof(BlockNumber) = 512kB with default
Stephen Frost writes:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> That's pretty unfortunate. As typical with OpenSSL, this stuff is not very
>> well documented, but I think we could do something like this in
>> SSLerrmessage():
>>
>> if (ERR_SYSTEM_ERROR(e))
>> errreason =
On Tue, Mar 05, 2024 at 04:52:23PM +, Amonson, Paul D wrote:
> Noted I will try to do the "reduced" bottom-posting. I might slip up
> occasionally because it's an Intel habit.
No worries.
> Is there a way to make Outlook do the leading ">" in a reply for the
> previous message?
I do not
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 PK, which
> perhaps is what we want. I'll do some testing
I've previously noted in "Add last commit LSN to
pg_last_committed_xact()" [1] that it's not possible to monitor how
many bytes of WAL behind a logical replication slot is (computing such
is obviously trivial for physical slots) because the slot doesn't need
to replicate beyond the last commit.
On Thu, Mar 07, 2024 at 02:46:55PM +0500, Andrey M. Borodin wrote:
> I’m not sure if it is connected, but so far many patches in CFbot keep
> hanging in this test. For example [0].
> [0] https://cirrus-ci.com/task/5911176840740864?logs=check_world#L292
Relevant part:
[22:03:10.292] stderr:
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/03/2024 02:12, David Zhang wrote:
> > The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
> > if there is a system error, such as "No such file or directory" in this
> > case:
> >
> > const char
Quite an interesting patch, in my opinion. I've decided to work on it a
bit, did some refactoring (sorry) and add
basic tests. Also, I try to take into account as much as possible notes on
the patch, mentioned by Cédric Villemain.
> and maybe better to go with FlushOneBuffer() ?
It's a good
This patch adds a link to the "attach partition" command section
(similar to the detach partition link above it) as well as a link to
"create table like" as both commands contain additional information
that users should review beyond what is laid out in this section.
There's also a couple of
Hi,
I decided to take a quick look on this patch today, to see how it works
and do some simple tests. I've only started to get familiar with it, so
I have only some comments / questions regarding usage, not on the code.
It's quite possible I didn't understand some finer points, or maybe it
was
On Thu, Feb 8, 2024 at 5:28 AM Jingxian Li wrote:
> Based on your comments above, I improve the commit message and comment for
> InsertSelfIntoWaitQueue in new patch.
Well, I had a look at this patch today, and even after reading the new
commit message, I couldn't really convince myself that it
I don't think anything discussed in this thread is ready for v17, so I am
going to punt it to v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Hi Peter and Tom,
> On Tue, Feb 20, 2024 at 3:51 PM Peter Eisentraut
> wrote:
> > >
> > > I have reverted the patch for now (and re-opened the commitfest entry).
> > > We should continue to work on this and see if we can at least try to
> get
> > > the pg_dump test coverage suitable.
> > >
> >
>
On Tue, Mar 05, 2024 at 10:12:35AM -0600, Nathan Bossart wrote:
> Thanks to Jeff's recent work with commits 2af07e2 and 59825d1, the issue
> that led to the revert of the MAINTAIN privilege and the pg_maintain
> predefined role (commit 151c22d) should now be resolved. Specifically,
> there was a
Hannu Krosing writes:
> On Sat, Feb 10, 2024 at 12:38 AM Tom Lane wrote:
>> Worth noting perhaps that this is actually required by the SQL
>> standard: per spec, functions and procedures are both "routines"
>> and share the same namespace,
> Can you point me to a place in the standard where it
On Thu, Mar 7, 2024 at 8:06 PM John Naylor wrote:
>
> On Thu, Mar 7, 2024 at 4:47 PM Masahiko Sawada wrote:
> >
> > On Thu, Mar 7, 2024 at 6:37 PM John Naylor wrote:
>
> > > $ git grep 'link_with: pgport_srv'
> > > src/test/modules/test_radixtree/meson.build: link_with: pgport_srv,
> > >
> > >
On 07/03/2024 02:12, David Zhang wrote:
The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
if there is a system error, such as "No such file or directory" in this
case:
const char *ERR_reason_error_string(unsigned long e)
{
ERR_STRING_DATA d, *p = NULL;
unsigned
On 03.03.24 11:02, Peter Eisentraut wrote:
On 29.02.24 19:14, Tom Lane wrote:
Peter Eisentraut writes:
In nodes/parsenodes.h, it says both
This *must* be false for RTEs other than RTE_RELATION entries.
Well, that's true in the parser ...
and also puts it under
Fields valid in
Hello,
I am not up to date with the last version of patch but I did a regular
benchmark with version 11 and typical issue we have at the moment and the
result are still very very good. [1]
In term of performance improvement the last proposals could be a real game
changer for 2 of our biggest
On Thu, Mar 7, 2024 at 8:06 PM John Naylor wrote:
>
> On Thu, Mar 7, 2024 at 4:47 PM Masahiko Sawada wrote:
> >
> > On Thu, Mar 7, 2024 at 6:37 PM John Naylor wrote:
>
> > > $ git grep 'link_with: pgport_srv'
> > > src/test/modules/test_radixtree/meson.build: link_with: pgport_srv,
> > >
> > >
Some more observations as I make my way through the patch:
In src/common/jsonapi.c,
> +#define JSON_NUM_NONTERMINALS 6
Should this be 5 now?
> + res = pg_parse_json_incremental(&(incstate->lex), &(incstate->sem),
> +
On 2024-Mar-07, Dean Rasheed wrote:
> On Thu, 7 Mar 2024 at 13:00, Alvaro Herrera wrote:
> >
> > So I think the original developers of REPLICA IDENTITY had the right
> > idea here (commit 07cacba983ef), and we mustn't change this aspect,
> > because it'll lead to data corruption in replication.
Hi!
On Tue, Mar 5, 2024 at 9:59 AM Andrei Lepikhov
wrote:
> On 5/3/2024 12:30, Andrei Lepikhov wrote:
> > On 4/3/2024 09:26, jian he wrote:
> ... and the new version of the patchset is attached.
I made some revisions for the patchset.
1) Use hash_combine() to combine hash values.
2) Upper limit
On Thu, Mar 7, 2024 at 23:14 Alvaro Herrera wrote:
> On 2024-Mar-07, Tomas Vondra wrote:
>
> > I was experimenting with the v42 patches, and I think the handling of ON
> > EMPTY / ON ERROR clauses may need some improvement.
>
> Well, the 2023 standard says things like
>
> ::=
> JSON_VALUE
>
On Wed, Mar 6, 2024 at 11:22 PM Amul Sul wrote:
>> You are not changing silently the internals of get_controlfile(), so
>> no objections here. The name of the new routine could be shorter, but
>> being short of ideas what you are proposing looks fine by me.
>
> Could be get_controlfile_by_path()
On 2024-Mar-07, Tomas Vondra wrote:
> I was experimenting with the v42 patches, and I think the handling of ON
> EMPTY / ON ERROR clauses may need some improvement.
Well, the 2023 standard says things like
::=
JSON_VALUE
[ ]
[ ON EMPTY ]
[ ON ERROR ]
which
On Thu, Mar 7, 2024 at 22:46 jian he wrote:
> On Thu, Mar 7, 2024 at 8:06 PM Amit Langote
> wrote:
> >
> >
> > Indeed.
> >
> > This boils down to the difference in the cast expression chosen to
> > convert the source value to int in the two cases.
> >
> > The case where the source value has no
Hi,
I was experimenting with the v42 patches, and I think the handling of ON
EMPTY / ON ERROR clauses may need some improvement. The grammar is
currently defined like this:
| json_behavior ON EMPTY_P json_behavior ON ERROR_P
This means the clauses have to be defined exactly in this order,
On Thu, Mar 7, 2024 at 8:06 PM Amit Langote wrote:
>
>
> Indeed.
>
> This boils down to the difference in the cast expression chosen to
> convert the source value to int in the two cases.
>
> The case where the source value has no quotes, the chosen cast
> expression is a FuncExpr for function
On Thu, 7 Mar 2024 at 13:00, Alvaro Herrera wrote:
>
> So I think the original developers of REPLICA IDENTITY had the right
> idea here (commit 07cacba983ef), and we mustn't change this aspect,
> because it'll lead to data corruption in replication. Using a deferred
> PK for DDL considerations
On 2024-Mar-05, Dean Rasheed wrote:
> So I think RelationGetIndexAttrBitmap() should include deferrable PKs,
I tried this, but it doesn't actually lead to a good place, because if
we allow deferrable PKs to identify rows, then they are not useful to
find the tuple to update when replicating.
Hi Nazir,
On 07/03/2024 12:19, Nazir Bilal Yavuz wrote:
On Wed, 6 Mar 2024 at 18:23, Cédric Villemain
wrote:
The behavior is 100% OK, and in fact it might a bad idea to prefetch
block by block as the result is just to put more pressure on a system if
it is already under pressure.
Though
On Thu, Mar 7, 2024 at 5:14 PM Kartyshov Ivan
wrote:
>
> Intro
> ==
> The main purpose of the feature is to achieve
> read-your-writes-consistency, while using async replica for reads and
> primary for writes. In that case lsn of last modification is stored
> inside application. We cannot
On Thu, Mar 7, 2024 at 8:13 PM Tomas Vondra
wrote:
> On 3/7/24 06:18, Himanshu Upadhyaya wrote:
Thanks Himanshu for the testing.
> > On Wed, Mar 6, 2024 at 9:04 PM Tomas Vondra
> > wrote:
> >>
> >> I'm pretty sure this is the correct & expected behavior. The second
> >> query treats the value
On Thu, Mar 7, 2024 at 4:39 PM David Rowley wrote:
> On Thu, 7 Mar 2024 at 19:09, Michał Kłeczek wrote:
> >
> > The following query:
> >
> > SELECT * FROM (
> > SELECT 2023 AS year, * FROM remote_table_1
> > UNION ALL
> > SELECT 2022 AS year, * FROM remote_table_2
> > )
> > ORDER BY year
On 3/7/24 08:33, Nikita Malakhov wrote:
> Hi!
>
> Tomas, I thought about this issue -
>> What if you only need the first slice? In that case decoding everything
>> will be a clear regression.
> And completely agree with you, I'm currently working on it and will post
> a patch a bit later.
Cool.
Intro
==
The main purpose of the feature is to achieve
read-your-writes-consistency, while using async replica for reads and
primary for writes. In that case lsn of last modification is stored
inside application. We cannot store this lsn inside database, since
reads are distributed across
On Thu, Mar 7, 2024 at 7:16 PM David Rowley wrote:
> On Thu, 15 Feb 2024 at 17:30, David Rowley wrote:
> >
> > On Tue, 6 Feb 2024 at 22:05, Richard Guo wrote:
> > > I'm thinking that maybe it'd be better to move the work of sorting the
> > > subquery's paths to the outer query level,
On Thu, 7 Mar 2024 at 23:40, Andy Fan wrote:
>
> David Rowley writes:
> > If you don't want the planner to use the statistics for the column why
> > not just do the following?
>
> Acutally I didn't want the planner to ignore the statistics totally, I
> want the planner to treat the "Const" which
Hi,
On Wed, 6 Mar 2024 at 18:23, Cédric Villemain
wrote:
>
> Hi Nazir,
>
>
> thank you for your review. I comment below.
>
>
> On 05/03/2024 12:07, Nazir Bilal Yavuz wrote:
> >> 2. The second one does implement smgrprefetch with range and loops by
> >> default per segment to still have a check
On Thu, 15 Feb 2024 at 17:30, David Rowley wrote:
>
> On Tue, 6 Feb 2024 at 22:05, Richard Guo wrote:
> > I'm thinking that maybe it'd be better to move the work of sorting the
> > subquery's paths to the outer query level, specifically within the
> > build_setop_child_paths() function, just
On Thu, Feb 22, 2024 at 2:56 PM Ashutosh Bapat
wrote:
> On Wed, Feb 21, 2024 at 4:55 PM Richard Guo
> wrote:
> >
> >
> > On Tue, Aug 2, 2022 at 4:24 AM Jacob Champion
> wrote:
> >>
> >> Once you think you've built up some community support and the patchset
> >> is ready for review, you (or any
On 3/7/24 06:18, Himanshu Upadhyaya wrote:
> On Wed, Mar 6, 2024 at 9:04 PM Tomas Vondra
> wrote:
>
>>
>>
>> I'm pretty sure this is the correct & expected behavior. The second
>> query treats the value as string (because that's what should happen for
>> values in double quotes).
>>
>> ok,
On Thu, 7 Mar 2024 at 19:09, Michał Kłeczek wrote:
>
> The following query:
>
> SELECT * FROM (
> SELECT 2023 AS year, * FROM remote_table_1
> UNION ALL
> SELECT 2022 AS year, * FROM remote_table_2
> )
> ORDER BY year DESC;
>
> yields the following remote query:
>
> SELECT [columns] FROM
On Thu, Mar 7, 2024 at 4:47 PM Masahiko Sawada wrote:
>
> On Thu, Mar 7, 2024 at 6:37 PM John Naylor wrote:
> > $ git grep 'link_with: pgport_srv'
> > src/test/modules/test_radixtree/meson.build: link_with: pgport_srv,
> >
> > No other test module uses this directive, and indeed, removing this
Andrei Lepikhov writes:
> On 5/3/2024 19:56, Andy Fan wrote:
>> I think it is OK for a design review, for the implementaion side, the
>> known issue includes:
>> 1. Support grap such infromation from its parent for partitioned table
>> if the child doesn't have such information.
>> 2. builtin
David Rowley writes:
> On Wed, 6 Mar 2024 at 02:09, Andy Fan wrote:
>> This patch introduces a new attoptions like this:
>>
>> ALTER TABLE t ALTER COLUMN col set (force_generic=true);
>>
>> Then selfunc.c realizes this and ignore the special Const value, then
>> average
1 - 100 of 113 matches
Mail list logo
