On 10.10.24 14:59, Ranier Vilela wrote:
Please look at the SCRAM secret, which breaks parse_scram_secret(),
perhaps because strsep() doesn't return NULL where strtok() did:
CREATE ROLE r PASSWORD
'SCRAM-
SHA-256$4096:hpFyHTUsSWcR7O9P$LgZFIt6Oqdo27ZFKbZ2nV+=vtnYM995pDh9ca6WSi
On 10/15/24 12:15, David Rowley wrote:
As for your patch, I'm suspicious that the general idea you're
proposing is an actual improvement.
I didn't intend to treat it as an 'improvement' but as an intermediate
patch. The main purpose here is to debate the way & introduce
considering of number of
We currently have
static PG_Locale_Strategy pg_regex_strategy;
static pg_locale_t pg_regex_locale;
static Oid pg_regex_collation;
but after the recent improvements to pg_locale_t handling, we don't need
all three anymore. All the information we have is contained in
pg_locale_t, s
On Tue, 15 Oct 2024 at 17:48, Andrei Lepikhov wrote:
> I am suspicious of that but open to hearing other opinions. The
> coefficient incorporates knowledge about how many comparisons will be
> made with this sorting operator. The caller can have some additional
> knowledge about that. For example,
On 10/15/24 02:59, Kirill Reshke wrote:
On Thu, 22 Aug 2024 at 23:46, Andrei Lepikhov wrote:
Two questions:
Thank you for the interest to this feature!
1) Why do we change the `cost_sort` definition? We can calculate the
length of `pathkeys` inside cost_sort if we want, just like we do
inside
On Wed, Oct 9, 2024 at 6:45 PM Andrew Dunstan wrote:
>
>
> On 2024-10-09 We 5:14 AM, Joel Jacobson wrote:
>
> On Tue, Oct 8, 2024, at 11:06, Amul Sul wrote:
>
> The attached patch proposes adding the ability to define CHECK and
> FOREIGN KEY constraints as NOT ENFORCED.
>
> Thanks for working on t
On Wed, Oct 9, 2024 at 2:44 PM Joel Jacobson wrote:
>
> On Tue, Oct 8, 2024, at 11:06, Amul Sul wrote:
> > The attached patch proposes adding the ability to define CHECK and
> > FOREIGN KEY constraints as NOT ENFORCED.
>
> Thanks for working on this!
>
> > Adding NOT ENFORCED to CHECK constraints
I wrote:
> I recall that when we settled on 4.0 as a good number for
> spinning-rust drives, it came out of some experimentation that
> I'd done that involved multiple-day-long tests. I don't recall any
> more details than that sadly, but perhaps trawling the mailing list
> archives would yield us
>
> You will find other places where relpathperm() is called without having
> a FileTag structure available, e.g. ReorderBufferProcessTXN().
>
I apologize for the confusion. What I meant to say is that in the
mdunlinkfiletag() function, the forknum is currently hardcoded as
MAIN_FORKNUM when calli
David Rowley writes:
> Yeah, I think any effort to change the default value for this setting
> would require some analysis to prove that the newly proposed default
> is a more suitable setting than the current default. I mean, why 1.2
> and not 1.1 or 1.3? Where's the evidence that 1.2 is the best
On Tue, 15 Oct 2024 at 10:15, Bruce Momjian wrote:
> I am not a fan of this patch. I don't see why _removing_ the magnetic
> part helps because you then have no logic for any 1.2 was chosen. I
> would put the magnetic in a separate paragraph perhaps, and recommend
> 4.0 for it. Also, per-tables
Hi,
I found that the consume_xids function incorrectly advances XIDs as
shown:
postgres=# select txid_current();
txid_current
--
746
(1 row)
postgres=# select consume_xids('100');
consume_xids
--
847
(1 row)
In the example, the consume_xids function
On Mon, Oct 14, 2024 at 3:40 PM Corey Huinker
wrote:
> However, this function seems to accept -1 for the relpages parameter.
>> Below is an example of execution:
>> ---
>> postgres=> CREATE TABLE data1(c1 INT PRIMARY KEY, c2 VARCHAR(10));
>> CREATE TABLE
>> postgres=> SELECT pg_set_relation_stats
Hi Bruce,
On Mon, 14 Oct 2024 16:31:11 -0400
Bruce Momjian wrote:
> On Mon, Oct 14, 2024 at 03:05:35PM -0400, Bruce Momjian wrote:
> > I did some more research and we able to clarify our behavior in
> > release.sgml:
>
> I have specified some more details in my patched version:
>
> We
On Sun, Oct 13, 2024 at 11:23 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Oct 14, 2024 at 09:57:22AM +1100, Peter Smith wrote:
> > Here are some minor review comments for v15-0002.
> >
> > ==
> > contrib/pg_logicalinspect/pg_logicalinspect.c
> >
> > 1.
> > +pg_get_logical_snapshot_meta(PG_F
On Thu, Sep 5, 2024 at 02:14:48PM +0200, Álvaro Herrera wrote:
> On 2024-Aug-30, Greg Sabino Mullane wrote:
>
> > I normally wouldn't mention my blog entries here, but this one was about
> > the hackers mailing list, so wanted to let people know about it in case you
> > don't follow Planet Postgr
Hi!
On 14.10.2024 22:59, Kirill Reshke wrote:
The patch in the attachment is a simplistic attempt to differentiate
these sortings by the number of columns. It is not ideal because
comparisons depend on the duplicates in each column, but it may be the
subject of further work.
Even such a trivial
On Tue, Oct 8, 2024 at 4:56 PM Thomas Munro wrote:
>
> Just by the way, you can't use anonymous structs or unions in C99
> (that was added to C11), but most compilers accept them silently
> unless you use eg -std=c99. Some buildfarm animal or other would
> bleat about that (ask me how I know), bu
On Mon, Oct 14, 2024 at 09:47:59AM +0200, Peter Eisentraut wrote:
> But we can do this better by using an incomplete struct, like
>
> struct Query *viewQuery ...;
>
> That way, everything has the correct type and fewer casts are required. This
> technique is already used elsewhere in node
On Mon, Sep 30, 2024 at 10:05:29AM -0400, Greg Sabino Mullane wrote:
> On Fri, Sep 27, 2024 at 12:03 PM Dagfinn Ilmari Mannsåker
> wrote:
>
> It might also be worth mentioning cloudy block storage (e.g. AWS' EBS),
> which is typically backed by SSDs, but has extra network latency.
>
>
>
On Mon, Sep 30, 2024 at 10:43:17AM +0800, px shi wrote:
> Hi, hackers
>
> When calculating the path, forknum is hardcoded as MAIN_FORKNUM:
>
> /* Compute the path. */
> p = relpathperm(ftag->rnode, MAIN_FORKNUM);
>
>
> But since the ftag structure already contains forknum:
>
> typedef struct F
Sorry, I was in a hurry and didn't check my patch properly.
On 14.10.2024 23:20, Alena Rybakina wrote:
On 28.08.2024 15:58, Benoit Lobréau wrote:
Hi,
Here is a new version of the patch. Sorry for the long delay, I was
hit by a motivation drought and was quite busy otherwise.
The guc is now
On Mon, Oct 14, 2024 at 03:29:34PM -0500, Nathan Bossart wrote:
> > I think it would be good to backpatch this to PG17 as well,
> > as to not introduce some differences in the macro across versions.
>
> I'd consider this a "low-risk" fix, which our versioning page [0] says is
> acceptable for a mi
On Mon, Oct 14, 2024 at 03:05:35PM -0400, Bruce Momjian wrote:
> I did some more research and we able to clarify our behavior in
> release.sgml:
I have specified some more details in my patched version:
We can only use Latin1 characters, not all UTF8 characters,
because some rende
On Mon, Oct 14, 2024 at 10:05:42PM +0200, Jelte Fennema-Nio wrote:
> I've been writing a C++ extension recently and it turns out that the
> foreach_ptr macro added in PG17 by one of my patches causes a
> compilation failure when used in C++. This is due to C++ its stricter
> rules around implicit c
On 28.08.2024 15:58, Benoit Lobréau wrote:
Hi,
Here is a new version of the patch. Sorry for the long delay, I was
hit by a motivation drought and was quite busy otherwise.
The guc is now called `log_parallel_workers` and has three possible
values:
* "none": disables logging
* "all": logs
I wrote:
> Anyway, my thought was to merge this into the other patch series,
> but I didn't do that yet.
I'd forgotten about merging these two patches into the bigger
ecpg patch series. Since there didn't seem to be any objection
to either, I went ahead and pushed them.
r
I've been writing a C++ extension recently and it turns out that the
foreach_ptr macro added in PG17 by one of my patches causes a
compilation failure when used in C++. This is due to C++ its stricter
rules around implicit casts from void pointers.
Attached is a tiny patch that fixes that by addin
On Tue, Oct 08, 2024 at 01:50:52PM -0500, Nathan Bossart wrote:
> 0002 could probably use some more commentary, but otherwise I think it is
> in decent shape. You (Michael) seem to be implying that I should
> back-patch the actual fixes and only apply the new assertions to v18. Am I
> understandi
On Mon, Oct 14, 2024, at 10:51, Joel Jacobson wrote:
> On Mon, Oct 14, 2024, at 10:07, Joel Jacobson wrote:
>> Attached is a first draft implementation of the new proposed COPY "raw"
>> format.
>>
>> The first two patches are just the bug fix in HEAD, reported separately:
>> https://commitfest.pos
Hi!
On Thu, 22 Aug 2024 at 23:46, Andrei Lepikhov wrote:
>
> Hi,
>
> I would like to propose a slight elaboration of the sort cost model.
> In practice, we frequently see the choice of suboptimal sortings, which
> slump performance by 10-50%.
>
> The key reason here is the optimiser's blindness t
>
> However, this function seems to accept -1 for the relpages parameter.
> Below is an example of execution:
> ---
> postgres=> CREATE TABLE data1(c1 INT PRIMARY KEY, c2 VARCHAR(10));
> CREATE TABLE
> postgres=> SELECT pg_set_relation_stats('data1', relpages=>-1);
> pg_set_relation_stats
> --
On Fri, Oct 11, 2024 at 12:36:53PM +0900, Yugo NAGATA wrote:
> On Fri, 11 Oct 2024 12:16:50 +0900 (JST)
> Tatsuo Ishii wrote:
>
> > > We can check non-ASCII letters SGML/XML files by preparing "allowlist"
> > > that contains lines which are allowed to have non-ascii characters,
> > > although thi
John Naylor writes:
>> [v5]
Thanks for reviewing! I pushed 0001-0005 and 0009, adopting
your suggestions except for
> + /* List a token here if pgc.l assigns to base_yylval.str for it */
> Does pgc.l need to have a similar comment?
That's not a bad suggestion, but I couldn't see any very usefu
On Sun, Oct 13, 2024 at 08:28:57AM -0400, Thomas Krennwallner wrote:
> In v2 I've made changes to the patch incorporating the suggestions here:
>
> * Default behaviour is to just fail with a report of all invalid databases
>
> * A new option --skip-invalid-databases will then skip the checks, and
On Mon, Oct 14, 2024 at 3:05 AM Peter Eisentraut wrote:
>
> On 14.10.24 08:12, Bertrand Drouvot wrote:
> >> It seems that src/backend/utils/adt/float.c file still has functions
> >> that can use [de]construct_array_builtin(), for example
> >> float8_combine(). I think it's an oversight of d746021d
On Sun, Oct 13, 2024 at 8:57 PM Amit Kapila wrote:
>
> On Sat, Oct 12, 2024 at 5:42 AM Masahiko Sawada wrote:
> >
> > I realized an obsolete comment in the definition of ReorderBufferTXN.
> >
> > Commit 9fab40ad32e changed ReorderBuffer to use Slab Context for
> > allocating ReorderBufferTXN entr
jian he writes:
> On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
>> Right, but we might not have entered either of those previous
>> if-blocks.
> in src/backend/parser/gram.y
> your makeRawStmt changes (v4) seem to guarantee that
> RawStmt->stmt_location >= 0.
Yes, I would expect that any RawS
Hi!
On 14.10.2024 16:41, Ilia Evdokimov wrote:
On 14.10.2024 12:25, Alexander Kuznetsov wrote:
Hello everyone,
I'd like to propose adding a check for the nullness of
tuplestorestate before dereferencing it
in src/backend/executor/nodeModifier.c. The patch is attached.
I am proposing this f
On Mon, 14 Oct 2024 at 16:34, jian he wrote:
>
> typedef struct ReturningOption
> {
> NodeTagtype;
> ReturningOptionKind option; /* specified option */
> char *value;/* option's value */
> ParseLoclocation;/* token location, or -1 if unknown */
On Mon, Oct 14, 2024 at 7:03 PM Dean Rasheed wrote:
>
> > > typedef struct ReturningOption
> > > {
> > > NodeTagtype;
> > > boolisNew;
> > > char *name;
> > > intlocation;
> > > } ReturningOption;
>
> Thinking about that struct some more, I think "
po 14. 10. 2024 v 5:38 odesílatel jian he
napsal:
> On Mon, Oct 14, 2024 at 1:13 AM Tom Lane wrote:
> >
> > Pavel Stehule writes:
> > > so 12. 10. 2024 v 9:33 odesílatel jian he >
> > > napsal:
> > >> + /*
> > >> + * If we have a location (which, as said above, we really always
> should)
> > >
On 24.09.24 11:09, Mark Dilger wrote:
On Sep 24, 2024, at 10:50 AM, Peter Eisentraut wrote:
Next, I have reviewed patches
v17-0010-Track-sort-direction-in-SortGroupClause.patch
v17-0011-Track-scan-reversals-in-MergeJoin.patch
Both of these seem ok and sensible to me.
They take the concept
On 14.10.2024 12:25, Alexander Kuznetsov wrote:
Hello everyone,
I'd like to propose adding a check for the nullness of tuplestorestate
before dereferencing it
in src/backend/executor/nodeModifier.c. The patch is attached.
I am proposing this fix based on the assumption that tuplestorestate
On 26.09.24 11:01, Daniel Gustafsson wrote:
Attached is a v7 which address a test failure in the CI. It turns out that the
test_misc module gather GUC names using the :alpha: character class which only
allows alphabetic whereas GUC names can have digits in them. The 0001 patch
fixes this by ins
If we are not going to implement this functionality, maybe it’s worth
adding an explicit description to the
[documentation](https://www.postgresql.org/docs/current/queries-table-expressions.html)?
A note like: "JOIN USING doesn’t support system columns. If you need to
join tables by a system co
On 14.08.2024 09:32, Steven Niu wrote:
Hi, Kirill, Junwang,
I made this patch to address the refactor issue in our previous email
discussion.
https://www.postgresql.org/message-id/flat/CABBtG=cdtcbdcbk7mcsy6bjr3s5xutog0vsffuw8olduyyc...@mail.gmail.com
That is, the for loop in function smg
On 14.10.24 08:12, Bertrand Drouvot wrote:
It seems that src/backend/utils/adt/float.c file still has functions
that can use [de]construct_array_builtin(), for example
float8_combine(). I think it's an oversight of d746021de1.
Thanks for looking at it.
Good catch, please find attached v2 taking
Hi Robert,
On Thu, Oct 10, 2024 at 6:52 PM Robert Haas wrote:
> On Wed, Sep 18, 2024 at 11:48 AM Robert Haas
> wrote:
> > Still, I think it's a pretty useful starting point. It is mostly
> > enough to give you control over join planning, and if combined with
> > similar work for scan planning,
On Sun, Oct 13, 2024 at 6:15 AM Noah Misch wrote:
>
> On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> > are unlocked outside the critical section. Why do we have to move the
> > buffer unlock within the crit
On 03.10.24 23:13, Nathan Bossart wrote:
On Tue, Oct 01, 2024 at 11:15:02AM -0400, Peter Eisentraut wrote:
I have committed 0001 (the new option) and 0004 (the docs tweak). I think
there is consensus for the rest, too, but I'll leave it for a few more days
to think about. I guess the test fail
Hello everyone,
I'd like to propose adding a check for the nullness of tuplestorestate before
dereferencing it
in src/backend/executor/nodeModifier.c. The patch is attached.
I am proposing this fix based on the assumption that tuplestorestate could be
NULL
since there is a check for it when ca
On Mon, Oct 14, 2024, at 10:07, Joel Jacobson wrote:
> Attached is a first draft implementation of the new proposed COPY "raw"
> format.
>
> The first two patches are just the bug fix in HEAD, reported separately:
> https://commitfest.postgresql.org/50/5297/
I forgot about adding support for the
FYI - Although I did not re-apply/test the latest patchset v16*, by
visual inspection of the minor v15/v16 diffs it looks good to me.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
On Sun, Oct 13, 2024, at 14:39, Joel Jacobson wrote:
> On Sun, Oct 13, 2024, at 11:52, Tatsuo Ishii wrote:
>> After copy imported the "unstructured text file" in "row" COPY format,
>> what the column type is? text? or bytea? If it's text, how do you
>> handle encoding conversion if the "unstructur
This is a small code simplification.
In primnodes.h, we have
typedef struct IntoClause
{
...
/* materialized view's SELECT query */
Node *viewQuery ...;
with the comment
/* (Although it's actually Query*, we declare
* it as Node* to avoid a forwar
56 matches
Mail list logo
