On Wed, Jun 05, 2024 at 07:28:42PM +0200, Matthias van de Meent wrote:
> As for "on my laptop", that sounds very reasonable, but could you
> check the performance on systems with larger shared buffer
> configurations? I'd imagine (but haven't checked) that binary upgrade
> target systems may alread
Thanks for the review and feedback!
On Mon, Jun 3, 2024 at 10:56 AM Nathan Bossart
wrote:
> > -/*
> > - * Send text representation of one attribute, with conversion and
> escaping
> > - */
> > #define DUMPSOFAR() \
>
> IIUC this comment was meant to describe the CopyAttributeOutText() function
On Wed, 5 Jun 2024 at 17:12, Robert Haas wrote:
> Well, hang on. The discussion on that thread suggests that this is
> only going to break connections to servers that don't have
> NegotiateProtocolVersion.
Yes, correct.
> What
> I really don't want is for v18 to break connections to v17 servers.
On Wed, Jun 5, 2024 at 12:37 PM Nathan Bossart
wrote:
> What about collectXXX() to match similar functions in pg_dump.c (e.g.,
> collectRoleNames(), collectComments(), collectSecLabels())?
>
sgtm.
> > (2) These functions malloc() a single ntups * sizeof(struct) allocation
> and
> > then index
On Sat, 2024-06-01 at 17:08 -0700, Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed. What that means is that the
> schema should not exist
Nathan Bossart writes:
> On Wed, Jun 05, 2024 at 12:22:03PM -0400, Neil Conway wrote:
>> (1) Names like `getXXX` for these functions suggest to me that they return
>> a value, rather than side-effecting. I realize some variants continue to
>> return a value, but the majority no longer do. Perhaps
I was having a discussion regarding out-of-support branches and effort
to keep them building, but could not for the life of me find any actual
documented policy (although I distinctly remember that we do something...).
I did find fleeting references, for example:
8<---
comm
On 2024-06-05 We 09:00, Alexander Lakhin wrote:
Another case (with psql using the port):
testrun/ssl/001_ssltests_47/log/regress_log_001_ssltests_47:# Checking
port 49448
testrun/ssl/001_ssltests_47/log/regress_log_001_ssltests_47:# Found
port 49448
testrun/ssl/001_ssltests_47/log/001_ssltest
On Sun, May 12, 2024 at 04:29:23PM -0700, Noah Misch wrote:
> I'm attaching patches implementing the LockTuple() design.
Starting 2024-06-10, I plan to push the first seven of the ten patches:
inplace005-UNEXPECTEDPASS-tap-meson-v1.patch
inplace010-tests-v1.patch
inplace040-waitfuncs-v1.patch
inp
Joe Conway writes:
> I was having a discussion regarding out-of-support branches and effort
> to keep them building, but could not for the life of me find any actual
> documented policy (although I distinctly remember that we do something...).
> Is the policy written down somewhere, or is it onl
Please find attached a quick patch to prevent this particularly bad error
message for running "postgres", when making the common mistake of
forgetting to put the "--single" option first because you added an earlier
arg (esp. datadir)
Current behavior:
$ ~/pg/bin/postgres -D ~/pg/data --single
202
On 2024-06-05 We 14:10, Andrew Dunstan wrote:
On 2024-06-05 We 09:00, Alexander Lakhin wrote:
Another case (with psql using the port):
testrun/ssl/001_ssltests_47/log/regress_log_001_ssltests_47:#
Checking port 49448
testrun/ssl/001_ssltests_47/log/regress_log_001_ssltests_47:# Found
port
On Wed, Jun 05, 2024 at 01:46:44PM -0400, Neil Conway wrote:
> We could go further and use the same code to handle both the tail of the
> string in the vectorized case and the entire string in the non-vectorized
> case, but I didn't bother with that -- as written, it would require taking
> an unnec
On Wed, Jun 05, 2024 at 02:51:05PM -0400, Greg Sabino Mullane wrote:
> Please find attached a quick patch to prevent this particularly bad error
> message for running "postgres", when making the common mistake of
> forgetting to put the "--single" option first because you added an earlier
> arg (es
Hello Andrew,
05.06.2024 21:10, Andrew Dunstan wrote:
I think I see what's going on here. It looks like it's because we start the server in unix socket mode, and then
switch to using TCP as well.
Can you try your test with this patch applied and see if the problem persists? If we start in TC
> On Mon, May 27, 2024 at 06:00:00PM GMT, Alexander Lakhin wrote:
> Hello hackers,
>
> As a recent buildfarm test failure on olingo (which builds postgres with
> -O1 and address sanitizer) [1] shows:
> ...
> [23:12:02.127](0.166s) not ok 6 - snapshot conflict: stats show conflict on
> standby
> [2
Hi,
At 2024.pgconf.dev, Heikki did a session on multithreading PostgreSQL
which I was unfortunately unable to attend due my involvement with
another session, and then we had an unconference discussion which I
was able to attend and at which I volunteered to have a look at a
couple of tasks, includ
On Wed, 5 Jun 2024 at 19:53, Jeff Davis wrote:
> Is this orthogonal to relocatability?
It's fairly orthogonal, but it has some impact on relocatability: You
can only relocate to a schema name that does not exist yet (while
currently you can only relocate to a schema that already exists). This
is
On Wed Jun 5, 2024 at 3:05 PM CDT, Robert Haas wrote:
...
== Extension Compatibility Solutions ==
The attached patch is a sketch of one possible approach: PostgreSQL
signals whether it is multithreaded by defining or not defining
PG_MULTITHREADING in pg_config_manual.h, and an extension signals
On Mon, Jun 03, 2024 at 02:04:19PM -0500, Nathan Bossart wrote:
> Of course, as soon as I committed this, I noticed another missing reference
> to max_wal_senders in the paragraph about POSIX semaphores. I plan to
> commit/back-patch the attached patch within the next couple days.
Committed.
--
On Wed, 5 Jun 2024 at 22:05, Robert Haas wrote:
> The attached patch is a sketch of one possible approach: PostgreSQL
> signals whether it is multithreaded by defining or not defining
> PG_MULTITHREADING in pg_config_manual.h, and an extension signals
> thread-readiness by defining PG_THREADSAFE_E
On Wed, Jun 5, 2024 at 1:50 PM Jelte Fennema-Nio wrote:
> Totally agreed, and that's easily achievable because of the
> NegotiateProtocolVersion message. We're all good on v18 to v17
> connections and protocol changes, as long as we make any new behaviour
> depend on either a protocol parameter or
On 2024-06-05 We 16:00, Alexander Lakhin wrote:
Hello Andrew,
05.06.2024 21:10, Andrew Dunstan wrote:
I think I see what's going on here. It looks like it's because we
start the server in unix socket mode, and then switch to using TCP as
well.
Can you try your test with this patch applie
On Wed, Jun 5, 2024 at 4:32 PM Tristan Partin wrote:
> Not entirely sure how I feel about the approach you've taken, but here
> is a patch that Heikki and I put together for extension compatibility.
> It's not a build time solution, but a runtime solution. Instead of
> PG_MODULE_MAGIC, extensions
On 5/21/24 11:27, Isaac Morland wrote:
On Tue, 21 May 2024 at 13:57, Robert Haas mailto:robertmh...@gmail.com>> wrote:
What I think is less clear is what that means for temporal primary
keys. As Paul pointed out upthread, in every other case, a temporal
primary key is at least as uni
On Thu, May 9, 2024 at 5:44 PM Matthias van de Meent
wrote:
> Additionally, because I can't create my own non-constraint-backing
> unique GIST indexes, I can't pre-create my unique constraints
> CONCURRENTLY as one could do for the non-temporal case
We talked about this a bit at pgconf.dev. I w
On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote:
> Thank you, Ashutosh, for the quick response. I've drafted a patch
> aimed at addressing this issue. The patch attempts to solve this
> issue by configuring the search_path for all security definer
> functions created by the extension.
I l
On Wed, 5 Jun 2024 at 22:48, Robert Haas wrote:
> I agree that we need such a mechanism, but if the driving feature is
> cancel-key length, I expect that opt-in isn't going to work very well.
> Opt-in seems like it would work well with compression or transparent
> column encryption, but few users
On 2024-06-05 We 16:49, Andrew Dunstan wrote:
On 2024-06-05 We 16:00, Alexander Lakhin wrote:
Hello Andrew,
05.06.2024 21:10, Andrew Dunstan wrote:
I think I see what's going on here. It looks like it's because we
start the server in unix socket mode, and then switch to using TCP
as well
Andrew Dunstan writes:
> On 2024-06-05 We 16:00, Alexander Lakhin wrote:
>> That is, psql from the test instance 001_ssltests_34 opened a
>> connection to
>> the test server with the client port 50072 and it made using the port by
>> the server from the test instance 001_ssltests_30 impossible.
On Wed Jun 5, 2024 at 3:56 PM CDT, Robert Haas wrote:
On Wed, Jun 5, 2024 at 4:32 PM Tristan Partin wrote:
> Not entirely sure how I feel about the approach you've taken, but here
> is a patch that Heikki and I put together for extension compatibility.
> It's not a build time solution, but a run
On Thu, 9 May 2024 at 05:03, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
I noticed a couple more things. This item:
Add functions to convert integers to hex and
On Wed, Jun 05, 2024 at 05:09:58PM +0530, Ashutosh Bapat wrote:
> Thanks for the suggestion. I didn't understand the dependency with the
> buildfarm module. Will the new module be used in buildfarm separately? I
> will work on this soon. Thanks for changing CF entry to WoA.
I had some doubts about
On 05/06/2024 23:55, Robert Haas wrote:
On Wed, Jun 5, 2024 at 4:32 PM Tristan Partin wrote:
Not entirely sure how I feel about the approach you've taken, but here
is a patch that Heikki and I put together for extension compatibility.
It's not a build time solution, but a runtime solution. Inst
There was an unconference session at pgconf.dev related to threading
support. One of the problems identified was setlocale().
The attached series of patches make collation not depend on
setlocale(), even if the database collation uses the libc provider.
Since commit 8d9a9f034e, all supported pla
On Tue, May 21, 2024 at 08:33:51AM -0500, Justin Pryzby wrote:
> It occurred to me that psql \dP+ should show the AM of partitioned
> tables (and other partitioned rels).
> Arguably, this could've been done when \dP was introduced in v12, but
> at that point would've shown the AM only for partition
On Wed, Jun 5, 2024 at 11:46:17PM +0100, Dean Rasheed wrote:
> On Thu, 9 May 2024 at 05:03, Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
>
> I noticed a c
On Wed, Jun 5, 2024 at 5:16 PM Jelte Fennema-Nio wrote:
> I agree longcancelkey=true is not what we want. In my patch 0004, you
> can specify max_protocol_version=latest to use the latest protocol
> version as opt-in. This is a future proof version of
> protocolversion=3.1 that you're proposing, b
On Wed, Jun 5, 2024 at 8:01 PM Heikki Linnakangas wrote:
> I'm very much in favor of a runtime toggle. To be precise, a
> PGC_POSTMASTER setting. We'll get a lot more testing if you can easily
> turn it on/off, and so far I haven't seen anything that would require it
> to be a compile time option.
On 2024-06-05 We 17:37, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-06-05 We 16:00, Alexander Lakhin wrote:
That is, psql from the test instance 001_ssltests_34 opened a
connection to
the test server with the client port 50072 and it made using the port by
the server from the test instanc
Hi,
On 2024-06-05 21:10:01 -0400, Robert Haas wrote:
> On Wed, Jun 5, 2024 at 8:01 PM Heikki Linnakangas wrote:
> > I'm very much in favor of a runtime toggle. To be precise, a
> > PGC_POSTMASTER setting. We'll get a lot more testing if you can easily
> > turn it on/off, and so far I haven't seen
On Wed, Jun 5, 2024 at 9:50 PM Andres Freund wrote:
> Depending on the architecture / ABI / compiler options it's often not
> meaningfully more expensive to access a thread local variable than a "normal"
> variable.
>
> I think these days it's e.g. more expensive on x86-64 windows, but not
> linux
Hi,
On 2024-06-05 21:59:42 -0400, Robert Haas wrote:
> On Wed, Jun 5, 2024 at 9:50 PM Andres Freund wrote:
> > Depending on the architecture / ABI / compiler options it's often not
> > meaningfully more expensive to access a thread local variable than a
> > "normal"
> > variable.
> >
> > I think
On Wed, Jun 5, 2024 at 10:09 PM Andres Freund wrote:
> Maybe. I think shipping a mode where users can fairly simply toggle between
> threaded and process mode will allow us to get this stable a *lot* quicker
> than if we distribute two builds. Most users don't build from source, distros
> will hav
Dear Shlok and Shubham,
Thanks for updating the patch!
I briefly checked the v5-0002. IIUC, your patch allows to copy generated
columns unconditionally. I think the behavior affects many people so that it is
hard to get agreement.
Can we add a new option like `GENERATED_COLUMNS [boolean]`? If th
On Wed, Jun 5, 2024 at 3:18 PM Nathan Bossart
wrote:
> Could we remove the requirement that --single must be first? I'm not
> thrilled about adding a list of "must be first" options that needs to stay
> updated, but given this list probably doesn't change too frequently, maybe
> that's still bet
On Wed, Jun 5, 2024 at 9:03 PM Robert Haas wrote:
> It's a funny use of "max" and "min", because the max is really what we're
> trying to do and the min is what we end
> up with, and those terms don't necessarily bring those ideas to mind.
requested_protocol_version and minimum_protocol_versio
On Wed, Jun 5, 2024 at 6:01 PM Ashutosh Bapat
wrote:
>
> On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila wrote:
>>
>> How about periodically sending this information?
>> >
>>
>> Now, if we want to support some sort of failover then probably this
>> will help. Do you have that use case in mind?
>
>
>
On Wednesday, June 5, 2024 2:32 PM Peter Smith wrote:
> Hi. Here are some minor review comments for the docs patch v4-0001.
Thanks for the comments!
> The SGML file wrapping can be fixed to fill up to 80 cols for some of the
> paragraphs.
Unlike comments in C code, I think we don't force the
On Wed, Jun 5, 2024 at 12:43 PM Amit Kapila wrote:
>
> On Tue, Jun 4, 2024 at 8:56 PM Yogesh Sharma
> wrote:
> >
> > On 6/4/24 06:57, Amit Kapila wrote:
> >
> > > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > > (or something like that) which users can perform before shu
On Wed, Jun 5, 2024 at 3:17 PM Bharath Rupireddy
wrote:
>
> On Tue, Jun 4, 2024 at 5:40 PM Amit Kapila wrote:
> >
> > Even if we decode it periodically (say each time we decode the
> > checkpoint record) then also we need to send the entire set of
> > sequences at shutdown. This is because the se
Hi, here are some review comments for the docs patch v5-0001.
Apart from these it LGTM.
==
doc/src/sgml/logical-replication.sgml
1.
+
+ On the subscriber node, use the following SQL to identify which slots
+ should be synced to the standby that we plan to promote. This query will
On Wed, Jun 05, 2024 at 10:27:51PM +0800, Julien Rouhaud wrote:
> Note that I removed the -Werror from lapwing a long time ago, so at
> least this animal shouldn't lead to hackish fixes for false positive
> anymore.
That's good to know. Thanks for the update.
--
Michael
signature.asc
Descriptio
On Wed, Jun 5, 2024 at 1:17 PM Ashutosh Bapat
wrote:
> Hi David,
> Thanks for looking into this.
>
> On Fri, May 31, 2024 at 2:19 AM David Christensen
> wrote:
>
>> Hello,
>>
>> I am looking through some outstanding CommitFest entries; I wonder if
>> this particular patch is already effectively
On Wed, Jun 5, 2024 at 9:30 PM Amit Kapila wrote:
>
> On Wed, Jun 5, 2024 at 12:51 PM Peter Eisentraut wrote:
> >
> > On 04.06.24 12:57, Amit Kapila wrote:
> > > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > > (or something like that) which users can perform before shut
Hi,
On Thu, May 23, 2024 at 02:10:54PM -0400, Robert Haas wrote:
> On Thu, May 23, 2024 at 12:19 AM Bertrand Drouvot
> wrote:
> > The reason why we are using a dirty snapshot here is for the cases where we
> > are
> > recording a dependency on a referenced object that we are creating at the
> >
At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith wrote in
> Hi, I have reproduced this multiple times now.
>
> I confirmed the initial post/steps from Alexander. i.e. The test
> script provided [1] gets itself into a state where function
> ReadPageInternal (called by XLogDecodeNextRecord and comme
On Thu, Jun 6, 2024 at 9:32 AM Masahiko Sawada wrote:
>
> On Wed, Jun 5, 2024 at 12:43 PM Amit Kapila wrote:
> >
> > On Tue, Jun 4, 2024 at 8:56 PM Yogesh Sharma
> > wrote:
> > >
> > > On 6/4/24 06:57, Amit Kapila wrote:
> > >
> > > > 2. Provide a command say Alter Subscription ... Replicate Se
Peter Eisentraut:
On 04.06.24 18:41, Tom Lane wrote:
Relevant to this: I wonder what we think the supported macOS versions
are, anyway. AFAICS, the buildfarm only covers current (Sonoma)
and current-1 (Ventura) major versions, and only the latest minor
versions in those OS branches.
For other
Hi,
On Thu, May 16, 2024 at 5:01 AM Jeff Davis wrote:
>
> The flushing behavior is entirely controlled by the table AM. The heap
> can use the same flushing logic that it did before, which is to hold
> 1000 tuples.
>
> I like that it's accounting for memory, too, but it doesn't need to be
> overl
On 04.06.24 12:57, Amit Kapila wrote:
2. Provide a command say Alter Subscription ... Replicate Sequences
(or something like that) which users can perform before shutdown of
the publisher node during upgrade. This will allow copying all the
sequences from the publisher node to the subscriber nod
Hi David,
Thanks for looking into this.
On Fri, May 31, 2024 at 2:19 AM David Christensen
wrote:
> Hello,
>
> I am looking through some outstanding CommitFest entries; I wonder if
> this particular patch is already effectively fixed by 5278d0a2, which
> is both attributed to the original author
Hi,
I am implementing my own JIT plugin (based on Cranelift) for PostgreSQL
to learn more about the JIT and noticed an API change in PostgreSQL 17.
When Heikki made the resource owners extensible in commit
b8bff07daa85c837a2747b4d35cd5a27e73fb7b2 the API for JIT plugins changed
when Resource
Hi,
I modified the patch, kept the old call of SlruReportIOError()
outside the for-loop, and add a call of erport() with LOG level
when file-close failure occurs in the for-loop.
Please check whether this modification is appropriate
and let me know if there is any problem. Thank you.
At 2024-06
On Wed, Jun 5, 2024 at 9:13 AM Amit Kapila wrote:
>
> On Tue, Jun 4, 2024 at 8:56 PM Yogesh Sharma
> wrote:
> >
> > On 6/4/24 06:57, Amit Kapila wrote:
> >
> > > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > > (or something like that) which users can perform before shut
On Fri, May 24, 2024 at 2:25 PM Ashutosh Bapat
wrote:
>
>
> On Fri, May 24, 2024 at 12:52 PM Ashutosh Sharma
> wrote:
>
>> Hi All,
>>
>> We all know that installing an extension typically requires superuser
>> privileges, which means the database objects it creates are owned by the
>> superuser.
Hi
On Tue, 4 Jun 2024 at 17:36, Heikki Linnakangas wrote:
> On 04/06/2024 18:28, Dave Page wrote:
> > I clearly missed the discussion in which it was decided to remove the
> > old MSVC++ support from the tree (and am disappointed about that as I
> > would have objected loudly). Having recently s
On Sun, 2 Jun 2024 at 10:08, James Coleman wrote:
> See attached for a small patch fixing some typos and grammatical
> errors in a couple of comments.
Thanks. I pushed this after messing with the comments a bit more.
> Side note: It's not clear to me what "Vars of higher levels don't
> matter he
On Fri, May 24, 2024 at 9:08 PM Richard Guo wrote:
> On the basis of the parser infrastructure fixup, 0002 patch adds the
> nullingrel bit that references the grouping RTE to the grouping
> expressions.
I found a bug in the v6 patch. The following query would trigger the
Assert in make_restricti
Hi,
On Tue, Jun 4, 2024 at 5:40 PM Amit Kapila wrote:
>
> Even if we decode it periodically (say each time we decode the
> checkpoint record) then also we need to send the entire set of
> sequences at shutdown. This is because the sequences may have changed
> from the last time we sent them.
Agr
> On 4 Jun 2024, at 00:26, Masahiko Sawada wrote:
Thank you! Vacuum enhancement is a really good step forward, and this small
change would help a lot of observability tools.
> On 4 Jun 2024, at 00:49, Peter Geoghegan wrote:
>
> Can we rename this to num_dead_item_ids (or something similar
On Tue, May 28, 2024 at 7:13 AM wrote:
> 1. I think the order by pk frac limit plans had just to similar
> performance behaviour for me to bother.
> But afaics the main point of your proposal is not related to frac plans
> at all.
>
Right.
> 2. We can't expect the optimizers to simply yield be
On Mon, Jun 3, 2024 at 10:04 PM Tristan Partin wrote:
> On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote:
> > "Tristan Partin" writes:
> > > On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote:
> > >> We talked this off-list at the conference. It seems we have to somehow
> > >> avoid pas
On Tue, Jun 4, 2024 at 4:28 AM Michael Paquier wrote:
> On Fri, Apr 26, 2024 at 06:38:22PM +0530, Ashutosh Bapat wrote:
> > Some points for discussion:
> > 1. The test still hardcodes the diffs between two dumps. Haven't found a
> > better way to do it. I did consider removing the problematic obj
While working on my patchset for protocol changes I realized that the
StartupMessage/SSLRequest/GSSENCRequest was not shown correctly in the
tracing output of libpq. With this change these messages are now shown
correctly in the tracing output.
To test you can add a PQreset(conn) call to the start
Em qua., 5 de jun. de 2024 às 01:12, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Mon, 27 May 2024 11:31:24 -0300, Ranier Vilela
> wrote in
> > Hi.
> >
> > The function *plpgsql_inline_handler* can use uninitialized
> > variable retval, if PG_TRY fails.
> > Fix like function*plpgsq
On Wed, Jun 5, 2024 at 12:51 PM Peter Eisentraut wrote:
>
> On 04.06.24 12:57, Amit Kapila wrote:
> > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > (or something like that) which users can perform before shutdown of
> > the publisher node during upgrade. This will allow
On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila wrote:
> On Tue, Jun 4, 2024 at 7:40 PM Ashutosh Bapat
> wrote:
> >
> > On Tue, Jun 4, 2024 at 4:27 PM Amit Kapila
> wrote:
> >>
> >>
> >> 3. Replicate published sequences via walsender at the time of shutdown
> >> or incrementally while decoding check
>From a quick skim of the latest messages in this thread, it sounds like
there are a couple of folks who think \conninfo (and consequently
\conninfo+) should only report values from the libpq API. I think they
would prefer server-side information to be provided via a system view or
maybe an entire
Em qua., 5 de jun. de 2024 às 02:04, Michael Paquier
escreveu:
> On Wed, Jun 05, 2024 at 01:12:41PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 27 May 2024 11:31:24 -0300, Ranier Vilela
> wrote in
> >> The function *plpgsql_inline_handler* can use uninitialized
> >> variable retval, if PG_TRY fa
Hello hackers,
As buildfarm shows, ssl tests are not stable enough when running via meson.
I can see the following failures for the last 90 days:
REL_16_STABLE:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2024-03-12%2023%3A15%3A50
https://buildfarm.postgresql.org/cgi-bin/sh
On Wed, Jun 5, 2024 at 9:12 AM shveta malik wrote:
>
> On Tue, Jun 4, 2024 at 9:37 AM Amit Kapila wrote:
> >
> > > >
> > > > >
> > > > > Conflict Resolution
> > > > >
> > > > > a) latest_timestamp_wins:The change with later commit timestamp
> > > > > wins.
> > > > > b) earli
While looking at the recent bug report from Alexander Lakhin [1], I got
annoyed by the relcache code, and RelationClearRelation in particular. I
propose to refactor it for clarity.
[1]
https://www.postgresql.org/message-id/e56be7d9-14b1-664d-0bfc-00ce9772721c%40gmail.com
## Patch 1
This is
On 04/06/2024 01:49, Heikki Linnakangas wrote:
A straightforward fix is to modify RelationFlushRelation() so that if
!IsTransactionState(), it just marks the entry as invalid instead of
calling RelationClearRelation(). That's what RelationClearRelation()
would do anyway, if it didn't hit the asse
On Tue, Jun 4, 2024 at 9:37 AM Amit Kapila wrote:
>
> Can you share the use case of "earliest_timestamp_wins" resolution
> method? It seems after the initial update on the local node, it will
> never allow remote update to succeed which sounds a bit odd. Jan has
> shared this and similar concerns
On Wed, Jun 5, 2024 at 08:19:04AM +0300, Alexander Pyhalov wrote:
> > * Passes unsafe binary data from the foreign server.
> >
> > Can someone show me where that last item is in the patch, and why can't
> > we just pass back values cast to text?
>
> In finalize_aggregate() when we see partial a
On Sun, Jun 2, 2024, 02:08 Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed.
Huge +1
Many managed PostgreSQL services block superuser a
On Jun 4, 2024, at 20:45, David E. Wheeler wrote:
> Here’s a new patch that demonstrates that behavior, since that code path is
> not currently represented in tests AFAICT (I would have expected to have
> broken it with this patch).
Commitfest link:
https://commitfest.postgresql.org/48/5017
On Wed, Jun 5, 2024 at 1:05 PM Michael Paquier wrote:
>
> This complain was from lapwing, that uses a version of gcc which
> produces a lot of noise with incorrect issues. It is one of the only
> 32b buildfarm members, so it still has a lot of value.
Note that I removed the -Werror from lapwing
> On Jun 20, 2023, at 1:01 PM, Matthias van de Meent
> wrote:
>
> 0001 is copied essentially verbatim from [1] and reduces overhead in
> the registered block's length field where possible. It is included to
> improve code commonality between varcoded integer fields. See [1] for
> more details
On Wed, Jun 5, 2024 at 10:06 AM Jelte Fennema-Nio wrote:
> FYI Heikki his patchset is here:
> https://www.postgresql.org/message-id/flat/508d0505-8b7a-4864-a681-e7e5edfe32aa%40iki.fi
>
> Afaict there's no way to implement this with old clients supporting
> the new message. So it would need to be o
While reviewing Daniel's pg_dump patch [0], I was initially confused
because the return value of getTypes() isn't saved anywhere. Once I found
commit 92316a4, I realized that data was actually stored in a separate hash
table. In fact, many of the functions in this area don't actually need to
retu
On Fri, Mar 8, 2024 at 5:20 PM Heikki Linnakangas wrote:
> The nice thing about relying on the message length was that we could
> just redefine the CancelRequest message to have a variable length
> secret, and old CancelRequest with 4-byte secret was compatible with the
> new definition too. But i
On Wed, Jun 5, 2024 at 11:14 AM Nathan Bossart
wrote:
> In fact, many of the functions in this area don't actually need to
return anything, so we can trim some code and hopefully reduce confusion a
> bit. Patch attached.
>
Nice cleanup! Two minor comments:
(1) Names like `getXXX` for these f
On Wed, Jun 05, 2024 at 12:22:03PM -0400, Neil Conway wrote:
> Nice cleanup! Two minor comments:
Thanks for taking a look.
> (1) Names like `getXXX` for these functions suggest to me that they return
> a value, rather than side-effecting. I realize some variants continue to
> return a value, but
Em ter., 4 de jun. de 2024 às 16:39, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> I noticed that the "Restoring database schemas in the new cluster" part of
> pg_upgrade can take a while if you have many databases, so I experimented
> with a couple different settings to see if there are
On Wed, Jun 05, 2024 at 01:47:09PM -0300, Ranier Vilela wrote:
> Why not use it too, if not binary_upgrade?
>
> else
> {
> appendPQExpBuffer(creaQry, "CREATE DATABASE %s WITH TEMPLATE = template0
> STRATEGY = FILE_COPY",
> qdatname);
> }
>
> It seems to me that it also improves in any use.
Well
On Wed, 5 Jun 2024 at 18:47, Ranier Vilela wrote:
>
> Em ter., 4 de jun. de 2024 às 16:39, Nathan Bossart
> escreveu:
>>
>> I noticed that the "Restoring database schemas in the new cluster" part of
>> pg_upgrade can take a while if you have many databases, so I experimented
>> with a couple dif
While working on commit b631d0149, I got a bee in my bonnet about
how unfriendly PL/Tcl's error CONTEXT reports are:
* The context reports expose PL/Tcl's internal names for the Tcl
procedures it creates, which'd be fine if those names were readable.
But actually they're something like "__PLTcl_pr
99 matches
Mail list logo
