Hi,
AFAICT this v2-0001 patch differences from v1 is mostly about adding
the new CREATE SUBSCRIPTION option. Specifically, I don't think it is
addressing any of my previous review comments for patch v1. [1]. So
these comments below are limited only to the new option code; All my
previous review co
On 5/20/24 16:40, Andrei Lepikhov wrote:
On 20/5/2024 15:52, Andy Fan wrote:
+ if (clauselist_selectivity_hook)
+ *return* clauselist_selectivity_hook(root, clauses, ..)
Of course - library may estimate not all the clauses - it is a reason,
why I added input/output parameter 'estimate
Hi
>
> Another question: Do you use pg_repack or such?
>
pg_repack was used for some tables, but I found broken tables, where
pg_repack was not used.
Regards
Pavel
>
> Greetings,
>
> Andres Freund
>
On 19.05.24 00:09, Andres Freund wrote:
On 2024-05-18 00:35:08 +0200, Peter Eisentraut wrote:
I retested the patch from 2024-04-07 (I think that's the one that "fixed
that"? There are multiple "v1" patches in this thread.) using gcc-14 and
clang-18, with ccache disabled of course. The measured
On Tue, May 21, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> I reviewed my collection of unica I gathered for several months, but had
> found some of them too minor/requiring more analysis.
> Then I added more with perlcritic's policy UnusedVariables, and also
> checked for unused subs with
On Tue, May 21, 2024 at 2:56 PM Kyotaro Horiguchi
wrote:
>
> I noticed that there are slightly inconsistent messages regarding
> quoting policies.
>
> > This happens if you temporarily set "wal_level=minimal" on the server.
> > WAL generated with "full_page_writes=off" was replayed during online b
I noticed that there are slightly inconsistent messages regarding
quoting policies.
> This happens if you temporarily set "wal_level=minimal" on the server.
> WAL generated with "full_page_writes=off" was replayed during online backup
> pg_log_standby_snapshot() can only be used if "wal_level" >
On Mon, May 20, 2024 at 12:20:02PM +0300, Aleksander Alekseev wrote:
> Robert Haas writes:
>> I agree that it's not necessary or particularly useful for this hint
>> to be exhaustive. I could get behind your suggestion of
>> s/You must specify/Specify/, but I also think it's fine to do nothing.
>
On Monday, May 20, 2024, jian he wrote:
> hi.
>
> https://www.postgresql.org/docs/current/functions-
> matching.html#FUNCTIONS-POSIX-REGEXP
>
>
> If there is a match,
> the source string is returned with the replacement string substituted
> for the matching substring.
>
This happens regardless
hi.
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
<<
Hello Dagfinn,
Thank you for paying attention to it and improving the possible fix!
20.05.2024 23:39, Dagfinn Ilmari Mannsåker wrote:
Nice cleanup! Did you use some static analysis tool, or did look for
them manually?
I reviewed my collection of unica I gathered for several months, but had
f
Earlier today in [1], a bug was reported regarding a problem with the
code added in 66c0185a3 where I'd failed to handle the case correctly
where the UNION's targetlist has columns which are not sortable. For
pg_class, that's relfrozenxid, relminmxid and relacl.
The most minimal reproducer prior
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c23ddbe1dac8b9a79db31ad67df423848e475905 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2023 14:28:53 -0800
Subject: [PATCH v23 1/5] introduce routine for checking mutually exclusive
string GUCs
---
s
On Thu, May 9, 2024 at 1:04 PM Bruce Momjian wrote:
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
>
> It will be improved until the final release. The item count is 188,
> which is similar
On Mon, May 20, 2024 at 05:01:15PM +0500, Andrey M. Borodin wrote:
> Both features look useful to me.
> I've tried to rebase my test of CV sleep during multixact generation[0]. I
> used it like this:
>
> INJECTION_POINT_PRELOAD("GetNewMultiXactId-done");
> multi = GetNewMultiXactId(nmembe
On 5/21/24 03:09, Robert Haas wrote:
On Fri, May 17, 2024 at 6:14 PM David Steele wrote:
Then intentionally corrupt a file in the incr backup:
$ truncate -s 0 test/backup/incr1/base/5/3764_fsm
In this case pg_verifybackup will error:
$ pg_verifybackup test/backup/incr1
pg_verifybackup: error
On Tue, May 21, 2024 at 9:11 AM Melanie Plageman
wrote:
> So, if you are seeing the slow-down mostly go away by reducing
> blocknums array size, does the regression only appear when the scan
> data is fully in shared buffers? Or is this blocknums other use
> (dealing with short reads)?
That must
On Sun, May 19, 2024 at 10:50 PM Thomas Munro wrote:
> Sometimes I question the sanity of the whole thing. Considering
> cfbot's original "zero-effort CI" goal (or I guess "zero-extra-effort"
> would be better), I was curious about what other projects had the same
> idea, or whether we're really
Andrew Dunstan writes:
> Attached is an attempt to thread this needle. The core is a new perl
> module that imports the current buildfarm client logic. The intention is
> that once we have this, the buildfarm client will switch to using the
> module (if found) rather than its own built-in logic
Many years ago we in effect moved maintenance of the typedefs list for
pgindent into the buildfarm client. The reason was that there were a
number of typedefs that were platform dependent, so we wanted to have
coverage across a number of platforms to get a comprehensive list.
Lately, this has
Thank you to all of you for looking into this.
On Sat, May 18, 2024 at 12:47 AM Thomas Munro wrote:
>
> On Sat, May 18, 2024 at 11:30 AM Thomas Munro wrote:
> > Andres happened to have TPC-DS handy, and reproduced that regression
> > in q15. We tried some stuff and figured out that it requires
Hi everyone!
I would like to share another perspective on this as a relatively new user
of the commitfest app. I really like the concept behind the commitfest app
but while using it, sometimes I feel that we can do a better job at having
some sort of a 'metainfo' for the patch.
Although in some ca
On Wed, May 15, 2024 at 2:18 PM Nazir Bilal Yavuz wrote:
>
> On Mon, 29 Apr 2024 at 18:41, Nazir Bilal Yavuz wrote:
> >
> > On Mon, 8 Apr 2024 at 04:21, Thomas Munro wrote:
> > I wanted to discuss what will happen to this patch now that
> > 27bc1772fc8 is reverted. I am continuing this thread bu
Alexander Lakhin writes:
> Hello hackers,
>
> Please look at a bunch of unused variables and a couple of other defects
> I found in the perl code, maybe you'll find them worth fixing:
Nice cleanup! Did you use some static analysis tool, or did look for
them manually? If I add [Variables::Prohi
On Mon, May 20, 2024 at 9:09 PM Andrey M. Borodin
wrote:
>
>
>
> > On 20 May 2024, at 23:37, Robert Haas wrote:
> >
> > But, does this mean that we should just refuse to offer compression as
> > a feature?
>
> No, absolutely, we need the feature.
>
> > I guess I don't understand why TLS removed
On Mon, May 20, 2024 at 11:37 AM Robert Haas wrote:
> But if that's a practical
> attack, preventing compression prior to the authentication exchange
> probably isn't good enough
I mean... you said it, not me. I'm trying not to rain on the parade
too much, because compression is clearly very valu
On Mon, May 20, 2024 at 11:05 AM Andrey M. Borodin wrote:
> > So, the data would be compressed first, with framing around that, and
> > then transport encryption would happen afterwards. I don't see how
> > that would leak your password, but I have a feeling that might be a
> > sign that I'm about
> On 20 May 2024, at 23:37, Robert Haas wrote:
>
> But if that's a practical
> attack, preventing compression prior to the authentication exchange
> probably isn't good enough: the user could also try to guess what
> queries are being sent on behalf of other users through the same
> pooled c
On Sat, 2024-05-18 at 17:51 -0400, Bruce Momjian wrote:
> Okay, I went with the attached applied patch. Adjustments?
I think it should have more emphasis on the actual new feature: a
platform-independent builtin collation provider and the C.UTF-8 locale.
The user can look at the documentation fo
On Mon, May 20, 2024 at 9:37 AM Bruce Momjian wrote:
>
> On Mon, May 20, 2024 at 01:23:02PM +0700, John Naylor wrote:
> > Hi Bruce, thanks for doing this again!
> >
> > I'm a bit late to this discussion -- there's been a bit of churn in
> > the vacuum items, and some streams got crossed along the
On Mon, May 20, 2024 at 02:35:37PM -0400, Melanie Plageman wrote:
> On Sat, May 18, 2024 at 11:13 AM Bruce Momjian wrote:
> > Please see the email I just posted. There are three goals we have to
> > adjust for:
> >
> > 1. short release notes so they are readable
> > 2. giving people credit for
On Mon, May 20, 2024 at 2:05 PM Andrey M. Borodin wrote:
> Compression defeats encryption. That's why it's not in TLS anymore.
> The thing is compression codecs use data self correlation. And if you mix
> secret data with user's data, user might guess how correlated they are.
Yeah, I'm aware tha
On Sat, May 18, 2024 at 11:13 AM Bruce Momjian wrote:
>
> On Thu, May 16, 2024 at 09:09:11AM -0400, Melanie Plageman wrote:
> > On Wed, May 15, 2024 at 11:48 PM Andres Freund wrote:
> > >
> > > On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote:
> > > > I disagree with this. IMO the impact of th
> On 20 May 2024, at 22:48, Robert Haas wrote:
>
> On Mon, May 20, 2024 at 1:23 PM Jacob Champion
> wrote:
>> On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
>>> I really hope that you can't poke big enough holes to kill the feature
>>> entirely, though. Because that sounds sad.
>>
>> E
On Mon, May 20, 2024 at 1:23 PM Jacob Champion
wrote:
> On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
> > I really hope that you can't poke big enough holes to kill the feature
> > entirely, though. Because that sounds sad.
>
> Even if there are holes, I don't think the situation's going to
On Tue, Apr 23, 2024 at 1:27 PM Robert Haas wrote:
> Just a quick update. We have so far had 8 suggested patches from 6
> people, if I haven't missed anything. I'm fairly certain that not all
> of those patches are going to be good candidates for this session, so
> it would be great if a few more
On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
> I really hope that you can't poke big enough holes to kill the feature
> entirely, though. Because that sounds sad.
Even if there are holes, I don't think the situation's going to be bad
enough to tank everything; otherwise no one would be abl
On Fri, May 17, 2024 at 10:11 PM Michael Paquier wrote:
> On Fri, May 17, 2024 at 03:53:58PM -0400, Robert Haas wrote:
> > The usual pattern for using hooks like this is to call the next
> > implementation, or the standard implementation, and pass down the
> > arguments that you got. If you try to
On Fri, May 17, 2024 at 6:14 PM David Steele wrote:
> Then intentionally corrupt a file in the incr backup:
>
> $ truncate -s 0 test/backup/incr1/base/5/3764_fsm
>
> In this case pg_verifybackup will error:
>
> $ pg_verifybackup test/backup/incr1
> pg_verifybackup: error: "base/5/3764_fsm" has siz
On Mon, May 20, 2024 at 12:49 PM Jacob Champion
wrote:
> ...and my response was that, no, the proposal doesn't seem to be
> requiring that authentication take place before compression is done.
> (As evidenced by your email. :D) If the claim is that there are no
> security problems with letting una
Hello hackers,
Please look at a bunch of unused variables and a couple of other defects
I found in the perl code, maybe you'll find them worth fixing:
contrib/amcheck/t/001_verify_heapam.pl
$result # unused since introduction in 866e24d47
unused sub:
get_toast_for # not used since 860593ec3
cont
On Mon, May 20, 2024 at 8:29 AM Robert Haas wrote:
> It does occur to me that if some compression algorithm has a buffer
> overrun bug, restricting its use until after authentication might
> reduce the score of the resulting CVE, because now you have to be able
> to authenticate to make an exploit
On 5/20/24 6:32 AM, David Rowley wrote:
On Mon, 20 May 2024 at 22:11, Alvaro Herrera wrote:
On 2024-May-16, David Rowley wrote:
On Thu, 16 May 2024 at 17:37, zaidagilist wrote:
I am trying to open the 17 docs but it looks removed. Getting
following message "Page not found"
https://www.pos
On 5/20/24 8:31 AM, jian he wrote:
release note (https://momjian.us/pgsql_docs/release-17.html)
is
"Add jsonpath methods to convert JSON values to other JSON data types
(Jeevan Chalke)"
Additionally, PostgreSQL 17 adds more functionality to its `jsonpath`
implementation, including the abilit
Tomas Vondra writes:
> On 5/20/24 16:37, Sushrut Shivaswamy wrote:
>> When trying to read the query response from the Datum, I get garbage values.
>> I've tried various types and none of them read the correct value.
> TimestampTz is int64, so using DatumGetInt64 is probably the simplest
> solutio
On 05/20/24 11:39, Tomas Vondra wrote:
> On 5/20/24 16:37, Sushrut Shivaswamy wrote:
>> I've tried various types and none of them read the correct value.
>> ```
>> ...
>> double current_time = DatumGetFloat8(current_timestamp); // prints 0
>>
>> int64 time = DatumGetUint64(current_timestamp); // pr
Yasir wrote on 19.05.2024 00:03:
I would also like to thank Robert for presenting the matter in detail.
My function date_trunc ( interval, timestamp, ...) is similar to
original function date_trunc ( text, timestamp ...) .
My extension only gives more granularity.
We don't
On Fri, 17 May 2024 at 15:02, Peter Eisentraut wrote:
>
> On 17.05.24 09:32, Heikki Linnakangas wrote:
> > Dunno about having to click a link or sparkly gold borders, but +1 on
> > having a free-form text box for notes like that. Things like "cfbot says
> > this has bitrotted" or "Will review this
On Mon, May 20, 2024 at 11:37 AM Andres Freund wrote:
> On 2024-05-20 09:37:46 -0400, Robert Haas wrote:
> > On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> > > A few tests with ccache disabled:
> >
> > These tests seem to show no difference between the two releases, so I
> > wonder what y
On 2024-05-20 Mo 06:58, Dave Page wrote:
Hi
I'm working on updating the build of PostgreSQL that pgAdmin uses in
its Windows installers to use Meson ready for the v17 release. I'm
using Visual Studio 2022, on Windows Server 2022.
I've been unable to persuade Meson to detect zlib, whilst Ope
On 5/20/24 16:37, Sushrut Shivaswamy wrote:
> Hey,
>
> I'm trying to read a timestamp column as EPOCH.
> My query is as follows.
> ```
> SELECT EXTRACT(EPOCH FROM timestamp_column) FROM table;
>
> column
> --
>
> 1716213097.86486
> ```
> When running in the console this query gives valid
On 2024-05-20 09:37:46 -0400, Robert Haas wrote:
> On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> > A few tests with ccache disabled:
>
> These tests seem to show no difference between the two releases, so I
> wonder what you're intending to demonstrate here.
They show a few seconds of w
On Mon, May 20, 2024 at 10:15 AM Jacob Champion
wrote:
> This is just restating the "you can already do bad things" argument. I
> understand that if your query gets executed, it's going to consume
> resources on the thing that's executing it (for the record, though,
> there are people working on c
On Sat, May 18, 2024 at 1:18 AM Jacob Burroughs
wrote:
> I like this more than what I proposed, and will update the patches to
> reflect this proposal. (I've gotten them locally back into a state of
> applying cleanly and dealing with the changes needed to support direct
> SSL connections, so refa
Hi,
Andy Fan asked me off-list for some feedback about this proposal. I
have hesitated to comment on it for lack of having studied the matter
in any detail, but since I've been asked for my input, here goes:
I agree that there's a problem here, but I suspect this is not the
right way to solve it.
Hey,
I'm trying to read a timestamp column as EPOCH.
My query is as follows.
```
SELECT EXTRACT(EPOCH FROM timestamp_column) FROM table;
column
--
1716213097.86486
```
When running in the console this query gives valid epoch output which
appears to be of type double.
When trying to read
On Mon, May 20, 2024 at 7:49 AM Alvaro Herrera wrote:
> On 2024-May-19, Tom Lane wrote:
> > (The cfbot tends to discourage this, since as soon as one of the
> > patches is committed it no longer knows how to apply the rest.
> > Can we improve on that tooling somehow?)
>
> I think a necessary next
On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > How do we make sure this time it will be different?
>
> Things *have* changed, if you take the long view.
That's true, but I think Dmitry's point is well-taken all the same: we
haven't really made
On Fri, May 17, 2024 at 4:03 PM Jelte Fennema-Nio wrote:
>
> On Fri, 17 May 2024 at 23:10, Jacob Champion
> wrote:
> > We're talking about a transport-level option, though -- I thought the
> > proposal enabled compression before authentication completed? Or has
> > that changed?
>
> I think it wo
On 2024-05-20 05:02 +0200, Tom Lane wrote:
> Erik Wienhold writes:
> > On 2024-05-20 03:26 +0200, jian he wrote:
> >> /* Check parameter number is in range */
> >> if (paramno <= 0 || paramno > MaxAllocSize / sizeof(Oid))
> >> ereport(ERROR, ...
>
> > Yes, it makes sense to show the upper bou
Peter Eisentraut writes:
> This patch converts the compile-time settings
> COPY_PARSE_PLAN_TREES
> WRITE_READ_PARSE_PLAN_TREES
> RAW_EXPRESSION_COVERAGE_TEST
> into run-time parameters
> debug_copy_parse_plan_trees
> debug_write_read_parse_plan_trees
> debug_raw_exp
On Mon, May 20, 2024 at 8:47 PM Jonathan S. Katz wrote:
>
> On 5/20/24 2:58 AM, John Naylor wrote:
> > Hi Jon,
> >
> > Regarding vacuum "has shown up to a 6x improvement in overall time to
> > complete its work" -- I believe I've seen reported numbers close to
> > that only 1) when measuring the i
On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> A few tests with ccache disabled:
These tests seem to show no difference between the two releases, so I
wonder what you're intending to demonstrate here.
Locally, I have ninja 1.11.1. I'm sure Andres will be absolutely
shocked, shocked I say
On Mon, May 20, 2024 at 01:23:02PM +0700, John Naylor wrote:
> Hi Bruce, thanks for doing this again!
>
> I'm a bit late to this discussion -- there's been a bit of churn in
> the vacuum items, and some streams got crossed along the way. I've
> attached an attempt to rectify this.
Agreed, patch a
On Mon, May 20, 2024 at 5:35 AM Jonathan S. Katz wrote:
>
> On 5/15/24 9:45 PM, Jonathan S. Katz wrote:
> > Hi,
> >
> > Attached is a copy of the PostgreSQL 17 Beta 1 release announcement
> > draft. This contains a user-facing summary of some of the features that
> > will be available in the Beta,
On Sun, May 19, 2024 at 9:39 AM David Rowley wrote:
> For #1, the locks taken for SELECT queries are less likely to conflict
> with other locks obtained by PostgreSQL, but at least at the moment if
> someone is getting deadlocks with a DDL type operation, they can
> change their query or DDL scrip
> On 20 May 2024, at 17:01, Andrey M. Borodin wrote:
Ugh, accidentally send without attaching the patch itself. Sorry for the noise.
Best regards, Andrey Borodin.
0001-Add-multixact-CV-sleep.patch
Description: Binary data
Hi!
> On 20 May 2024, at 08:18, Michael Paquier wrote:
Both features look useful to me.
I've tried to rebase my test of CV sleep during multixact generation[0]. I used
it like this:
INJECTION_POINT_PRELOAD("GetNewMultiXactId-done");
multi = GetNewMultiXactId(nmembers, &offset); // star
Hi Thom,
On Thu, May 16, 2024 at 8:50 AM Thom Brown wrote:
> On Mon, 8 Apr 2024 at 10:09, Amit Langote wrote:
>>
>> On Mon, Apr 8, 2024 at 2:02 PM jian he wrote:
>> > On Mon, Apr 8, 2024 at 11:21 AM jian he
>> > wrote:
>> > >
>> > > On Mon, Apr 8, 2024 at 12:34 AM jian he
>> > > wrote:
>> >
On 2024-May-19, Tom Lane wrote:
> (The cfbot tends to discourage this, since as soon as one of the
> patches is committed it no longer knows how to apply the rest.
> Can we improve on that tooling somehow?)
I think a necessary next step to further improve the cfbot is to get it
integrated in pgin
On 5/20/24 2:58 AM, John Naylor wrote:
Hi Jon,
Regarding vacuum "has shown up to a 6x improvement in overall time to
complete its work" -- I believe I've seen reported numbers close to
that only 1) when measuring the index phase in isolation or maybe 2)
the entire vacuum of unlogged tables with
On 5/19/24 7:24 PM, David Rowley wrote:
On Mon, 20 May 2024 at 09:35, Jonathan S. Katz wrote:
Thanks for all the feedback to date. Please see the next revision.
Again, please provide feedback no later than 2024-05-22 18:00 UTC.
Thanks for the updates.
[`COPY`](https://www.postgresql.org/doc
Em seg., 20 de mai. de 2024 às 04:28, Peter Eisentraut
escreveu:
> This patch converts the compile-time settings
>
> COPY_PARSE_PLAN_TREES
> WRITE_READ_PARSE_PLAN_TREES
> RAW_EXPRESSION_COVERAGE_TEST
>
> into run-time parameters
>
> debug_copy_parse_plan_trees
> debug_wri
On Mon, 20 May 2024 at 23:16, Thom Brown wrote:
>
> On Mon, 20 May 2024 at 00:24, David Rowley wrote:
>>
>> On Mon, 20 May 2024 at 09:35, Jonathan S. Katz wrote:
>> > Thanks for all the feedback to date. Please see the next revision.
>> > Again, please provide feedback no later than 2024-05-22 1
On Mon, 20 May 2024 at 00:24, David Rowley wrote:
> On Mon, 20 May 2024 at 09:35, Jonathan S. Katz
> wrote:
> > Thanks for all the feedback to date. Please see the next revision.
> > Again, please provide feedback no later than 2024-05-22 18:00 UTC.
>
> Thanks for the updates.
>
> > [`COPY`](htt
On Fri, May 17, 2024 at 5:25 AM Michael Paquier wrote:
>
> On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote:
> > This can only be a problem if the apply worker generates more LOG
> > entries with the required context but it won't do that unless there is
> > an operation on the publisher
Hi,
>
> I was trying to test this utility when 'sync_replication_slots' is on
> and it gets in an ERROR loop [1] and never finishes. Please find the
> postgresql.auto used on the standby attached. I think if the standby
> has enabled sync_slots, you need to pass dbname in
> GenerateRecoveryConfig()
On Tue, May 14, 2024 at 8:19 PM Robert Haas wrote:
>
> I looked at your version and wrote something that is shorter and
> doesn't touch any existing text. Here it is.
Hi Robert, you are a real tactician here - thanks for whatever
references the original problem! :) Maybe just slight hint nearby
e
On Mon, 20 May 2024 at 22:11, Alvaro Herrera wrote:
>
> On 2024-May-16, David Rowley wrote:
>
> > On Thu, 16 May 2024 at 17:37, zaidagilist wrote:
> > > I am trying to open the 17 docs but it looks removed. Getting
> > > following message "Page not found"
> > >
> > > https://www.postgresql.org/do
On Sun, May 19, 2024 at 4:25 AM Thomas Munro wrote:
>
> 040_pg_createsubscriber.pl seems to be failing occasionally on
> culicidae near "--dry-run on node S". I couldn't immediately see why.
> That animal is using EXEC_BACKEND and I also saw a one-off failure a
> bit like that on my own local Lin
On 2024-May-16, David Rowley wrote:
> On Thu, 16 May 2024 at 17:37, zaidagilist wrote:
> > I am trying to open the 17 docs but it looks removed. Getting
> > following message "Page not found"
> >
> > https://www.postgresql.org/docs/17/
>
> It's called "devel" for "development" until we branch so
On 2024-May-19, Jonathan S. Katz wrote:
> ### Query and Operational Performance Improvements
In this section I'd add mention the new GUCs to control SLRU memory
size, which is going to be a huge performance boon for cases where the
current fixed-size buffers cause bottlenecks. Perhaps something
On 20/5/2024 15:52, Andy Fan wrote:
Hi Andrei,
On 4/3/24 01:22, Tomas Vondra wrote:
Cool! There's obviously no chance to get this into v18, and I have stuff
to do in this CF. But I'll take a look after that.
I'm looking at your patch now - an excellent start to an eagerly awaited
feature!
A
Hi,
On Sun, May 19, 2024 at 05:10:10PM -0400, Jonathan S. Katz wrote:
> On 5/16/24 1:15 AM, Bertrand Drouvot wrote:
> > Hi,
> >
> > On Wed, May 15, 2024 at 09:45:35PM -0400, Jonathan S. Katz wrote:
> > > Hi,
> > >
> > > Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft.
>
On 20/05/2024 06:56, Mark Cave-Ayland wrote:
In general you find that a series consists of 2 parts: 1) a set of refactorings to
enable a new feature and 2) the new feature itself. Even if the details of 2) are
still under discussion, often it is possible to merge 1) fairly quickly which also
h
Hi,
> Robert Haas writes:
> > If the reason that somebody is upset is because it's not technically
> > true to say that you *must* do one of those things, we could fix that
> > with "You must" -> "You can" or with "You must specify" -> "Specify".
> > The patch you propose is also not terrible or
On 20/05/2024 02:09, Tom Lane wrote:
Bruce Momjian writes:
On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote:
* Another reason for things sitting a long time is that they're too
big to review without an unreasonable amount of effort. We should
encourage authors to break large patches
On Mon, 20 May 2024 at 13:49, Masahiko Sawada wrote:
>
> Hi,
>
> On Wed, May 8, 2024 at 4:14 PM Shubham Khanna
> wrote:
> >
> > On Wed, May 8, 2024 at 11:39 AM Rajendra Kumar Dangwal
> > wrote:
> > >
> > > Hi PG Hackers.
> > >
> > > We are interested in enhancing the functionality of the pgoutpu
Hi Andrei,
> On 4/3/24 01:22, Tomas Vondra wrote:
>> Cool! There's obviously no chance to get this into v18, and I have stuff
>> to do in this CF. But I'll take a look after that.
> I'm looking at your patch now - an excellent start to an eagerly awaited
> feature!
> A couple of questions:
> 1.
On Thu, May 16, 2024 at 3:47 PM Andrei Lepikhov
wrote:
>
> On 24.04.2024 13:25, jian he wrote:
> > hi.
> > I found an interesting case.
> >
> > CREATE TABLE t1 AS
> >SELECT (i % 10)::numeric AS x,(i % 10)::int8 AS y,'abc' || i % 10 AS
> > z, i::int4 AS w
> >FROM generate_series(1, 100) AS
On 4/3/24 01:22, Tomas Vondra wrote:
Cool! There's obviously no chance to get this into v18, and I have stuff
to do in this CF. But I'll take a look after that.
I'm looking at your patch now - an excellent start to an eagerly awaited
feature!
A couple of questions:
1. I didn't find the implemen
Hi,
On Wed, May 8, 2024 at 4:14 PM Shubham Khanna
wrote:
>
> On Wed, May 8, 2024 at 11:39 AM Rajendra Kumar Dangwal
> wrote:
> >
> > Hi PG Hackers.
> >
> > We are interested in enhancing the functionality of the pgoutput plugin by
> > adding support for generated columns.
> > Could you please g
> On 20 May 2024, at 07:49, Thomas Munro wrote:
> We're actually
> halfway to Gitlab et al already, with a web account and interaction
> required to start the process of submitting a patch for consideration.
Another Web<->Mailinglist extreme is Git themselves who have a Github bridge
for integra
> On 17 May 2024, at 18:21, Amonson, Paul D wrote:
> Hi, forgive the top-post but I have not seen any response to this post?
The project is currently in feature-freeze in preparation for the next major
release so new development and ideas are not the top priority right now.
Additionally there is
On Sun, May 19, 2024 at 02:49:22PM -0300, Euler Taveira wrote:
> My bad. :( I'll post patches soon to address all of the points.
Please note that I have added an open item pointing at this thread.
--
Michael
signature.asc
Description: PGP signature
This patch converts the compile-time settings
COPY_PARSE_PLAN_TREES
WRITE_READ_PARSE_PLAN_TREES
RAW_EXPRESSION_COVERAGE_TEST
into run-time parameters
debug_copy_parse_plan_trees
debug_write_read_parse_plan_trees
debug_raw_expression_coverage_test
They can be activated f
so 18. 5. 2024 v 18:31 odesílatel Alvaro Herrera
napsal:
> On 2024-Jan-30, Dmitry Dolgov wrote:
>
> > Yep, in this constellation the implementation holds much better (in
> > terms of memory) in my create/let/drop testing.
> >
> > I've marked the CF item as ready for committer, but a note for anyo
97 matches
Mail list logo
