On 2024-Nov-05, hugo wrote:
> Hi, Kirill
>
> Sorry for the late reply, thanks for your suggestion.
> A simple fix has been added to the attached patch.
Actually, AFAICT my patch at https://commitfest.postgresql.org/50/5224/
adds a use of this field, so if you remove it, I might have to put it
ba
On 2024-Nov-05, Alvaro Herrera wrote:
> All in all, I think this text serves no purpose and should be removed
> (from all live branches), as in the attached patch.
Attached here.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"Los cuentos de hadas no dan al niñ
Foreign key violation errors are incorrectly raised in a few cases for a
temporal foreign key with default ON UPDATE NO ACTION. Test is based on
the commited v39 patches (used a snapshot version of PG18 devel
available from PGDG).
If there exists a single referencing row for a foreign key (wit
Em ter., 5 de nov. de 2024 às 00:23, David Rowley
escreveu:
> On Tue, 5 Nov 2024 at 06:39, Ranier Vilela wrote:
> > I think we can add a small optimization to this last patch [1].
> > The variable *aligned_end* is only needed in the second loop (for).
> > So, only before the for loop do we actua
Em ter., 5 de nov. de 2024 às 01:12, Michael Paquier
escreveu:
> On Tue, Nov 05, 2024 at 04:23:34PM +1300, David Rowley wrote:
> > I tried your optimisation in the attached allzeros.c and here are my
> results:
> >
> > # My version
> > $ gcc allzeros.c -O2 -o allzeros && for i in {1..3}; do ./all
Interesting idea.
This patch needs a rebase.
On Thu, 17 Oct 2024 at 15:59, Shayon Mukherjee wrote:
>
>
> On Oct 16, 2024, at 6:01 PM, Shayon Mukherjee wrote:
>
> I'll take some time to think this through and familiarize myself with the
> new systable_inplace_update_begin. In the meantime, aside
Hello,
While doing final review for not-null constraints, I noticed that the
ALTER TABLE ATTACH PARTITION have this phrase:
If any of the CHECK constraints of the table being attached are marked NO
INHERIT, the command will fail; such constraints must be recreated without
the
NO INHE
Hi jian,
On Tue, Nov 5, 2024 at 3:13 PM jian he wrote:
>
> On Mon, Nov 4, 2024 at 7:34 PM Dean Rasheed wrote:
> >
> > Testing this with an array with non-default lower bounds, it fails to
> > preserve the array bounds, which I think it should (note:
> > array_reverse() and array_shuffle() do pre
Hi Hackers,
On 9/5/24 01:39, Amit Kapila wrote:
On Wed, Sep 4, 2024 at 6:35 PM Aleksander Alekseev
wrote:
> > I don't think you can rely on a system clock for conflict resolution.
> > In a corner case a DBA can move the clock forward or backward between
> > recordings of Ts1 and Ts2. On top o
Hi Tender,
> While learning the GIST codes, I find an obsolete comment in gistinsert ().
>
> itup = gistFormTuple(giststate, r,
> values, isnull, true /* size is currently
> bogus */ );
Thanks for reporting. I agree that this is an oversight of commit 1f7ef54.
On Tue, 5 Nov 2024 at 12:32, Peter Smith wrote:
>
> Hi Vignesh,
>
> Here are my review comments for patch v48-0001.
>
> ==
> src/backend/catalog/pg_publication.c
>
> has_column_list_defined:
>
> 1.
> + if (HeapTupleIsValid(cftuple))
> + {
> + bool isnull = true;
> +
> + /* Lookup the column li
On Tue, Nov 5, 2024 at 1:06 AM Bertrand Drouvot
wrote:
> Does it sound ok to you to move with the above principal? (I'm +1 on it).
Yes, provided we can get a clean implementation of it.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
On Tue, Nov 05, 2024 at 05:08:41PM +1300, David Rowley wrote:
> On Tue, 5 Nov 2024 at 06:39, Ranier Vilela wrote:
> > I think we can add a small optimization to this last patch [1].
>
> I think if you want to make it faster, you could partially unroll the
> inner-most loop, like:
>
> // siz
On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh wrote:
> I'm unable to confirm the veracity of the claim that the pgevent.dll
> file on Windows is now placed in a different directory, and that this
> is a result of meson builds. But the patch looks good to me; it
> applies cleanly to REL_17_STABLE an
On Thu, Oct 17, 2024 at 9:59 AM Shayon Mukherjee wrote:
> My take away from whether or not an in-place update is needed on pg_index [1]
>
> - It’s unclear to me why it’s needed.
> - I understand the xmin would get incremented when using CatalogTupleUpdate
> to update indisenabled.
> - However, I
On Tue, Oct 29, 2024 at 1:45 PM Thom Brown wrote:
> Taking a look at what's happening under the hood, it seems to be
> getting stuck here:
>
> if (nextMXOffset == 0)
> {
> /* Corner case 2: next multixact is still
> being filled in */
>
Hello Takahashi-san,
I am reluctant to draw conclusions about the general performance of
this patch from one example. It seems that the performance could
depend on many things: table size, column definitions, row width,
hardware, OS version, shared_buffers, max_wal_size. I don't think we
can say f
On 2024/11/01 22:38, Greg Sabino Mullane wrote:
$ psql "postgres://localhost:5432/postgres?application_name=a b"
psql: error: trailing data found: "a b"
This works fine for me, and sets a space in the application_name string as
expected. Do you have a different example?
You'll enc
On 2024/10/31 10:22, Yushi Ogiwara wrote:
Hi,
I made a patch to make the error message more user-friendly when using a URI to
connect a database with psql.
Current Error Message:
$ psql "postgres://localhost:5432/postgres?application_name=a b"
psql: error: trailing data found: "a b"
Curre
On 16.09.24 11:22, jian he wrote:
in v7.
doc/src/sgml/ref/alter_table.sgml
and column_constraint is:
section need representation of:
GENERATED ALWAYS AS ( generation_expr ) [VIRTUAL]
I have addressed this in patch v8.
in RelationBuildTupleDesc(Relation relation)
we need to add "constr->has_
On Tue, 5 Nov 2024 at 15:23, Aleksander Alekseev
wrote:
>
> > > =# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
> > > {5}
> > > {1, 3, 8}
> > > {7, 6}
> > > ...
> >
> > Yeah, that looks like a neater API.
> >
> > Something that bothers me somewhat is that it's completely tr
On 18.09.24 04:38, jian he wrote:
On Mon, Sep 16, 2024 at 5:22 PM jian he wrote:
in v7.
seems I am confused with the version number.
here, I attached another minor change in tests.
make
ERROR: invalid ON DELETE action for foreign key constraint containing
generated column
becomes
ERROR:
> On 1 Nov 2024, at 00:25, Thom Brown wrote:
>
> Unfortunately I didn't gather much information when it was occuring, and
> prioritised getting rid of the process blocking replay. I just attached gdb
> to it, got a backtrace and then "print ProcessInterrupts()".
>
Currently I do not see ho
On 11/4/24 7:32 PM, Tom Lane wrote:
Seems reasonable. Pushed with some trivial cosmetic adjustments
to make it look more like the identical adjacent cases for policies
and triggers.
Thanks!
Andreas
Hi Shlok,
> Here the generated column 'b' is set as REPLICA IDENTITY for table
> 'testpub_gencol'. When we create publication 'pub_gencol' we do not
> specify any column list, so column 'b' will not be published.
> So, the update message generated by the last UPDATE would have NULL
> for column 'b
Hi Ryohei,
Thanks for the patch. Here are my two cents.
> I noticed that the COPY performance on PG 17.0 Windows is worse than PG 16.4.
>
> [...]
>
> By applying the attached patch to PG 17.0, the copy result is 401.5s.
So we are trading a potential 3.8% speedup in certain environments for
the
Hi,
While learning the GIST codes, I find an obsolete comment in gistinsert ().
itup = gistFormTuple(giststate, r,
values, isnull, true /* size is currently
bogus */ );
The comment "/* size is currently bogus */" is weird because it follows a
bool variable.
I t
Hi, Kirill
Sorry for the late reply, thanks for your suggestion.
A simple fix has been added to the attached patch.
--
hugo
v1-0001-Remove-useless-field-ispartitioned-in-CreateStmtC.patch
Description: Binary data
On 2024-10-18 01:51, Fujii Masao wrote:
Thanks for your review and sorry for my late reply.
On 2024/10/17 22:45, torikoshia wrote:
Hi,
4ac2a9bec introduced reject_limit option to the COPY command, and I
was wondering if it might be beneficial to add the same option to
file_fdw.
Although th
> On 5 Nov 2024, at 10:33, Alvaro Herrera wrote:
> Therefore I +1 Daniel's original proposal with thanks, and BTW I'm not
> sorry for changing my name to use the hard-won ' accent on it :-)
Done.
--
Daniel Gustafsson
Robert Haas writes:
> On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh wrote:
>> I'm unable to confirm the veracity of the claim that the pgevent.dll
>> file on Windows is now placed in a different directory, and that this
>> is a result of meson builds. But the patch looks good to me; it
>> applies
Hi Dean,
Thanks for your input.
> > Any reason not to have an interface as simple and straightforward as
> > this:
> >
> > =# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
> > {5}
> > {1, 3, 8}
> > {7, 6}
> > ...
> >
>
> Yeah, that looks like a neater API.
>
> Something tha
On Tue, 5 Nov 2024 at 15:10, Robert Haas wrote:
> On Tue, Nov 5, 2024 at 1:00 AM Gurjeet Singh wrote:
> > I'm unable to confirm the veracity of the claim that the pgevent.dll
> > file on Windows is now placed in a different directory, and that this
> > is a result of meson builds. But the patch
On 2024/09/24 21:31, Daniel Gustafsson wrote:
On 24 Sep 2024, at 10:32, btnakamurakoukil
wrote:
I noticed unnecessary variable "low" in index_delete_sort()
(/postgres/src/backend/access/heap/heapam.c), patch attached. What do you think?
That variable does indeed seem to not be used, an
Alexander Pyhalov писал(а) 2021-10-04 10:42:
Ashutosh Bapat писал 2021-06-15 16:15:
Hi Alexander,
Hi.
The current version of the patch is based on asymetric partition-wise
join.
Currently it is applied after
v19-0001-Asymmetric-partitionwise-join.patch from
on
https://www.postgresql.org/me
Hi,
This issue has been bugging me for a while but I haven't gotten around
to reporting it until now. Apologies if this is a duplicate report.
When I try to build an extension such as pg_catcheck against a meson
build, it does not work. If I do the same thing with a configure-based
build, it does
Hi,
> If we are going to add such a function to core, then I think we should
> make it consistent and at least as flexible as the other array
> functions, and support multi-dimensional arrays with optional
> non-default lower-bounds, like array_fill(). I.e., something like:
>
> random_array(min
Hi, I thought it would be nice to give the user a better idea of what
avg_leaf_density and leaf_fragmentation mean.
Patch attached. What do you think?From 5c82c207776fb8cde2357081b8579ba6db195c06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Yhuel?=
Date: Tue, 5 Nov 2024 17:59:4
Hi,
On Mon, Nov 04, 2024 at 10:01:50AM +, Bertrand Drouvot wrote:
> And why not add more per-backend stats in the future? (once the I/O part is
> done).
>
> I think that's one more reason to go with option 2 (and implementing a brand
> new
> PGSTAT_KIND_BACKEND kind).
I'm starting working
Hi hackers,
In pg_stat_statements there is entry's mutex spinlock which is used to be
able to modify counters without holding pgss->lock exclusively.
Here is a comment from the top of pg_stat_statements.c:
* Note about locking issues: to create or delete an entry in the shared
* hashtable, one
On Thu, Oct 31, 2024 at 9:49 PM Daniel Gustafsson wrote:
> > On 31 Oct 2024, at 06:48, Thomas Munro wrote:
> > I guess at a minimum a copy of the licence would need to appear somewhere
>
> That's my interpretation of it as well.
>
> > perhaps under src/backend/jit/llvm?
>
> Since SectionMemoryMan
Hi,
There was an issue reported recently by Sawada-san on a different thread [1].
I have created this thread to discuss the issue separately.
Currently, generated columns can be published only when we explicitly
specify it in the Publication column list.
An issue was found that UPDATE and DELETE
On 02.11.24 14:18, Bruce Momjian wrote:
On Sat, Nov 2, 2024 at 12:02:12PM +0900, Tatsuo Ishii wrote:
Yes, we _allow_ LATIN1 characters in the SGML docs, but I replaced the
LATIN1 characters we had with HTML entities, so there are none
currently.
I think it is too easy for non-Latin1 UTF8 to cr
On 2024-Nov-04, Erik Wienhold wrote:
> I think Bruce's suggestion is pretty clear that it does not mean line or
> block comments, but rather the COMMENT command. But I also think that
> "SQL" in front of the command name is unnecessary [...]
+1 for "Do not dump COMMENT commands", which is what I
Le lundi 4 novembre 2024, 17:10:01 heure normale d’Europe centrale Tom Lane a
écrit :
> The cfbot says many of these fail regression tests --- lots of
>
> CREATE EXTENSION citext SCHEMA s;
> +ERROR: extension "citext" has no installation script nor update path for
> version "1.8"
>
> and such.
On Thu, Oct 31, 2024 at 11:51 PM Bruce Momjian wrote:
>
> On Fri, Oct 18, 2024 at 10:00:54AM +0800, jian he wrote:
> > On Fri, Oct 18, 2024 at 2:05 AM Bruce Momjian wrote:
> > > Yes, updated patch attached.
> > >
> > looks good.
> >
> > in the meantime, do you think it's necessary to slightly rep
On 2024-Nov-01, Peter Eisentraut wrote:
> > LGTM. I'd also add this line while at it:
> >
> > Peter Eisentraut
> >
> > This takes care of all the duplicate "identities" in the history AFAICT.
>
> I'm not sure if this is a good use of the mailmap feature. If someone
> commits under for a wh
Thanks for the v2 patch!
I see v1 review comments got addressed in v2 along with some
further improvements.
1) v2 Patch again needs re-base.
2) I think we need not worry whether table name is unique or not,
table name can be provided by user and we can check if it does
not exists then simply we
On Tue, Nov 5, 2024 at 9:00 AM Thomas Munro wrote:
> Reasoning: Old LLVM required C++11. LLVM 9 switched to C++14. LLVM
> 14 switched C++17. Pretty soon they'll flip to C++20 or C++23, they
> don't mess around. The corresponding -std=c++XX flag finishes up in
> our compile lines, because llvm
On Tue, Nov 5, 2024 at 12:32 PM Peter Smith wrote:
>
> has_column_list_defined:
>
> 1.
> + if (HeapTupleIsValid(cftuple))
> + {
> + bool isnull = true;
> +
> + /* Lookup the column list attribute. */
> + (void) SysCacheGetAttr(PUBLICATIONRELMAP, cftuple,
> +Anum_pg_publication_rel_prattrs,
> +
On Tue, Nov 5, 2024 at 10:19 AM Robert Haas wrote:
> On Tue, Nov 5, 2024 at 1:02 PM Nikolay Samokhvalov
> wrote:
> > hi, I have a proposal, resulted from numerous communications with
> various folks, both very experienced and new Postgres users:
> >
> > 1) EXPLAIN ANALYZE Is sometimes very confu
On Tue, Nov 5, 2024 at 1:24 PM Nikolay Samokhvalov
wrote:
> Item 3 is already solved, as it turned out.
ANALYZE and VERBOSE are treated specially because those options
existed prior to the parenthesized syntax. Scaling that treatment to a
large number of options will not work out.
> Let's focus
> On 2 Nov 2024, at 02:23, Masahiko Sawada wrote:
>
> Most of the timing durations were nanoseconds and fell into either 0
> ns. Others fell into >1023 bins.
Indeed. We cannot have these 2 bits from nanoseconds :(
I've tried to come up with some clever tricks, but have not succeeded.
Let's use
>> I suggest this change to simplify the terminology and make the function
>> name more intuitive, as "postgres" directly refers to the database server.
>> This seems more suitable to me.
>Seems like an unnecessary change of a publicly facing feature. IMO
>stability wins out over any debatable imp
hi, I have a proposal, resulted from numerous communications with various
folks, both very experienced and new Postgres users:
1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
Let's rename it to EXPLAIN EXECUTE?
2) VERBOSE doesn't include BUFFERS, and doesn't include SET
Hi!
I have been working on some servers that haven't been shut down or restarted
for many days. As a result, the need arose to use the function
'pg_postmaster_start_time' (which I had completely forgotten existed).
While working with it, I realized that it would be more appropriate for its
nam
On Tue, Nov 5, 2024 at 1:02 PM Nikolay Samokhvalov
wrote:
> hi, I have a proposal, resulted from numerous communications with various
> folks, both very experienced and new Postgres users:
>
> 1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
> Let's rename it to EXPLAIN
On Mon, 4 Nov 2024 at 20:42, Heikki Linnakangas wrote:
> Having spent some time playing with this, I quite like option C: break
> compatibility, but provide an out-of-tree header file with
> *forward*-compatibility macros. That encourages extension authors to
> adapt to new idioms, but avoids havi
Nikolay Samokhvalov writes:
> 1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
> Let's rename it to EXPLAIN EXECUTE?
This has got far too many years of history to be renamed now.
> 2) VERBOSE doesn't include BUFFERS, and doesn't include SETTINGS; it might
> be also conf
On Tue, Nov 5, 2024 at 10:16 AM Tom Lane wrote:
> Nikolay Samokhvalov writes:
> > 1) EXPLAIN ANALYZE Is sometimes very confusing (because there is
> ANALYZE).
> > Let's rename it to EXPLAIN EXECUTE?
>
> This has got far too many years of history to be renamed now.
>
This is a really, really str
On Tue, Nov 5, 2024 at 11:26 AM Maiquel Grassi
wrote:
> I suggest this change to simplify the terminology and make the function
> name more intuitive, as "postgres" directly refers to the database server.
> This seems more suitable to me.
>
Seems like an unnecessary change of a publicly facing fe
Nikolay Samokhvalov writes:
> Let's focus on item 2. Is it really impossible to make VERBOSE really
> verbose?
It's obviously not "impossible" -- the code changes would likely be
trivial. The question is whether it's a good idea. These semantics
were (I presume) deliberately chosen when the opt
On Tue, Nov 5, 2024 at 11:59 AM Maiquel Grassi
wrote:
> >> I suggest this change to simplify the terminology and make the function
> >> name more intuitive, as "postgres" directly refers to the database
> server.
> >> This seems more suitable to me.
>
> >Seems like an unnecessary change of a publ
On Sat, 2 Nov 2024 at 22:13, Andrei Lepikhov wrote:
> Okay, I passed through the code. It looks good. Hashing expressions are
> too simple to give notably impressive results, but it is a step in the
> right direction.
> I found only one minor issue: an outdated comment (see attachment).
Thanks fo
On Mon, 4 Nov 2024 at 21:00, Bruce Momjian wrote:
>
> On Mon, Nov 4, 2024 at 07:49:45PM +0100, Daniel Gustafsson wrote:
> > > On 4 Nov 2024, at 17:24, Erik Wienhold wrote:
> > > But I also think that
> > > "SQL" in front of the command name is unnecessary because the man page
> > > uses the "FOO
On Tue, Nov 5, 2024 at 10:30 AM Tom Lane wrote:
> we're not working in a green field here, and all these
> decisions have history.
>
I hear you and understand.
Ready to do legwork here.
1. VERBOSE first appeared in 1997 in 6.3 in 3a02ccfa, with different
meaning:
> This command [EXPLAIN] ou
I'm trying to write release notes for commits 53af9491a et al,
and it seems to me that we need to explain how to get out of
the mess that would be left behind by the old DETACH code.
There's no hint about that in the commit message :-(
Clearly, if you have now-inconsistent data, there's little
hel
On Tue, Nov 5, 2024 at 2:54 PM Nikolay Samokhvalov
wrote:
> 6. FInally, the fresh SERIALIZE option was discussed in
> https://www.postgresql.org/message-id/flat/ca0adb0e-fa4e-c37e-1cd7-91170b18cae1%40gmx.de
> (2023-2024, 17), and unfortunately again.
>
(didn't finish the phrase here and hit Send
On Sun, Nov 3, 2024 at 9:00 PM jian he wrote:
> The above Assert looks very wrong to me.
I can switch to Assert(false) if that's preferred, but it makes part
of the libc assert() report useless. (I wish we had more fluent ways
to say "this shouldn't happen, but if it does, we still need to get
ou
On Wed, 6 Nov 2024 at 04:03, Bertrand Drouvot
wrote:
> Another option could be to use SIMD instructions to check multiple bytes
> is zero in a single operation. Maybe just an idea to keep in mind and
> experiment
> if we feel the need later on.
Could do. I just wrote it that way to give the comp
On Tue, Nov 5, 2024 at 3:55 PM Nikolay Samokhvalov
wrote:
>
> 4. Making BUFFERS default behavior for EXPLAIN ANALYZE was raised several
> times, for example
> https://www.postgresql.org/message-id/flat/CANNMO++=LrJ4upoeydZhbmpd_ZgZjrTLueKSrivn6xmb=yf...@mail.gmail.com
> (2021) – and my understand
On Tue, Nov 05, 2024 at 05:37:15PM +, Bertrand Drouvot wrote:
> I'm starting working on option 2, I think it will be easier to discuss with
> a patch proposal to look at.
>
> If in the meantime, one strongly disagree with option 2 (means implement a
> brand
> new PGSTAT_KIND_BACKEND and keep
On Tue, Nov 5, 2024 at 3:33 PM Jacob Champion
wrote:
> Done in v36, attached.
Forgot to draw attention to this part:
> +# XXX libcurl must link after libgssapi_krb5 on FreeBSD to avoid
> segfaults
> +# during gss_acquire_cred(). This is possibly related to Curl's Heimdal
> +# depend
> On 5 Nov 2024, at 17:40, Fujii Masao wrote:
>
> On 2024/09/24 21:31, Daniel Gustafsson wrote:
>>> On 24 Sep 2024, at 10:32, btnakamurakoukil
>>> wrote:
>>> I noticed unnecessary variable "low" in index_delete_sort()
>>> (/postgres/src/backend/access/heap/heapam.c), patch attached. What do yo
On Tue, Nov 05, 2024 at 10:33:13AM +0100, Alvaro Herrera wrote:
> While I would agree with this line of thinking if the situation were as
> you describe, it should be obvious that it isn't; nobody here uses or
> has ever used a work email as committer address[1][2]. Nevertheless,
> since this argu
On Tue, Nov 5, 2024 at 1:19 PM Nikolay Samokhvalov
wrote:
>
>> > 2) VERBOSE doesn't include BUFFERS, and doesn't include SETTINGS; it
>> might
>> > be also confusing sometimes. Let's include them so VERBOSE would be
>> really
>> > verbose?
>>
>> This is not likely to fly for compatibility reasons
On Wed, Nov 06, 2024 at 12:16:33PM +1300, David Rowley wrote:
> On Wed, 6 Nov 2024 at 04:03, Bertrand Drouvot
> wrote:
>> Another option could be to use SIMD instructions to check multiple bytes
>> is zero in a single operation. Maybe just an idea to keep in mind and
>> experiment
>> if we feel t
On Tue, Nov 05, 2024 at 10:14:02AM +0100, Ronan Dunklau wrote:
> Sorry you're right I missed one for xml2. But most importantly I forgot to
> update the meson build files for every one of them, using only the Makefile...
If you want to catch that easily in the future, you can also set up
the CI w
On Wed, Nov 06, 2024 at 01:38:50PM +1300, David Rowley wrote:
> We could just write it that way and leave it up to the compiler to
> decide whether to use SIMD or not. Going by [1], gcc with -O2 uses
> SIMD instructions from 14.1 and clang with -O2 does it from version
> 8.0.0. gcc 14.1 was release
On Wed, 6 Nov 2024 at 12:33, David G. Johnston
wrote:
> The main premise here is that explain should include buffers by default, and
> to do so we are willing to inconvenience testers who do not want buffer data
> in their test plans to have to modify their tests to explicitly exclude
> buffers
Hi Vignesh,
Here are my review comments for patch v49-0001.
==
src/backend/catalog/pg_publication.c
1. check_fetch_column_list
+bool
+check_fetch_column_list(Publication *pub, Oid relid, MemoryContext mcxt,
+ Bitmapset **cols)
+{
+ HeapTuple cftuple = NULL;
+ Datum cfdatum = 0;
+ bool found
On Wed, 6 Nov 2024 at 13:52, Michael Paquier wrote:
>
> On Wed, Nov 06, 2024 at 01:38:50PM +1300, David Rowley wrote:
> > We could just write it that way and leave it up to the compiler to
> > decide whether to use SIMD or not. Going by [1], gcc with -O2 uses
> > SIMD instructions from 14.1 and cl
looks good to me.
I didn't find any issue.
group_by_has_partkey can even cope with:
EXPLAIN (COSTS OFF, settings)
SELECT c collate "C" collate case_insensitive collate "C", count(c)
FROM pagg_tab3 GROUP BY c collate "C" collate case_insensitive collate
"C" ORDER BY 1;
so i guess in group_by_has_p
On Wed, 6 Nov 2024 at 13:14, Kirk Wolak wrote:
> But, personally, as a relatively new person to PG, I was surprised that
> VERBOSE did not include the buffers.
> Could we somehow turn this on? (GUC: VERBOSE_INCLUDES_BUFFERS = yes/no)?
Please read
https://postgr.es/m/CA+TgmoYH_p-y=45saj58cu6jsm
On Tue, Nov 05, 2024 at 12:05:11PM -0700, David G. Johnston wrote:
> The ease or difficulty of making the change in the server has no meaningful
> bearing on whether breaking this public API is warranted or not.
This function has this name since 600da67fbe5e back from 2008.
Changing that 16 years
On Wed, 6 Nov 2024 at 13:20, Michael Paquier wrote:
>
> On Wed, Nov 06, 2024 at 12:16:33PM +1300, David Rowley wrote:
> > On Wed, 6 Nov 2024 at 04:03, Bertrand Drouvot
> > wrote:
> >> Another option could be to use SIMD instructions to check multiple bytes
> >> is zero in a single operation. Mayb
Michael Paquier writes:
> I was wondering what was going on here, and this patch comes down to
> switching all these definitions from that:
> CREATE FUNCTION lo_oid(lo) RETURNS pg_catalog.oid AS
> 'SELECT $1::pg_catalog.oid' LANGUAGE SQL STRICT IMMUTABLE PARALLEL SAFE;
> To that:
> +CREATE OR REP
Hi Alvaro,
On Tue, Nov 5, 2024 at 9:01 PM Alvaro Herrera wrote:
>
> Hello,
>
> While doing final review for not-null constraints, I noticed that the
> ALTER TABLE ATTACH PARTITION have this phrase:
>
> If any of the CHECK constraints of the table being attached are marked NO
> INHERIT, th
On Tue, Nov 5, 2024 at 8:30 PM Junwang Zhao wrote:
>
>
> Thanks for the bounds preserve solution, I just looked at 0002,
>
> + if (astate->arraystate != NULL)
> + {
> + memcpy(astate->arraystate->dims, dims, ndim * sizeof(int));
> + memcpy(astate->arraystate->lbs, lbs, ndim * sizeof(int));
> + Ass
Hello,
For some unknown reason (probably a very big transaction at the source), we
experienced a logical decoding breakdown,
due to a timeout from the subscriber side (either wal_receiver_timeout or
connexion drop by network equipment due to inactivity).
The problem is, that due to that fail
On Wed, Nov 6, 2024 at 11:35 AM Peter Smith wrote:
>
> I am observing some unexpected errors with the following scenario.
>
You are getting an expected ERROR. It is because of the design of
logical decoding which relies on historic snapshots.
> ==
> Tables:
>
> Publisher table:
> test_pub=#
On Wed, Nov 6, 2024 at 7:34 AM Peter Smith wrote:
>
> Hi Vignesh,
>
> Here are my review comments for patch v49-0001.
>
I have a question on the display of this new parameter.
postgres=# \dRp+
Publication pub_gen
Owner | All tables | Inserts | Updates |
I'm trying to build Postgres 17.0 and have about learning meson as I go.
The build setup command I have so far is:
meson setup build --prefix=%prefix% --buildtype=release -Dssl=auto -Dzlib=auto
-Dicu=auto
but I believe that cmd expects ssl, zlib, and icu to be installed in default
locations.
H
On Wed, Nov 06, 2024 at 03:53:48PM +1300, David Rowley wrote:
> I'm not sure if I'm clear on what works for you. The latest patch I
> saw did 1 size_t per iteration. Are you saying we should do just
> size_t per loop? or we should form the code in a way that allows the
> compiler to use SIMD instr
On Wed, Nov 6, 2024 at 3:26 PM Amit Kapila wrote:
>
> On Wed, Nov 6, 2024 at 7:34 AM Peter Smith wrote:
> >
> > Hi Vignesh,
> >
> > Here are my review comments for patch v49-0001.
> >
>
> I have a question on the display of this new parameter.
>
> postgres=# \dRp+
>
On Thu, Aug 29, 2024 at 10:26 AM Richard Guo wrote:
>
>
> > 2. I think there might be techniques we could use to limit planning
> > effort at an earlier stage when the approach doesn't appear promising.
> > For example, if the proposed grouping column is already unique, the
> > exercise is pointle
On Wed, Nov 6, 2024 at 10:26 AM Peter Smith wrote:
>
> On Wed, Nov 6, 2024 at 3:26 PM Amit Kapila wrote:
> >
> > On Wed, Nov 6, 2024 at 7:34 AM Peter Smith wrote:
> > >
> > > Hi Vignesh,
> > >
> > > Here are my review comments for patch v49-0001.
> > >
> >
> > I have a question on the display of
On Wed, 06 Nov 2024 09:59:37 +0530 Mark Hill wrote ---
I’m trying to build Postgres 17.0 and have about learning meson as I go.
The build setup command I have so far is:
meson setup build --prefix=%prefix% --buildtype=release -Dssl=auto -Dzlib=auto
-Dicu=auto
but I believe that cmd
On Fri, Nov 01, 2024 at 02:47:38PM -0700, Jacob Champion wrote:
> On Sun, Sep 1, 2024 at 5:10 PM Michael Paquier wrote:
>> Could it be more transparent to use a "startup" or
>> "starting"" state instead that gets also used by pgstat_bestart() in
>> the case of the patch where !pre_auth?
>
> Done.
On Tue, Nov 05, 2024 at 08:05:16PM -0500, Tom Lane wrote:
> No, I don't think so. For one thing, it would not help existing
> installations unless they issue "ALTER EXTENSION UPDATE", which
> people are not likely to do in a minor update. But also, we don't
> know of live attacks against these fu
1 - 100 of 102 matches
Mail list logo
