On Tue, Sep 17, 2024 at 9:08 AM shveta malik wrote:
>
> On Mon, Sep 16, 2024 at 4:04 PM Amit Kapila wrote:
> >
> > On Mon, Sep 16, 2024 at 2:55 PM shveta malik wrote:
> > >
> > > On Mon, Sep 16, 2024 at 11:13 AM Amit Kapila
> > > wrote:
> > > >
> > >
> > > > Another question aside from the abo
still based on v3.
in src/sgml/html/ddl-partitioning.html
<<
On Thu, Sep 19, 2024 at 12:17 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> Thanks for the review!
>
Thanks for the patch.
Should we include in the document who can execute these functions and
the required access permissions, similar to how it's done for
pgwalinspect, pg_ls_logicalmapdir(), and other s
On Thu, 19 Sept 2024 at 16:21, Tatsuo Ishii wrote:
> Thanks. Attached is a patch for CTE scan, table function scan and
> recursive union scan nodes.
1. It's probably a minor detail, but in show_recursive_union_info(), I
don't think the tuplestores can ever be NULL.
+ if (working_table != NULL)
+
On Tue, Sep 17, 2024 at 12:44 PM Bertrand Drouvot
wrote:
>
> On Tue, Sep 17, 2024 at 10:18:35AM +0530, shveta malik wrote:
> > Thanks for addressing the comments. I have not started reviewing v4
> > yet, but here are few more comments on v3:
> >
>
> > 4)
> > Most of the output columns in pg_get_lo
>> > That code could be modified to swap the tuplestores and do a
>> > tuplestore_clear() instead of tuplestore_end() followed by
>> > tuplestore_begin_heap().
>> >
>> Impressive result. I also ran your query with count 1000.
>
> I've pushed that patch. That should now unblock you on the
> nodeRec
On Wed, Sep 18, 2024 at 3:31 PM shveta malik wrote:
>
> On Wed, Sep 18, 2024 at 2:49 PM shveta malik wrote:
> >
> > > > Please find the attached v46 patch having changes for the above review
> > > > comments and your test review comments and Shveta's review comments.
> > > >
>
When we promote ho
On Thu, Sep 19, 2024 at 08:06:19AM +0900, Michael Paquier wrote:
> I did not notice this one. I have to admit that the error message
> consistency is welcome, not the extra checks required at
> transformation.
I have applied 0001 for now to add ATT_PARTITIONED_TABLE. Attached is
the remaining pi
On Thu, Sep 19, 2024 at 6:46 AM David Rowley wrote:
>
> On Thu, 19 Sept 2024 at 11:54, Masahiko Sawada wrote:
> > I've done some benchmark tests for three different code bases with
> > different test cases. In short, reducing the generation memory context
> > block size to 8kB seems to be promisi
On 2024/09/19 8:53, Masahiko Sawada wrote:
On Tue, Sep 17, 2024 at 2:06 AM Amit Kapila wrote:
On Mon, Sep 16, 2024 at 10:43 PM Masahiko Sawada wrote:
On Fri, Sep 13, 2024 at 3:58 AM Amit Kapila wrote:
Can we try reducing the size of
8MB memory blocks? The comment atop allocation says:
Justin Pryzby writes:
> This commit seems to trigger elog(), not reproducible in the
> parent commit.
> 6e086fa2e77 Allow parallel workers to cope with a newly-created session user
> ID.
> postgres=# SET min_parallel_table_scan_size=0; CLUSTER pg_attribute USING
> pg_attribute_relid_attnum_ind
On Tue, Sep 17, 2024 at 1:47 AM Alvaro Herrera wrote:
>
still digging inheritance related issues.
drop table if exists pp1,cc1, cc2;
create table pp1 (f1 int, constraint nn check (f1 > 1));
create table cc1 (f2 text, f3 int ) inherits (pp1);
create table cc2(f4 float, constraint nn check (f1 >
On Thu, 19 Sept 2024 at 13:49, Tatsuo Ishii wrote:
>
> > That code could be modified to swap the tuplestores and do a
> > tuplestore_clear() instead of tuplestore_end() followed by
> > tuplestore_begin_heap().
> >
> Impressive result. I also ran your query with count 1000.
I've pushed that patch.
Hello Tom and Nathan,
23.09.2023 21:00, Alexander Lakhin wrote:
23.09.2023 17:39, Tom Lane wrote:
I'm also now more than just slightly skeptical about whether
pg_database should have a toast table. Has anybody tried,
say, storing a daticurules field wide enough to end up
out-of-line?
So for
On Thu, 19 Sept 2024 at 13:49, Tatsuo Ishii wrote:
> I also ran your query with count 1000.
>
> without the patch:
> Time: 3.655 ms
> Time: 4.123 ms
> Time: 2.163 ms
>
> wit the patch:
> Time: 3.641 ms
> Time: 2.356 ms
> Time: 2.347 ms
>
> It seems with the patch the performance is slightly better
> That code could be modified to swap the tuplestores and do a
> tuplestore_clear() instead of tuplestore_end() followed by
> tuplestore_begin_heap().
>
> It's likely worthwhile from a performance point of view. Here's a
> small test as an example:
>
> master:
> postgres=# with recursive cte (a)
On Tue, Sep 17, 2024 at 09:43:41PM -0700, Masahiko Sawada wrote:
> On Mon, Sep 16, 2024 at 9:24 AM Noah Misch wrote:
> > On Thu, Sep 12, 2024 at 03:42:48PM -0700, Masahiko Sawada wrote:
> > > On Tue, Sep 10, 2024 at 3:05 PM Noah Misch wrote:
> > > > On Tue, Sep 10, 2024 at 05:56:47PM -0400, Tom L
On Thu, 19 Sept 2024 at 11:54, Masahiko Sawada wrote:
> I've done some benchmark tests for three different code bases with
> different test cases. In short, reducing the generation memory context
> block size to 8kB seems to be promising; it mitigates the problem
> while keeping a similar performa
On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
>> Another new API that is useful for extension authors is the following
>> one (I'm obviously biased since I'm the author, and I don't know if
>> there's still time):
On Thu, 19 Sept 2024 at 12:01, Tatsuo Ishii wrote:
> > Could you add the two sizes together and take the storage type from
> > the tuplestore with the highest storage size?
>
> I don't think this works because tuplestore_begin/tuplestore_end are
> called while executing the node (ExecRecursiveUnio
Jubilee Young writes:
> On Wed, Sep 18, 2024 at 2:23 PM Nathan Bossart
> wrote:
>>
>> On Wed, Sep 18, 2024 at 05:35:56PM +0800, Andy Fan wrote:
>> > Currently detoast_attr always detoast the data into a palloc-ed memory
>> > and then if user wants the detoast data in a different memory, user h
Thanks for the updated patch.
Here are a few more trivial comments for the patch v7-0001.
==
1.
Should the extension descriptions all be identical?
I noticed small variations:
contrib/pg_logicalinspect/Makefile
+PGFILEDESC = "pg_logicalinspect - functions to inspect logical
decoding compon
Thank you all for the double check.
> Andy Fan writes:
>> * Note if caller provides a non-NULL buffer, it is the duty of caller
>> * to make sure it has enough room for the detoasted format (Usually
>> * they can use toast_raw_datum_size to get the size)
>
> ..., It puts it on the caller
> On Thu, 19 Sept 2024 at 00:13, Tatsuo Ishii wrote:
>> Actually there's one more executor node type that uses tuplestore:
>> recursive union (used in "with recursive"). The particular node type
>> uses two tuplestore and we cannot simply apply tuplestore_get_stats()
>> to the node type. We need t
On Tue, Sep 17, 2024 at 2:06 AM Amit Kapila wrote:
>
> On Mon, Sep 16, 2024 at 10:43 PM Masahiko Sawada
> wrote:
> >
> > On Fri, Sep 13, 2024 at 3:58 AM Amit Kapila wrote:
> > >
> > > Can we try reducing the size of
> > > 8MB memory blocks? The comment atop allocation says: "XXX the
> > > alloc
Andy Fan writes:
> * Note if caller provides a non-NULL buffer, it is the duty of caller
> * to make sure it has enough room for the detoasted format (Usually
> * they can use toast_raw_datum_size to get the size)
This is a pretty awful, unsafe API design. It puts it on the caller
to know h
On Wed, Sep 18, 2024 at 2:23 PM Nathan Bossart wrote:
>
> On Wed, Sep 18, 2024 at 05:35:56PM +0800, Andy Fan wrote:
> > Currently detoast_attr always detoast the data into a palloc-ed memory
> > and then if user wants the detoast data in a different memory, user has to
> > copy them, I'm thinking
On Wed, Sep 18, 2024 at 03:14:07PM -0500, Sami Imseih wrote:
> Agree, will do start a new thread.
Thanks.
--
Michael
signature.asc
Description: PGP signature
On Wed, Sep 18, 2024 at 10:58:34AM -0500, Nathan Bossart wrote:
> On Wed, Sep 18, 2024 at 10:17:47AM -0500, Nathan Bossart wrote:
>> Could we also use ATT_PARTITIONED_TABLE to remove the partitioned table
>> check in ATExecAddIndexConstraint()?
>
> Eh, never mind. That ends up being gross because
On Thu, 19 Sept 2024 at 00:13, Tatsuo Ishii wrote:
> Actually there's one more executor node type that uses tuplestore:
> recursive union (used in "with recursive"). The particular node type
> uses two tuplestore and we cannot simply apply tuplestore_get_stats()
> to the node type. We need to modi
On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> On Wed, 11 Sept 2024 at 16:10, Bruce Momjian wrote:
> > You are right that I do mention changes specifically designed for the
> > use of extensions, but there is no mention in the commit message of its
> > use for extensions. In
On Tue, Sep 17, 2024 at 08:13:20PM -0400, Bruce Momjian wrote:
> I think trying to add text to each item is both redundant and confusing,
> because I am guessing that many people will not even know what a commit
> is, and will be confused by clicking on the link.
>
> What I have done is to add tex
On Wed, Sep 18, 2024 at 05:35:56PM +0800, Andy Fan wrote:
> Currently detoast_attr always detoast the data into a palloc-ed memory
> and then if user wants the detoast data in a different memory, user has to
> copy them, I'm thinking if we could provide a buf as optional argument for
> detoast_attr
On Thu, Sep 05, 2024 at 04:59:54AM +, Bertrand Drouvot wrote:
> Please find attached v6, a mandatory rebase due to catversion bump conflict.
> I'm removing the catversion bump from the patch as it generates too frequent
> conflicts (just mention it needs to be done in the commit message).
v6 l
On Mon, Sep 9, 2024 at 5:00 AM Daniel Gustafsson wrote:
> Good catch. OpenSSL 3.2 changed the error message to be a lot more helpful,
> before that there is no error added to the queue at all for this processing
> (hence the "no SSL error reported"). The attached adds a hint as well as a
> prope
On Wed, Sep 18, 2024 at 10:16:48AM -0400, Tom Lane wrote:
> Jelte Fennema-Nio writes:
> > On Wed, 18 Sept 2024 at 02:55, Bruce Momjian wrote:
> >>> Also very clutter-y. I'm not convinced that any of this is a good
> >>> idea that will stand the test of time: I estimate that approximately
> >>> 0
> By the way, with the main issue fixed as of 933848d16dc9, could it be
> possible to deal with the plan cache part in a separate thread? This
> is from the start a separate thread to me, and we've done quite a bit
> here already.
Agree, will do start a new thread.
--
Sami
> So, I have applied 0001 down to 14, followed by 0002 on HEAD.
Thank you!
> 0002 is going to be interesting to see moving forward. I am wondering
> how existing out-of-core extensions will react on that and if it will
> help catching up any issues. So, let's see how the experiment goes
> with HE
On Wed, Sep 18, 2024 at 10:54:56AM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Any objections to committing this?
>
> Nope.
Committed. I waffled on whether to add a test for system indexes that used
pg_index's varlena columns, but I ended up leaving it out. I've attached
it here in case
Hi,
On Wed, Sep 18, 2024 at 10:03:21AM +0200, Peter Eisentraut wrote:
> On 18.09.24 06:16, Bertrand Drouvot wrote:
> > +#define pg_structiszero(addr, s, r)
> > \
> > + do {
On Wed, Sep 18, 2024 at 7:36 AM Tomas Vondra wrote:
> Makes sense. I started with the testing before before even looking at
> the code, so it's mostly a "black box" approach. I did read the 1995
> paper before that, and the script generates queries with clauses
> inspired by that paper, in particu
Hi,
On Wed, Sep 18, 2024 at 07:52:51PM +1000, Peter Smith wrote:
> HI, here are some mostly minor review comments for the patch v5-0001.
>
Thanks for the review!
> ==
> Commit message
>
> 1.
> Do you think you should also name the new functions here?
Not sure about this one. It has not be
On 2024/09/18 23:35, Anton A. Melnikov wrote:
Fujii, Alexander thanks a lot!
On 17.09.2024 05:47, Fujii Masao wrote:
Regarding the patch:
if (do_restartpoint)
PendingCheckpointerStats.restartpoints_performed++;
+ else
+
On 2024/09/18 21:22, Alexander Korotkov wrote:
Patch attached.
Unless there are any objections, I plan to commit this and back-patch it to v17.
I've checked this patch, it looks good to me.
Generally, it looks like I should be in charge for this, given I've
committed previous patch by Anton
On Wed, Sep 18, 2024 at 10:17:47AM -0500, Nathan Bossart wrote:
> Could we also use ATT_PARTITIONED_TABLE to remove the partitioned table
> check in ATExecAddIndexConstraint()?
Eh, never mind. That ends up being gross because you have to redo the
relation type check in a few places.
--
nathan
d
On Tue, Aug 27, 2024 at 4:07 PM Robert Haas wrote:
> I think that the beginning of add_paths_to_joinrel() looks like a
> useful spot to get control. You could, for example, have a hook there
> which returns a bitmask indicating which of merge-join, nested-loop,
> and hash join will be allowable fo
On Tue, Sep 10, 2024 at 09:42:31AM +0900, Michael Paquier wrote:
> 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 partit
Nathan Bossart writes:
> On Wed, Sep 04, 2024 at 03:20:33PM -0400, Jonathan S. Katz wrote:
>> On 9/4/24 3:08 PM, Tom Lane wrote:
>>> Nathan Bossart writes:
Thanks to commit 96cdeae, only a few catalogs remain that are missing TOAST
tables: pg_attribute, pg_class, pg_index, pg_largeobjec
On Wed, Sep 04, 2024 at 03:20:33PM -0400, Jonathan S. Katz wrote:
> On 9/4/24 3:08 PM, Tom Lane wrote:
>> Nathan Bossart writes:
>> > Thanks to commit 96cdeae, only a few catalogs remain that are missing TOAST
>> > tables: pg_attribute, pg_class, pg_index, pg_largeobject, and
>> > pg_largeobject_m
Marcos Pegoraro writes:
> Em qua., 18 de set. de 2024 às 06:02, Peter Eisentraut
> escreveu:
>> Maybe this shouldn't be done between RC1 and GA. This is clearly a more
>> complex topic that should go through a proper review and testing cycle.
> I think this is just a question of decision, not r
Here is a new version that fixes the aforementioned problems.
If this patch is accepted in this form, the counters could be used for
the patch in pg_stat_database. [1]
[1]
https://www.postgresql.org/message-id/flat/783bc7f7-659a-42fa-99dd-ee0565644...@dalibo.com
--
Benoit Lobréau
Consultant
h
On Wed, Sep 18, 2024 at 10:10 PM Tom Lane wrote:
>
> jian he writes:
> > Can we error out at the stage "create table", "create domain"
> > time if the attndims or typndims is larger than MAXDIM (6) ?
>
> The last time this was discussed, I think the conclusion was
> we should remove attndims and
Fujii, Alexander thanks a lot!
On 17.09.2024 05:47, Fujii Masao wrote:
Regarding the patch:
if (do_restartpoint)
PendingCheckpointerStats.restartpoints_performed++;
+ else
+ PendingCheckpointerStats.num_performed++;
I ex
st 18. 9. 2024 v 16:25 odesílatel Florents Tselai
napsal:
>
>
> On Wed, Sep 18, 2024 at 1:09 PM Pavel Stehule
> wrote:
>
>> Hi
>>
>> st 18. 9. 2024 v 9:04 odesílatel Florents Tselai <
>> florents.tse...@gmail.com> napsal:
>>
>>> Correct me if I'm wrong,
>>> but for an extension that defines comp
On Wed, Sep 18, 2024 at 1:09 PM Pavel Stehule
wrote:
> Hi
>
> st 18. 9. 2024 v 9:04 odesílatel Florents Tselai <
> florents.tse...@gmail.com> napsal:
>
>> Correct me if I'm wrong,
>> but for an extension that defines composite types,
>> there's currently no easy way to get a TupleDesc, even for i
Jelte Fennema-Nio writes:
> On Wed, 18 Sept 2024 at 02:55, Bruce Momjian wrote:
>>> Also very clutter-y. I'm not convinced that any of this is a good
>>> idea that will stand the test of time: I estimate that approximately
>>> 0.01% of people who read the release notes will want these links.
>>
jian he writes:
> Can we error out at the stage "create table", "create domain"
> time if the attndims or typndims is larger than MAXDIM (6) ?
The last time this was discussed, I think the conclusion was
we should remove attndims and typndims entirely on the grounds
that they're useless. I certa
On 13/9/2024 01:38, Alexander Korotkov wrote:
I've tried to implement handling of concurrent invalidation similar to
commit fdd965d074. However that appears to be more difficult that I
thought, because for some datatypes like arrays, ranges etc we might
need fill the element type and reference i
On Sat, Sep 14, 2024 at 2:10 PM Ed Behn wrote:
> Was there a resolution of this? I'm wondering if it is worth it for me to
> submit a PR for the next commitfest.
Well, it seems like what you want is different than what I want, and
what Tom wants is different from both of us. I'd like there t
On 2024/07/18 16:08, Nitin Jadhav wrote:
I apologize for not being active on this thread. However, I have now
returned to the thread and confirmed that the inconsistency is still
present in the latest code. I believe it’s crucial to address this
issue, and I am currently submitting the v5 vers
hi.
while looking at tablecmd.c, BuildDescForRelation
attdim = list_length(entry->typeName->arrayBounds);
if (attdim > PG_INT16_MAX)
ereport(ERROR,
errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("too many array dimensions"))
mak
On 2024-09-18 We 4:23 AM, Peter Eisentraut wrote:
On 17.09.24 21:16, David E. Wheeler wrote:
On Sep 17, 2024, at 15:03, Florents Tselai
wrote:
Fallback scenario: make this an extension, but in a first pass I
didn’t find any convenient hooks.
One has to create a whole new scanner, grammar
On Wed, Sep 18, 2024 at 1:21 PM Fujii Masao wrote:
> On 2024/09/17 11:47, Fujii Masao wrote:
> >
> >
> > On 2024/09/16 23:30, Anton A. Melnikov wrote:
> >> +1
> >> This idea seems quite tenable to me.
> >>
> >> There is a small clarification. Now if there were no skipped restartpoints
> >> then
>
> Thanks. I have added it and pushed the patch.
So I have created patches to do the same for CTE scan and table
function scan node. Patch attached.
Actually there's one more executor node type that uses tuplestore:
recursive union (used in "with recursive"). The particular node type
uses two tupl
On Mon, Sep 16, 2024 at 10:41 PM Bharath Rupireddy
wrote:
>
> Thanks for looking into this.
>
> On Mon, Sep 16, 2024 at 4:54 PM Amit Kapila wrote:
> >
> > Why raise the ERROR just for timeout invalidation here and why not if
> > the slot is invalidated for other reasons? This raises the question
On Wed, 18 Sept 2024 at 13:38, Marcos Pegoraro wrote:
>> Maybe this shouldn't be done between RC1 and GA. This is clearly a more
>> complex topic that should go through a proper review and testing cycle.
>
> I think this is just a question of decision, not reviewing or testing.
> And I'm sure the
Em qua., 18 de set. de 2024 às 06:02, Peter Eisentraut
escreveu:
> Maybe this shouldn't be done between RC1 and GA. This is clearly a more
> complex topic that should go through a proper review and testing cycle.
>
I think this is just a question of decision, not reviewing or testing.
And I'm s
On 9/18/24 00:14, Peter Geoghegan wrote:
> On Mon, Sep 16, 2024 at 6:05 PM Tomas Vondra wrote:
>> I've been looking at this patch over the couple last days, mostly doing
>> some stress testing / benchmarking (hence the earlier report) and basic
>> review.
>
> Thanks for taking a look! Very helpfu
On Wed, Sep 18, 2024 at 8:55 AM Bruce Momjian wrote:
>
> On Tue, Sep 17, 2024 at 08:22:41PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Sep 17, 2024 at 03:29:54PM -0300, Marcos Pegoraro wrote:
> > >> Em ter., 17 de set. de 2024 às 05:12, Alvaro Herrera
> > >>
> > >>> Add back
On 2024-Sep-18, Jelte Fennema-Nio wrote:
> It seems a shame to remove those links from the HTML view where they
> look acceptable and which most people will use, just because they look
> bad in the pdf. And honestly, they don't even look that terrible in
> the PDF imo.
Eh, someday maybe we should
On 2024/09/17 11:47, Fujii Masao wrote:
On 2024/09/16 23:30, Anton A. Melnikov wrote:
+1
This idea seems quite tenable to me.
There is a small clarification. Now if there were no skipped restartpoints then
restartpoints_done will be equal to restartpoints_timed + restartpoints_req.
Similar
On Wed, 18 Sept 2024 at 11:26, Alvaro Herrera wrote:
>
> On 2024-Sep-17, Bruce Momjian wrote:
>
> > I think trying to add text to each item is both redundant and confusing,
> > because I am guessing that many people will not even know what a commit
> > is, and will be confused by clicking on the l
st 18. 9. 2024 v 9:04 odesílatel Florents Tselai
napsal:
> Correct me if I'm wrong,
> but for an extension that defines composite types,
> there's currently no easy way to get a TupleDesc, even for its own types.
>
> Something like
> TupleDesc get_extension_type_tupledesc(const char *extname, con
On Wed, 18 Sept 2024 at 02:55, Bruce Momjian wrote:
> > Also very clutter-y. I'm not convinced that any of this is a good
> > idea that will stand the test of time: I estimate that approximately
> > 0.01% of people who read the release notes will want these links.
>
> Yes, I think 0.01% is accura
Hi
st 18. 9. 2024 v 9:04 odesílatel Florents Tselai
napsal:
> Correct me if I'm wrong,
> but for an extension that defines composite types,
> there's currently no easy way to get a TupleDesc, even for its own types.
>
> Something like
> TupleDesc get_extension_type_tupledesc(const char *extname,
On Wed, Sep 18, 2024 at 2:49 PM shveta malik wrote:
>
> > > Please find the attached v46 patch having changes for the above review
> > > comments and your test review comments and Shveta's review comments.
> > >
When the synced slot is marked as 'inactive_timeout' invalidated on
hot standby due t
HI, here are some mostly minor review comments for the patch v5-0001.
==
Commit message
1.
Do you think you should also name the new functions here?
==
contrib/pg_logicalinspect/pg_logicalinspect.c
2.
Regarding the question about static function declarations:
Shveta wrote: I was someho
Hi,
Currently detoast_attr always detoast the data into a palloc-ed memory
and then if user wants the detoast data in a different memory, user has to
copy them, I'm thinking if we could provide a buf as optional argument for
detoast_attr to save such wastage.
current format:
/* --
*
On 2024-Sep-17, Bruce Momjian wrote:
> I think trying to add text to each item is both redundant and confusing,
> because I am guessing that many people will not even know what a commit
> is, and will be confused by clicking on the link.
Uh, I 100% disagree that Postgres users reading the release
On Wed, Sep 18, 2024 at 12:21 PM shveta malik wrote:
>
> On Mon, Sep 16, 2024 at 3:31 PM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> >
> > Please find the attached v46 patch having changes for the above review
> > comments and your test review comments and Shveta's review comments.
> >
>
> Thank
On Wed, Sep 18, 2024 at 09:42:43AM +0200, Anthonin Bonnefoy wrote:
> Looking at the failure, it seems like the issue was already present
> with \bind, though there was no assertion failure: repeatedly calling
> \bind would allocate new stmtName/bind_params and leak them at the
> start of exec_comma
On Wed, Sep 18, 2024 at 08:40:02AM +, Li, Yong wrote:
> I am so glad to see that my patch got committed. Thank you a lot for it!
> This is my first accepted patch. It really means a lot to me.
No problem. Thanks for the patch!
--
Michael
signature.asc
Description: PGP signature
On 18.09.24 02:54, Bruce Momjian wrote:
On Tue, Sep 17, 2024 at 08:22:41PM -0400, Tom Lane wrote:
Bruce Momjian writes:
On Tue, Sep 17, 2024 at 03:29:54PM -0300, Marcos Pegoraro wrote:
Em ter., 17 de set. de 2024 às 05:12, Alvaro Herrera
Add backend support for injection points (Michael Paq
Hi,
On Wed, Sep 18, 2024 at 11:33:08AM +0530, shveta malik wrote:
> Thanks for the patch. Few trivial things:
>
> 1)
> May be we shall change 'INTERNAL_SNAPBUILD_H' in snapbuild_internal.h
> to 'SNAPBUILD_INTERNAL_H'?
Indeed, done in v6 attached, thanks!
> 2)
> ValidateSnapshotFile()
>
> It is
> On Sep 12, 2024, at 13:39, Michael Paquier wrote:
>
> External Email
>
>
> I was looking at all that, and this is only moving code around. While
> the part for heap_xlog_logical_rewrite in rewriteheap.c is a bit sad
> but historical, the header cleanup in heapam.c is nice.
>
> Seeing heap
> On 18 Sep 2024, at 11:23 AM, Peter Eisentraut wrote:
>
> On 17.09.24 21:16, David E. Wheeler wrote:
>> On Sep 17, 2024, at 15:03, Florents Tselai wrote:
>>> Fallback scenario: make this an extension, but in a first pass I didn’t
>>> find any convenient hooks.
>>> One has to create a whole n
On Wed, Sep 18, 2024 at 4:09 PM Peter Eisentraut wrote:
>
> >
> > i guess, it will have some minor speed up, also more accurate.
>
> I'm having a hard time interpreting this report. Could you be more
> clear about what is the existing code, and what is the code you are
> proposing as new.?
>
sor
On 17.09.24 21:16, David E. Wheeler wrote:
On Sep 17, 2024, at 15:03, Florents Tselai wrote:
Fallback scenario: make this an extension, but in a first pass I didn’t find
any convenient hooks.
One has to create a whole new scanner, grammar etc.
Yeah, it got me thinking about the RFC-9535 JSO
On 16.09.24 06:12, jian he wrote:
hi.
one minor issue in src/backend/catalog/information_schema.sql
/*
* 6.22
* COLUMNS view
*/
CREATE VIEW columns
CAST(CASE WHEN a.attgenerated = '' THEN pg_get_expr(ad.adbin,
ad.adrelid) END AS character_data) AS column_default,
can change to
CAST(C
On 18.09.24 06:16, Bertrand Drouvot wrote:
+#define pg_structiszero(addr, s, r)
\
+ do {
\
+
Hi,
On Wed, Sep 18, 2024 at 03:07:15PM +0900, Michael Paquier wrote:
> On Wed, Sep 18, 2024 at 04:16:12AM +, Bertrand Drouvot wrote:
> > The macro is created in pgstat_internal.h as it looks like that "only" the
> > statistics related code would benefit of it currently (could be moved to
> >
On 12.09.24 04:25, David Rowley wrote:
On Thu, 12 Sept 2024 at 14:03, Tom Lane wrote:
I do grant that sometimes shadowing of locals can cause bugs. I don't
recall right now why we opted for -Wshadow=compatible-local over
-Wshadow=local, but we could certainly take another look at that.
I don
On Wed, 18 Sept 2024 at 19:28, Peter Eisentraut wrote:
>
> On 12.09.24 03:43, David Rowley wrote:
> > (Likely it could just look at pg_attribute.attnotnull instead)
>
> That won't work because you can't record dependencies on that. (This is
> one of the reasons for cataloging not-null constraints
On Tue, Sep 17, 2024 at 5:00 PM Alexander Lakhin wrote:
>
> Please look at an assertion failure, caused by \bind_named:
> regression=# SELECT $1 \parse s
> \bind_named s
>
> regression=# \bind_named
> \bind_named: missing required argument
> regression=# 1 \g
> psql: common.c:1501: ExecQueryAndPro
On 12.09.24 03:43, David Rowley wrote:
On Sat, 30 Dec 2023 at 04:05, Zhang Mingli wrote:
So my patch make it easy: check unique index’s columns, it’s a valid candidate
if all of that have NOT NULL constraint.
And we choose a best one who has the least column numbers in
get_min_unique_not_null
Correct me if I'm wrong,
but for an extension that defines composite types,
there's currently no easy way to get a TupleDesc, even for its own types.
Something like
TupleDesc get_extension_type_tupledesc(const char *extname, const char
*typname)
Here's a routine I've stolen borrowed from pramsey'
96 matches
Mail list logo
