On Mon, Jun 17, 2024 at 07:00:51PM +0200, Michail Nikolaev wrote:
> The simplest possible fix is to use ShareLock
> instead ShareUpdateExclusiveLock in the index_concurrently_swap
>
> oldClassRel = relation_open(oldIndexId, ShareLock);
> newClassRel = relation_open(newIndex
On Thu, Jun 20, 2024 at 6:36 AM Peter Smith wrote:
>
> Hi Amit.
>
> I modified the patch text slightly according to Peter E's suggestion [1].
>
> I also tested the above examples against all older PostgreSQL versions
> 12,13,14,15,16,17. The logical replication behaviour of skipping
> generated co
On 20.06.24 16:34, Noah Misch wrote:
On Thu, Jun 20, 2024 at 09:29:45AM +0200, Peter Eisentraut wrote:
On 16.06.24 21:34, Noah Misch wrote:
On Thu, Oct 05, 2023 at 05:46:46PM +0200, Peter Eisentraut wrote:
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
$(top_builddir)/src/include/
On Wed, Jun 19, 2024 at 10:44 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Horiguchi-san,
>
> Thanks for sharing the patch! I agree this approach (ensure WAL records are
> flushed)
> Is more proper than others.
>
> I have an unclear point. According to the comment atop GetInsertRecPtr(), it
> just
On 20.06.24 14:05, Andrew Dunstan wrote:
On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote:
I have this patch series that fixes up the types of the new
incremental JSON API a bit. Specifically, it uses "const" throughout
so that the top-level entry points such as pg_parse_json_incremental()
ca
On Thursday, June 20, 2024, Markus Winand wrote:
>
>
> > On 21.06.2024, at 06:46, David G. Johnston
> wrote:
> >>
>
> >
> > 2 also has the benefit of being standard conforming while 1 does not.
>
> Why do you think so? Do you have any references or is this just based on
> previous statements in
On Fri, Jun 21, 2024 at 10:31:30AM +0500, Andrey M. Borodin wrote:
> Thanks for the pointer, I’ll try this approach!
Thanks. FWIW, I've put my mind into it, and fixed the thing a few
minutes ago:
https://www.postgresql.org/message-id/ZnURUaujl39wSoEW%40paquier.xyz
--
Michael
signature.asc
Descr
On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote:
> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
> > This patch looks good to me.
>
> Thanks for looking.
While double-checking the whole, where I don't have much to say about
0001, I have fixed a few issues with
> On 21 Jun 2024, at 09:01, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>> I’ve tried to dig into the test.
>> The problem is CV is allocated in
>>
>> inj_state = GetNamedDSMSegment("injection_points”,
>>
>> which seems to be destroyed in
>>
> On 21.06.2024, at 06:46, David G. Johnston wrote:
>>
>> On Thursday, June 20, 2024, Pavel Stehule wrote:
>>
>>
>> pá 21. 6. 2024 v 6:01 odesílatel Amit Langote
>> napsal:
>> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
>> wrote:
>>
>> > > By the standard, it is implementation-de
> On 21.06.2024, at 03:00, David G. Johnston wrote:
>
> On Thu, Jun 20, 2024 at 5:22 PM Amit Langote wrote:
>
> Soft error handling *was* used for catching cast errors in the very
> early versions of this patch (long before I got involved and the
> infrastructure you mention got added). It w
Hi Shubham/Shlok.
FYI, my patch describing the current PG17 behaviour of logical
replication of generated columns was recently pushed [1].
Note that this will have some impact on your patch set. e.g. You are
changing the current replication behaviour, so the "Generated Columns"
section note will
On Thursday, June 20, 2024, Pavel Stehule wrote:
>
>
> pá 21. 6. 2024 v 6:01 odesílatel Amit Langote
> napsal:
>
>> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
>> wrote:
>>
>> > > By the standard, it is implementation-defined whether JSON parsing
>> errors
>> > > should be caught by ON E
pá 21. 6. 2024 v 6:01 odesílatel Amit Langote
napsal:
> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
> wrote:
> > On Thu, Jun 20, 2024 at 5:22 PM Amit Langote
> wrote:
> >>
> >>
> >> Soft error handling *was* used for catching cast errors in the very
> >> early versions of this patch (lon
On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier
> wrote in
>> * The kind IDs may change across restarts, meaning that any stats data
>> associated to a custom kind is stored with the *name* of the custom
>> stats kind. De
pá 21. 6. 2024 v 2:22 odesílatel Amit Langote
napsal:
> On Fri, Jun 21, 2024 at 1:11 AM David G. Johnston
> wrote:
> > On Thu, Jun 20, 2024 at 2:19 AM Amit Langote
> wrote:
> >> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand
> wrote:
> >> > > On 17.06.2024, at 08:20, Amit Langote
> wrote:
> >
At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier wrote
in
> * The kind IDs may change across restarts, meaning that any stats data
> associated to a custom kind is stored with the *name* of the custom
> stats kind. Depending on the discussion happening here, I'd be open
> to use the same co
On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
> I’ve tried to dig into the test.
> The problem is CV is allocated in
>
> inj_state = GetNamedDSMSegment("injection_points”,
>
> which seems to be destroyed in
>
> shmem_exit() calling dsm_backend_shutdown()
>
> This happens be
On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
wrote:
> On Thu, Jun 20, 2024 at 5:22 PM Amit Langote wrote:
>>
>>
>> Soft error handling *was* used for catching cast errors in the very
>> early versions of this patch (long before I got involved and the
>> infrastructure you mention got added)
On Thu, 20 Jun 2024 at 23:44, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Jun 20, 2024 at 08:32:57AM +0200, Joel Jacobson wrote:
> >> I've added overloaded versions for regclass and regproc so far:
> >>
> >> \df pg_get_acl
> >> List of functions
> >> Schema |Name| Result data
On Thu, 20 Jun 2024 at 02:33, Joel Jacobson wrote:
> On Wed, Jun 19, 2024, at 16:23, Isaac Morland wrote:
> > I have no idea how often this would be useful, but I wonder if it could
> > work to have overloaded single-parameter versions for each of
> > regprocedure (pg_proc.proacl), regclass (pg_c
Michael Paquier writes:
> On Thu, Jun 20, 2024 at 08:32:57AM +0200, Joel Jacobson wrote:
>> I've added overloaded versions for regclass and regproc so far:
>>
>> \df pg_get_acl
>> List of functions
>> Schema |Name| Result data type | Argument data types | Type
>> +---
Hi, here are some review comments for patch v9-0002.
==
src/backend/replication/logical/relation.c
1. logicalrep_rel_open
- if (attr->attisdropped)
+ if (attr->attisdropped ||
+ (!MySubscription->includegencols && attr->attgenerated))
You replied to my question from the previous review [1,
On Thu, Jun 20, 2024 at 08:32:57AM +0200, Joel Jacobson wrote:
> I've added overloaded versions for regclass and regproc so far:
>
> \df pg_get_acl
> List of functions
>Schema |Name| Result data type | Argument data types | Type
> +
Andy Fan writes:
> I relies on some compiler's check to reduce some simple coding issues, I
> use clang 18.1.6 for now. however "CFLAGS='-Wall -Werror ' ./configure"
> would fail,
Nope, you cannot do that: -Werror breaks many of configure's tests.
See
https://www.postgresql.org/docs/current/inst
On Thu, Jun 20, 2024 at 7:30 PM jian he wrote:
> "predicate check expressions return the single three-valued result of
>
the predicate: true, false, or unknown."
> "unknown" is wrong, because `select 'unknown'::jsonb;` will fail.
> here "unknown" should be "null"? see jsonb_path_query doc entry a
On Tue, Jun 18, 2024 at 9:52 AM Nathan Bossart
wrote:
> On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> > On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart
> wrote:
> >> I think we could improve matters by abandoning the table and instead
> >> documenting these roles more like we doc
Hi Shubham, here are some more patch v8-0001 comments that I missed yesterday.
==
src/test/subscription/t/011_generated.pl
1.
Are the PRIMARY KEY qualifiers needed for the new tab2, tab3 tables? I
don't think so.
~~~
2.
+$result = $node_subscriber->safe_psql('postgres', "SELECT * FROM tab2"
On Mon, Jan 15, 2024 at 1:50 PM Richard Guo wrote:
> Updated this patch over 29f114b6ff, which indicates that we should apply
> the same rules for PHVs.
Here is a new rebase of this patch, with some tweaks to comments. I've
also updated the commit message to better explain the context.
To recap
hi.
-
9.16.2.1.1. Boolean Predicate Check Expressions
As an extension to the SQL standard, a PostgreSQL path expression can
be a Boolean predicate, whereas the SQL standard allows predicates
only within filters. While SQL-standard path expressions return the
relevant element(s) of the q
Hi,
I relies on some compiler's check to reduce some simple coding issues, I
use clang 18.1.6 for now. however "CFLAGS='-Wall -Werror ' ./configure"
would fail, and if I run ' ./configure' directly, it is OK. I'm not sure
why it happens. More details is below:
(master)> echo $CC
clang
(master)>
On Thu, Jun 20, 2024 at 08:01:19PM -0400, Bruce Momjian wrote:
> FYI, looking at the release notes, I see 15 GUC variables added in this
> release, and two removed. That 15 number seemed unusually high so I
> thought I would report it.
Scanning pg_settings across the two versions, I'm seeing:
- R
On Wed, Jun 19, 2024 at 05:14:50AM +, Hayato Kuroda (Fujitsu) wrote:
> I have an unclear point. According to the comment atop GetInsertRecPtr(), it
> just
> returns the approximated value - the position of the last full WAL page [1].
> If there is a continuation WAL record which across a page,
On Thu, Jun 20, 2024 at 5:22 PM Amit Langote
wrote:
>
> Soft error handling *was* used for catching cast errors in the very
> early versions of this patch (long before I got involved and the
> infrastructure you mention got added). It was taken out after Pavel
> said [1] that he didn't like prod
On Thu, Jun 20, 2024 at 9:01 AM jian he wrote:
> On Thu, Jun 20, 2024 at 5:46 PM Amit Langote
> wrote:
> >
> > On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston
> > wrote:
> > > On Wed, Jun 19, 2024 at 8:29 AM jian he
> wrote:
> > >>
> > >> On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack
> wrot
On Fri, Jun 21, 2024 at 1:11 AM David G. Johnston
wrote:
> On Thu, Jun 20, 2024 at 2:19 AM Amit Langote wrote:
>> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand
>> wrote:
>> > > On 17.06.2024, at 08:20, Amit Langote wrote:
>> > > Agree that the documentation needs to be clear about this. I'll
On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
wrote:
> If vacuum fails to remove a tuple with xmax older than
> VacuumCutoffs->OldestXmin and younger than
> GlobalVisState->maybe_needed, it will ERROR out when determining
> whether or not to freeze the tuple with "cannot freeze committed
> xmax
FYI, looking at the release notes, I see 15 GUC variables added in this
release, and two removed. That 15 number seemed unusually high so I
thought I would report it.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you ca
Hi,
If vacuum fails to remove a tuple with xmax older than
VacuumCutoffs->OldestXmin and younger than
GlobalVisState->maybe_needed, it will ERROR out when determining
whether or not to freeze the tuple with "cannot freeze committed
xmax".
In back branches starting with 14, failing to remove tuple
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas wrote:
> > By "negotiation" I mean the server's response to the startup packet.
> > I.e. "supported"/"not supported"/"error".
>
> Ok, I'm still a little confused, probably a terminology issue. The
> server doesn't respond with "supported" or "not
On 21/06/2024 02:12, Tom Lane wrote:
Heikki Linnakangas writes:
In commit af0e7deb4a, I removed the call to RelationCloseSmgr() from
RelationCacheInvalidate(). I thought it was no longer needed, because we
no longer free the underlying SmgrRelation.
However, it meant that if the relfilenode
On Thu, Jun 20, 2024 at 02:27:14PM +, Bertrand Drouvot wrote:
> On Thu, Jun 20, 2024 at 09:46:30AM +0900, Michael Paquier wrote:
> I think it makes sense to follow the same "behavior" as the custom
> wal resource managers. That, indeed, looks much more simpler than v1.
Thanks for the feedback.
On 20/06/2024 20:02, Jacob Champion wrote:
On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion
wrote:
I think the behavior with v2 and v3 errors should be the same. And I
think an immediate failure is appropriate on any v2/v3 error during
negotiation, assuming we don't use those errors for things li
Heikki Linnakangas writes:
> In commit af0e7deb4a, I removed the call to RelationCloseSmgr() from
> RelationCacheInvalidate(). I thought it was no longer needed, because we
> no longer free the underlying SmgrRelation.
> However, it meant that if the relfilenode of the relation was changed,
>
On Thu, Jun 20, 2024 at 01:05:42PM +, Bertrand Drouvot wrote:
> On Thu, Jun 13, 2024 at 04:59:50PM +0900, Michael Paquier wrote:
>> * Making custom stats data persistent is an interesting problem, and
>> there are a couple of approaches I've considered:
>> ** Allow custom kinds to define callba
On 19/06/2024 23:00, Alexander Lakhin wrote:
Please look at a new anomaly, that I've discovered in master.
...
triggers a segfault:
2024-06-19 19:22:49.009 UTC [1607210:6] LOG: server process (PID 1607671) was
terminated by signal 11: Segmentation fault
...
server.log might also contain:
20
Here's a fix adding the missing headers to pg_combinebackup, and fixing
some compile-time issues in the ifdef-ed block.
I've done some basic manual testing today - I plan to test this a bit
more tomorrow, and I'll also look at integrating this into the existing
tests.
regards
--
Tomas Vondra
E
While working on skip scan, I stumbled upon a bug on HEAD. This is an
issue in my commit 5bf748b8, "Enhance nbtree ScalarArrayOp execution".
The attached test case (repro_wrong_prim.sql) causes an assertion
failure on HEAD. Here's the stack trace:
TRAP: failed Assert("so->keyData[opsktrig].sk_stra
Hi,
On 2024-06-19 14:47:50 +0100, Dave Page wrote:
> > I'm *NOT* sure that vcpkg is the way to go, fwiw. It does seem
> > advantageous to
> > use one of the toolkits thats commonly built for building dependencies on
> > windows, which seems to mean vcpkg or conan.
> >
>
> I don't think requiring
On Thu, Jun 20, 2024 at 3:43 PM Hannu Krosing wrote:
> Still it would be nice to have some public support for users of
> non-managed PostgreSQL databases as well
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
It does happen with some regularity.
At least one large cloud database provider I know of saw this more
than once a month until the mitigations were integrated in the major
version upgrade process.
It is possible that making database upgrades easier via better
automation is what made this turn up
On 15.06.2024 20:40, Justin Pryzby wrote:
On Thu, May 23, 2024 at 10:14:57PM +0100, Ilya Gladyshev wrote:
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 a
Hannu Krosing writes:
> Or perhaps we should still also patch pg_dump to ignore the aclentries
> which refer to roles that do not exist in the database ?
I didn't want to do that before, and I still don't. Given that this
issue has existed since pg_init_privs was invented (9.6) without
prior rep
On Thu, Jun 20, 2024 at 2:25 PM Tom Lane wrote:
> Hannu Krosing writes:
> > Or perhaps we should still also patch pg_dump to ignore the aclentries
> > which refer to roles that do not exist in the database ?
>
> I didn't want to do that before, and I still don't. Given that this
> issue has exis
Or perhaps we should still also patch pg_dump to ignore the aclentries
which refer to roles that do not exist in the database ?
On Thu, Jun 20, 2024 at 7:41 PM Hannu Krosing wrote:
>
> Then maybe we should put a query / function in the release notes to
> clean up the existing mess.
>
> Thinking o
Then maybe we should put a query / function in the release notes to
clean up the existing mess.
Thinking of it we should do it anyway, as the patch only prevents new
messiness from happening and does not fix existing issues.
I could share a query to update the pg_init_privs with non-existent
role
On Jun 20, 2024, at 13:12, Robert Haas wrote:
> I'm working to start a mentoring program where code contributors can
> be mentored by current committers. Applications are now open:
> https://forms.gle/dgjmdxtHYXCSg6aB7
This is amazing! Thank you for putting it together, Robert.
Best,
David
Hi,
I'm working to start a mentoring program where code contributors can
be mentored by current committers. Applications are now open:
https://forms.gle/dgjmdxtHYXCSg6aB7
Nine committers have volunteered to mentor one person each; hence, the
anticipated number of acceptances is less than or equal
On Jun 19, 2024, at 13:50, Jelte Fennema-Nio wrote:
> This indeed does sound like the behaviour that pretty much every
> existing extension wants to have. One small addition/clarification
> that I would make to your definition: fully qualified references to
> other objects should still be allowed
On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion
wrote:
> > I think the behavior with v2 and v3 errors should be the same. And I
> > think an immediate failure is appropriate on any v2/v3 error during
> > negotiation, assuming we don't use those errors for things like "TLS not
> > supported", which
On Jun 19, 2024, at 11:28, Robert Haas wrote:
> But I wonder if there might also be another possible approach: could
> we, somehow, prevent object references in extension scripts from
> resolving to anything other than the system catalogs and the contents
> of that extension? Perhaps with a contr
On Thu, Jun 20, 2024 at 2:19 AM Amit Langote
wrote:
> Hi,
>
> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand
> wrote:
> > > On 17.06.2024, at 08:20, Amit Langote wrote:
> > > Agree that the documentation needs to be clear about this. I'll update
> > > my patch at [1] to add a note next to table
On Thu, Jun 20, 2024 at 5:46 PM Amit Langote wrote:
>
> On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston
> wrote:
> > On Wed, Jun 19, 2024 at 8:29 AM jian he wrote:
> >>
> >> On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack wrote:
> >> >
> >> > Hi,
> >> >
> >> > On 06/17/24 02:43, Amit Langote wr
On Wed, Jun 19, 2024 at 1:50 PM Jelte Fennema-Nio wrote:
> I do think, even if we have this, there would be other good reasons to
> use "owned schemas" for extension authors. At least the following two:
> 1. To have a safe search_path that can be used in SET search_path on a
> function (see also [
On 06/20/24 10:54, David E. Wheeler wrote:
> Still not sure about `24:00:00` as a time, though. I presume the jsonpath
> standard disallows it.
In 9075-2 9.46 "SQL/JSON path language: syntax and semantics", the behavior
of the .time() and .time_tz() and similar item methods defers to the
behavior
Hannu Krosing writes:
> Is there anything that could be back-patched with reasonable effort ?
Afraid not. The whole thing is dependent on pg_shdepend entries
that won't exist in older branches.
regards, tom lane
Ranier Vilela writes:
> Em qua., 19 de jun. de 2024 às 20:52, Tom Lane escreveu:
>> Hah: it's the second case. If I patch radixtree.h as attached,
>> then x86_64 valgrind complains about
>> ==00:00:00:32.759 247596== Conditional jump or move depends on
>> uninitialised value(s)
>> ==00:00:00:32.
On 6/20/24 5:22 PM, Andreas Karlsson wrote:
On 10/12/23 11:48 AM, Daniel Gustafsson wrote:
Thoughts?
I have looked at the patch and it still applies, builds and passes the
test cases and I personally think these optimizations are pretty much
no-brainers that we should do and it is a pity nob
On 10/12/23 11:48 AM, Daniel Gustafsson wrote:
Thoughts?
I have looked at the patch and it still applies, builds and passes the
test cases and I personally think these optimizations are pretty much
no-brainers that we should do and it is a pity nobody has had the time
to review this patch.
On Thu, Jun 20, 2024 at 12:17:44PM +0500, Andrey M. Borodin wrote:
> On 20 Jun 2024, at 06:29, Noah Misch wrote:
> > This resolves the last inplace update defect known to me.
>
> That’s a huge amount of work, thank you!
>
> Do I get it right, that inplace updates are catalog-specific and some ot
On Apr 29, 2024, at 20:45, David E. Wheeler wrote:
> I noticed that the jsonpath date/time functions (.time() and timestamp(), et
> al.) don’t support some valid but special-case PostgreSQL values, notably
> `infinity`, `-infinity`, and, for times, '24:00:00`:
Looking at ECMA-404[1], “The JSON
On Thu, Jun 20, 2024 at 09:29:45AM +0200, Peter Eisentraut wrote:
> On 16.06.24 21:34, Noah Misch wrote:
> > On Thu, Oct 05, 2023 at 05:46:46PM +0200, Peter Eisentraut wrote:
> > > --- a/src/backend/Makefile
> > > +++ b/src/backend/Makefile
> >
> > > $(top_builddir)/src/include/storage/lwlocknam
Hi,
On Thu, Jun 20, 2024 at 09:46:30AM +0900, Michael Paquier wrote:
> On Thu, Jun 13, 2024 at 04:59:50PM +0900, Michael Paquier wrote:
> > - How should the persistence of the custom stats be achieved?
> > Callbacks to give custom stats kinds a way to write/read their data,
> > push everything int
On 20/06/2024 16:41, Heikki Linnakangas wrote:
Attached is a patch to fix this, with a test case.
The patch did not compile, thanks to a last-minute change in a field
name. Here's a fixed version.
--
Heikki Linnakangas
Neon (https://neon.tech)
From ccb0bd36619f03055382205eddd7a0e9b64bba95 Mo
Hi,
Konstantin and I found an MVCC bug with:
- a prepared transaction,
- which has a subtransaction,
- on a hot standby,
- after starting the standby from a shutdown checkpoint.
See the test case in the attached patch to demonstrate this. The last
query in the new test returns incorrect result
On Wed, Jun 19, 2024 at 8:33 PM vignesh C wrote:
>
> On Tue, 18 Jun 2024 at 16:10, Amit Kapila wrote:
> >
> >
> > Agreed and I am not sure which is better because there is a value in
> > keeping the state name the same for both sequences and tables. We
> > probably need more comments in code and
On Thu, Jun 20, 2024 at 5:06 PM Ashutosh Bapat
wrote:
>
> On Thu, Jun 20, 2024 at 3:21 PM Amit Kapila wrote:
>>
>> On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat
>> wrote:
>> >
>> > On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila
>> > wrote:
>> >>
>> >> > I doubt that it would be that simple. The
Hi,
On Thu, Jun 13, 2024 at 04:59:50PM +0900, Michael Paquier wrote:
> Hi all,
>
> 2) Make the shmem pgstats pluggable so as it is possible for extensions
> to register their own stats kinds.
Thanks for the patch! I like the idea of having custom stats (it has also been
somehow mentioned in [1])
On Thu, 20 Jun 2024 at 12:52, vignesh C wrote:
>
> On Wed, 19 Jun 2024 at 21:43, Peter Eisentraut wrote:
> >
> > On 19.06.24 13:22, Shubham Khanna wrote:
> > > All the comments are handled.
> > >
> > > The attached Patch contains all the suggested changes.
> >
> > Please also take a look at the p
On 2024-06-20 Th 8:05 AM, Andrew Dunstan wrote:
On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote:
I have this patch series that fixes up the types of the new
incremental JSON API a bit. Specifically, it uses "const" throughout
so that the top-level entry points such as
pg_parse_json_increm
On Thu, Jun 20, 2024 at 4:58 PM John Naylor wrote:
>
> On Thu, Jun 20, 2024 at 8:12 AM Masahiko Sawada wrote:
>
> > On Thu, Jun 20, 2024 at 7:54 AM Tom Lane wrote:
> > >
> > > I don't know if there's any reason why the current order
> > > is preferable.)
> >
> > IIUC there is no particular reaso
Hello Team,
Good Day,
I have been working on adding a CustomScanState object in the executor
state in my project. As part of CustomScanState, I execute queries and
store their results in the Tuplestorestate object. After storing all tuples
in the Tuplestorestate, I retrieve each tuple and place it
Em qui., 20 de jun. de 2024 às 08:54, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 6/20/24 13:32, Ranier Vilela wrote:
> > Em qui., 20 de jun. de 2024 às 07:28, Tomas Vondra <
> > tomas.von...@enterprisedb.com> escreveu:
> >
> >> Hi,
> >>
> >> While running valgrind on 32-bit A
On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote:
I have this patch series that fixes up the types of the new
incremental JSON API a bit. Specifically, it uses "const" throughout
so that the top-level entry points such as pg_parse_json_incremental()
can declare their arguments as const char
On 6/20/24 13:32, Ranier Vilela wrote:
> Em qui., 20 de jun. de 2024 às 07:28, Tomas Vondra <
> tomas.von...@enterprisedb.com> escreveu:
>
>> Hi,
>>
>> While running valgrind on 32-bit ARM (rpi5 with debian), I got this
>> really strange report:
>>
>>
>> ==25520== Use of uninitialised value of
Em qua., 19 de jun. de 2024 às 20:52, Tom Lane escreveu:
> I wrote:
> > I hypothesize that the reason we're not seeing equivalent failures
> > on x86_64 is one of
>
> > 1. x86_64 valgrind is stupider than aarch64, and fails to track that
> > the contents of the SIMD registers are only partially d
On Thu, Jun 20, 2024 at 3:21 PM Amit Kapila wrote:
> On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila
> wrote:
> >>
> >> > I doubt that it would be that simple. The application will have to
> intervene and tell one of the employees tha
Em qui., 20 de jun. de 2024 às 07:28, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
> Hi,
>
> While running valgrind on 32-bit ARM (rpi5 with debian), I got this
> really strange report:
>
>
> ==25520== Use of uninitialised value of size 4
> ==25520==at 0x94A550: wrapper_handler (pqs
On Wed, 19 Jun 2024 at 17:22, David G. Johnston
wrote:
>
> On Wed, Jun 19, 2024 at 8:19 AM Jelte Fennema-Nio wrote:
>
>>
>> Because part of it would
>> only be relevant once we support upgrading from PG18. So for now the
>> upgrade_code I haven't actually run.
>
>
> Does it apply against v16? If
Another thing I changed in reporting was to report <= ns instead of < ns
This was inspired by not wanting to report "zero ns" as "< 1 ns" and
easiest was to change them all to <=
On Thu, Jun 20, 2024 at 12:41 PM Hannu Krosing wrote:
>
> (resending to list and other CC:s )
>
> Hi Tom
>
> This is
(resending to list and other CC:s )
Hi Tom
This is my current patch which also adds running % and optionally uses
faster way to count leading zeros, though I did not see a change from
that.
It also bucketizes first 128 ns to get better overview of exact behaviour.
We may want to put reporting
On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar wrote:
>
> On Tue, Jun 18, 2024 at 10:17 AM Dilip Kumar wrote:
> >
> > >
> > > I think the unbounded size of the vector could be a problem to store
> > > for each event. However, while researching previous discussions, it
> > > came to our notice that
Hi,
While running valgrind on 32-bit ARM (rpi5 with debian), I got this
really strange report:
==25520== Use of uninitialised value of size 4
==25520==at 0x94A550: wrapper_handler (pqsignal.c:108)
==25520==by 0x4D7826F: ??? (sigrestorer.S:64)
==25520== Uninitialised value was created by
Hi Tom,
Is there anything that could be back-patched with reasonable effort ?
--
Hannu
On Mon, Jun 17, 2024 at 6:37 PM Daniel Gustafsson wrote:
>
> > On 17 Jun 2024, at 16:56, Tom Lane wrote:
> > Daniel Gustafsson writes:
>
> >> I wonder if this will break any tools/scripts in prod which reli
On Sat, Jun 15, 2024 at 6:46 AM Jeff Davis wrote:
> Attached is a patch to use simplehash.h instead, which speeds things up
> enough to make them fairly close (from around 15% slower to around 8%).
+#define SH_HASH_KEY(tb, key) hash_uint32((uint32) key)
For a static inline hash for speed reaso
Hi, hackers
When I read [1], I think the "counted_by" attribute may also be valuable for
PostgreSQL.
The 'counted_by' attribute is used on flexible array members. The argument for
the attribute is the name of the field member in the same structure holding
the count of elements in the flexible a
On Fri, Jun 14, 2024 at 6:20 PM Yao Wang wrote:
>
> hi Tomas,
>
> So many thanks for your kind response and detailed report. I am working
> on locating issues based on your report/script and optimizing code, and
> will update later.
Hi,
This is an interesting proof-of-concept!
Given the above, I
On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat
wrote:
>
> On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila wrote:
>>
>> > I doubt that it would be that simple. The application will have to
>> > intervene and tell one of the employees that their reservation has failed.
>> > It looks natural that the
On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston
wrote:
> On Wed, Jun 19, 2024 at 8:29 AM jian he wrote:
>>
>> On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack wrote:
>> >
>> > Hi,
>> >
>> > On 06/17/24 02:43, Amit Langote wrote:
>> > > context_item expression can be a value of
>> > > any type tha
On 6/20/24 07:55, Peter Eisentraut wrote:
> The pg_combinebackup --clone option currently doesn't work at all. Even
> on systems where it should it be supported, you'll always get a "file
> cloning not supported on this platform" error.
>
> The reason is this checking code in pg_combinebackup.c:
1 - 100 of 109 matches
Mail list logo
