Dear Shubham,
Thanks for updating the patch!
> I agree that ensuring the correct order of objects (like publications)
> matching with databases is crucial, especially when explicitly
> specifying databases using -d switches.
> To address this, I have created a 0002 patch that aligns object
> crea
Michael Paquier писал(а) 2025-03-27 05:20:
On Wed, Mar 26, 2025 at 10:01:47PM +0700, Vladlen Popolitov wrote:
I mentioned this patch in my message
https://www.postgresql.org/message-id/f28f3b45ec84bf9dc99fe129023a2d6b%40postgrespro.ru
Starting from it queries with Parallel Seq Scan (probably wi
On Wed, Mar 26, 2025 at 4:02 PM Shubham Khanna
wrote:
>
Let's combine 0001 and 0002.
A few minor comments:
*
+ If database name is not specified in publisher-server, it will try to
+ connect with postgres/template1 database to fetch the databases from
+ primary.
Can we change
On Tue, Mar 25, 2025 at 12:14 PM Amit Kapila wrote:
>
> On Tue, Mar 25, 2025 at 11:05 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Hi,
> >
> > When testing the slot synchronization with logical replication slots that
> > enabled two_phase decoding, I found that transactions prepared before
> > two-p
>
> HI
>
> > As far as I know, our usage of instr_time really needs the highest
> resolution available, because we are usually trying to measure pretty
> short intervals. You say that this patch reduces execution time,
> and I imagine that's true ... but I wonder if it doesn't do so at
> the cost
jian he writes:
> the attached patch is to implement $subject.
Why would this be a good idea? I don't see any principled fallback
definition of the column. (No, "NULL" is not that.) Certainly we
should support ALTER TABLE DROP COLUMN, but removing the expression
and not providing a substitute
On Wed, Mar 26, 2025 at 10:01:47PM +0700, Vladlen Popolitov wrote:
> I mentioned this patch in my message
> https://www.postgresql.org/message-id/f28f3b45ec84bf9dc99fe129023a2d6b%40postgrespro.ru
> Starting from it queries with Parallel Seq Scan (probably with other
> parallel executor nodes)
> ha
On Thu, 27 Mar 2025 at 14:51, Michael Paquier wrote:
> One habit that I've found really useful to do when it comes to this
> area of the code is to apply the tests first to show what kind of
> behavior we had before changing the jumbling, then apply the update to
> the query jumbling. This has tw
On Thu, 27 Mar 2025 at 18:03, Sami Imseih wrote:
> Maybe I am missing something, but when I applied the
> v9-0001 patch alone, it did not solve the problem it
> claims to and the pg_s_s regression test fails:
That was an artifact of me not having made the split quite in the
right place when divid
On Wed, Mar 26, 2025 at 9:33 AM Amul Sul wrote:
> On Tue, Mar 25, 2025 at 10:18 PM Peter Eisentraut
> wrote:
> >
> > On 21.03.25 06:58, Amul Sul wrote:
> > >
> > > []
> > > Attached is the updated version, where the commit messages for patch
> > > 0005 and 0006 have been slightly corrected.
Hello Heikki,
04.11.2024 18:08, Heikki Linnakangas wrote:
Committed, thanks for the review!
I've discovered that the following script:
export PGOPTIONS='-c lock_timeout=1s'
createdb regression
for i in {1..100}; do
echo "ITERATION: $i"
psql -c "CREATE TABLE t(i int);"
cat << 'EOF' | psql &
DO
On 24.03.25 21:33, Matheus Alcantara wrote:
I'm a bit confused about the refactoring patch 0001. There are some
details there that don't seem right. For example, you write that the
pfree(rconn) calls are no longer necessary, but AFAICT, it would still
be needed in dblink_get_conn(). Also, ther
Maybe I am missing something, but when I applied the
v9-0001 patch alone, it did not solve the problem it
claims to and the pg_s_s regression test fails:
+++
/local/home/simseih/pghead/install1/postgresql/contrib/pg_stat_statements/results/select.out
2025-03-27 04:56:35.143855392 +
@@ -215
On Wed, Mar 26, 2025 at 12:29 PM Álvaro Herrera wrote:
>
> On 2025-Mar-26, Amul Sul wrote:
>
> > The reason for the change is to revert to the behavior before commit
> > #80d7f990496b1c, where recursion occurred regardless of the
> > changed flags. This is also described in the header comment for
On Mon, Mar 24, 2025 at 11:08 AM David Rowley wrote:
> 2. You should use list_free() in the following:
>
> /*
> * XXX Should we use list_free()? I decided to use this style to take
> * advantage of speculative execution.
> */
> if (unlikely(it->list_is_copy))
> pfree(it->ec_members);
>
> The
Hi Kruti
You can start by reviewing paths ，
https://commitfest.postgresql.org/53/ ,you can choose a path with fewer
changes . Here's my little suggestion.
Thanks
On Thu, Mar 27, 2025 at 2:15 AM Kruti Popat wrote:
> Hello PostgreSQL Developers,
>
> My name is Kruti Popat, and I am an IT
On Wed, Mar 26, 2025 at 04:44:24PM -0500, Nathan Bossart wrote:
> IMHO these are acceptable results, at least for the use-cases I see in the
> tree. We might be able to minimize the difference between the Neon and SVE
> implementations on the low end with some additional code, but I'm really
> not
Hi,
According to the comment above DecodeTXNNeedSkip(), transactions committed
before SNAPBUILD_CONSISTENT state won't be decoded. It's important for initial
table data synchronization because the table sync workers use the consistent
snapshot to copy data so transactions before SNAPBUILD_CONSI
On Wednesday, March 26, 2025, Tom Lane wrote:
> jian he writes:
> > the attached patch is to implement $subject.
>
> Why would this be a good idea? I don't see any principled fallback
> definition of the column. (No, "NULL" is not that.) Certainly we
> should support ALTER TABLE DROP COLUMN,
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sun, 23 Mar 2025 02:01:59 -0700,
Masahiko Sawada wrote:
> ---
> +/*
> + * Process the "format" option.
> + *
> + * This function checks whether the option value is a built-in format such as
> + * "text" and
Yurii Rashkovskii writes:
>> Can you propose a specific change to clean it up? I wanted to write
>> just "PG_MODULE_MAGIC_DATA()", but I'm not sure that's valid C either.
> I was thinking about passing `.name = NULL, .version = NULL` instead of
> `0`—do you have any reservations about this?
If
On Mon, Mar 17, 2025 at 9:47 AM Matheus Alcantara
wrote:
>
> Sorry for the delay, attached v4 with the remaining fixes.
Thanks for the patch.
I started reviewing this with the intent to commit it. But, I decided
while studying it that I want to separate the SKIP_PAGES_NONE case and
the other cas
=?UTF-8?B?5p2o5rGf5Y2O?= writes:
> This patch modifies the instr_time.h header to prefer CLOCK_MONOTONIC_COARSE
> when available.
As far as I know, our usage of instr_time really needs the highest
resolution available, because we are usually trying to measure pretty
short intervals. You say that
On Wed, Mar 26, 2025 at 7:45 PM Tom Lane wrote:
> > This recent patch is great but causes a small problem. It mixes
> designated
> > and non-designated initializers, specifically in
> `PG_MODULE_MAGIC_DATA(0)`.
>
> Ugh. I felt a bit itchy about that, but my compiler wasn't
> complaining...
>
Th
Robert Haas writes:
> - -> Index Scan using daucus_id_idx on daucus v2_2 (actual
> rows=0.12 loops=8)
> + -> Index Scan using daucus_id_idx on daucus v2_2 (actual
> rows=0.13 loops=8)
Even if this had not failed in the buildfarm, it would certainly
have caused problems for someb
On Thu, Mar 27, 2025 at 1:13 PM cca5507 wrote:
>
> Hi,
>
> - IIUC your "fast forward" concern is not related to this particular thread
> but you
> - think it's already an issue on the master branch (outside of the
> BUILDING_SNAPSHOT
> - handling we are discussing here), is that correct? (that's
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consistent state can also be delayed in the presence of
both of these conditions:
hi.
the attached patch is to implement $subject.
the generation expression will be dropped.
the column value previous was NULL will be materialized
based on generation expression.
It seems fairly straightforward:
drop the generation expression in ATExecDropExpression,
and instruct phase 3 to comp
HI Maxim Orlov Heikki Linnakangas
Thank you for working on it,A few more days is a code freeze.It seems
like things have been quiet for a while, but I believe implementing xid64
is absolutely necessary. For instance, there’s often concern about
performance jitter caused by frequent freezes. If
On Wed, Mar 26, 2025 at 6:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
>> I pondered mentioning the 2s interval but the environment variable itself
> doesn't have a default, it's either set or unset which determines whether
> it provides the default or not. IMO, adding this deta
On Wed, Mar 26, 2025 at 02:09:32PM -0400, Robert Haas wrote:
> On Sat, Mar 22, 2025 at 12:10 PM Robert Haas wrote:
> > I'm not going
> > to insist on shipping this if I'm the ONLY one who would ever get any
> > use out of it, but I doubt that's the case.
>
> Hearing no other votes against this, I
On Wed, Mar 26, 2025 at 2:09 PM Robert Haas wrote:
> Hearing no other votes against this, I have committed it, but now I
> wonder if that is going to break the buildfarm, because I just noticed
> that the changes I made in v9 seem not to have resolved the problem
> with debug_parallel_query, for r
On Thu, Mar 27, 2025 at 12:09:35PM +1300, David Rowley wrote:
> I think it's better it's two commits. They're for different purposes.
Fine for me.
> Ok, I won't protest. I just feel the bug is a relic of the old design
> and I don't believe the tests are testing anything useful in the new
> desig
Hi Tom,
This recent patch is great but causes a small problem. It mixes designated
and non-designated initializers, specifically in `PG_MODULE_MAGIC_DATA(0)`.
While this is permissible in C, when imported in C++ code (in extern "C"),
it causes GCC to emit an error: `either all initializer clauses
On Wed, Mar 26, 2025 at 2:11 AM Daniel Gustafsson wrote:
> On 26 Mar 2025, at 04:52, David G. Johnston
> wrote:
> On Tue, Mar 25, 2025 at 8:07 PM Kyotaro Horiguchi
> wrote:
>
>
> I came across the following help message added in commit 1a759c83278:
>>
>> + HELP0(" WATCH_INTERVAL\n"
>> +
On Thu, 27 Mar 2025 at 04:19, Andrei Lepikhov wrote:
> But if we partition on HASH(x,y) it is not working (see
> incorrect-pruning-example.sql):
>
> PREPARE test2 (int,int) AS
> SELECT 1 FROM array_prune
> WHERE id1 = ANY(ARRAY[$1]) AND id2 = ANY(ARRAY[$2]);
> EXPLAIN (COSTS OFF) EXECUTE test2
On Wed, Mar 26, 2025 at 11:14:47AM -0700, 杨江华 wrote:
> This patch modifies the instr_time.h header to prefer CLOCK_MONOTONIC_COARSE
> when available. By using CLOCK_MONOTONIC_COARSE, we can leverage a lower
> resolution(4ms) but faster alternative for timing operations, which reduces
> the overhead
It Makes sense, but we can distinguish such code which needs `
CLOCK_MONOTONIC`.
Now I add the configure option `--with-clock-monotonic-coarse`.
Michael Paquier 于2025年3月26日周三 15:34写道：
> On Wed, Mar 26, 2025 at 11:14:47AM -0700, 杨江华 wrote:
> > This patch modifies the instr_time.h header to pref
Hi! I started reviewing it and noticed that your code repeated this
cycle maybe it would be better to put it in a separate function, for
example in the form of a name like "analyze_stmts"?
or is it possible to create a macro for them?
@@ -2016,6 +2017,17 @@ exec_bind_message(StringInfo input_m
On Wed, 26 Mar 2025 at 14:04, Michael Paquier wrote:
>
> On Wed, Mar 26, 2025 at 11:56:50AM +1300, David Rowley wrote:
> > Here is the v8 version with the bug fix and performance stuff
> > separated out.
>
> Why not. I assume that you would merge these together?
I think it's better it's two comm
On Mon, Mar 03, 2025 at 11:35:15AM -0600, Sami Imseih wrote:
> Thanks for the update. This LGTM! and I will mark as RFC.
Yes, agreed that there is no specific need to be precise about the
attributes that can become inconsistent, as this would also depend on
the addition of more states, or event mo
Hi Dmitrii,
Thanks for the quick update!
On 3/26/25 02:45, Dmitrii Bondar wrote:
>> 3. Consider updating documentation for doc/src/contrib-spi.sgml, or any file
as appropriate, to
>> reflect the changes.
>
> The changes have now been added to doc/src/contrib-spi.sgml. I also added a
considerat
> On 20 Mar 2025, at 10:39, Álvaro Herrera wrote:
> In initialize_SSL(), the test for conn->sslkeylogfile is inside the
> #ifdef for the existance of the SSL function. I think it's better to
> log a message (probably just a warning) that says "this feature is not
> supported with this TLS librar
On Fri, Mar 21, 2025 at 10:21 AM Richard Guo wrote:
> Not quite sure if this is something we need to worry about.
I haven't really dug into this but I bet it's not that serious, in the
sense that we could probably work around it with more logic if we
really need to.
However, I'm a bit concerned
On Wed, Mar 26, 2025 at 05:17:17PM +0300, Maksim.Melnikov wrote:
> Test check visibility of prepared transactions in standby after a restart
> while primary is down.
> Failed assert check that changes, commited on transaction on primary node,
> were synchronously replicated to standby node.
> In te
> Suppose:
> BEGIN;
> SELECT 1;
> SAVEPOINT bob;
> progressively explain something that aborts
> I think in this case we will call AbortSubTransaction(), not
AbortTransaction().
Indeed. We need special treatment for subtransactions. There are 2
scenarios where
AbortSubTransaction() will be called
On Thu, Mar 27, 2025 at 10:41 AM Andres Freund wrote:
> > > Subject: [PATCH v2.12 13/28] Enable IO concurrency on all systems
> >
> > Consider also updating this comment to stop focusing on prefetch; I think
> > changing that aligns with the patch's other changes:
> >
> > /*
> > * How many buffer
I've attached a new set of patches in which I've tried to address John's
feedback. I ran some new benchmarks with these patches. "M3" is an Apple
M3 (my laptop), "G3" is an r7g.4xlarge, and "G4" is an r8g.4xlarge. "no
SVE" means the patches are applied but the function pointer points to the
Neon
Hi,
On 2025-03-26 21:20:47 +, Thom Brown wrote:
> I took a quick gander through this just out of curiosity (yes, I know
> I'm late), and found these show-stoppers:
>
> v2.12-0015-aio-Add-pg_aios-view.patch:
>
> + ERROR mean the I/O failed with an error.
>
> s/mean/means/
>
>
> v2
Hi,
On 2025-03-26 11:31:02 -0700, Noah Misch wrote:
> I reviewed everything up to and including "[PATCH v2.12 17/28] aio, bufmgr:
> Comment fixes", the last patch before write support.
Thanks!
> postgr.es/m/20250326001915.bc.nmi...@google.com covered patches 1-9, and this
> email covers patches
On Wed, Mar 26, 2025 at 04:33:49PM -0400, Andres Freund wrote:
> On 2025-03-25 17:19:15 -0700, Noah Misch wrote:
> > On Mon, Mar 24, 2025 at 09:18:06PM -0400, Andres Freund wrote:
> > Second, the aio_internal.h comment changes discussed in
> > postgr.es/m/20250325155808.f7.nmi...@google.com and ea
On Tue, 25 Mar 2025 at 01:18, Andres Freund wrote:
>
> Hi,
>
> Attached v2.12, with the following changes:
I took a quick gander through this just out of curiosity (yes, I know
I'm late), and found these show-stoppers:
v2.12-0015-aio-Add-pg_aios-view.patch:
+ ERROR mean the I/O failed
Hi,
On 2025-03-25 17:19:15 -0700, Noah Misch wrote:
> On Mon, Mar 24, 2025 at 09:18:06PM -0400, Andres Freund wrote:
> > @@ -296,7 +299,9 @@ pgaio_io_call_complete_local(PgAioHandle *ioh)
> >
> > /*
> > * Note that we don't save the result in ioh->distilled_result, the
> > local
> > -
On Mon, Mar 24, 2025 at 7:58 PM Masahiko Sawada wrote:
>
> You're right. I've studied the read stream code and figured out how to
> use it. In the attached patch, we end the read stream at the end of
> phase 1 and start a new read stream, as you suggested.
I've started looking at this patch set s
Hello John,
v15 LGTM. Couple of minor comments:
> I'm leaning towards a length limit for v15-0001 so that inlined instructions
> are
> likely to be unrolled. Aside from lack of commit message, I think that one is
> ready
> for commit soon-ish.
+1
> I'm feeling pretty good about 0002, but
On Wed, 26 Mar 2025 at 21:18, Maksim.Melnikov wrote:
>
> So my question is
> can we accept such behavior as bug of postgres codebase, or, on other way, it
> is bug of unstable test?
> P.S.
> For me it is looking strange, that postgres start processing workload before
> full config initializing.
On Mon, Mar 24, 2025 at 6:46 PM Tom Lane wrote:
> As I said, I'm not necessarily averse to showing these numbers
> somehow. But I don't think they belong in the default output,
> and I'm not even convinced that VERBOSE is the right place.
> pg_overexplain seems like it could be an ideal home for
26.03.2025, 21:06, "Masahiko Sawada" :Agreed. I've done this in the attached patch.Great! The patch looks good to me.Best regards, Andrey Borodin.
On 2025-Mar-26, Nikolay Shaplov wrote:
> git blame reloptions.c | grep "Robert Haas" | wc -l
> 112
>
> git blame reloptions.c | grep Álvaro | wc -l
> 792
>
> For me Alvary is the keeper of the concept of reloption. And he sees
> difference. If he would said isset_offset is good, I will follow.
On Fri, Mar 21, 2025 at 11:02 AM Daniel Gustafsson wrote:
> >> How about we provide the current libpq.so without linking to curl and also
> >> a
> >> libpq-oauth.so that has curl support? If we do it right libpq-oauth.so
> >> would
> >> itself link to libpq.so, making libpq-oauth.so a fairly sma
В письме от среда, 26 марта 2025 г. 21:43:42 MSK пользователь Robert Haas
написал:
> why is it worth arguing about?
I have full model of current reloptions and my patch unrolled in my head. They
have some harmony. (Mine has more harmony, but it is not the case).
isset_offset the way it is intr
On Tue, 28 Jan 2025 at 07:49, jian he wrote:
>
> On Mon, Jan 6, 2025 at 5:34 PM jian he wrote:
> >
> > hi.
> >
> > about this issue,
> > last email in 2012 (https://postgr.es/m/8967.1353167...@sss.pgh.pa.us)
> > """
> > Even if it happens to be trivial in the current patch, it's an added
> > func
On Fri, Mar 21, 2025 at 3:23 PM Melanie Plageman
wrote:
>
> I've committed the btree and gist read stream users. I think we can
> come back to the test after feature freeze and make sure it is super
> solid.
I've now committed the spgist vacuum user as well. I'll mark the CF
entry as completed.
I
On Fri, 31 Jan 2025 at 21:05, Daniel Gustafsson wrote:
>
> > On 31 Jan 2025, at 16:29, Andres Freund wrote:
>
> >> #ifdef ENABLE_GSS
> >> -#if defined(HAVE_GSSAPI_H)
> >> -#include
> >> -#else
> >> -#include
> >> -#endif /* HAVE_GSSAPI_H */
> >> +#include "libpq/pg-gssapi.h"
> >> #endif /* ENAB
On Wed, Mar 26, 2025 at 2:34 PM Nikolay Shaplov wrote:
> В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
> написал:
> > The reason why I felt that way is
> > because you were using what seemed to me to be very strong language
> > over what seemed to me to be a very minor
On Wed, Mar 26, 2025 at 12:32 PM Nikita Malakhov wrote:
> Vladlen, I've checked your example and also got this behavior
> on the current master under Gdb (Ubuntu 22.04 LTS).
>
> On the query above server waits in this state (as shown by gdb):
> Program received signal SIGUSR1, User defined signal
В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
написал:
> The reason why I felt that way is
> because you were using what seemed to me to be very strong language
> over what seemed to me to be a very minor issue.
Being not native speaker has it's own difficulties. Plus
I reviewed everything up to and including "[PATCH v2.12 17/28] aio, bufmgr:
Comment fixes", the last patch before write support.
postgr.es/m/20250326001915.bc.nmi...@google.com covered patches 1-9, and this
email covers patches 10-17. All remaining review comments are minor, so I've
marked the com
> On 26 Mar 2025, at 10:12, Pavel Stehule wrote:
> yes, it is ok after this change
Thanks for confirming, committed.
--
Daniel Gustafsson
Hi,
On 2025-03-26 21:53:35 +0700, Vladlen Popolitov wrote:
> During debug session I found, that queries with Parallel Seq Scan hang
> in the current master - the leader worker waits indefinitely the signal
> from parallel workers. A query is not possible to break, the leader
> does not check inter
This reflects the correct insertion of 100 million rows instead of 10
million.
-- Create table and insert 100 million rows
CREATE TABLE t1(a int);
INSERT INTO t1 SELECT * FROM generate_series(1, 1);
-- close parallel
SET max_parallel_workers_per_gather = 0;
SET max_parallel_workers =
On Wed, Mar 26, 2025 at 1:29 PM Nikolay Shaplov wrote:
> > What I'm upset about is that it feels to me like Nikolay is trying to
> > win the argument by yelling.
>
> I do not think it is fair. When votes are against you (and I did not ask
> anybody else's help for it) it turned out, that I am yell
On Thu, Feb 27, 2025 at 4:12 PM Robert Haas wrote:
> On Thu, Feb 27, 2025 at 4:08 PM Tom Lane wrote:
> > I was down on it to start with, on the grounds that it wasn't adding
> > enough ease-of-use to justify even a relatively small amount of added
> > code. I'm not sure that the dump-reload fail
Dear PostgreSQL Hackers,
This patch modifies the instr_time.h header to prefer CLOCK_MONOTONIC_COARSE
when available. By using CLOCK_MONOTONIC_COARSE, we can leverage a lower
resolution(4ms) but faster alternative for timing operations, which reduces
the overhead of frequent timestamp retrievals.
Hello PostgreSQL Developers,
My name is Kruti Popat, and I am an IT engineering student interested in
contributing to PostgreSQL for GSoC 2025.
I am comfortable with C, C++, and have a basic understanding of PostgreSQL.
I am eager to explore database internals and open-source development. While
I
On Sat, Mar 22, 2025 at 12:10 PM Robert Haas wrote:
> I'm not going
> to insist on shipping this if I'm the ONLY one who would ever get any
> use out of it, but I doubt that's the case.
Hearing no other votes against this, I have committed it, but now I
wonder if that is going to break the buildf
On Wed, Mar 26, 2025 at 10:29 AM Nikolay Shaplov wrote:
> The only thing I am asking for: please keep code consistent. Better keep
> reloption core the way it was, but if it is not possible, then keep it
> consistent then.
>
Consistency at the expense of all else is a debatable position that wil
Hello Masao-san and Melanie,
Thank you for your attention to this!
23.03.2025 19:26, Fujii Masao wrote:
With autovacuum = off, all of these fluctuations go away.
So you are suggesting disabling autovacuum during the postgres_fdw regression
test?
No, I'd prefer to have the test stable wit
В письме от среда, 26 марта 2025 г. 18:41:13 MSK пользователь Robert Haas
написал:
> What I'm upset about is that it feels to me like Nikolay is trying to
> win the argument by yelling.
I do not think it is fair. When votes are against you (and I did not ask
anybody else's help for it) it turne
Thanks for all the feedback. Please find attached a version which prints
"[none]" as the default value, "[local]" for a socket, and otherwise
whatever pg_getnameinfo_all spits out. I cleaned up the coding, respected
padding, removed the family checks, and expanded the docs a tiny bit to
give the re
Hi,
My colleague Oleksii Kozlov ran into an assertion while testing aborted
UPDATE-commands in sub transactions.
To reproduce this assertion run the SQl in the attached script. I tested
this on 15.10 and 17.4
Running the script will lead to the the assertion:
TRAP: failed Assert("HEAP_XMAX_IS_LOC
Hello community,
I recently encountered a deadlock in postgresql while performing concurrent
INSERT statements on the same table in two separate sessions.
The error message explicitly mentions that the deadlock occurred while
inserting an index tuple.
There were no explicit transactions (BEGIN/
On Wed, Mar 26, 2025 at 6:00 AM Andrey Borodin wrote:
>
>
>
> > On 26 Mar 2025, at 08:32, Masahiko Sawada wrote:
> >
> > Please review it.
>
> The patch looks good to me except one nit.
> +WITH uuidts AS (
> + SELECT y, ts as ts, lag(ts) OVER (ORDER BY y) AS prev_ts
> + FROM (SELECT y, uu
On Wed, Mar 26, 2025 at 08:09:53AM -0700, David G. Johnston wrote:
> I'm willing to say "I don't know why this is so very important to Nikolay,
> but I trust him that it is, and since my opinion isn't that strong and this
> isn't a big deal, so I will accommodate the person screaming that adding
>
On Wed, Mar 26, 2025 at 9:14 AM Nathan Bossart
wrote:
> FWIW one of the big reasons I didn't proceed with the enum approach
initially is because I worried that I'd end up in a similar discussion
> about how terrible _that_ approach is. When I look at that patch [0], I
> genuinely wonder if folk
On Wed, Mar 26, 2025 at 11:41:13AM -0400, Robert Haas wrote:
> What I'm upset about is that it feels to me like Nikolay is trying to
> win the argument by yelling. I don't want that to be the way we do
> things around here. I admit that sometimes it is, and I think that is
> bad, no matter who the
Hi,
On my windows machine I've found unstable test, it fails very rarely,
but anyway, sometimes it fails.
src/test/recovery/t/009_twophase.pl
# Failed test 'Committed prepared transaction is visible to new
snapshot in standby'
# at t/009_twophase.pl line 360.
# got: '0'
# ex
Hi!
Vladlen, I've checked your example and also got this behavior
on the current master under Gdb (Ubuntu 22.04 LTS).
On the query above server waits in this state (as shown by gdb):
Program received signal SIGUSR1, User defined signal 1.
0x562beb21c6ed in ExecInterpExpr (state=0x562bec781858
> On 26 Mar 2025, at 17:15, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Thanks for review! Pushed after making the above changes and taking it for
>> another CI run.
>
> CF entry should be marked closed no?
Yep, just wanted to allow some time to see how the buildfarm liked it before
clos
On Wed, Mar 26, 2025 at 8:41 AM Robert Haas wrote:
> Nathan has already had to spend a significant amount of time engaging
with this thread over what I think should be a complete non-event, and
> will probably have to spend more, and all that takes away from time
> that could, for example, be sp
Daniel Gustafsson writes:
> Thanks for review! Pushed after making the above changes and taking it for
> another CI run.
CF entry should be marked closed no?
https://commitfest.postgresql.org/patch/5060/
regards, tom lane
On Wed, Mar 26, 2025 at 10:40 AM Nikolay Shaplov wrote:
> Then please, listen to a reason. If we add isset_offset, it will make code
> inconsistent, because it follow same purpose as unreachable default_value in
> other non boolean options. Having two conflicting ways to do same thing is a
> bad d
Vladlen Popolitov writes:
> d) Above query will start parallel worker(s). When worker(s) finish(es),
> it/they send SIGUSR1 that is caught by debugger. When you dimiss
> the signal message, you find that query continues to run, but really it
> waits (in latch.c or in waiteventset.c depending on co
Christoph Berg writes:
> Re: Peter Eisentraut
>> Moreover, if there are zero-based months, why not zero-based days,
>> or any of the other fields?
> I would suspect this is coming from C's struct tm where tm_mon is
> 0..11 and all other fields being "normal". Used by asctime(), gmtime()
> and fri
On Wed, Mar 26, 2025 at 11:10 AM David G. Johnston
wrote:
> I'm willing to say "I don't know why this is so very important to Nikolay,
> but I trust him that it is, and since my opinion isn't that strong and this
> isn't a big deal, so I will accommodate the person screaming that adding this
>
Hi,
Working on improving partition pruning [1] I found a case that I may
treat like a bug. I mean the case with expression on a partitioning
column like:
id = ARRAY[$1,$2]
Basically, pruning on ARRAY[$1,$2] works in the case of single column
(see correct-pruning-example.sql in attachment):
Hearing no further discussion, I've pushed this.
regards, tom lane
On Wed, Mar 26, 2025 at 7:42 AM Robert Haas wrote:
> On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
> wrote:
> > The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere
> to how existing code is written
st 26. 3. 2025 v 9:05 odesílatel Daniel Gustafsson napsal:
> > On 26 Mar 2025, at 08:42, Pavel Stehule wrote:
>
> > The reason is probably my LANG=cs_CZ.UTF8. When I switched to LANG=C,
> then tests passed.
> >
> > The main problem is in numeric format. Czech uses the comma instead of
> the dot.
On Wed, Mar 26, 2025 at 4:59 AM Jakub Wartak
wrote:
> ERROR: unexpected data beyond EOF in block 1472 of relation base/5/16387
> HINT: This has been seen to occur with buggy kernels; consider
> updating your system.
>
> to something more generic and less confusing. It is coming from
> ffae5cc5a6
1 - 100 of 156 matches
Mail list logo
