On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
> If we are looking for avoiding a segfault and get a message which helps
> debugging, using get_attname and get_attnum might be better options.
> get_attname throws an error. get_attnum doesn't throw an error and returns
> InvalidAttn
On Thu, Nov 23, 2023 at 1:43 PM Alexander Korotkov
wrote:
> Hello PostgreSQL Hackers,
>
> I am pleased to submit a series of patches related to the Table Access
> Method (AM) interface, which I initially announced during my talk at
> PGCon 2023 [1]. These patches are primarily designed to support
On Fri, May 24, 2024 at 11:03 AM Michael Paquier
wrote:
> On Thu, May 23, 2024 at 08:54:12AM -0300, Ranier Vilela wrote:
> > All calls to functions like SearchSysCacheAttName, in the whole codebase,
> > checks if returns are valid.
> > It must be for a very strong reason, such a style.
>
> Usuall
Hi Chen Yajie,
Your provided information is fuzzy, so I can only give some simple suggestions:
1. Use `file dict_snowball.so` to see the detail info of dict_snowball.so,
maybe you can get some useful hint.
2. Use gdb to debug the initdb processing, then you can get more detail error
info. That
On Thu, May 23, 2024 at 08:54:12AM -0300, Ranier Vilela wrote:
> All calls to functions like SearchSysCacheAttName, in the whole codebase,
> checks if returns are valid.
> It must be for a very strong reason, such a style.
Usually good practice, as I've outlined once upthread, because we do
expect
Ashutosh Bapat writes:
> OJ is an outer join, AFAIU. OJ's have their own relids. If you are
> wondering why not all joins - I think inner joins need not be tracked as
> separated relations in parse tree, but OJ's need to be.
An outer join is necessarily associated with explicit JOIN syntax
in the
On Fri, May 24, 2024 at 9:09 AM jian he wrote:
> On Fri, May 24, 2024 at 11:14 AM Tom Lane wrote:
> >
> > jian he writes:
> > > imho, the above comment is not very helpful.
> > > we should say more about what kind of information relid says about a
> base rel?
> >
> > "Relid" is defined at the v
On Tue, May 21, 2024 at 02:33:16PM +0900, Michael Paquier wrote:
> Nice catches from both of you. The two ones in
> generate-wait_event_types.pl are caused by me, actually.
>
> Not sure about the changes in the errcodes scripts, though. The
> current state of thing can be also useful when it com
On Fri, May 24, 2024 at 11:14 AM Tom Lane wrote:
>
> jian he writes:
> > imho, the above comment is not very helpful.
> > we should say more about what kind of information relid says about a base
> > rel?
>
> "Relid" is defined at the very top of the file:
>
> /*
> * Relids
> * Se
On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
> >> I also don't agree these should be left to "Source code" section. I
> >> feel that section is best suited for extension authors who might care
>
On Thu, May 23, 2024 at 8:43 PM Euler Taveira wrote:
>
> On Thu, May 23, 2024, at 5:54 AM, Amit Kapila wrote:
>
>
> Why in the first place do we need to ensure that primary_slot_name is
> active on the primary? You mentioned something related to WAL
> retention but I don't know how that is related
jian he writes:
> imho, the above comment is not very helpful.
> we should say more about what kind of information relid says about a base rel?
"Relid" is defined at the very top of the file:
/*
* Relids
* Set of relation identifiers (indexes into the rangetable).
*/
typedef Bitm
jian he 于2024年5月24日周五 10:58写道：
> hi
>
> typedef struct RelOptInfo
> {
>
> /*
> * information about a base rel (not set for join rels!)
> */
> Index relid;
> ...
> }
>
> imho, the above comment is not very helpful.
> we should say more about what kind of information relid says about a base
>
Bruce Momjian writes:
> On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
>> I also don't agree these should be left to "Source code" section. I
>> feel that section is best suited for extension authors who might care
>> about some internal API change. I'm talking of stuff that makes
On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
> On Thu, 23 May 2024 at 14:01, Bruce Momjian wrote:
> >
> > On Thu, May 23, 2024 at 01:34:10PM +1200, David Rowley wrote:
> > > What is the best way to communicate this stuff so it's easily
> > > identifiable when you parse the commit
hi
typedef struct RelOptInfo
{
/*
* information about a base rel (not set for join rels!)
*/
Index relid;
...
}
imho, the above comment is not very helpful.
we should say more about what kind of information relid says about a base rel?
I don't know much about RelOptInfo, that's why I ask.
Hi,
Here are some review comments for the patch v3-0001.
I don't think v3 addressed any of my previous review comments for
patches v1 and v2. [1][2]
So the comments below are limited only to the new code (i.e. the v3
versus v2 differences). Meanwhile, all my previous review comments may
still ap
Robert Haas writes:
> On Wed, May 22, 2024 at 9:46 PM Andy Fan wrote:
>> Please give me one more chance to explain this. What I mean is:
>>
>> Take SELECT f(a) FROM t1 join t2...; for example,
>>
>> When we read the Datum of a Var, we read it from tts->tts_values[*], no
>> matter what kind of
On Thu, May 23, 2024 at 08:12:07AM +, Ilyasov Ian wrote:
> > It seems to me that we should keep the 'for replication target relation
> "public.tbl" in transaction \d+,', before the "finished at" so as it
> is possible to make a difference with the context that has a column
> name and the contex
On Wed, May 22, 2024 at 6:50 PM Bruce Momjian wrote:
> Agreed, patch applied, thanks.
The item for my commit 5bf748b8 currently reads:
"Allow btree indexes to more efficiently find array matches"
I think that this isn't likely to mean much to most users. It seems
like it'd be a lot clearer if t
On Mon, May 20, 2024 at 4:54 PM jian he wrote:
>
>
> The behavior is still the same as the master.
> meaning that below quoted queries are still using "Presorted Key: x".
>
> > > EXPLAIN (COSTS OFF) SELECT count(*) FROM t1 GROUP BY x,z,y,w;
> > > EXPLAIN (COSTS OFF) SELECT count(*) FROM t1 GROUP B
Hannu Krosing writes:
> While the 'DROP OWNED BY fails to clean out pg_init_privs grants'
> issue is now fixed,we have a similar issue with REASSIGN OWNED BY that
> is still there:
Ugh, how embarrassing. I'll take a look tomorrow, if no one
beats me to it.
regards, tom l
While the 'DROP OWNED BY fails to clean out pg_init_privs grants'
issue is now fixed,we have a similar issue with REASSIGN OWNED BY that
is still there:
Tested on fresh git checkout om May 20th
test=# create user privtestuser superuser;
CREATE ROLE
test=# set role privtestuser;
SET
test=# create
Hi,
I think it's well worth the effort to revive the patch, so I rebased it
on master, updated it and will return it back to the commitfest.
Alexander, Justin feel free to add yourselves as authors
On 29.01.2024 12:43, Alexander Pyhalov wrote:
Hi.
I've rebased patch on master and it'seems t
Hi,
On Thu, May 23, 2024 at 02:10:54PM -0400, Robert Haas wrote:
> On Thu, May 23, 2024 at 12:19 AM Bertrand Drouvot
> wrote:
> > The reason why we are using a dirty snapshot here is for the cases where we
> > are
> > recording a dependency on a referenced object that we are creating at the
> >
On 2024-05-23 Th 04:08, Sandeep Thakkar wrote:
Hi Andrew, Devrim,
I'm seeing these errors on MacOS:
--
/opt/local/Current_v15/bin/xsltproc --nonet --path . --path .
--stringparam pg.version '17beta1' stylesheet.xsl postgres-full.xml
I/O error : Attempt to load network entity
http://docbook.s
On 2024-05-22 We 22:15, David Rowley wrote:
On Thu, 23 May 2024 at 13:23, David Rowley wrote:
Master:
$ pgbench -n -f bench.sql -T 10 -M prepared postgres | grep tps
tps = 362.494309 (without initial connection time)
tps = 363.182458 (without initial connection time)
tps = 362.679654 (without
Robert Haas writes:
> I think part of the reason we ended up with the protocol parameters =
> GUCs thing is because you seemed to be concurring with that approach
> upthread. I think it was Jelte's idea originally, but I interpreted
> some of your earlier remarks to be supporting it. I'm not sure
-
Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
The column names accepted by pg_stat_slru_rest() are also changed.
Is pg_stat_slru_rest() correct ?
Hi
st 22. 5. 2024 v 16:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote:
> > On 18.05.24 13:29, Alvaro Herrera wrote:
> > > I want to note that when we discussed this patch series at the dev
> > > meeting in FOSDEM, a
On Thu, May 23, 2024 at 2:12 PM Tom Lane wrote:
> I got around to looking through this thread in preparation for next
> week's patch review session. I have a couple of opinions to offer:
I agree with these opinions. Independently of that, I'm glad you shared them.
I think part of the reason we
Jacob Champion writes:
> Would it be good to expand on that idea of criticality? IIRC one of
> Jelte's complaints earlier was that middleware has to know all the
> extension types anyway, to be able to figure out whether it has to do
> something about them or not. HTTP has the concept of hop-by-ho
On Thu, May 23, 2024 at 11:12 AM Tom Lane wrote:
> If a reader doesn't recognize a particular
> chunk code, it can still tell whether the chunk is "critical" or not,
> and thereby decide if it must give up or can proceed while ignoring
> that chunk.)
Would it be good to expand on that idea of cri
Jelte Fennema-Nio writes:
> On Fri, 17 May 2024 at 21:24, Robert Haas wrote:
>> Perhaps these are all minority positions, but I can't tell you what
>> everyone thinks, only what I think.
> I'd love to hear some opinions from others on these design choices. So
> far it seems like we're the only t
On Thu, May 23, 2024 at 12:19 AM Bertrand Drouvot
wrote:
> The reason why we are using a dirty snapshot here is for the cases where we
> are
> recording a dependency on a referenced object that we are creating at the same
> time behind the scene (for example, creating a composite type while creat
On 23/05/2024 18:36, Srirama Kucherlapati wrote:
Hi Peter, thanks for your feedback.
We are eager to extend our support in resolving the issues specific
to AIX or corresponding compilers (XLC and cLang).
But as there are no issues with the patch after reverting the
changes(with the latest co
Hi Peter, thanks for your feedback.
We are eager to extend our support in resolving the issues specific to AIX or
corresponding
compilers (XLC and cLang).
But as there are no issues with the patch after reverting the changes(with the
latest compilers
gcc12 and xlc-16.0.1.18), we were wondering
On Wed, 2024-05-22 at 18:39 -0400, Bruce Momjian wrote:
> On Mon, May 20, 2024 at 11:48:09AM -0700, Jeff Davis wrote:
> > 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 ac
On Thu, May 23, 2024, at 5:54 AM, Amit Kapila wrote:
> On Wed, May 22, 2024 at 8:46 PM Euler Taveira wrote:
> >
> > Following the same line that simplifies the code, we can: (a) add a loop in
> > check_subscriber() that waits until walreceiver is available on subscriber
> > or
> > (b) use a timeo
"=?utf-8?B?6ZmI5Lqa5p2w?=" <1441147...@qq.com> writes:
> Hello, I have a question about cross-compiling. I get an error when doing
> initdb for postgresql for arm64 architecture devices.
> The error information is Error relocating
> /data/postgresql/postgresql-16.3-arm64-v8a-build/tmp_install/usr
Yes, I got it. Thank you very much for the explanation.
On 23.05.2024 00:17, Tom Lane wrote:
"a.rybakina" writes:
I faced the issue, when the sorting node in the actual information
shows a larger number of tuples than it actually is. And I can not
understand why?
If I'm reading this correctly
On Thu, May 23, 2024 at 4:40 AM Amit Kapila wrote:
> Sorry, for the wrong link. See [1] for the correct link for --dry-run
> related suggestion:
>
> [1]
> https://www.postgresql.org/message-id/CAA4eK1J2fAvsJ2HihbWJ_GxETd6sdqSMrZdCVJEutRZRpm1MEQ%40mail.gmail.com
Yeah, those should definitely be f
On Wed, May 22, 2024 at 9:46 PM Andy Fan wrote:
> Please give me one more chance to explain this. What I mean is:
>
> Take SELECT f(a) FROM t1 join t2...; for example,
>
> When we read the Datum of a Var, we read it from tts->tts_values[*], no
> matter what kind of TupleTableSlot is. So if we can
On 23/05/2024 15:39, Wang Yao wrote:
No obvious perf regression is expected because PG will follow original
qsort code path when mksort is disabled. For the case, the only extra
cost is the check in tuplesort_sort_memtuples() to enter mksort code path.
And what about the case the mksort is enab
No obvious perf regression is expected because PG will follow original
qsort code path when mksort is disabled. For the case, the only extra
cost is the check in tuplesort_sort_memtuples() to enter mksort code path.
It's also proved by the experiment today:
Mksort disabled:
2949.287 ms
2955.258 m
On Thu, 23 May 2024 at 09:19, Shubham Khanna
wrote:
>
> > Dear Shubham,
> >
> > Thanks for creating a patch! Here are high-level comments.
>
> > 1.
> > Please document the feature. If it is hard to describe, we should change
> > the API.
>
> I have added the feature in the document.
>
> > 4.
> >
On 5/23/24 8:00 AM, Alvaro Herrera wrote:
Looks good. Some minor changes:
Thanks for this - right at the deadline! :D
### Query and Operational Performance Improvements
PostgreSQL 17 builds on recent releases and continues to improve performance
across the entire system.
[Vacuum](https://
Looks good. Some minor changes:
On 2024-May-22, Jonathan S. Katz wrote:
> ### Query and Operational Performance Improvements
>
> PostgreSQL 17 builds on recent releases and continues to improve performance
> across the entire system.
> [Vacuum](https://www.postgresql.org/docs/17/routine-vacuu
Em qui., 23 de mai. de 2024 às 06:27, Ashutosh Bapat <
ashutosh.bapat@gmail.com> escreveu:
>
>
> On Thu, May 23, 2024 at 5:52 AM Michael Paquier
> wrote:
>
>> On Wed, May 22, 2024 at 03:28:48PM -0300, Ranier Vilela wrote:
>> > 1. Another concern is the function *get_partition_ancestors*,
>> >
Hi Micheal,
Em qua., 22 de mai. de 2024 às 21:21, Michael Paquier
escreveu:
> On Wed, May 22, 2024 at 03:28:48PM -0300, Ranier Vilela wrote:
> > 1. Another concern is the function *get_partition_ancestors*,
> > which may return NIL, which may affect *llast_oid*, which does not handle
> > NIL ent
Hello,
Regarding this item
: Allow the SLRU cache sizes to be configured (Andrey Borodin, Dilip Kumar)
:
: The new server variables are commit_timestamp_buffers,
: multixact_member_buffers, multixact_offset_buffers, notify_buffers,
: serializable_buffers, subtransaction_buffers, and transaction_
Hello hackers,
I'd like to discuss ways to improve the buildfarm experience for anyone who
are interested in using information which buildfarm gives to us.
Unless I'm missing something, as of now there are no means to determine
whether some concrete failure is known/investigated or fixed, how
fr
Hello, I have a question about cross-compiling. I get an error when doing
initdb for postgresql for arm64 architecture devices.
The error information is Error relocating
/data/postgresql/postgresql-16.3-arm64-v8a-build/tmp_install/usr/postgresql/arm64-v8a/lib/dict_snowball.so:
palloc0: symbol no
On Thu, May 23, 2024 at 5:52 AM Michael Paquier wrote:
> On Wed, May 22, 2024 at 03:28:48PM -0300, Ranier Vilela wrote:
> > 1. Another concern is the function *get_partition_ancestors*,
> > which may return NIL, which may affect *llast_oid*, which does not handle
> > NIL entries.
>
> Hm? We alre
On Wed, May 22, 2024 at 8:46 PM Euler Taveira wrote:
>
> On Wed, May 22, 2024, at 8:19 AM, Amit Kapila wrote:
>
> > v2-0002: not changed
> >
>
> We have added more tries to see if the primary_slot_name becomes
> active but I think it is still fragile because it is possible on slow
> machines that
On Wed, May 22, 2024 at 8:02 PM Robert Haas wrote:
>
> On Mon, May 20, 2024 at 2:42 AM Amit Kapila wrote:
> > Just to summarize, apart from BF failures for which we had some
> > discussion, I could recall the following open points:
> >
> > 1. After promotion, the pre-existing replication objects
> It seems to me that we should keep the 'for replication target relation
"public.tbl" in transaction \d+,', before the "finished at" so as it
is possible to make a difference with the context that has a column
name and the context where there is no target relation.
I agree. Attached the updated p
Hi Andrew, Devrim,
I'm seeing these errors on MacOS:
--
/opt/local/Current_v15/bin/xsltproc --nonet --path . --path . --stringparam
pg.version '17beta1' stylesheet.xsl postgres-full.xml
I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
w
On Fri, May 17, 2024 at 5:41 PM Richard Guo wrote:
> I've spent some more time on this patch, and now it passes all the
> regression tests. But I had to hack explain.c and ruleutils.c to make
> the varprefix stuff work as it did before, which is not great.
>
I've realized that I made a mistake
59 matches
Mail list logo
