On Thu, Sep 5, 2024 at 5:07 PM Zhijie Hou (Fujitsu)
wrote:
>
>
> Hi hackers,
>
> I am starting a new thread to discuss and propose the conflict detection for
> update_deleted scenarios during logical replication. This conflict occurs when
> the apply worker cannot find the target tuple to be updat
On Tue, 10 Sept 2024 at 04:47, Bruce Momjian wrote:
> Yes. There are so many changes at the source code level it is unwise to
> try and get them into the main release notes. If someone wants to
> create an addendum, like was suggested for pure performance
> improvements, that would make sense.
Masahiko Sawada writes:
> On Mon, Sep 9, 2024 at 4:42 PM Tom Lane wrote:
>> Do you have an idea for how we'd get
>> this to happen during pg_upgrade, exactly?
> What I was thinking is that we have "pg_dump --binary-upgrade" emit a
> function call, say "SELECT binary_upgrade_update_gin_meta_page(
On Mon, 9 Sept 2024 at 13:12, Amit Kapila wrote:
>
> On Mon, Sep 9, 2024 at 11:44 AM Dilip Kumar wrote:
> >
> > On Fri, Sep 6, 2024 at 4:48 PM vignesh C wrote:
> > >
> > > On Mon, 2 Sept 2024 at 18:22, Dilip Kumar wrote:
> > > >
> > > > On Mon, Sep 2, 2024 at 3:32 PM Amit Kapila
> > > > wrote
Hi,
On Thu, Sep 05, 2024 at 04:48:36AM +, Bertrand Drouvot wrote:
> Please find attached a mandatory rebase.
>
> In passing, checking if based on the previous discussion (and given that we
> don't have the relation OID when writing buffers out) you see another approach
> that the one this pat
On Tue, Sep 03, 2024 at 02:47:57PM -0700, Jacob Champion wrote:
> On Sun, Sep 1, 2024 at 5:10 PM Michael Paquier wrote:
>> that gets also used by pgstat_bestart() in
>> the case of the patch where !pre_auth?
>
> To clarify, do you want me to just add the new boolean directly to
> pgstat_bestart()
On Tue, Sep 10, 2024 at 8:40 AM Peter Smith wrote:
>
> Hi, here are some review comments for patch v1.
>
> ==
> Commit message
>
> 1.
> ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary
> as there is no way...
>
> suggestion:
> ALTER_REPLICATION_SLOT for invalid replicatio
On Mon, Sep 9, 2024 at 4:42 PM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > When do we set the byte on the primary server? If it's the first time
> > to use the GIN index, secondary servers would have to wait for the
> > primary to use the GIN index, which could be an unpredictable time or
> >
On Tue, Sep 10, 2024 at 12:11 AM Bharath Rupireddy
wrote:
>
> Hi,
>
> ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary
> as there is no way to get the invalidated (logical) slot to work.
> Please find the patch to add an error in such cases. Relevant
> discussion is at [1].
>
On Mon, Sep 9, 2024 at 2:58 PM shveta malik wrote:
>
> On Fri, Sep 6, 2024 at 2:05 PM Ajin Cherian wrote:
> >
> >
> > Thank you for your feedback, Shveta. I've addressed both sets of comments
> > you provided.
>
> Thanks for the patches. I am reviewing v12-patch001, it is WIP. But
> please find
Hi,
I have attached a rebased patch.
Regards,
Hunaid Sohail
On Mon, Sep 9, 2024 at 6:22 PM Jim Jones wrote:
> Hi Hunaid
>
> On 02.08.24 14:11, Hunaid Sohail wrote:
> >
> > I have also edited the documentation and added it to the patch. Please
> > let me know if any changes are required.
> >
>
On Friday, August 9, 2024 7:21 PM Shlok Kyal wrote:
Hi,
>
> In the v7 patch, I am looping through the reorder buffer of the current
> committed
> transaction and storing all invalidation messages in a list. Then I am
> distributing those invalidations.
> But I found that for a transaction we a
On Tue, Sep 10, 2024 at 2:51 AM Masahiko Sawada wrote:
>
> On Mon, Sep 9, 2024 at 2:38 AM Shubham Khanna
> wrote:
> >
>
> Thank you for updating the patches. I have some comments:
>
> Do we really need to add this option to test_decoding?
>
I don't see any reason to have such an option in test_d
On Tue, Sep 10, 2024 at 10:27 AM Thomas Munro wrote:
> Mats, what do you think about
> this? (I haven't tried to preserve the prefetching behaviour, which
> probably didn't actually too work for you in v16 anyway at a guess,
> I'm just looking for the absolute simplest thing we can do to resolve
On Tue, Sep 10, 2024 at 8:46 AM jian he wrote:
>
> hi,
> one minor issue. not that minor,
> since many DDLs need to consider the system attribute.
>
> looking at these functions:
> SearchSysCacheCopyAttName
> SearchSysCacheAttName
> get_attnum
>
> get_attnum says:
> Returns InvalidAttrNumber if th
On Wed, Sep 4, 2024 at 9:16 AM Richard Guo wrote:
> I'm seeking the possibility to push 0001 and 0002 sometime this month.
> Please let me know if anyone thinks this is unreasonable.
>
> For 0003, it might be extended to remove all no-op PHVs except those
> that are serving to isolate subexpressio
jian he writes:
> get_attnum says:
> Returns InvalidAttrNumber if the attr doesn't exist (or is dropped).
> So I conclude that "attnum == 0" is not related to the idea of a system
> column.
attnum = 0 is also used for whole-row Vars. This is a pretty
unfortunate choice given the alternative m
hi,
one minor issue. not that minor,
since many DDLs need to consider the system attribute.
looking at these functions:
SearchSysCacheCopyAttName
SearchSysCacheAttName
get_attnum
get_attnum says:
Returns InvalidAttrNumber if the attr doesn't exist (or is dropped).
So I conclude that "attnum == 0
Hi, here are some review comments for patch v1.
==
Commit message
1.
ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary
as there is no way...
suggestion:
ALTER_REPLICATION_SLOT for invalid replication slots should not be
allowed because there is no way...
==
2. Missi
On Mon, Sep 9, 2024 at 1:37 PM Joe Conway wrote:
> Seems the mounted drive got unmounted somehow ¯\_(ツ)_/¯
>
> Please check it out and let me know if it is working properly now.
Looks good, thanks!
On Sat, Sep 7, 2024 at 11:55:09AM +0200, Álvaro Herrera wrote:
> On 2024-Sep-05, Bruce Momjian wrote:
>
> > That seems more infrastructure/extension author stuff which isn't
> > normally mentioned in the release notes. I think such people really
> > need to look at all the commit messages.
>
>
> > >> I think the testing discussion should be moved to a different thread.
> > >> What do you think?
> > > See v4.
> > >
> > > 0001 deals with reporting queryId in exec_execute_message and
> > > exec_bind_message.
> > > 0002 deals with reporting queryId after a cache invalidation.
> > >
> > >
Hi, here is the remainder of my v45-0001 review. These comments are
for the test code only.
==
Testcase #1
1.
+# Testcase start
+#
+# Invalidate streaming standby slot and logical failover slot on primary due to
+# inactive timeout. Also, check logical failover slot synced to standby from
+#
> >> I think the testing discussion should be moved to a different thread.
> >> What do you think?
> > See v4.
> >
> > 0001 deals with reporting queryId in exec_execute_message and
> > exec_bind_message.
> > 0002 deals with reporting queryId after a cache invalidation.
> >
> > There are no tests
On Mon, Sep 09, 2024 at 03:56:14PM +0900, Michael Paquier wrote:
> How about inventing a new ATT_PARTITIONED_TABLE and make a clean split
> between both relkinds? I'd guess that blocking both SET LOGGED and
> UNLOGGED for partitioned tables is the best move, even if it is
> possible to block only
Sorry for taking so long to respond. I was at my day-job.
As I mentioned, I am the maintainer of the PL/Haskell language extension.
This extension allows users to write code in the Haskell language. In order
to use numeric types, I will need to create a Haskell type equivalent.
Something like
dat
On Mon, Sep 09, 2024 at 05:45:13PM +0900, Yugo NAGATA wrote:
> I mean to remove emode from XLogFileRead, too, but this fix is accidentally
> missed in the previous patch. I attached the updated patch.
This is neat because we don't need to guess how XLogFileRead() should
fail on PANIC, allow things
Masahiko Sawada writes:
> When do we set the byte on the primary server? If it's the first time
> to use the GIN index, secondary servers would have to wait for the
> primary to use the GIN index, which could be an unpredictable time or
> it may never come depending on index usages. Probably we ca
On Fri, Sep 6, 2024 at 3:36 PM Tom Lane wrote:
>
> Noah Misch writes:
> > Yes, that's one way to make it work. If we do it that way, it would be
> > critical to make the ALTER EXTENSION UPDATE run before anything uses the
> > index. Otherwise, we'll run new v18 "signed char" code on a v17 "unsi
Sorry for the late reply on this thread.
On 14/8/2024 23:05, Imseih (AWS), Sami wrote:
> There are no tests as this requires more discussion in a separate thread(?)
> Unfortunately, TAP tests don't allow us to keep a connection and
> manually permutate the order of queries sent to different conne
On Tue, Sep 10, 2024, 00:52 Jelte Fennema-Nio wrote:
> On Mon, Sep 9, 2024, 22:02 Robert Haas wrote:
>
>> Should I #blamemagnus?
>>
>
> Yes. He seems unavailable for whatever reason based on my private holidays
> (maybe summer holidays)
>
*based on my private/off-list communication with him
>
On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
> Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck on
> that level for some time, but 1.1.0 is gone from production use.
The cleanup induced by the removal of 1.1.0 is minimal. I'm on board
about your ar
On Mon, Sep 9, 2024, 22:02 Robert Haas wrote:
> Should I #blamemagnus?
>
Yes. He seems unavailable for whatever reason based on my private holidays
(maybe summer holidays)
>
On Mon, Sep 09, 2024 at 11:24:28AM -0400, Robert Haas wrote:
> That's interesting, but it sort of seems like it's reinventing the
> wheel, vs. the one-line change that I proposed.
Probably. I'll try to look at all that this week (with some automated
tests!).
--
Michael
signature.asc
Description
On Tue, Sep 10, 2024 at 3:36 AM Michael Banck wrote:
> I am a bit confused about the status of this thread. Robert mentioned
> RC1, so I guess it pertains to v17 but I don't see it on the open item
> wiki list?
Yes, v17. Alight, I'll add an item.
> Does the above mean you are going to revert it
On Tue, 10 Sept 2024 at 09:39, Shayon Mukherjee wrote:
> Adding and removing indexes is a common operation in PostgreSQL. On larger
> databases, however, these operations can be resource-intensive. When
> evaluating the performance impact of one or more indexes, dropping them might
> not be ide
Hello hackers,
This is my first time posting here, and I’d like to propose a new feature
related to PostgreSQL indexes. If this idea resonates, I’d be happy to
follow up with a patch as well.
*Problem*:
Adding and removing indexes is a common operation in PostgreSQL. On larger
databases, however,
On Mon, Sep 09, 2024 at 06:25:07PM +0300, Nazir Bilal Yavuz wrote:
> On Thu, 5 Sept 2024 at 18:54, Noah Misch wrote:
> > On Thu, Sep 05, 2024 at 03:59:53PM +0300, Nazir Bilal Yavuz wrote:
> > > On Wed, 4 Sept 2024 at 21:43, Noah Misch wrote:
> > > > https://postgr.es/m/caeudqaozv3wty5tv2t29jcwpyd
> On 9 Sep 2024, at 16:48, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
>> for configuring cipher suites in TLS 1.3 handshakes require an API available
>> in
>> OpenSSL 1.1.1 and onwards. With that as motivation
> On 9 Sep 2024, at 20:41, Jacob Champion
> wrote:
>
> On Mon, Sep 9, 2024 at 11:30 AM Daniel Gustafsson wrote:
>> Just to make sure I understand, this is for guarding against overreads in
>> validation of strings containing torn MB characters?
>
> Right. Our SASLprep code doesn't require/enfo
On Mon, Sep 9, 2024 at 2:38 AM Shubham Khanna
wrote:
>
> On Thu, Aug 29, 2024 at 11:46 AM Amit Kapila wrote:
> >
> > On Thu, Aug 29, 2024 at 8:44 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Aug 28, 2024 at 1:06 AM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, May 20, 2024 at 1:49 PM
> On 9 Sep 2024, at 21:17, Nathan Bossart wrote:
>
> On Thu, Sep 05, 2024 at 01:32:34PM +0200, Daniel Gustafsson wrote:
>> I've read and tested through the latest version of this patchset and I think
>> it's ready to go in.
>
> Thanks for reviewing. I'm aiming to commit it later this week.
+1.
On Wed, 2024-03-06 at 14:32 +0100, Laurenz Albe wrote:
> On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> > On 11/6/23 14:23, Laurenz Albe wrote:
> > > This behavior looks buggy to me. What do you think?
> > > I cannot imagine that it is a security problem, though.
> >
> > How could code
On Sat, Sep 7, 2024 at 11:27 AM Tomas Vondra wrote:
> I started looking at this patch today.
Thanks for taking a look!
> The first thing I usually do for
> new patches is a stress test, so I did a simple script that generates
> random table and runs a random query with IN() clause with various
>
On Mon, Aug 26, 2024 at 9:39 PM Thomas Munro wrote:
> I've built a system for pushing all the data required to show the
> cfbot traffic lights over to the CF app, and shared it with Magnus to
> see if he likes it. If so, hopefully some more progress soon...
I don't see any traffic lights on comm
I would rather that you didn't add simple_ptr_list_destroy_deep()
given that you don't need it for this patch series.
+
"\"%s\" unexpected file in the tar format backup",
This doesn't seem grammatical to me. Perhaps change this to: file
\"%s\" is not expected in a tar format backup
+ /* We
On 2024-09-09 Mo 1:19 PM, Robert Haas wrote:
On Mon, Sep 9, 2024 at 1:03 PM Andrew Dunstan wrote:
I guess I could try to write code to migrate everything, but it would be
somewhat fragile. And what would we do if we ever decided to migrate
"master" to another name like "main"? I do at least h
On Tue, Sep 10, 2024 at 02:45:37AM +0900, Fujii Masao wrote:
> On 2024/09/10 1:02, Robert Haas wrote:
>> On Mon, Sep 9, 2024 at 10:37 AM Fujii Masao
>> wrote:
>> > In v8.2, the RULE privilege for tables was removed, but for backward
>> > compatibility,
>> > GRANT/REVOKE RULE, has_table_privilege
So, there was limited enthusiasm for a new message here, but I noticed
that current CF messages don't include the CF entry link [1]. What
about adding a link to its existing e-mails?
Thanks,
Maciek
[1]: e.g.,
https://www.postgresql.org/message-id/172579582925.1126.2395496302629349708.pgcf%40cori
On Thu, Sep 05, 2024 at 01:32:34PM +0200, Daniel Gustafsson wrote:
> I've read and tested through the latest version of this patchset and I think
> it's ready to go in.
Thanks for reviewing. I'm aiming to commit it later this week.
> The one concern I have is that tasks can exit(1) on libpq
> er
On Mon, Sep 9, 2024 at 2:02 PM Tom Lane wrote:
> By that argument, we should move every declaration in every .c file
> into c.h and be done. I'd personally be happier if we had *not*
> exposed the other data structure details you mention, but that
> ship has sailed.
Not every declaration in ever
Hi,
On Mon, Sep 9, 2024 at 3:04 PM Amit Kapila wrote:
>
> > > > > We should not allow the invalid replication slot to be altered
> > > > > irrespective of the reason unless there is any benefit.
> > > >
> > > > Okay, then I think we need to change the existing behaviour of the
> > > > other inval
On Mon, Sep 9, 2024 at 11:30 AM Daniel Gustafsson wrote:
> Just to make sure I understand, this is for guarding against overreads in
> validation of strings containing torn MB characters?
Right. Our SASLprep code doesn't require/enforce UTF8-encoded inputs.
> Assuming I didn't
> misunderstand yo
Hi,
ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary
as there is no way to get the invalidated (logical) slot to work.
Please find the patch to add an error in such cases. Relevant
discussion is at [1].
Thoughts?
[1]
https://www.postgresql.org/message-id/CAA4eK1%2Bszcosq0n
=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= writes:
> v4 patch attached.
LGTM, pushed.
regards, tom lane
> On 9 Sep 2024, at 17:29, Jacob Champion
> wrote:
> pg_utf8_string_len() doesn't check the remaining string length before
> calling pg_utf8_is_legal(), so there's a possibility of jumping a
> couple of bytes past the end of the string. (The overread stops there,
> because the function won't val
On 09/09/24 13:00, Robert Haas wrote:
> I don't agree with this reponse at all. It seems entirely reasonable
> for third-party code to want to have a way to construct and interpret
> numeric datums. Keeping the details private would MAYBE make sense if
> the internal details were changing release t
Robert Haas writes:
> On Mon, Sep 9, 2024 at 1:25 PM Tom Lane wrote:
>> IMO it'd be a lot better if numeric.c exposed whatever functionality
>> Ed feels is missing, while keeping the contents of a numeric opaque.
> We could certainly expose a bunch of functions, but I think that would
> actually
On Mon, Sep 9, 2024 at 1:25 PM Tom Lane wrote:
> We have changed numeric's internal representation in the past, and
> I'd like to keep the freedom to do so again. There's been discussion
> for example of reconsidering the choice of NBASE to make more sense
> on 64-bit hardware. Yeah, maintaining
Peter Eisentraut writes:
> On 06.09.24 21:43, Tom Lane wrote:
>> * I don't really like the new control structure, or rather lack of
>> structure, in hashvalidate. In particular the uncommented
>> s/break/continue/ changes look like typos. They aren't, but can't
>> you do this in a less confusing
On 2024/09/10 1:02, Robert Haas wrote:
On Mon, Sep 9, 2024 at 10:37 AM Fujii Masao wrote:
In v8.2, the RULE privilege for tables was removed, but for backward
compatibility,
GRANT/REVOKE RULE, has_table_privilege(..., 'RULE') etc are still accepted,
though they don't perform any actions.
Do
Robert Haas writes:
> On Mon, Sep 9, 2024 at 10:14 AM Tom Lane wrote:
>> It's intentional that that stuff is not exposed, so no.
>> What actual functionality do you need that numeric.h doesn't expose?
> I don't agree with this reponse at all. It seems entirely reasonable
> for third-party code t
On Mon, Sep 9, 2024 at 1:03 PM Andrew Dunstan wrote:
> I guess I could try to write code to migrate everything, but it would be
> somewhat fragile. And what would we do if we ever decided to migrate
> "master" to another name like "main"? I do at least have code ready for
> that eventuality, but i
On 2024-09-08 Su 11:35 PM, Tom Lane wrote:
David Rowley writes:
I think HEAD is commonly misused to mean master instead of the latest
commit of the current branch. I see the buildfarm even does that.
Thanks for getting that right in your blog post.
IIRC, HEAD *was* the technically correct te
On Mon, Sep 9, 2024 at 10:14 AM Tom Lane wrote:
> Ed Behn writes:
> > I want to be able to have a function received and/or return numeric data.
> > However, I'm having trouble getting data from Datums and building Datums to
> > return. numeric.h does not contain the macros to do this. They are in
On Mon, Sep 9, 2024 at 12:20 PM Tom Lane wrote:
> I wrote:
> > I too think it's good to go. If no one complains or asks for
> > more time to review, I will push it Monday or so.
>
> And done.
I didn't see this thread until after the commit had already happened,
but a belated +1 for this and any
I wrote:
> I too think it's good to go. If no one complains or asks for
> more time to review, I will push it Monday or so.
And done.
regards, tom lane
On Mon, Sep 9, 2024 at 10:37 AM Fujii Masao wrote:
> In v8.2, the RULE privilege for tables was removed, but for backward
> compatibility,
> GRANT/REVOKE RULE, has_table_privilege(..., 'RULE') etc are still accepted,
> though they don't perform any actions.
>
> Do we still need to maintain this b
On Fri, Aug 16, 2024 at 11:29 AM Robert Haas wrote:
> > I'll split this patch like that, to make it easier to compare and merge
> > with Jelte's corresponding patches.
>
> That sounds great. IMHO, comparing and merging the patches is the next
> step here and would be great to see.
Heikki, do you
On Mon, Aug 26, 2024 at 8:40 AM Robert Haas wrote:
> On Fri, Aug 23, 2024 at 3:40 PM Jacob Champion
> wrote:
> > Agreed on the name. I've attached a reconfigured version of v15-0003,
> > with an extension that should hopefully not throw off the cfbot, and a
> > commit message that should hopefull
Hi,
On Thu, Sep 05, 2024 at 09:12:07PM +1200, Thomas Munro wrote:
> On Thu, Sep 5, 2024 at 6:45 PM Mats Kindahl wrote:
> > Making the ReadStream API non-opaque (that is, moving the definition
> > to the header file) would at least solve our problem (unless I am
> > mistaken). However, I am ignora
Hi all,
pg_utf8_string_len() doesn't check the remaining string length before
calling pg_utf8_is_legal(), so there's a possibility of jumping a
couple of bytes past the end of the string. (The overread stops there,
because the function won't validate a sequence containing a null
byte.)
Here's a q
On Mon, Sep 9, 2024 at 12:09 AM Richard Guo wrote:
> Fixed.
Thanks to Alexander for the very good catch and to Richard for pushing the fix.
(I started to respond to this last week but didn't quite get to it
before I ran out of time/energy.)
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
On Thu, 5 Sept 2024 at 18:54, Noah Misch wrote:
>
> On Thu, Sep 05, 2024 at 03:59:53PM +0300, Nazir Bilal Yavuz wrote:
> > On Wed, 4 Sept 2024 at 21:43, Noah Misch wrote:
> > > https://postgr.es/m/caeudqaozv3wty5tv2t29jcwpydbmkbiwqkzd42s2ogzdixp...@mail.gmail.com
> > > then observed that col
On Wed, Aug 28, 2024 at 6:48 PM Michael Paquier wrote:
> This is being discussed already on a different thread:
> - Thread:
> https://www.postgresql.org/message-id/ca+427g8diw3az6popvgkpbqk97oubdf18vlihfesea2juk3...@mail.gmail.com
> - CF entry: https://commitfest.postgresql.org/49/4963/
>
> There
Daniel Gustafsson writes:
> The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
> for configuring cipher suites in TLS 1.3 handshakes require an API available
> in
> OpenSSL 1.1.1 and onwards. With that as motivation I'd like to propose that
> we
> remove support for O
Hi,
In v8.2, the RULE privilege for tables was removed, but for backward
compatibility,
GRANT/REVOKE RULE, has_table_privilege(..., 'RULE') etc are still accepted,
though they don't perform any actions.
Do we still need to maintain this backward compatibility?
Could we consider removing the RUL
Hi there
On 26.08.24 02:00, jian he wrote:
> hi all.
> patch updated.
> simplified the code a lot.
>
> idea is same:
> COPY t_on_error_null FROM STDIN WITH (on_error set_to_null);
>
> If the STDIN number of columns is the same as the target table, then
> InputFunctionCallSafe
> call failure will
Ed Behn writes:
> I want to be able to have a function received and/or return numeric data.
> However, I'm having trouble getting data from Datums and building Datums to
> return. numeric.h does not contain the macros to do this. They are in
> numeric.c.
> Is there a way to access the values in t
On 2024/07/02 16:34, Yugo NAGATA wrote:
So, I would like to propose to add
has_large_object_function for checking if a user has the privilege on a large
object.
+1
BTW since we already have pg_largeobject, using has_largeobject_privilege might
offer better consistency. However, I'm okay wit
On 9/7/24 22:45, Tom Lane wrote:
I wrote:
Now alternatively you could argue that a "new" page isn't usable free
space yet and so we should count it as zero, just as we don't count
dead tuples as usable free space. You need VACUUM to turn either of
those things into real free space. But that'
Hi Tom, thanks for your review.
On 9/7/24 22:10, Tom Lane wrote:
I looked at this patch. I agree with making the change. However,
I don't agree with the CF entry's marking of "target version: stable"
(i.e., requesting back-patch). I think this falls somewhere in the
gray area between a bug fi
On 08.08.24 22:00, Jeff Davis wrote:
On Wed, 2024-08-07 at 22:44 +0200, Peter Eisentraut wrote:
But after this patch set, locale cannot be NULL anymore, so the third
branch is obsolete.
...
Second, there are a number of functions in like.c like the above that
take separate arguments like pg_
Hi Hunaid
On 02.08.24 14:11, Hunaid Sohail wrote:
>
> I have also edited the documentation and added it to the patch. Please
> let me know if any changes are required.
>
I just wanted to review this patch again but v30 does not apply
=== Applying patches on top of PostgreSQL commit ID
d8df7ac5c
po 9. 9. 2024 v 13:57 odesílatel Daniel Gustafsson napsal:
> > On 9 Sep 2024, at 13:45, Pavel Stehule wrote:
>
> > echo 'Libs.private: -L/usr/lib64 -lpgcommon -lpgport -lssl -lm'
> >>libpq.pc
> > fe-secure-openssl.c:62:10: fatal error: openssl/engine.h: Adresář nebo
> soubor neexistuje
> >62
po 9. 9. 2024 v 13:58 odesílatel Herbert J. Skuhra
napsal:
> On Mon, 09 Sep 2024 13:45:50 +0200, Pavel Stehule wrote:
> >
> > Hi
> >
> > I try new Fedora 41. Build fails
> >
> > echo 'Name: libpq' >>libpq.pc
> > echo 'Description: PostgreSQL libpq library' >>libpq.pc
> > echo 'URL: https://www.po
Em sáb., 7 de set. de 2024 às 17:18, Tom Lane escreveu
Functions that are primarily meant to implement operators are normally not
documented separately: we feel it would bloat the
docs without adding a lot
Those two functions, elem_contained_by_range and pg_relation_is_updatable
were only example
On 06.09.24 21:43, Tom Lane wrote:
Peter Eisentraut writes:
hashvalidate(), which validates the signatures of support functions for
the hash AM, contains several hardcoded exceptions.
...
This patch removes those exceptions by providing new support functions
that have the proper declared signat
Hi,
On Sun, Sep 8, 2024 at 4:09 AM Tom Lane wrote:
> A few notes from a quick read of the patch:
>
> * roman_to_int() should have a header comment, notably explaining its
> result convention. I find it fairly surprising that "0" means an
> error --- I realize that Roman notation can't represent
Commit a70e01d430 removed support for OpenSSL 1.0.2 in order to simplify the
code by removing the need for finicky initialization of the library. Based on
our API usage the new minimum version was defined as 1.1.0.
The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
for
> On 22 Jul 2024, at 19:14, Jacob Champion
> wrote:
>
> On Fri, Jul 12, 2024 at 1:03 PM Daniel Gustafsson wrote:
>> The original author added the string parsing in order to provide a good error
>> message in case of an error in the list, and since that seemed like a nice
>> idea
>> I kept in m
I'm the maintainer of the PL/Haskell language extension. (
https://github.com/ed-o-saurus/PLHaskell/)
I want to be able to have a function received and/or return numeric data.
However, I'm having trouble getting data from Datums and building Datums to
return. numeric.h does not contain the macros
On Mon, 09 Sep 2024 13:45:50 +0200, Pavel Stehule wrote:
>
> Hi
>
> I try new Fedora 41. Build fails
>
> echo 'Name: libpq' >>libpq.pc
> echo 'Description: PostgreSQL libpq library' >>libpq.pc
> echo 'URL: https://www.postgresql.org/' >>libpq.pc
> echo 'Version: 18devel' >>libpq.pc
> echo 'Requi
> On 9 Sep 2024, at 13:45, Pavel Stehule wrote:
> echo 'Libs.private: -L/usr/lib64 -lpgcommon -lpgport -lssl -lm' >>libpq.pc
> fe-secure-openssl.c:62:10: fatal error: openssl/engine.h: Adresář nebo soubor
> neexistuje
>62 | #include
> | ^~
> compilation termin
Hi
I try new Fedora 41. Build fails
echo 'Name: libpq' >>libpq.pc
echo 'Description: PostgreSQL libpq library' >>libpq.pc
echo 'URL: https://www.postgresql.org/' >>libpq.pc
echo 'Version: 18devel' >>libpq.pc
echo 'Requires: ' >>libpq.pc
echo 'Requires.private: libssl, libcrypto' >>libpq.pc
echo '
On Fri, Aug 30, 2024 at 5:18 PM Bertrand Drouvot
wrote:
>
> On Fri, Aug 30, 2024 at 03:43:12PM +0530, Amit Kapila wrote:
> > On Thu, Aug 29, 2024 at 6:33 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Thu, Aug 29, 2024 at 3:44 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > Yeah that's fair. An
Hi everyone,
I've taken a closer look at the patch and realized that we don't need
the new function 'mcv_clause_selectivity_var_op_var()' we can use
'mcv_clause_selectivity()' instead.
I'm attaching the updated patch and test generator.
--
Regards,
Ilia Evdokimov,
Tantor Labs LCC.
#!/usr/bin
On Wed, Sep 4, 2024 at 6:42 PM Alena Rybakina wrote:
> On 04.09.2024 18:31, Alena Rybakina wrote:
> > I rewrote the tests with integer types. Thanks for your suggestion. If
> > you don't mind, I've updated the diff file you attached earlier to
> > include the tests.
> Sorry, I've just noticed that
Hi,
On 9/9/24 11:39, Richard Guo wrote:
> While looking at label_sort_with_costsize() due to another issue, I
> noticed that we build explicit Sort nodes but not explicit Incremental
> Sort nodes. I wonder why this is the case. It seems to me that
> Incremental Sorts are preferable in some cases
On Fri, Jul 12, 2024 at 10:42 AM Ashutosh Bapat
wrote:
>
> I have merged the two patches now.
>
894be11adfa60ad1ce5f74534cf5f04e66d51c30 changed the schema in which
objects in test genereated_stored.sql are created. Because of this the
new test added by the patch was failing. Fixed the failure in
1 - 100 of 112 matches
Mail list logo
