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
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;
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
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
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
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
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
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,
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
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
> >
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:
>>
>>
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
> >
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
>
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
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,
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
>
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
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
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
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
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
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.
>
>
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
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.
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
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
> 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)"
> );
>
> 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
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
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
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,
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
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
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
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
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
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
On Mon, Jun 17, 2024 at 10:07 PM Markus Winand wrote:
> > On 17.06.2024, at 08:20, Amit Langote wrote:
> >>> 2. EMPTY [ARRAY|OBJECT] ON ERROR implies ERROR ON EMPTY
> >>>
> >>> 17beta1=# SELECT JSON_QUERY('[]', '$[*]' EMPTY ARRAY ON ERROR) a;
> >>>a
> >>>
> >>>[]
> >>> (1 row)
On Thu, Jun 13, 2024 at 5:04 PM Amit Langote wrote:
> On Thu, Jun 6, 2024 at 6:20 PM Amit Langote wrote:
> >
> > Hi,
> >
> > Alvaro reported off-list that the following should really fail,
> > because the jsonpath expression refers to a PASSING variable that
> > doesn't exist:
> >
> > select
> On Jun 18, 2024, at 20:42, Melanie Plageman wrote:
>
> External Email
>
> On Mon, Jun 17, 2024 at 9:12 PM Li, Yong wrote:
>>
>> As a newcomer, when I was walking through the code looking for WAL replay
>> related code, it was relatively easy for me to find them for the B-Tree
>> access
On Tue, Jun 11, 2024 at 3:12 PM Ashutosh Bapat
wrote:
>
> On Sat, Jun 8, 2024 at 3:52 PM Amit Kapila wrote:
>>
>> On Fri, Jun 7, 2024 at 5:39 PM Ashutosh Bapat
>> wrote:
>> >
>> > On Thu, Jun 6, 2024 at 5:16 PM Nisha Moond
>> > wrote:
>> >>
>> >> >
>> >>
>> >> Here are more use cases of the
On Tuesday, June 18, 2024, Tom Lane wrote:
> Yugo NAGATA writes:
> > On Tue, 18 Jun 2024 20:56:58 -0700
> > "David G. Johnston" wrote:
> >> But it is neither a keyword nor an identifier.
>
> The lexer would be quite surprised by your claim that NULL isn't
> a keyword. Per
On Tue, Jun 18, 2024 at 7:44 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, June 13, 2024 2:11 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> > On Wed, Jun 5, 2024 at 3:32 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > This time at PGconf.dev[1], we had some discussions regarding this
> > > project.
Yugo NAGATA writes:
> On Tue, 18 Jun 2024 20:56:58 -0700
> "David G. Johnston" wrote:
>> But it is neither a keyword nor an identifier.
The lexer would be quite surprised by your claim that NULL isn't
a keyword. Per src/include/parser/kwlist.h, NULL is a keyword,
and a fully reserved one at
On Tue, Jun 11, 2024 at 4:21 AM John H wrote:
>
> Building on bf279ddd1c, this patch introduces a GUC
> 'standby_slot_names_from_syncrep' which allows logical failover slots
> to wait for changes to have been synchronously replicated before sending
> the decoded changes to logical subscribers.
>
On Tue, 18 Jun 2024 20:56:58 -0700
"David G. Johnston" wrote:
> On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote:
>
> >
> > It may be a trivial thing but I am not sure we need to mention case
> > insensitivity
> > here, because all keywords and unquoted identifiers are case-insensitive in
> >
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
returns the approximated value - the position of the last full WAL page [1].
If
Richard Guo writes:
> On Mon, Jun 17, 2024 at 10:51 PM Alexander Pyhalov
> wrote:
>> ERROR: could not find commutator for operator XXX
> 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
On Wed, Jun 19, 2024 at 6:46 AM Peter Smith wrote:
>
> On Tue, Jun 18, 2024 at 9:40 PM Amit Kapila wrote:
> >
> > On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
> > >
> > > While reviewing another thread that proposes to include "generated
> > > columns" support for logical replication [1]
On Mon, Jun 17, 2024 at 10:51 PM Alexander Pyhalov
wrote:
> There's the following inconsistency between try_mergejoin_path() and
> create_mergejoin_plan().
> When clause operator has no commutator, we can end up with mergejoin
> path.
> Later create_mergejoin_plan() will call
On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote:
>
> It may be a trivial thing but I am not sure we need to mention case
> insensitivity
> here, because all keywords and unquoted identifiers are case-insensitive in
> PostgreSQL and it is not specific to NULL.
>
But it is neither a keyword nor
On Tue, Jun 18, 2024 at 12:13 PM Peter Eisentraut wrote:
>
> On 18.06.24 05:59, Amit Kapila wrote:
> >> 1. After promotion, the pre-existing replication objects should be
> >> removed (either optionally or always), otherwise, it can lead to a new
> >> subscriber not being able to restart or
On Tue, Jun 18, 2024 at 12:41 PM Euler Taveira wrote:
>
> On Tue, Jun 18, 2024, at 12:59 AM, Amit Kapila wrote:
>
> On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
> >
> > On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> > >
> > > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> >
>
> Probably at the 90% complete mark. Minimal index entries, not as thorough
> a look-about of the existing documentation as I'd like. Probably some
> wording and style choices to tweak. Figured better to get feedback now
> before I go into polish mode. In particular, tweaking a
Hi,
On Wed, Jun 19, 2024 at 6:06 AM John H wrote:
>
> Hi Ashutosh,
>
> Thanks for clarifying.
>
> > not standalone functions created independently
>
> I'm wondering why we wouldn't want to extend that functionality so
> that if users (including superusers) do want to automatically
> configure
Hi,
On 2024-06-18 12:00:13 -0700, Andres Freund wrote:
> On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> > > 1) Sometimes hangs hard on windows if started processes have not been shut
> > >down before script exits. I've mostly encountered this via the
> > > buildfarm /
> > >CI, so I
Richard Guo 于2024年6月18日周二 17:24写道：
> On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> > Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
> >
> > * I think we should not consider materializing the cheapest inner path
> > if we're doing JOIN_UNIQUE_INNER, because in this
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
What about just inlining --version and --help e.g.
else if (strcmp(argv[i],
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 index scan. When disabled, the query planner
>> will produce a plan with GROUP
On Tue, Jun 18, 2024 at 8:49 PM Masahiko Sawada wrote:
> > At least I couldn't find anywhere in the docs where we have
> > described the relationship between these columns before. Thoughts?
>
> It would be a good idea to improve the documentation, but I think that
> we cannot simply compare these
On Tue, Jun 18, 2024 at 9:40 PM Amit Kapila wrote:
>
> On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
> >
> > While reviewing another thread that proposes to include "generated
> > columns" support for logical replication [1] I was looking for any
> > existing PostgreSQL documentation on
On Sat, Jun 15, 2024 at 8:47 PM Robert Treat wrote:
>
> On Thu, Jun 13, 2024 at 9:22 PM Masahiko Sawada wrote:
> > On Fri, Jun 14, 2024 at 9:57 AM Masahiko Sawada
> > wrote:
> > > On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier
> > > wrote:
> > > > On Thu, Jun 13, 2024 at 08:38:05PM -0400,
On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
> Another one:
>
> Have a general cap of 64, but additionally limit it to something like
> max(1, min(WORKER_CAP, max_connections / 4))
>
> so that cases like tap tests don't end up allocating vastly more worker slots
> than
Hi Ashutosh,
Thanks for clarifying.
> not standalone functions created independently
I'm wondering why we wouldn't want to extend that functionality so
that if users (including superusers) do want to automatically
configure search_path
when they're creating functions it's available.
> The
On 03/06/2024 21:21, David E. Wheeler wrote:
On Jun 3, 2024, at 14:58, Andres Freund wrote:
Hi,
Hello Andres.
Are there notes for the session?
Yes, but not posted yet. Here’s what Andreas 'ads' Scherbaum sent me for that
bit of the conversation:
* Core is focused on core ABI stability
On Tue, 18 Jun 2024 at 15:14, Richard Guo wrote:
>
> On Tue, Jun 18, 2024 at 10:53 AM David Rowley wrote:
> > I think the best solution is to apply the attached. I didn't test,
> > but it should fix the issue you reported and also ensure that
> > MemoizePath.calls is never zero, which would
Hi,
On 2024-06-18 16:09:09 -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> > I just don't see much point in reserving 256 worker "possibilities", tbh. I
> > can't think of any practical system where it makes sense to use this much
> > (nor
> > do I
Hi,
On 2024-06-18 08:36:57 -0500, Justin Pryzby wrote:
> On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> > Hm. There actually already is the mingw ccache installed. The images for
> > mingw and msvc used to be separate (for startup performance when using
> > containers), but we
On Tue, Jun 18, 2024 at 01:32:38PM -0700, Andres Freund wrote:
> On 2024-06-18 13:50:46 -0500, Nathan Bossart wrote:
>> Have we ruled out further adjustments to the cost parameters as a first
>> step?
>
> I'm not against that, but I it doesn't address the issue that with the current
> logic one
On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> I just don't see much point in reserving 256 worker "possibilities", tbh. I
> can't think of any practical system where it makes sense to use this much (nor
> do I think it's going to be reasonable in the next 10 years) and it's just
Andres Freund writes:
> I wonder if there's an argument the "persistent" TopTransactionContext should
> live under a different name outside of transactions, to avoid references to it
> working in a context where it's not valid? It's probably not worth it, but
> not sure.
Hm. We could stash
Hi,
On 2024-06-18 14:00:00 -0500, Nathan Bossart wrote:
> On Mon, Jun 03, 2024 at 04:24:27PM -0700, Andres Freund wrote:
> > On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
> >> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
> >> > Why do we think that increasing the number of
On 2024-06-18 Tu 3:00 PM, Andres Freund wrote:
Hi,
On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
The one
thing I
Hi,
On 2024-06-18 13:50:46 -0500, Nathan Bossart wrote:
> Have we ruled out further adjustments to the cost parameters as a first
> step?
I'm not against that, but I it doesn't address the issue that with the current
logic one set of values just isn't going to fit a 60MB that's allowed to burst
Hi,
On 2024-06-18 15:28:03 -0400, Tom Lane wrote:
> After awhile I had an epiphany: what we should do is make
> CommitTransactionCommand restore the memory context that was active
> before StartTransactionCommand. That's what we want in every place
> that was cognizant of this issue, and it
> On 18 Jun 2024, at 21:50, Nathan Bossart wrote:
>
> I noticed that the "check" variable, which is used for "pg_upgrade
> --check", is commented as follows:
>
> bool check; /* true -> ask user for permission to make
> * changes */
>
> This comment was first added when pg_upgrade was
/*
- * Create a toplevel context for the transaction.
+ * Likewise, if this is the first time through, create a top-level context
+ * for transaction-local data. This context will be reset at transaction
+ * end, and then re-used in later transactions.
*/
- TopTransactionContext =
- AllocS
Hi,
On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
> > On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > > > The one
> > > > thing I know about that *I* think is
On Mon, Jun 03, 2024 at 04:24:27PM -0700, Andres Freund wrote:
> On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
>> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
>> > Why do we think that increasing the number of PGPROC slots, heavyweight
>> > locks
>> > etc by 256 isn't
On Mon, Jun 17, 2024 at 03:39:27PM -0400, Robert Haas wrote:
> I think we might able to get fairly far by observing that if the
> number of running autovacuum workers is equal to the maximum allowable
> number of running autovacuum workers, that may be a sign of trouble,
> and the longer that
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah
On Tue, Jun 18, 2024 at 01:20:50PM -0400, Bruce Momjian wrote:
> On Tue, Jun 18, 2024 at 05:14:08PM +, Amonson, Paul D wrote:
> > > And this bit doesn't look good. The LICENSE file says:
> > ...
> > > > //* Redistributions in binary form must reproduce the above
> > > > // copyright
On Tue, Jun 18, 2024 at 05:14:08PM +, Amonson, Paul D wrote:
> > And this bit doesn't look good. The LICENSE file says:
> ...
> > > //* Redistributions in binary form must reproduce the above
> > > // copyright notice, this list of conditions and the following
> > > disclaimer // in the
> Hmm, I wonder if the "(c) 2024 Intel" line is going to bring us trouble.
> (I bet it's not really necessary anyway.)
Our lawyer agrees, copyright is covered by the "PostgreSQL Global Development
Group" copyright line as a contributor.
> And this bit doesn't look good. The LICENSE file says:
On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
> On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > > The one
> > > thing I know about that *I* think is a pretty big problem about Perl
> > > is that IPC::Run is not
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 document GUCs, i.e., each one has a
>> section below it where
On Mon, 2024-06-17 at 16:40 -0500, Justin Pryzby wrote:
> > The feature will become much less useful if unique voilations keep getting
> > logged.
>
> Uh, to be clear, your patch is changing the *defaults*, which I found
> surprising, even after reaading the thread. Evidently, the current
>
On Tue, Jun 18, 2024 at 12:10:50PM -0400, Jonathan Katz wrote:
>
> Hi,
>
> PostgreSQL 17 Beta 2 is planned to be release on June 27, 2024. Please
> continue your hard work on closing out open items[1] ahead of the release
> and have the fixes targeted for the release committed by June 22, 2024.
Hi,
On 2024-06-18 15:54:27 +0100, Dave Page wrote:
> On Tue, 18 Jun 2024 at 15:38, Andres Freund wrote:
> > Do you have logs for those failures?
> >
>
> Sure - https://developer.pgadmin.org/~dpage/build-logs.zip. Those are all
> without any modifications to %LIB% or %INCLUDE%.
Thanks.
> > I
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 check the
> mentioned flag in the
Hi,
On Tue, Jun 18, 2024 at 8:25 PM Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > On Tue, Jun 18, 2024 at 7:50 PM Tom Lane wrote:
> >> I think the assertion you noticed is there because the code path gets
> >> traversed during REINDEX, which is an operation we do support on
> >> system
301 - 400 of 158748 matches
Mail list logo
