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_class.relacl), …. To call,
> just cast the OID to the appro
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:
#if (defined(HAVE_COPYFILE) && defined(COPYFILE_
On Wed, Jun 19, 2024 at 08:37:17AM -0500, Nathan Bossart wrote:
> My understanding is that you basically have to restart the upgrade from
> scratch if that happens. I suppose there could be a problem if you try to
> use the half-upgraded cluster after a crash, but I imagine you have a good
> chanc
On Wed, Jun 19, 2024 at 11:00:00PM +0300, Alexander Lakhin wrote:
> Starting from af0e7deb4, the following script:
> [...]
> 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
Open item added for this
On Thu, Jun 20, 2024 at 10:11:37AM +0900, Masahiko Sawada wrote:
> I agree with radixtree-fix-proposed.patch. Even if we zero more fields
> in the node it would not add noticeable overheads.
This needs to be tracked as an open item, so I have added one now.
--
Michael
signature.asc
Description:
On Thu, Jun 20, 2024 at 2:35 AM Euler Taveira wrote:
>
> I will open new threads soon if you don't.
>
Okay, thanks. I'll wait for you to start new threads and then we can
discuss the respective problems in those threads.
--
With Regards,
Amit Kapila.
Hi, here are my review comments for v8-0001.
==
Commit message.
1.
It seems like the patch name was accidentally omitted, so it became a
mess when it defaulted to the 1st paragraph of the commit message.
==
contrib/test_decoding/test_decoding.c
2.
+ data->include_generated_columns = tru
https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> Separable, nontrivial things not fixed in the attached patch stack:
> - Trouble is possible, I bet, if the system crashes between the inplace-update
> memcpy() and XLogInsert(). See the new XXX comment below the memcpy().
That co
Hi,
On Thu, Jun 20, 2024 at 7:54 AM Tom Lane wrote:
>
> I wrote:
> > I've reproduced what looks like about the same thing on
> > my Pi 4 using Fedora 38: just run "make installcheck-parallel"
> > under valgrind, and kaboom. Definitely needs investigation.
>
> The problem appears to be that RT_AL
On Wed, Jun 19, 2024 at 2:21 PM Amit Kapila wrote:
>
...
>
> Thanks for sharing examples. Your proposed patch as-is looks good to
> me. We should back-patch this unless you or someone else thinks
> otherwise.
>
Hi Amit.
I modified the patch text slightly according to Peter E's suggestion [1].
I
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 into a single file, or support both?
> - Should this do like custom RMGRs and ass
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 defined.
> 2. x86_64 valgrind is smarter than aarch64, and is able to
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 defined.
> 2. x86_64 valgrind is smarter than aarch64, and is able to
I wrote:
> I've reproduced what looks like about the same thing on
> my Pi 4 using Fedora 38: just run "make installcheck-parallel"
> under valgrind, and kaboom. Definitely needs investigation.
The problem appears to be that RT_ALLOC_NODE doesn't bother to
initialize the chunks[] array when makin
On Tue, Jun 18, 2024 at 08:07:27PM -0700, Andres Freund wrote:
> > > > 1) Sometimes hangs hard on windows if started processes have not been
> > > > shut
> > > >down before script exits.
> It reliably reproduces if I comment out
> the lines below
> # explicitly shut down psql instances grac
On Thu, Jun 13, 2024 at 10:56 PM Joseph Koshakow wrote:
On Thu, Jun 13, 2024 at 10:48 PM Joseph Koshakow
wrote:
>I've attached
>v4-0002-Handle-overflow-in-money-arithmetic.patch which adds some
>overflow checks and tests. I didn't address the float
multiplication
On Tue, Jun 18, 2024 at 10:20:06PM +0200, Daniel Gustafsson wrote:
> Nice catch, +1 for committing.
Committed.
--
nathan
Tomas Vondra writes:
> On 6/19/24 17:11, Tom Lane wrote:
>> What's the test scenario that triggers this?
> I haven't investigated that yet, I just ran "make check".
I've reproduced what looks like about the same thing on
my Pi 4 using Fedora 38: just run "make installcheck-parallel"
under valgri
On Wed, Jun 19, 2024, at 12:51 AM, Amit Kapila wrote:
> Ideally, invalidated slots shouldn't create any problems but it is
> better that we discuss this also as a separate problem in new thread.
Ok.
> > Do you have any other scenarios in mind?
> >
>
> No, so we have three issues to discuss (a) s
On Fri, Jun 14, 2024 at 3:46 PM Alexander Korotkov wrote:
> On Wed, Jun 12, 2024 at 11:36 AM Kartyshov Ivan
> wrote:
> >
> > Hi, Alexander, Here, I made some improvements according to your
> > discussion with Heikki.
> >
> > On 2024-04-11 18:09, Alexander Korotkov wrote:
> > > On Thu, Apr 11, 202
Hello Heikki,
11.03.2024 10:09, Heikki Linnakangas wrote:
On 10/03/2024 22:59, Thomas Munro wrote:
On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas wrote:
Barring objections, I'll commit the attached.
+1
Pushed, thanks!
Please look at a new anomaly, that I've discovered in master.
St
On Wed, Jun 19, 2024 at 6:02 PM Pavel Borisov wrote:
> On Wed, 19 Jun 2024 at 05:27, Alexander Korotkov wrote:
>>
>> On Tue, Jun 18, 2024 at 4:14 PM Pavel Borisov wrote:
>> >> Controls if the query planner will produce a plan which will provide
>> >> GROUP BY keys presorted in the order of keys
On Wed, Jun 19, 2024 at 03:14:16PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> The attached patch removes these hooks and enhances the error message to
>> look like this:
>
>> FATAL: too many backends configured
>> DETAIL: "max_connections" (262100) plus "autovacuum_max_workers
Nathan Bossart writes:
> The attached patch removes these hooks and enhances the error message to
> look like this:
> FATAL: too many backends configured
> DETAIL: "max_connections" (262100) plus "autovacuum_max_workers" (3)
> plus "max_worker_processes" (8) plus "max_wal_senders"
Nathan Bossart writes:
> While working on an idea from another thread [0], I noticed that each of
> max_connections, max_worker_process, max_autovacuum_workers, and
> max_wal_senders have a check hook that verifies the sum of those GUCs does
> not exceed a certain value. Then, in InitializeMaxBac
On Wed, 19 Jun 2024 at 19:55, Tom Lane wrote:
>
> Jelte Fennema-Nio writes:
> > On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
> >> I have a feeling that this might be pretty annoying to implement, and
> >> if that is true, then never mind.
>
> > Based on a quick look it's not trivial, but als
While working on an idea from another thread [0], I noticed that each of
max_connections, max_worker_process, max_autovacuum_workers, and
max_wal_senders have a check hook that verifies the sum of those GUCs does
not exceed a certain value. Then, in InitializeMaxBackends(), we do the
same check on
Thanks for taking a look at my patches, Álvaro!
On Wed, Jun 19, 2024 at 12:51 PM Alvaro Herrera wrote:
>
> On 2024-Jun-14, Melanie Plageman wrote:
>
> > Subject: [PATCH v21 12/20] Update variable names in bitmap scan descriptors
> >
> > The previous commit which added BitmapTableScanDesc and
> >
> On 19 Jun 2024, at 17:09, Nathan Bossart wrote:
> I've been using 'ts -i' as Peter suggested
Oh nice, I had forgotten about that one, thanks for the reminder!
--
Daniel Gustafsson
On Wed, Jun 19, 2024 at 12:38 PM Tomas Vondra
wrote:
>
>
>
> On 6/19/24 17:55, Melanie Plageman wrote:
> > On Tue, Jun 18, 2024 at 6:02 PM Tomas Vondra
> > wrote:
>
> > From your v22b-0017-review.patch
> >
> > diff --git a/src/include/access/relscan.h b/src/include/access/relscan.h
> > index 036e
On 2024-02-13 Tu 7:00 AM, Marco Atzeri wrote:
On 22/11/2023 13:02, Andrew Dunstan wrote:
I've been trying to get meson working with Cygwin. On a fresh install
(Cygwin 3.4.9, gcc 11.4.0, meson 1.0.2, ninja 1.11.1) I get a bunch
of errors like this:
ERROR: incompatible library
"/home/andr
On Wed, Jun 19, 2024 at 1:39 PM Alvaro Herrera wrote:
> FWIW I don't think HEAP_XMAX_INVALID as purely a hint.
> HEAP_XMAX_COMMITTED is a hint, for sure, as is HEAP_XMIN_COMMITTED on
> its own; but as far as I recall, the INVALID flags must persist once
> set.
Seems we disagree on some pretty fun
Jelte Fennema-Nio writes:
> On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
>> I have a feeling that this might be pretty annoying to implement, and
>> if that is true, then never mind.
> Based on a quick look it's not trivial, but also not super bad.
> Basically it seems like in src/backend/ca
On Wed, 19 Jun 2024 at 17: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?
This indeed does
The order of json related aggregate functions in the docs is currently
like this:
[...]
json_agg
json_objectagg
json_object_agg
json_object_agg_strict
json_object_agg_unique
json_arrayagg
json_object_agg_unique_strict
max
min
range_agg
range_intersect_agg
json_agg_strict
[...]
json_arrayagg and
On 2024-Jun-19, Peter Geoghegan wrote:
> On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov wrote:
> > So it is quite different code paths, and one could not be used
> > to decline or justify other.
>
> The point is that we shouldn't need to rely on what is formally a
> hint. It might be useful to use
On Wed, Jun 19, 2024 at 1:00 PM Yura Sokolov wrote:
> So it is quite different code paths, and one could not be used
> to decline or justify other.
The point is that we shouldn't need to rely on what is formally a
hint. It might be useful to use the hint to decide whether or not
freezing now actu
On 2024-Jun-14, Anton A. Melnikov wrote:
> Hello!
>
> The src/backend/access/heap/README.tuplock says about HEAP_XMAX_INVALID bit
> that "Any tuple with this bit set does not have a valid value stored in XMAX."
>
> Found that FreezeMultiXactId() tries to process such an invalid multi xmax
> and
I had occasion to run the same benchmark you described in the initial
email in this thread. To do so I applied patch series v49 on top of
07cb29737a4e, which is just one that happened to have the same date as
v49.
I then used a script like this (against a server having
plan_cache_mode=force_gener
18.06.2024 18:47, Peter Geoghegan пишет:
On Tue, Jun 18, 2024 at 10:29 AM Maxim Orlov wrote:
Maybe, I'm too bold, but looks like a kinda bug to me. At least, I don't
understand why we do not check the HEAP_XMAX_INVALID flag.
My guess is nobody noticed, that MultiXactIdIsValid call does not ch
On 2024-Jun-14, Melanie Plageman wrote:
> Subject: [PATCH v21 12/20] Update variable names in bitmap scan descriptors
>
> The previous commit which added BitmapTableScanDesc and
> BitmapHeapScanDesc used the existing member names from TableScanDescData
> and HeapScanDescData for diff clarity. This
On 6/19/24 17:55, Melanie Plageman wrote:
> On Tue, Jun 18, 2024 at 6:02 PM Tomas Vondra
> wrote:
>>
>> I went through v22 to remind myself of what the patches do and do some
>> basic review - I have some simple questions / comments for now, nothing
>> major. I've kept the comments in separate
Peter Eisentraut writes:
> AFAICT, pg_test_timing doesn't use gettimeofday(), so this doesn't
> really address the original question.
It's not exactly hard to make it do so (see attached).
I tried this on several different machines, and my conclusion is that
gettimeofday() reports full microsec
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 proposed patch for virtual generated
columns [0] and consider how that would affect your patch. I think your
feature can only replicat
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 that can be cast to jsonb. This includes types
> > > such as char, text
On Wed, Jun 19, 2024 at 05:34:52PM +0200, Peter Eisentraut wrote:
> I'm not really sure all this here is worth solving. I think requiring
> things like --single or --boot to be first seems ok, and the alternatives
> just make things more complicated.
Yeah, I'm fine with doing something more like
Thanks Hikki, for going through the changes.
> +/* Commenting for XLC
> + * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
> + * expansions of ginCompareItemPointers() "long long" arithmetic. To take
> + * advantage of inlining, build a 64-bit PostgreSQL.
> +#if defined(__ILP
On 18.06.24 08:40, Peter Smith wrote:
For now, I have provided just a simple patch for the "Generated
Columns" section [3]. Perhaps it is enough.
Makes sense.
+ Generated columns are skipped for logical replication, and cannot be
+ specified in a CREATE PUBLICATION column-list.
Maybe remove t
On 6/19/24 17:11, Tom Lane wrote:
> Tomas Vondra writes:
>> I tried running master under valgrind on 64-bit ARM (rpi5 running debian
>> 12.5), and I got some suspicous reports, all related to the radixtree
>> code used by tidstore.
>
> What's the test scenario that triggers this?
>
I haven't
On 18.06.24 07:47, Andrey M. Borodin wrote:
On 19 Mar 2024, at 13:28, Peter Eisentraut wrote:
I feel that we don't actually have any information about this portability
concern. Does anyone know what precision we can expect from gettimeofday()?
Can we expect the full microsecond precision
On 19.06.24 16:04, Nathan Bossart wrote:
What about just inlining --version and --help e.g.
else if (strcmp(argv[i], "--version") == 0 || strcmp(argv[i], "-V") == 0)
{
fputs(PG_BACKEND_VERSIONSTR, stdout);
exit(0);
}
I'm fine with being more persnickety about the other options; they
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 that can be cast to jsonb. This includes types
> > such as char, text, bpchar,
> > character varying, and bytea (with
> > ENCODING UTF
On Sat, Jun 1, 2024 at 8:08 PM Jelte Fennema-Nio wrote:
> Writing the sql migration scripts that are run by CREATE EXTENSION and
> ALTER EXTENSION UPDATE are security minefields for extension authors.
> One big reason for this is that search_path is set to the schema of the
> extension while runni
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 so, branch off there, apply it, then upgrade
from the v16 branch to
Attached is an updated version of this patch that fixes a few issues
that CI reported (autoconf, compiler warnings and broken docs).
I also think I changed the pg_upgrade to do the correct thing, but I'm
not sure how to test this (even manually). Because part of it would
only be relevant once we s
Tomas Vondra writes:
> I tried running master under valgrind on 64-bit ARM (rpi5 running debian
> 12.5), and I got some suspicous reports, all related to the radixtree
> code used by tidstore.
What's the test scenario that triggers this?
regards, tom lane
On Wed, Jun 19, 2024 at 04:50:59PM +0200, Daniel Gustafsson wrote:
> When doing performance hacking on pg_upgrade it's often important to see
> individual runtimes to isolate changes. I've written versions of the attached
> patch numerous times, and I wouldn't be surprised if others have done the
Hi, Alexander!
On Wed, 19 Jun 2024 at 05:27, Alexander Korotkov
wrote:
> On Tue, Jun 18, 2024 at 4:14 PM Pavel Borisov
> wrote:
> >> Controls if the query planner will produce a plan which will provide
> GROUP BY keys presorted in the order of keys of a child
> node of the plan, such as an inde
Hi Team,
Please find the attached patch, which resumes the AIX support with gcc alone.
We have
removed changes wrt to XLC on AIX.
We are also continuing to work on the XLC and IBM-clang(openXLC) specific patch
as well.
Once we get an approval for the above patch we can submit a subsequent patch
When doing performance hacking on pg_upgrade it's often important to see
individual runtimes to isolate changes. I've written versions of the attached
patch numerous times, and I wouldn't be surprised if others have done the same.
Is there any interest in adding something like the attached to pg_u
Hi,
I tried running master under valgrind on 64-bit ARM (rpi5 running debian
12.5), and I got some suspicous reports, all related to the radixtree
code used by tidstore. I'm used to valgrind on arm sometimes reporting
harmless issues, but this seems like it might be an actual issue.
I'm attaching
Richard Guo писал(а) 2024-06-19 16:30:
On Wed, Jun 19, 2024 at 12:49 PM Tom Lane wrote:
Richard Guo writes:
> It seems to me that the new operator is somewhat artificial, since it is
> designed to support a mergejoin but lacks a valid commutator. So before
> we proceed to discuss the fix, I'd
On Wed, 19 Jun 2024 at 07:35, Joel Jacobson wrote:
> Hello hackers,
>
> Currently, obtaining the Access Control List (ACL) for a database object
> requires querying specific pg_catalog tables directly, where the user
> needs to know the name of the ACL column for the object.
>
I have no idea how
On Wed, Jun 19, 2024, at 15:51, Ranier Vilela wrote:
> Regarding the patch, could it be written in the following style?
Thanks for nice improvement. New version attached.
Best,
Joel
v2-0001-Add-pg_get_acl.patch
Description: Binary data
Hi,
On Mon, Jun 17, 2024 at 05:57:05PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Jun 17, 2024 at 12:24:46PM -0400, Robert Haas wrote:
> > So to try to sum up here: I'm not sure I agree with this design. But I
> > also feel like the design is not as clear and consistently implemented
> > as
On Tue, Jun 18, 2024 at 09:42:32PM -0400, Greg Sabino Mullane wrote:
> If I am reading your patch correctly, we have lost the behavior of least
> surprise in which the first "meta" argument overrides all others:
>
> $ bin/postgres --version --boot --extrastuff
> postgres (PostgreSQL) 16.2
Right,
Em qua., 19 de jun. de 2024 às 10:28, Ranier Vilela
escreveu:
> Em qua., 19 de jun. de 2024 às 10:26, Joel Jacobson
> escreveu:
>
>> Hi Ranier,
>>
>> Thanks for looking at this.
>>
>> I've double-checked the patch I sent, and it works fine.
>>
>> I think I know the cause of your problem:
>>
>> S
Hi
On Tue, 18 Jun 2024 at 17:08, Andres Freund wrote:
> > None of the dependencies include cmake files for distribution on Windows,
> > so there are no additional files to tell meson to search for. The same
> > applies to pkgconfig files, which is why the EDB team had to manually
> craft
> > the
On Tue, Jun 18, 2024 at 02:00:34PM -0400, Bruce Momjian wrote:
> While the license we are concerned about does not have this clause, it
> does have:
>
>2. Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following
> dis
On Wed, 19 Jun 2024 at 15:17, Robert Haas wrote:
>
> On Fri, Jun 14, 2024 at 5:29 PM Nathan Bossart
> wrote:
> > On Wed, Jun 12, 2024 at 09:41:01AM -0500, Nathan Bossart wrote:
> > > Actually, I think you are right that we need a manual checkpoint, except I
> > > think we need it to be after pre
On Wed, Jun 19, 2024 at 09:17:00AM -0400, Robert Haas wrote:
> OK, I have a (probably) stupid question. The comment says:
>
> + * In binary upgrade mode, we can skip this checkpoint because neither of
> + * these problems applies: we don't ever replay the WAL generated during
> + * pg_upgrade, and
Hi Robert,
On Wed, Jun 19, 2024 at 5:50 PM Robert Haas wrote:
>
> On Wed, Jun 19, 2024 at 7:49 AM Ashutosh Sharma wrote:
> > If the dependency is more, this can hit max_locks_per_transaction
> > limit very fast.
>
> Your experiment doesn't support this conclusion. Very few users would
> have 15
On Mon, Jun 17, 2024 at 9:07 PM Markus Winand wrote:
>
>
> I think it affects the following feature IDs:
>
> - T821, Basic SQL/JSON query operators
> For JSON_VALUE, JSON_TABLE and JSON_EXISTS
> - T828, JSON_QUERY
>
> Also, how hard would it be to add the functions that accept
> character
On Wed, Jun 19, 2024 at 12:49 PM Tom Lane wrote:
> Richard Guo writes:
> > It seems to me that the new operator is somewhat artificial, since it is
> > designed to support a mergejoin but lacks a valid commutator. So before
> > we proceed to discuss the fix, I'd like to know whether this is a va
Em qua., 19 de jun. de 2024 às 10:26, Joel Jacobson
escreveu:
> Hi Ranier,
>
> Thanks for looking at this.
>
> I've double-checked the patch I sent, and it works fine.
>
> I think I know the cause of your problem:
>
> Since this is a catalog change, you need to run `make clean`, to ensure
> the c
Hi Ranier,
Thanks for looking at this.
I've double-checked the patch I sent, and it works fine.
I think I know the cause of your problem:
Since this is a catalog change, you need to run `make clean`, to ensure the
catalog is rebuilt,
followed by the usual `make && make install`.
You also need
On Fri, Jun 14, 2024 at 5:29 PM Nathan Bossart wrote:
> On Wed, Jun 12, 2024 at 09:41:01AM -0500, Nathan Bossart wrote:
> > Actually, I think you are right that we need a manual checkpoint, except I
> > think we need it to be after prepare_new_globals(). set_frozenxids()
> > connects to each data
On Fri, 14 Jun 2024 at 23:29, Nathan Bossart wrote:
>
> On Wed, Jun 12, 2024 at 09:41:01AM -0500, Nathan Bossart wrote:
> > Actually, I think you are right that we need a manual checkpoint, except I
> > think we need it to be after prepare_new_globals(). set_frozenxids()
> > connects to each data
Em qua., 19 de jun. de 2024 às 08:35, Joel Jacobson
escreveu:
> Hello hackers,
>
> Currently, obtaining the Access Control List (ACL) for a database object
> requires querying specific pg_catalog tables directly, where the user
> needs to know the name of the ACL column for the object.
>
> Consid
On Wed, Jun 19, 2024 at 7:49 AM Ashutosh Sharma wrote:
> If the dependency is more, this can hit max_locks_per_transaction
> limit very fast.
Your experiment doesn't support this conclusion. Very few users would
have 15 separate user-defined types in the same table, and even if
they did, and drop
On Tue, Jun 18, 2024 at 11:55 PM Amit Kapila wrote:
> We can close the open item pointing to this thread.
Done, and for the record I also asked for the thread to be split, back
on May 22.
IMHO, we shouldn't add open items pointing to general complaints like
the one that started this thread. Open
On Mon, Jun 17, 2024 at 1:57 PM Peter Smith wrote:
>
> Hi, here are my review comments for patch v7-0001.
>
> ==
> 1. GENERAL - \dRs+
>
> Shouldn't the new SUBSCRIPTION parameter be exposed via "describe"
> (e.g. \dRs+ mysub) the same as the other boolean parameters?
>
> ==
> Commit messag
Hi,
If the dependency is more, this can hit max_locks_per_transaction
limit very fast. Won't it? I just tried this little experiment with
and without patch.
1) created some UDTs (I have just chosen some random number, 15)
do $$
declare
i int := 1;
type_name text;
begin
while i <= 15 l
> Few comments:
> 1) Here tab1 and tab2 are exactly the same tables, just check if the
> table tab1 itself can be used for your tests.
> @@ -24,20 +24,50 @@ $node_publisher->safe_psql('postgres',
> "CREATE TABLE tab1 (a int PRIMARY KEY, b int GENERATED ALWAYS
> AS (a * 2) STORED)"
> );
> +
Hello hackers,
Currently, obtaining the Access Control List (ACL) for a database object
requires querying specific pg_catalog tables directly, where the user
needs to know the name of the ACL column for the object.
Consider:
```
CREATE USER test_user;
CREATE USER test_owner;
CREATE SCHEMA test_s
> Hi Shubham, thanks for providing a patch.
> I have some comments for v6-0001.
>
> 1. create_subscription.sgml
> There is repetition of the same line.
>
> +
> + Specifies whether the generated columns present in the tables
> + associated with the subscription should be r
Here is the output of nanosecond-precision pg_test_timing on M1 Macbook Air
/work/postgres/src/bin/pg_test_timing % ./pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 21.54 ns
Histogram of timing durations:
<= ns % of total running % count
0
On 18.06.24 00:40, David E. Wheeler wrote:
On Jun 12, 2024, at 11:57, Peter Geoghegan wrote:
That having been said, it would be useful if there was a community web
resource for this -- something akin to coverage.postgresql.org, but
with differential ABI breakage reports. You can see an example
On 18.06.24 00:37, David E. Wheeler wrote:
ABI Policy
==
The PostgreSQL core team maintains two application binary interface (ABI)
guarantees: one for major releases and one for minor releases.
Major Releases
--
Applications that use the PostgreSQL APIs
This is probably
On Wed, Jun 19, 2024 at 2:36 PM shveta malik wrote:
>
> On Wed, Jun 19, 2024 at 1:52 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 18, 2024 at 3:29 PM shveta malik wrote:
> > > On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar
> > > wrote:
> > >
> > > I tried to work out a few scenarios with this, wher
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 first one to reserve the room should get the
> reservation, but imple
On 15.06.24 01:35, Jeff Davis wrote:
On Thu, 2024-06-06 at 11:37 -0700, Jeff Davis wrote:
I think this patch series is a nice cleanup, as well, making libc
more
like the other providers and not dependent on global state.
New rebased series attached with additional cleanup. Now that
pg_locale_
On Wed, Jun 19, 2024 at 1:52 PM Dilip Kumar wrote:
>
> On Tue, Jun 18, 2024 at 3:29 PM shveta malik wrote:
> > On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar wrote:
> >
> > I tried to work out a few scenarios with this, where the apply worker
> > will wait until its local clock hits 'remote_commit
On 09.02.24 14:19, Jim Jones wrote:
> v9 attached with rebase due to changes done to primnodes.h in 615f5f6
>
v10 attached with rebase due to changes in primnodes, parsenodes.h, and
gram.y
--
Jim
From fbd98149d50fe19b886b30ed49b9d553a18f30b4 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Wed,
At Tue, 18 Jun 2024 09:18:28 +0200, Peter Eisentraut
wrote in
> Under the topic of getting rid of thread-unsafe functions in the
> backend [0], here is a patch series to deal with strtok().
>
> Of course, strtok() is famously not thread-safe and can be replaced by
> strtok_r(). But it also has
On Tue, Jun 18, 2024 at 3:29 PM shveta malik wrote:
> On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar wrote:
>
> I tried to work out a few scenarios with this, where the apply worker
> will wait until its local clock hits 'remote_commit_tts - max_skew
> permitted'. Please have a look.
>
> Let's say,
On 15.06.24 01:46, Jeff Davis wrote:
* instead of a hardwired set of special collation IDs, have a single-
element "last collation ID" to check before doing the hash lookup?
I'd imagine that method could be very effective.
FYI - I applied this latest patch and re-ran the original failing test
script 10 times (e.g. 10 x 100 test iterations; it took 4+ hours).
There were zero failures observed in my environment.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
98 matches
Mail list logo
