should not be backpatched. How
about fixing the documentation for v12 and v13 then?
[1]: https://www.postgresql.org/docs/12/extend-pgxs.html
[2]:
https://www.postgresql.org/message-id/flat/CAMsr%2BYFsCMH3B4uOPFE%2B2qWM6k%3Do%3Dhf9LGiPNCfwqKdUPz_BsQ%40mail.gmail.com
Best regards,
Karina Litskevich
trying to understand whether it's a
bug
in computing the counters or just changes in how many blocks are
read/written
during the query execution. If anyone can help me, I would be grateful.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
On Mon, Sep 11, 2023 at 9:08 AM Karina Litskevich <
litskevichkar...@gmail.com> wrote:
> I found a bug that causes one of the differences. Wrong counter is
> incremented
> in ExtendBufferedRelLocal(). The attached patch fixes it and should be
> applied
> to REL_16_STABLE
s is called 1 time) [2]
> >
> > I think [0] is the same path as [1] but [2] is new. 'fsm extends'
> > wasn't counted in local_blks_written in PG_15. Calling
> > ExtendBufferedRelTo() from fsm_extend() caused 'fsm extends' to be
> > counted
we also should check weather some other functions
become
useless. Maybe that is the right way, but it looks much harder than the
existing solutions, so I believe, before anyone began going this way, it's
better to know whether there are any pitfalls there.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
I believe it's better to rename "oldsize"
into
"oldchksize".
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 9556b7918e6abccb2dc19f20dbf572d41cd35cb4 Mon Sep 17 00:00:00 2001
From: Karina Litskevich
Date: Tue, 14 Feb 2023 17:13:17 +0300
Subj
NED. So we only "may need to adjust
trailing bytes" if RANDOMIZE_ALLOCATED_MEMORY isn't defined. I reflected it in
v2 of 0001 too.
From 009ef9bbabcd71e0d5f2b60799c0b71d21fb9767 Mon Sep 17 00:00:00 2001
From: Karina Litskevich
Date: Fri, 17 Feb 2023 15:32:05 +0300
Subject: [PATCH v2 2/2] Cha
se ways just to change the error code.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 6407538f0bfd3eb56f5a4574d8893f9494f2a810 Mon Sep 17 00:00:00 2001
From: Karina Litskevich
Date: Fri, 14 Oct 2022 17:48:27 +0300
Subject: [PATCH v2 2/2] better error message for settin
overall.
I also believe that changing "misses" to "reads" should belong to 0001
patch since we only change it because we replace AnalyzePageMiss with
bufferusage.shared_blks_read + bufferusage.local_blks_read in 0001.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
>
I wrote:
>
> I suggest assigning values
> bufferusage.shared_blks_read + bufferusage.local_blks_read
> and
> bufferusage.shared_blks_dirtied + bufferusage.local_blks_dirtied
> to new variables and using them. This would keep the changed lines within
> the 80 symbols limit, and make the code more r
no-op.
I attached a patch that removes only one assignment. Could you please try
it and check whether Coverity is still complaining about need_recordsep
variable?
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 92c86657181c13c48a4b4176bf4ad1d6221cf9b5 Mon Sep 17 00:0
On Tue, Jul 25, 2023 at 1:04 AM Ranier Vilela wrote:
> Checked today, Coverity does not complain about need_recordsep.
>
Great! Thanks.
So v2 patch makes Coverity happy, and as for me doesn't make the code
less readable. Does anyone have any objections?
Best regards,
Karina Litskevi
s doesn't seem user friendly to me.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
Hi,
I also would like to suggest a cosmetic change.
In v15 a new field checkunique is added after heapallindexed and before
no_btree_expansion fields in struct definition, but in initialisation it is
added after no_btree_expansion:
--- a/src/bin/pg_amcheck/pg_amcheck.c
+++ b/src/bin/pg_amcheck/pg
bvious, so I also have doubts about removing this line. If someday
print options are changed, for example to support printing footers and not
printing headers, or anything else changes in this function, the output might
be unexpected with this line removed.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
e that another backend might have extended the relation by the time
* we get the lock.
I attached the new version of the patch as I see it.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 7425d5b1b9d30f0da75aabd94e862906f9635a60 Mon Sep 17 00:00:00 2001
From: Kar
hile iterating it, but at least I can't reproduce the bug on master.
I attached a bugfix for PG 15.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 5f0e59b225ebb408a0c971bc78e22050b296ae9a Mon Sep 17 00:00:00 2001
From: Karina Litskevich
Date: Thu, 6 J
t line will make
the code more readable.
Moreover, removing the line will possibly complicate the future maintenance.
As I wrote in the part you just quoted, if the function changes in the way
that need_recordsep is not true right before printing footers any more, then
output will be unexpected.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
tead
of "123a".
I've attached the patch. Are there any pitfalls I can't see? It just keeps
bothering me why wasn't it done from the beginning. Matching the whole
identifier after a numeric literal just seems more obvious to me than
matching its first byte.
Best regards,
Kari
x27;,100) \gexec
ERROR: trailing junk after numeric literal at or near "1ppp"
And another query that leads to this without patch:
postgres=# select 'select 1'||repeat('@',100)||'1' \gexec
ERROR: operator too long at or
On Thu, Sep 5, 2024 at 1:52 AM Tom Lane wrote:
> Karina Litskevich writes:
> > I see the two solutions here: either move the rule for decinteger_junk
> > below the rules for hexinteger_junk, octinteger_junk and
bininteger_junk,
> > or just use a single rule decinteger_jun
On Thu, Sep 5, 2024 at 6:07 PM Karina Litskevich
wrote:
> In v3 of the patch I grouped all the *_junk rules together and included
> the suggested comment with a little added something.
Oops, I forgot to attach the patch, here it is.
Best regards,
Karina Litskevich
Postgres Professional
I suggest eliminating holding the excessive lock. See the attached patch.
This would also restore the consistency between the code and the comments
about entry's mutex spinlock usage.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From c817fc9373ca08488088414a05
oblem with "USING " and
"USING " in v5-0004.
Also, make sure you ran pgindent before creating patches. In v5-0004
there are comments that are too long for one line, and there is a line
with a trailing space:
+ else if (Matches("CREATE", "MATERIALIZED", "VIEW", MatchAny, "AS") ||
Other than that, everything looks fine to me.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
statements--1.10--1.11.sql if it's not
too late for PostgreSQL 17 yet.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 2273e72e35fe2d4ff500a2127413121b1709be17 Mon Sep 17 00:00:00 2001
From: Karina Litskevich
Date: Mon, 23 Sep 2024 16:06:25 +0300
Sub
_WITH("AS");
to
+ COMPLETE_WITH("AS", "USING");
Please fix it.
I hope to look more thoroughly into tab-complete.in.c tomorrow or on
Monday to see if there are any other problems I can't see at first
glance. I'll send another mail when I get to do this.
[1] https://www.postgresql.org/docs/current/sql-altertype.html
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
tch!
I can't judge if 0002 adds useful completion cases, but I noticed that
you add completion of "DROP/ADD ATTRIBUTE ..." with CASCADE/RESRTICT
while ignoring "ALTER/RENAME ATTRIBUTE ..." that also can be followed
by CASCADE/RESRTICT according to the documentation. Is it intentional?
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
the shorter wording of the comment.
I used it in the new version of the patch.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From 4b7f7ea0c9923fa9d2622d86aa1214f331c600ec Mon Sep 17 00:00:00 2001
From: Karina Litskevich
Date: Thu, 7 Nov 2024 15:54:32 +0
"AS".
Other completions work fine.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
(opts.allrel)
appendPQExpBuffer(&sql,
" AND c.relam = %u"
" AND c.relkind IN ("
CppAsString2(RELKIND_RELATION) ", "
CppAsString2(RELKIND_SEQUENCE) ", "
CppAsString2(RELKIND_MATVIEW) ", "
CppAsString2(RELKIND_TOASTVALUE) ")"
" AND c.relnamespace != %u",
HEAP_TABLE_AM_OID, PG_TOAST_NAMESPACE);
What do you think?
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
malloc() is used instead, but we have to check if
return value is NULL.
Please find attached patch for REL_15_STABLE. This should be fixed in
older versions too.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From f33e9823d6413b88c7a42f6509e5c796fd0bab95 Mon Sep 17
31 matches
Mail list logo
