On Fri, Nov 15, 2024 at 06:46:52AM +, Bertrand Drouvot wrote:
> Makes sense even if that looks "more difficult" to read.
I don't think it's that "bad".
> which is adding a "." at the end of single line comments (as the few already
> part of this file don't do so).
I did so after looking at t
Hi,
On Fri, Nov 15, 2024 at 09:30:25AM +0900, Michael Paquier wrote:
> On Thu, Nov 14, 2024 at 12:33:20PM +, Bertrand Drouvot wrote:
> Anyway, as you say, the
> portability of v12 is OK even for sizeof(size_t) == 4 because we don't
> rely on any hardcoded values, and this patch does what it sh
On Fri, Nov 15, 2024 at 9:06 AM Peter Smith wrote:
>
> On Fri, Nov 15, 2024 at 2:07 PM Amit Kapila wrote:
> >
> > > A better solution may be just to *combine* everything, so the user
> > > only has to deal with one error. IIUC that's what is already happening
> > > in master code, so this patch d
On Thu, 14 Nov 2024 at 15:51, Shlok Kyal wrote:
>
> Thanks for providing the comments.
>
> On Thu, 14 Nov 2024 at 12:22, vignesh C wrote:
> >
> > On Wed, 13 Nov 2024 at 11:15, Shlok Kyal wrote:
> > >
> > > Thanks for providing the comments.
> > >
> > > On Tue, 12 Nov 2024 at 12:52, Zhijie Hou (F
On Thu, Nov 14, 2024 at 7:08 AM Masahiko Sawada wrote:
>
> Sure. I've attached the updated patch. I just added the commit message.
>
@@ -1815,6 +1818,8 @@ LogicalIncreaseRestartDecodingForSlot(XLogRecPtr
current_lsn, XLogRecPtr restart
confirmed_flush = slot->data.confirmed_flush;
SpinLockRel
čt 14. 11. 2024 v 8:41 odesílatel Pavel Stehule
napsal:
>
>
> st 13. 11. 2024 v 17:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Sun, Nov 10, 2024 at 06:51:40PM GMT, Pavel Stehule wrote:
>> > ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule <
>> pavel.steh...@gmail.com>
On Thu, Nov 14, 2024 at 10:07:41AM +, Bertrand Drouvot wrote:
> === 1
>
> Maybe use "generation" instead of generation in the comments (where it's not
> done,
> some comments do it already).
I've tweaked things to be more consistency, and applied that down to 15.
> === 2
>
> We could think
On Tue, Nov 12, 2024 at 3:45 PM Peter Eisentraut wrote:
>
> On 11.11.24 14:25, Heikki Linnakangas wrote:
> > Sadly the algorithm is O(n^2) with non-deterministic collations.Is there
> > any way this could be optimized? We make no claims on how expensive any
> > functions or operators are, so I sup
On Fri, Nov 15, 2024 at 2:07 PM Amit Kapila wrote:
>
> On Fri, Nov 15, 2024 at 6:10 AM Peter Smith wrote:
> >
> > 3. A different approach?
> >
> > TBH, is introducing a whole new error message even a good idea?
> >
> > Now there are going to be two separate error messages where previously
> > the
On Thu, Nov 14, 2024 at 12:02 AM Suraj Kharage <
suraj.khar...@enterprisedb.com> wrote:
> Alvaro stated that allowing a not null constraint state to be modified
> from INHERIT to NO INHERIT is going to be quite problematic because of the
> number of weird cases to avoid, so for now that support is
On Wed, Nov 13, 2024 at 5:23 PM Tomas Vondra wrote:
>
> On 11/13/24 11:59, Amit Kapila wrote:
> > On Tue, Nov 12, 2024 at 12:43 PM Ashutosh Bapat
> > wrote:
> >>
> >> On Tue, Nov 12, 2024 at 12:02 PM Masahiko Sawada
> >> wrote:
> >>>
> >>> On Mon, Nov 11, 2024 at 2:08 PM Tomas Vondra wrote:
>
On Fri, Nov 15, 2024 at 1:00 AM Tom Lane wrote:
> Noah Misch writes:
> > It's not immediately to clear to me why this would crash in a non-asserts
> > build. palloc issues a 512-byte chunk for sizeof(ResultRelInfo)==368 on
> v16,
> > so I expect no actual writing past the end of the chunk.
>
>
Hi Sawada-Sn,
Here are some review comments for patch v8-0001.
==
contrib/test_decoding/sql/stats.sql
1.
+-- The INSERT changes are large enough to be spilled but not, because the
+-- transaction is aborted. The logical decoding skips collecting further
+-- changes too. The transaction is pr
On Fri, Nov 15, 2024 at 6:10 AM Peter Smith wrote:
>
> 3. A different approach?
>
> TBH, is introducing a whole new error message even a good idea?
>
> Now there are going to be two separate error messages where previously
> there was only one. So if the table has multiple problems at the same
> t
Dear Shubham,
Thanks for creating a patch! I checked yours and I have comments.
01.
```
+ StringInfoData gencolsattsbuf;
+ int generatedatts = 0;
+
+ initStringInfo(&gencolsattsbuf);
```
gencolsattsbuf is initialized at the beginning
On 2024-11-13 22:02, Yugo NAGATA wrote:
On Tue, 12 Nov 2024 17:38:25 +0900
torikoshia wrote:
On 2024-11-12 14:17, Yugo Nagata wrote:
> On Tue, 12 Nov 2024 14:03:50 +0900
> Yugo Nagata wrote:
>
>> On Tue, 12 Nov 2024 01:27:53 +0500
>> Kirill Reshke wrote:
>>
>> > On Mon, 11 Nov 2024 at 16:11,
On Mon, Nov 11, 2024 at 12:20 PM Masahiko Sawada wrote:
>
> On Sat, Nov 9, 2024 at 9:07 AM Sergey Prokhorenko
> wrote:
> >
> > On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada
> > wrote:
> >
> > > the microsecond part is working also as a counter in a sense. IT seems
> > > fin
Hi Shubham.
==
Commit message.
1.
FYI, to clarify my previous review comment [1] #1, I think a more
correct commit message might be:
SUGGESTION
Currently, if logical replication attempts to target a subscriber-side
table column that is either missing or generated, it produces the
following i
On Thu, Nov 14, 2024 at 12:33:20PM +, Bertrand Drouvot wrote:
> Case 2 should be read as "in the 4-31" bytes range on 32-bit system as all
> comparisons are done in size_t.
I'd suggest to use a -m32 in your gcc switches, when it comes to
tests, but you already know that.. Anyway, as you say,
On Thu, Nov 14, 2024 at 5:41 PM Noah Misch wrote:
> I'm hearing the only confirmed impact on non-assert builds is the need to
> recompile timescaledb. (It's unknown whether recompiling will suffice for
> timescaledb. For assert builds, six PGXN extensions need recompilation.)
>
That matches wh
On Wed, Nov 13, 2024 at 11:19 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <20241105.174328.1705956947135248653@clear-code.com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 05 Nov 2024 17:43:28 +0900 (JST),
> Sutou Kouhei wrote:
>
> >> I've further inves
On Wed, Nov 13, 2024 at 8:23 PM Peter Smith wrote:
>
> Hi Sawda-San,
>
> Here are some more review comments for the latest (accidentally called
> v6 again?) v6-0001 patch.
Thank you for reviewing the patch! Indeed, the previous version should
have been v7.
>
> ==
> contrib/test_decoding/sql/
Hello, everyone.
Rebased on master.
>
From 9c85b499793e9a4bcbb55cc5d78cfeacab368b58 Mon Sep 17 00:00:00 2001
From: nkey
Date: Thu, 14 Nov 2024 22:36:26 +0100
Subject: [PATCH v4 2/4] Modify the infer_arbiter_indexes function to consider
both indisvalid and indisready indexes. Ensure that at lea
Hi,
> The allocation should be big enough. The other
> hazard would be failing to initialize the field, but if the extension
> uses InitResultRelInfo then that's taken care of.
> So what is timescale doing differently?
I see 3 usages of makeNode(ResultRelInfo) in Timescale:
- src/nodes/chunk_d
On Thu, Nov 14, 2024 at 09:33:32PM +0100, Alvaro Herrera wrote:
> On 2024-Nov-14, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > But timescale did crash:
> >
> > So what is timescale doing differently?
> src/ts_catalog/catalog.c-extern TSDLLEXPORT ResultRelInfo *
> src/ts_catalog/catalog.c-ts_
On Thu, 14 Nov 2024 at 16:28, Dmitry Koval wrote:
>
> I think having gamma() and lgamma() functions in PostgreSQL would be
> useful for some users, this is asked [1].
>
Thanks for looking.
> >SELECT gamma(float8 '1e-320');
> ERROR: value out of range: overflow
>
> >SELECT gamma(float8 '0');
>
On Fri, Nov 15, 2024 at 4:54 AM Christoph Berg wrote:
> postgresql 13.17, Debian bullseye, amd64:
>
> t/039_end_of_wal.pl .. Dubious, test returned 2 (wstat 512,
> 0x200)
This seems to be the interesting bit:
build/src/test/recovery/tmp_check/log/regress_log_039_end_of_
Aleksander Alekseev writes:
> The third case is the following:
> ```
> extern TSDLLEXPORT ResultRelInfo *
> ts_catalog_open_indexes(Relation heapRel)
> {
> ResultRelInfo *resultRelInfo;
> resultRelInfo = makeNode(ResultRelInfo);
> resultRelInfo->ri_RangeTableIndex = 0; /* dummy */
>
Hi Alvaro,
> There are three makeNode(ResultRelInfo), but they don't look anything
> out of the ordinary:
> [...]
> src/ts_catalog/catalog.c-extern TSDLLEXPORT ResultRelInfo *
> src/ts_catalog/catalog.c-ts_catalog_open_indexes(Relation heapRel)
> src/ts_catalog/catalog.c-{
> src/ts_catalog/catalog
On 2024-Nov-14, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Nov-14, Christoph Berg wrote:
> >> It didn't actually crash, true.
>
> > But timescale did crash:
>
> So what is timescale doing differently?
No idea. Maybe a stacktrace from a core would tell us more; but the
jenkins task d
On Wed, 13 Nov 2024 at 10:53AM(EST), Nazir Bilal Yavuz
wrote:
> I think that the problem is that you are setting '.../include/openssl'
> as an include_dir not '.../include'. Could you please try:
> set
> openssl_include_dir=D:\Jenkins\workspace\workspace\Postgres-9.4\OpenSSL\OpenSSL-Install\Op
Alvaro Herrera writes:
> On 2024-Nov-14, Christoph Berg wrote:
>> It didn't actually crash, true.
> But timescale did crash:
So what is timescale doing differently?
regards, tom lane
On 2024-Nov-14, Christoph Berg wrote:
> It didn't actually crash, true.
But timescale did crash:
https://pgdgbuild.dus.dg-i.net/job/timescaledb-autopkgtest/9/architecture=amd64,distribution=sid/console
11:59:51 @@ -34,6 +40,7 @@
11:59:51 CREATE INDEX ON _hyper_1_3_chunk(temp2);
11:59:51 -- IN
Christoph Berg writes:
> Re: Noah Misch
>> The non-asserts build passed. The asserts build failed with "+WARNING:
>> problem in alloc set ExecutorState: detected write past chunk" throughout the
>> diffs, but there were no crashes. (Note that AGE "make installcheck" creates
>> a temporary instal
Re: Noah Misch
> The non-asserts build passed. The asserts build failed with "+WARNING:
> problem in alloc set ExecutorState: detected write past chunk" throughout the
> diffs, but there were no crashes. (Note that AGE "make installcheck" creates
> a temporary installation, unlike PostgreSQL "mak
On 11/14/24 10:14, Matthias van de Meent wrote:
I called this issue out earlier this year: amcanunique implies
btree-style uniqueness, and allows CREATE UNIQUE INDEX. However, that
IndexAmRoutine field seems to be ignored for indexes that are created
to back temporal unique constraints, which thu
Noah Misch writes:
> It's not immediately to clear to me why this would crash in a non-asserts
> build. palloc issues a 512-byte chunk for sizeof(ResultRelInfo)==368 on v16,
> so I expect no actual writing past the end of the chunk.
I'm confused too. The allocation should be big enough. The ot
On Thu, Nov 14, 2024 at 10:26:58AM -0800, Noah Misch wrote:
> On Thu, Nov 14, 2024 at 05:29:18PM +0100, Christoph Berg wrote:
> > Re: Noah Misch
> > > Based on a grep of PGXN code, here are some or all of the modules that
> > > react
> > > to sizeof(ResultRelInfo):
> > >
> > > $ grepx -r 'lloc.*R
On Thu, Nov 14, 2024 at 05:29:18PM +0100, Christoph Berg wrote:
> Re: Noah Misch
> > Based on a grep of PGXN code, here are some or all of the modules that react
> > to sizeof(ResultRelInfo):
> >
> > $ grepx -r 'lloc.*ResultRelInfo' | tee /tmp/1 | sed 's/-[^:]*/:/'|sort -u
> > apacheage::resul
On Thu, Nov 14, 2024 at 9:43 PM Peter Eisentraut
wrote:
> On 14.11.24 15:35, Noah Misch wrote:
> > The postgr.es/c/e54a42a standard would have us stop here. But I'm open
> to
> > treating the standard as mistaken and changing things.
>
> That text explicitly calls out that adding struct members
On Wed, 13 Nov 2024, 11:11 Peter Eisentraut, wrote:
> This conditional is really hard to understand:
>
> + /*
> +* The AM must support uniqueness, and the index must in fact be
> unique.
> +* If we have a WITHOUT OVERLAPS constraint (identified by
> uniqueness +
> +*
On Thu, Nov 14, 2024 at 11:29 AM Alvaro Herrera wrote:
> ISTM that we have spare bytes where we could place that boolean without
> breaking ABI. In x86_64 there's a couple of 4-byte holes, but those
> won't be there on x86, so not great candidates. Fortunately there are
> 3-byte and 7-byte holes
On Tue, Nov 12, 2024 at 1:47 PM Jacob Champion
wrote:
> On Fri, Nov 8, 2024 at 1:21 AM Peter Eisentraut wrote:
> > Also, shouldn't [oauth_validator_library] be an hba option instead? What
> > if you want to
> > use different validators for different connections?
>
> Yes. This is again the multi
Just sharing my progress here since it's been a week:
On 11/6/24 17:03, Paul Jungwirth wrote:
On 11/4/24 13:16, Sam Gabrielsson wrote:
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 v3
On 11/13/24 02:11, Peter Eisentraut wrote:
I have committed the documentation patches
v43-0001-Add-WITHOUT-OVERLAPS-and-PERIOD-to-ALTER-TABLE-r.patch
v43-0002-Update-conexclop-docs-for-WITHOUT-OVERLAPS.patch
Thanks!
For the logical replication fixes
v43-0003-Fix-logical-replication-for-temp
Hi,
> Right. makeNode(), palloc(sizeof), and stack allocation have that problem.
> Allocation wrappers like CreateExecutorState() avoid the problem. More
> generally, structs allocated in non-extension code are fine.
Perhaps we should consider adding an API like makeResultRelInfo() and
others,
On Thu, Nov 14, 2024 at 05:13:35PM +0100, Peter Eisentraut wrote:
> On 14.11.24 15:35, Noah Misch wrote:
> > The postgr.es/c/e54a42a standard would have us stop here. But I'm open to
> > treating the standard as mistaken and changing things.
>
> That text explicitly calls out that adding struct m
Timescale at least has many users, I don't know about the others. But
they won't be happy if we let things be. IMO we should rewrap ...
especially 12, since there won't be a next one.
ISTM that we have spare bytes where we could place that boolean without
breaking ABI. In x86_64 there's a coupl
Re: Noah Misch
> Based on a grep of PGXN code, here are some or all of the modules that react
> to sizeof(ResultRelInfo):
>
> $ grepx -r 'lloc.*ResultRelInfo' | tee /tmp/1 | sed 's/-[^:]*/:/'|sort -u
> apacheage::resultRelInfo = palloc(sizeof(ResultRelInfo));
Confirmed, crashing: AGE for 14..
Hi!
I think having gamma() and lgamma() functions in PostgreSQL would be
useful for some users, this is asked [1].
I have a question regarding the current implementation of gamma()
function. Code block:
+ if (errno == ERANGE && arg1 != 0)
+ {
+ if (result != 0.0)
+
On 14.11.24 15:35, Noah Misch wrote:
The postgr.es/c/e54a42a standard would have us stop here. But I'm open to
treating the standard as mistaken and changing things.
That text explicitly calls out that adding struct members at the end of
a struct is considered okay. But thinking about it now
Re: Thomas Munro
> Pushed. Thanks!
Well...
postgresql 13.17, Debian bullseye, amd64:
t/039_end_of_wal.pl .. Dubious, test returned 2 (wstat 512,
0x200)
No subtests run
Test Summary Report
---
t/039_end_of_wal.pl(Wstat: 512 Tests: 0 Failed: 0)
Hi,
> To add to this list, Christoph Berg confirmed that timescaledb test suite
> crashes. [1]
Yes changing ResultRelInfo most definetely breaks TimescaleDB. The
extension uses makeNode(ResultRelInfo) and this can't end-up well:
```
static inline Node *
newNode(size_t size, NodeTag tag)
{
N
I encountered a problem with logical replication.
The object identifier types, regclass, regproc, regtype, etc. are
transferred as an oid in the binary mode. However, the subscriber
expects them as text which makes sense because it cannot do anything
with the oids. I am getting "invalid byte seq
On Thu, 14 Nov 2024 at 16:35, Noah Misch wrote:
> Based on a grep of PGXN code, here are some or all of the modules that
> react
> to sizeof(ResultRelInfo):
>
To add to this list, Christoph Berg confirmed that timescaledb test suite
crashes. [1]
Regards,
Ants Aasma
[1]
https://pgdgbuild.dus.dg
On Thu, Nov 14, 2024 at 04:18:02PM +0530, Pavan Deolasee wrote:
> Commit 51ff46de29f67d73549b2858f57e77ada8513369 (backported all the way
> back to v12) added a new member to `ResultRelInfo` struct. This can
> potentially cause ABI breakage for the extensions that allocate the struct
> and pass it
Hi Alvaro,
The commit message looks good to me, except maybe using a "master" word,
which I would suggest to replace with "primary".
And a small nitpick:
+/*
+ * Initialize a hash table to store WAL file names that must be kept.
+ */
+void
+keepwal_init(void)
+{
+ /*
+* This hash table is e
On 14.11.24 08:48, Thomas Munro wrote:
The three MinGW environments we test today are using ucrt, and
configure detects the symbol on all. Namely: fairwren
(msys2/mingw64), the CI mingw64 task and the mingw cross-build that
runs on Linux in the CI CompilerWarnings task. As far as I know these
a
On 09/10/2024 23:40, Heikki Linnakangas wrote:
I pushed the first three patches, with the new test and one of the small
refactoring patches. Thanks for all the comments so far! Here is a new
version of the remaining patches.
Lots of little cleanups and changes here and there since the last
versi
Hi,
On Thu, Nov 14, 2024 at 03:31:51PM +0900, Michael Paquier wrote:
> On Fri, Nov 08, 2024 at 02:09:30PM +, Bertrand Drouvot wrote:
> > 1. one assertion in pgstat_drop_entry_internal() is not necessary true
> > anymore
> > with this new stat kind. So, adding an extra bool as parameter to ta
On 11/13/24 03:56, Amit Kapila wrote:
the key point Andres
is raising is that we won't be able to convert the operation in
ReserveXLogInsertLocation() to use atomics after such a solution. Now,
even, if the change is only in the *commit* code path, we may or may
not be able to maintain two code
On 11/14/24 2:55 AM, jian he wrote:
On Tue, Nov 12, 2024 at 12:28 PM Jonathan S. Katz wrote:
Hi,
Please review the draft of the release announcement for the 2024-11-14
release. Please provide any feedback by 2024-11-14 12:00 UTC.
someone reminded me.
i am wondering do we need include the f
On 11/11/24 11:54 PM, Thomas Munro wrote:
On Tue, Nov 12, 2024 at 5:28 PM Jonathan S. Katz wrote:
Please review the draft of the release announcement for the 2024-11-14
release. Please provide any feedback by 2024-11-14 12:00 UTC.
I think "* Fixes random crashes in JIT compilation on aarch64
> On 14 Nov 2024, at 13:11, Ashutosh Bapat wrote:
>>> On Mon, Nov 11, 2024 at 7:50 AM Andres Freund wrote:
If you just want that we could print out a file:// url or even open it?
Rather
than an http server?
+1
> I noticed that the documentation served by the postgresql.org site
On Mon, 21 Oct 2024 at 11:49, Alvaro Herrera wrote:
> I guess it would be helpful if the commitfest app can read a URL to a
> mailing list post and reverse-engineer the message-id from it ... maybe
> you'd have to propose a patch to this:
> https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=
Hello Ashutosh,
On 2024-Nov-14, Ashutosh Bapat wrote:
> Because of the test I am developing under discussion at [1], I noticed
> that the DDLs dumped for inheritance children with NOT NULL
> constraints defer between original database and database restored from
> a dump of original database. I in
Hi,
On Thu, Nov 14, 2024 at 09:13:19AM -0300, Ranier Vilela wrote:
> Em qui., 14 de nov. de 2024 às 08:58, Bertrand Drouvot <
> Maybe I'm doing something wrong.
> But I'm testing in 32-bit, with the size set to 63, with v12 and I'm seeing
> the SIMD loop execute.
Yeah, that's expected and safe as
On Sun, 10 Nov 2024 at 22:30, Heikki Linnakangas wrote:
> I thought of the Wiki so that it could updated more casually by
> extension authors.
Makes sense, I agree it would be nice not to have to rely on
committers to merge these changes. Especially since many extension
authors are not committers
On 07.11.24 22:57, Alexandra Wang wrote:
The v5 patch includes the following updates:
- Fixed the aforementioned issue and added more tests covering composite
types with domains, nested domains, and arrays of domains over
JSON/JSONB.
- Refactored the logic for parsing JSON/JSONB object fields b
On Thu, 31 Oct 2024 at 22:47, Michael Banck wrote:
> Even though there has not been a lot of discussion on this, here is a
> rebased patch. I have also added it to the upcoming commitfest.
After considering this again, I actually think this is a good change.
Basically all cloud providers already
On 11/14/24 08:09, Richard Guo wrote:
On Wed, Nov 13, 2024 at 7:36 PM Andrei Lepikhov wrote:
On 11/13/24 13:49, Richard Guo wrote:
In thread [1], I try to add one more strategy that minimises the number
of comparison operator calls. It seems that it would work the same way
with the DISTINCT sta
Em qui., 14 de nov. de 2024 às 08:58, Bertrand Drouvot <
bertranddrouvot...@gmail.com> escreveu:
> Hi,
>
> On Thu, Nov 14, 2024 at 08:22:23AM -0300, Ranier Vilela wrote:
> > Em qui., 14 de nov. de 2024 ąs 07:09, Bertrand Drouvot <
> > bertranddrouvot...@gmail.com> escreveu:
> >
> > > Hi,
> > >
> >
On Tue, Nov 12, 2024 at 4:00 PM Ashutosh Bapat
wrote:
>
> On Mon, Nov 11, 2024 at 10:41 PM Jacob Champion
> wrote:
> >
> > On Mon, Nov 11, 2024 at 7:50 AM Andres Freund wrote:
> > > If you just want that we could print out a file:// url or even open it?
> > > Rather
> > > than an http server?
>
Hi,
On Thu, Nov 14, 2024 at 08:22:23AM -0300, Ranier Vilela wrote:
> Em qui., 14 de nov. de 2024 às 07:09, Bertrand Drouvot <
> bertranddrouvot...@gmail.com> escreveu:
>
> > Hi,
> >
> > On Thu, Nov 14, 2024 at 09:27:06AM +0900, Michael Paquier wrote:
> > > Makes sense to me to just do that, with
On 2024-Nov-14, Michael Paquier wrote:
> Already mentioned previously at [1] and echoing with some surrounding
> arguments, but I'd suggest to keep it simple and just remove entirely
> the part of the patch where the stats information gets spilled into
> disk. With more than 6000-ish context info
Thanks Tomas, that's useful to know.
Cheers
Jim
On Wed, 13 Nov 2024 at 13:13, Tomas Vondra wrote:
> On 11/13/24 13:08, Jim Vanns wrote:
> > (sent to general users mailing list yesterday - but perhaps this is a
> > more suitable audience?)
> >
> > In PG16.4, we have a table of key/pair data (ar
On Thu, Nov 14, 2024 at 4:04 PM Peter Eisentraut wrote:
> I propose that I go ahead with committing the v7 patch (with your typo
> fixes) and then we continue discussing these other issues afterwards in
> a separate thread.
>
looks good to me.
but in create_table.sgml
In addition, wh
Em qui., 14 de nov. de 2024 às 07:09, Bertrand Drouvot <
bertranddrouvot...@gmail.com> escreveu:
> Hi,
>
> On Thu, Nov 14, 2024 at 09:27:06AM +0900, Michael Paquier wrote:
> > Makes sense to me to just do that, with a first < 8 loop, and a second
> > for the 8~63 range.
>
> Thanks for looking at i
Hi Michael,
> The scans may be quite long as well, actually, which could be a
> bottleneck. Did you measure the runtime with a maximized (still
> realistic) pool of files for these SLRUs in the upgrade time? For
> upgrades, data would be the neck.
Good question.
In theory SLRUs are not suppose
Hello,
Commit 51ff46de29f67d73549b2858f57e77ada8513369 (backported all the way
back to v12) added a new member to `ResultRelInfo` struct. This can
potentially cause ABI breakage for the extensions that allocate the struct
and pass it down to the PG code. The previously built extensions may
allocat
Thanks for providing the comments.
On Thu, 14 Nov 2024 at 12:22, vignesh C wrote:
>
> On Wed, 13 Nov 2024 at 11:15, Shlok Kyal wrote:
> >
> > Thanks for providing the comments.
> >
> > On Tue, 12 Nov 2024 at 12:52, Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Friday, November 8, 2024 7:06 PM
Hi,
On Thu, Nov 14, 2024 at 09:27:06AM +0900, Michael Paquier wrote:
> Makes sense to me to just do that, with a first < 8 loop, and a second
> for the 8~63 range.
Thanks for looking at it!
> There is also a "cant'" in the last size_t check. Simple typo.
Please find attached v12, with more c
Hi,
On Thu, Nov 14, 2024 at 04:55:23PM +0900, Michael Paquier wrote:
> I've been going through this patch again, and the failures that could
> be seen because of such failures, like standbys failing in an
> unpredictible way is not cool, so I am planning to apply the attached
> down to 15 now that
On 14/11/2024 09:48, Thomas Munro wrote:
On Thu, Aug 29, 2024 at 6:50 AM Peter Eisentraut wrote:
The error handling with pg_ensure_c_locale(), that's the sort of thing
I'm afraid will be hard to test or even know how it will behave. And it
creates this weird coupling between pgtypeslib and ecp
On Thu, Nov 14, 2024 at 6:28 PM Richard Guo wrote:
> 1. We need to teach set_operation_ordered_results_useful() that sorted
> input paths are also useful for INTERSECT/EXCEPT, so that we can have
> setop_pathkeys set for the subqueries.
BTW, I noticed a typo in the comment for function
set_operat
On Tue, Nov 12, 2024 at 9:47 PM Peter Eisentraut wrote:
>
> On 10.11.24 04:16, Amit Kapila wrote:
> > The possible idea to replicate virtual generated columns is to compute
> > the corresponding expression before sending the data to the client. If
> > we can allow it in the row filter than why not
On Thu, Nov 14, 2024 at 11:00 AM Tom Lane wrote:
> Aside from that minor TODO, the main thing that's left undone in this
> patch series is to persuade the thing to exploit presorted input
> paths. Right now it fails to do so, as can be seen in some of the
> regression test cases, eg
>
> regressio
On 11/14/24 08:20, Richard Guo wrote:
On Wed, Nov 13, 2024 at 9:59 PM Andrei Lepikhov wrote:
Even So, it would be better to insert changes, induced by new
feature by one commit.
I'm not sure I understand what you mean by this sentence.
Yeah, it's my bad English. nothing special, I just wanted
On 29.10.24 15:20, Tom Lane wrote:
Peter Eisentraut writes:
There are a bunch of (void *) casts in the code that don't make sense to
me. I think some of these were once necessary because char * was used
in place of void * for some function arguments. And some of these were
probably just copie
On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
> Good catch. I agree with this being an unwarranted behaviour.
> A minor comment from my end is the wording of the error message.
> Based on the Postgresql error message style huide, something like this could
> be better,
> "could not access te
On Wed, Nov 13, 2024 at 11:30 AM jian he wrote:
>
> These 3 functions will call StoreRelNotNull to store the not-null constraint.
> StoreConstraints
> AddRelationNotNullConstraints
> AddRelationNewConstraints
>
> we can disallow not-null on virtual generated columns via these 3 functions.
> I gues
Hi Shubham,
+1 for the patch idea.
Improving this error message for subscriber-side generated columns
will help to remove some confusion.
Here are my review comments for patch v1-0001.
==
Commit message.
1.
The error message was misleading, as it failed to clarify that the replication
of r
Hi,
On Thu, Nov 14, 2024 at 12:16:52AM +0200, Heikki Linnakangas wrote:
> On 13/11/2024 18:08, Bertrand Drouvot wrote:
> > === 1
> >
> > + parentOffset--;
> > + parents[parentOffset]->totalXids = totalXids;
> >
> > what about "parents[--parentOffset]->totalXids = totalXids;" instead?
> >
> >
On Wed, Nov 13, 2024 at 10:49 PM Alvaro Herrera wrote:
> On 2024-Nov-13, Amit Langote wrote:
>
> > I rebased my patch over 14e87ffa5c54 and noticed that NOT NULL
> > constraints can also (or not) be marked NO INHERIT. I think we should
> > allow NO INHERIT NOT NULL constraints on leaf partitions
On Thu, Oct 17, 2024 at 01:24:50PM +0900, Michael Paquier wrote:
>> Yeah, FWIW, we would be going from 32 bytes:
>>/* total size (bytes): 32 */
>>
>> to 40 bytes (with the patch applied):
>>/* total size (bytes): 40 */
>>
>> Due
On Tue, Nov 12, 2024 at 12:28 PM Jonathan S. Katz wrote:
>
> Hi,
>
> Please review the draft of the release announcement for the 2024-11-14
> release. Please provide any feedback by 2024-11-14 12:00 UTC.
>
someone reminded me.
i am wondering do we need include the following two items:
https://git
On 14.11.24 03:21, jian he wrote:
On Wed, Nov 13, 2024 at 8:56 PM jian he wrote:
https://stackoverflow.com/questions/14921668/difference-between-restrict-and-no-action
mentioned about the difference between "no action" and "restrict".
RI_FKey_restrict_upd comments also says:
* The SQL stan
97 matches
Mail list logo
