When testing the json_table function, it was discovered that specifying FORMAT
JSON in the column definition clause and applying this column to the
JSON_OBJECT function results in an output that differs from Oracle's output.
The sql statement is as follows:
SELECT JSON_OBJECT('config' VALUE c
Here are some review comments for the v19-0001 docs patch.
The content seemed reasonable, but IMO it should be presented quite differently.
1. Use sub-sections
I expect this logical replication "Conflicts" section is going to
evolve into something much bigger. Surely, it's not going to be
On 21/08/2024 01:42, Thomas Munro wrote:
On Wed, Aug 21, 2024 at 9:48 AM Alvaro Herrera wrote:
Hi. I noticed chipmunk is failing in configure:
checking whether the C compiler works... no
configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
configure: error: C compiler cannot creat
On Wed, Aug 21, 2024 at 12:46:31PM +0900, Michael Paquier wrote:
> Sorry, I should have split that for clarity (one patch for the GUC,
> one to change the test to use CACHED/LOAD). It is not an error
> though: if we don't have a controlled way to disable the stats of the
> module, then the test wo
On Wed, Aug 21, 2024 at 2:25 AM Heikki Linnakangas wrote:
>
> On 14/08/2024 16:54, Arseny Sher wrote:
> > On 8/13/24 06:35, Amit Kapila wrote:
> >> On Mon, Aug 12, 2024 at 3:43 PM Arseny Sher wrote:
> >>>
> >>> Sorry for the poor formatting of the message above, this should be
> >>> better:
> >>>
A USING clause when altering the type of a generated column does not
make sense. It would write the output of the USING clause into the
converted column, which would violate the generation expression.
This patch adds a check to error out if this is specified.
There was a test for this, but t
On Tue, Aug 20, 2024 at 4:45 PM Zhijie Hou (Fujitsu)
wrote:
>
> Here are the remaining patches.
>
> 0001 adds additional doc to explain the log format.
> 0002 collects statistics about conflicts in logical replication.
>
0002 has not changed since I last reviewed it. It seems all my old
comments
Dear Hou,
Thanks for updating the patch! I think the patch is mostly good.
Here are minor comments.
0001:
01.
```
+
+LOG: conflict detected on relation "schemaname.tablename":
conflict=conflict_type
+DETAIL: detailed explaination.
...
+
```
I don't think the label is correct. label should b
Hi,
On Wed, Aug 21, 2024 at 10:14:20AM +0530, Ashutosh Bapat wrote:
> If this isn't in commitfest already, please add it there.
>
Done in [0].
[0]: https://commitfest.postgresql.org/49/5193/
Thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon W
If this isn't in commitfest already, please add it there.
On Tue, Aug 20, 2024 at 9:58 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Tue, Aug 20, 2024 at 12:06:52PM +, Bertrand Drouvot wrote:
> > Hi,
> >
> > On Tue, Aug 20, 2024 at 05:41:48PM +0900, Michael Paquier wrote:
> > > On Tue, Aug 20, 20
On Tue, Aug 20, 2024 at 5:55 PM Masahiko Sawada wrote:
>
> On Fri, Aug 16, 2024 at 12:22 AM Shlok Kyal wrote:
> >
>
> Thank you for testing the patch!
>
> I'm slightly hesitant to add a test under src/test/subscription since
> it's a bug in ReorderBuffer and not specific to logical replication.
>
On Tue, Aug 20, 2024 at 08:13:12PM -0400, Alvaro Herrera wrote:
> I don't understand what do the inj_stats_enabled stuff have to do with
> this patch. I suspect it's a git operation error, ie., you seem to have
> squashed two different things together.
Sorry, I should have split that for clarity
On Tue, Aug 20, 2024 at 4:45 PM Zhijie Hou (Fujitsu)
wrote:
>
> Here are the remaining patches.
>
> 0001 adds additional doc to explain the log format.
Thanks for the patch. Please find few comments on 001:
1)
+Key (column_name, ...)=(column_name, ...);
existing local tuple (column_name, ...)=(c
On 2024-Aug-20, Jehan-Guillaume de Rorthais wrote:
> I'm back on this issue as well. I start poking at this patch to review it,
> test it, challenge it and then report here.
>
> I'll try to check if some other issues might have lost/forgot on they way as
> well.
Thanks, much appreciated, looking
On Wednesday, August 21, 2024 9:33 AM Jonathan S. Katz
wrote:
> On 8/6/24 4:15 AM, Zhijie Hou (Fujitsu) wrote:
>
> > Thanks for the idea! I thought about few styles based on the suggested
> > format, what do you think about the following ?
>
> Thanks for proposing formats. Before commenting on
Hi Vignesh, Here are my only review comments for the latest patch set.
v20240820-0003.
nit - missing period for comment in FetchRelationStates
nit - typo in function name 'ProcessSyncingTablesFoSync'
==
Kind Regards,
Peter Smith.
Fujitsu Australia
diff --git a/src/backend/replication/logical
On Tue, Aug 20, 2024 at 6:53 PM David Rowley wrote:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
The table modifier
Avoid unnecessary form and deform tuple.
In the TPCH test, HashJoin speed up to ~2x.
diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c
index 61480733a1..2dad0c8a55 100644
--- a/src/backend/executor/nodeHash.c
+++ b/src/backend/executor/nodeHash.c
@@ -1627,6 +1627,23 @
On 8/6/24 4:15 AM, Zhijie Hou (Fujitsu) wrote:
Thanks for the idea! I thought about few styles based on the suggested format,
what do you think about the following ?
Thanks for proposing formats. Before commenting on the specifics, I do
want to ensure that we're thinking about the following f
Yugo Nagata 于2024年8月21日周三 00:49写道：
>
>
> > Is s1 a cascading standby of s2? If otherwise s1 and s2 is the standbys
> of
> > the primary server respectively, it is not surprising that s2 has
> progressed
> > far than s1 when the primary fails. I believe that this is the case you
> should
> > use p
On 2023-Oct-27, Ryo Matsumura (Fujitsu) wrote:
> Hi hackers,
>
> I found that 'make update-po' for PGXS does not work.
> Even if execute 'make update-po', but xx.po.new is not generated.
> I don't test and check for meson build system, but I post it tentatively.
>
> I attached patch and test set
Hi!
On Thu, Aug 15, 2024 at 10:13 PM Alena Rybakina
wrote:
> On 07.08.2024 04:11, Alexander Korotkov wrote:
> > On Mon, Aug 5, 2024 at 11:24 PM Alena Rybakina
> > wrote:
> >> Ok, thank you for your work)
> >>
> >> I think we can leave only the two added libraries in the first patch,
> >> others
On 2024-Aug-21, Michael Paquier wrote:
> I see that you've gone the way with the SQL function doing a load().
> Would it be worth switching the test to rely on the two macros for
> load and caching instead? I've mentioned that previously but never
> got down to present a patch for the sake of thi
On Tue, Aug 20, 2024 at 02:37:34PM -0400, Alvaro Herrera wrote:
> OK, I've made some minor adjustments and pushed. CI seemed OK for me,
> let's see what does the BF have to say.
I see that you've gone the way with the SQL function doing a load().
Would it be worth switching the test to rely on th
On Tue, Aug 20, 2024 at 12:10:08PM -0400, Tom Lane wrote:
> ... which would also imply writing documentation and so forth,
> and it'd mean that injection_points starts to show up in end-user
> installations. (That would happen with the alternative choice of
> hacking install-world to include src/t
David Rowley writes:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
>> I like trying to use ONLY somehow.
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
> Making it a command option means that the option
On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> I like trying to use ONLY somehow.
Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
or as a table modifier like gram.y's extended_relation_expr?
Making it a command option means that the option would apply to all
tables liste
On Wed, Aug 21, 2024 at 9:48 AM Alvaro Herrera wrote:
> Hi. I noticed chipmunk is failing in configure:
>
> checking whether the C compiler works... no
> configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
> configure: error: C compiler cannot create executables
One of the runs show
I think you've counted the above system tables from the database, but
I'll double-check it. Thank you for your review!
On 19.08.2024 19:28, Ilia Evdokimov wrote:
Are you certain that all tables are included in
`pg_stat_vacuum_tables`? I'm asking because of the following:
SELECT count(*) FROM
We check it there: "tabentry->vacuum_ext.type != type". Or were you
talking about something else?
On 19.08.2024 12:32, jian he wrote:
in pg_stats_vacuum
if (type == PGSTAT_EXTVAC_INDEX || type == PGSTAT_EXTVAC_HEAP)
{
Oidrelid = PG_GETARG_OID(1);
Hi! Thank you very much for your review! Sorry for my late response I
was overwhelmed by tasks.
On 16.08.2024 14:12, jian he wrote:
On Thu, Aug 15, 2024 at 4:49 PM Alena Rybakina
wrote:
Hi!
I've applied all the v5 patches.
0002 and 0003 have white space errors.
+
+Number of
On Tue, Aug 20, 2024 at 09:05:54AM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
>> too.
>
> +1. I think the fmgr.h prototype may have been left there
> deliberately to avoid breaking extension code, but it's past
On Tue, 20 Aug 2024 at 23:48, Jacob Champion
wrote:
> That guarantee (if adopted) would also make it possible for my use
> case to proceed correctly, since a libpq client can still speak 3.0
> packets on the socket safely.
Not necessarily (at least not how I defined it). If a protocol
parameter h
On Thu, 25 Jul 2024 at 08:45, Anthonin Bonnefoy
wrote:
> +1 keeping this as a separate command and using \bind_named. \bind has
> a different behaviour as it also parses the query so keeping them as
> separate commands would probably avoid some confusion.
+1 on naming it \bind_named
@Anthonin ar
Hi. I noticed chipmunk is failing in configure:
checking whether the C compiler works... no
configure: error: in `/home/pgbfarm/buildroot/HEAD/pgsql.build':
configure: error: C compiler cannot create executables
You may want to give it a look.
Thanks!
--
Álvaro Herrera PostgreSQL Deve
On Tue, Aug 20, 2024 at 12:55 PM Jelte Fennema-Nio wrote:
> Another way of describing this guarantee: If a client connects using
> 3.8 and configures no protocol parameters, the client needs to handle
> anything 3.8 specific that the handshake requires (such as longer
> cancel token). But then aft
I've combined all the current proposed changes into one patch. I've also
introduced signed versions of the negation functions into int.h to avoid
relying on multiplication.
--
nathan
>From 2364ba4028f879a22b9f69f999aee3ea9c013ec0 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 20 Aug 2
On 14/08/2024 16:54, Arseny Sher wrote:
On 8/13/24 06:35, Amit Kapila wrote:
On Mon, Aug 12, 2024 at 3:43 PM Arseny Sher wrote:
Sorry for the poor formatting of the message above, this should be
better:
Hey. Currently synchronous_commit is disabled for logical apply worker
on the ground th
On Tue, 20 Aug 2024 at 19:31, Jacob Champion
wrote:
> It's applicable to the use case I was talking about with Jelte. A
> libpq client dropping down to the socket level is relying on
> (implicit, currently undocumented/undecided, possibly incorrect!)
> intermediary guarantees that the protocol pro
On Tue, 20 Aug 2024 at 19:02, David G. Johnston
wrote:
> So basically my proposal amounted to making every update a "major version
> update" and changing the behavior surrounding NegotiateProtocolVersion so it
> applies to major version differences. I'll stand by that change in
> definition.
> As it looks like we have a consensus that reducing the number of interrupts
> also
> makes sense, I just provided a rebase version of the 1 Hz version (see [0],
> that
> also makes clear in the doc that the new field might show slightly old
> values).
That makes sense. However, I suspect the
On Mon, Aug 5, 2024 at 4:16 AM Alexander Korotkov wrote:
> I've revised the patchset. First of all, I've re-ordered the patches.
>
> 0001-0002 (former 0002-0003)
> Comprises hash_search_with_hash_value() function and its application
> to avoid full hash iteration in InvalidateAttoptCacheCallback(
On Tue, Aug 20, 2024 at 02:12:25PM +0530, Amit Kapila wrote:
> +1 for Nathan's version. It is quite close to the previous version,
> for which we haven't heard any complaints since they were introduced.
Committed, thanks.
--
nathan
On Tue, Aug 13, 2024 at 03:22:27PM +0300, Nazir Bilal Yavuz wrote:
> 2- collect_corrupt_items()
>
> This one is more complicated. The read stream callback function loops
> until it finds a suitable block to read. So, if the callback returns
> an InvalidBlockNumber; it means that the stream process
On Tue, Aug 20, 2024 at 07:03:56PM +0200, Jelte Fennema-Nio wrote:
> On Tue, 20 Aug 2024 at 18:50, Bruce Momjian wrote:
> > Okay, so we can do MAX easily, and AVG if the count can be represented
> > as the same data type as the sum? Is that correct? Our only problem is
> > that something like AV
On Tue, Aug 20, 2024 at 1:52 AM Michael Harris wrote:
> 2. The existing ANALYZE command has the following structure:
>
> ANALYZE [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
>
> It would be easiest to add ONLY as another option, but that
> doesn't look quite
> right to me
On 2024-Aug-19, Andrey M. Borodin wrote:
> > On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote:
> >
> > Alvaro, please find attached the test.
> > I’ve addressed some Michael’s comments in a nearby thread: removed
> > extra load, made injection point names lowercase, fixed some grammar
> > issues
I wrote:
> Michael Paquier writes:
>> It looks like %replace_line expects all its elements to have one space
>> between each token, still this is not enforced with a check across its
>> hardcoded elements?
> Yeah, I was wondering about that. I wouldn't do it exactly like
> that, but with a check
On Tue, Aug 20, 2024 at 10:46 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston
> wrote:
> > Semantic versioning guidelines are not something we are following,
> especially here.
>
> I understand; the protocol is ours, and we'll do wh
On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston
wrote:
> Semantic versioning guidelines are not something we are following, especially
> here.
I understand; the protocol is ours, and we'll do whatever we do in the
end. I'm claiming that we can choose to provide semantics, and if we
do, those
On Tue, Aug 20, 2024 at 10:31 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> If we decide we can't, then so be it -- things will
> break either way -- but it's still strange to me that we'd be okay
> with literally zero forward compatibility and still call that a "minor
> version".
On Tue, Aug 20, 2024 at 8:24 AM Heikki Linnakangas wrote:
> > Put another way: for a middlebox on the connection (which may be
> > passively observing, but also maybe actively adding new messages to
> > the stream), what is guaranteed to remain the same in the protocol
> > across a minor version b
On Tue, Aug 20, 2024 at 10:03 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio
> wrote:
> > In practical terms I think that means for a minor version bump the
> > format of the StartupMessage cannot be changed. Changing anything else
On Tue, Aug 20, 2024 at 1:02 PM David G. Johnston
wrote:
> So basically my proposal amounted to making every update a "major version
> update" and changing the behavior surrounding NegotiateProtocolVersion so it
> applies to major version differences. I'll stand by that change in
> definition.
On Tue, 20 Aug 2024 at 18:50, Bruce Momjian wrote:
> Okay, so we can do MAX easily, and AVG if the count can be represented
> as the same data type as the sum? Is that correct? Our only problem is
> that something like AVG(interval) can't use an array because arrays have
> to have the same data
On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio wrote:
> In practical terms I think that means for a minor version bump the
> format of the StartupMessage cannot be changed. Changing anything else
> is fair game for a minor protocol version bump.
I may be in a tiny minority here, but when I com
On Tue, Aug 20, 2024 at 9:44 AM Robert Haas wrote:
> On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston
> wrote:
> > I'm wondering why we are indicating that minor versions of the protocol
> are even a real thing.
>
> Because that concept is already a part of the existing wire protocol.
>
>
Righ
On Tue, 20 Aug 2024 at 18:42, David G. Johnston
wrote:
> v18 libpq-based clients, if they attempt to connect using v4 and fail, will
> try again using the v3 connection. That will retain status quo behavior when
> something like a connection pooler doesn't understand the new reality.
Having co
On Tue, Aug 20, 2024 at 04:46:54PM +0300, Heikki Linnakangas wrote:
> There are pros and cons. With direct I/O, you cannot take advantage of the
> kernel page cache anymore, so it becomes important to tune shared_buffers
> more precisely. That's a downside: the system requires more tuning. For many
On Tue, Aug 20, 2024 at 10:07:32AM +0200, Jelte Fennema-Nio wrote:
> On Thu, 15 Aug 2024 at 23:12, Bruce Momjian wrote:
> > Third, I would like to show a more specific example to clarify what is
> > being considered above. If we look at MAX(), we can have FDWs return
> > the max for each FDW, and
On Mon, 19 Aug 2024 16:43:09 +0800
px shi wrote:
> Hi, hackers,
>
> I've recently encountered an issue where a standby crashes when
> reconnecting to a new primary after a switchover under certain conditions.
> Here's a procedure of the crash scenario:
>
>
> 1) We have three instances: one pri
On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston
wrote:
> I'm wondering why we are indicating that minor versions of the protocol are
> even a real thing.
Because that concept is already a part of the existing wire protocol.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 20, 2024 at 9:02 AM Robert Haas wrote:
> Yes. And the major * 1 + minor convention is used in other places
> already, for PG versions, so it might already be familiar to some
> people.
>
I'm wondering why we are indicating that minor versions of the protocol are
even a real thing
On 2024-Aug-20, Tom Lane wrote:
> We do, however, need to preserve the property that installcheck
> works after install-world. I'm starting to think that maybe
> the 041 test should be hacked to silently skip if it doesn't
> find injection_points available.
Yeah, I like this option. Injection p
Melih Mutlu , 20 Ağu 2024 Sal, 19:26 tarihinde şunu
yazdı:
> Hi Michael,
>
> Thanks for starting this thread. I've also spent a bit time on this after
> reading your first thread on this issue [1]
>
Forgot to add the reference [1]
[1]
https://www.postgresql.org/message-id/cadofcaxvbd0ygp_eac9chmz
Hi,
On Tue, Aug 20, 2024 at 12:06:52PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Aug 20, 2024 at 05:41:48PM +0900, Michael Paquier wrote:
> > On Tue, Aug 20, 2024 at 11:10:46AM +0530, Ashutosh Bapat wrote:
> > > Since these are all related changes, doing them at once might make it
> > > fa
Hi Michael,
Thanks for starting this thread. I've also spent a bit time on this after
reading your first thread on this issue [1]
Michael Harris , 20 Ağu 2024 Sal, 08:52 tarihinde şunu
yazdı:
> The problem is that giving an ANALYZE command targeting a partitioned table
> causes it to update stat
Hi,
On Tue, Aug 20, 2024 at 09:30:48PM +0900, Yugo Nagata wrote:
> Should be the follwing also rewritten using sizeof(PG_REPLSLOT_DIR)?
>
>struct stat statbuf;
> charpath[MAXPGPATH * 2 + 12];
>
>
Yeah, done in v3 that I just shared up-thread (also removed the macros from
the co
Hi,
On Tue, Aug 20, 2024 at 10:15:44AM -0400, Alvaro Herrera wrote:
> On 2024-Aug-19, Bertrand Drouvot wrote:
>
> > diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h
> > index 6f006d5a93..a6cb091635 100644
> > --- a/src/include/common/relpath.h
> > +++ b/src/include/common/
I wrote:
> Ugh. The basic issue here is that "make install-world" doesn't
> install anything from underneath src/test/modules, which I recall
> as being an intentional decision. Rather than poking a hole in
> that policy for injection_points, I wonder if we should move it
> to contrib.
... which
On Tue, Aug 20, 2024 at 11:53 AM Jelte Fennema-Nio wrote:
> On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote:
> > I personally like this less than both (a) adding a new function and
> > (b) redefining the existing function as Jelte proposes. It just seems
> > too clever to me.
>
> Agreed, I'm not
On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote:
> I personally like this less than both (a) adding a new function and
> (b) redefining the existing function as Jelte proposes. It just seems
> too clever to me.
Agreed, I'm not really seeing a benefit of returning 4 instead of
30004. Both are new
On Tue, Aug 20, 2024 at 11:24 AM Heikki Linnakangas wrote:
> That's not a completely crazy idea, it crossed my mind too. And since we
> already decided to skip protocol number 3.1, how about we jump directly
> to 3.4. That way:
>
> protocol |
> version | PQProtocolVersion()
>
> 2 | 2 (
On 20/08/2024 16:48, Jacob Champion wrote:
On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio wrote:
My point is that the code that breaks, actually wants to be broken in this case.
I'll turn this around then and assume for a moment that this is true:
no matter what the use cases are, they all
Dear All,
I would propose a new function like GetXLogInsertRecPtr(), but with some
modifications (please, see the attached patch). The result LSN can be passed to
XLogFLush() safely. I believe, it will not raise an error in any case.
XLogFlush(GetXLogLastInsertEndRecPtr()) will flush (fsync) a
Maxim Orlov writes:
> So, my point here: installcheck-world doesn't
> work on the current master branch until I explicitly install
> injection_points extension. In my view, it's a bit wired, since
> neither test_decoding, pg_stat_statements or pg_prewarm demand it.
Ugh. The basic issue here is
On Tue, Aug 20, 2024 at 9:00 AM Amit Langote wrote:
> I think we'd modify plancache.c to postpone the locking of only
> prunable relations (i.e., partitions), so we're looking at only a
> handful of concurrent modifications that are going to cause execution
> errors. That's because we disallow ma
On Tue, 20 Aug 2024 at 15:48, Jacob Champion
wrote:
> Put another way: for a middlebox on the connection (which may be
> passively observing, but also maybe actively adding new messages to
> the stream), what is guaranteed to remain the same in the protocol
> across a minor version bump? Hopefully
Hi
On Mon, Aug 19, 2024 at 10:12 PM Tom Lane wrote:
>
> We have had multiple instances of code "return"ing out of a PG_TRY,
> so I fully agree that some better way to detect that would be good.
> But maybe we ought to think about static analysis for that.
I have some static analysis scripts for
On 2024-Aug-19, Bertrand Drouvot wrote:
> diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h
> index 6f006d5a93..a6cb091635 100644
> --- a/src/include/common/relpath.h
> +++ b/src/include/common/relpath.h
> @@ -33,6 +33,10 @@ typedef Oid RelFileNumber;
> #define TABLESPACE_V
On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio wrote:
> My point is that the code that breaks, actually wants to be broken in this
> case.
I'll turn this around then and assume for a moment that this is true:
no matter what the use cases are, they all want to be broken for
correctness. If thi
On 20/08/2024 11:46, 陈宗志 wrote:
I’ve recently started exploring PostgreSQL implementation. I used to
be a MySQL InnoDB developer, and I find the PostgreSQL community feels
a bit strange.
There are some areas where they’ve done really well, but there are
also some obvious issues that haven’t been
On 2024-08-19 Mo 8:00 AM, Alexander Lakhin wrote:
Hello Andrew,
29.07.2024 13:54, Andrew Dunstan wrote:
On 2024-07-29 Mo 4:00 AM, Alexander Lakhin wrote:
And another interesting fact is that TEMP_CONFIG is apparently
ignored by
`meson test regress/regress`. For example, with temp.config
On Tue, Aug 20, 2024 at 3:21 AM Robert Haas wrote:
> On Mon, Aug 19, 2024 at 1:52 PM Tom Lane wrote:
> > Robert Haas writes:
> > > But that seems somewhat incidental to what this thread is about.
> >
> > Perhaps. But if we're running into issues related to that, it might
> > be good to set asid
Heikki Linnakangas writes:
> On 20/08/2024 07:46, Michael Paquier wrote:
>> How about removing it like in the attached to be consistent?
> +1. There's also a prototype for _PG_fini() in fmgr.h, let's remove that
> too.
+1. I think the fmgr.h prototype may have been left there
deliberately to a
On Tue, Aug 20, 2024 at 1:39 AM Robert Haas wrote:
> On Fri, Aug 16, 2024 at 8:36 AM Amit Langote wrote:
> > So it is possible for the executor to try to run a plan that has
> > become invalid since it was created, so...
>
> I'm not sure what the "so what" here is.
I meant that if the executor h
Hi,
On Tue, Aug 13, 2024 at 11:40:27AM -0500, Nathan Bossart wrote:
> On Tue, Aug 13, 2024 at 11:07:46AM -0500, Imseih (AWS), Sami wrote:
> > Having to add special handling to space out instrumentation
> > directly in vacuum_delay_point seems very odd to me. I don't
> > think vacuum_delay_point sh
Hi,
On Mon, Jul 01, 2024 at 04:59:25AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Jun 28, 2024 at 08:07:39PM +, Imseih (AWS), Sami wrote:
> > > 46ebdfe164 will interrupt the leaders sleep every time a parallel workers
> > > reports
> > > progress, and we currently don't handle interrup
On Tue, 20 Aug 2024 17:47:57 +0900
Michael Paquier wrote:
> On Mon, Aug 19, 2024 at 02:11:55PM +, Bertrand Drouvot wrote:
> > I made the changes for pg_tblspc in pg_combinebackup.c as the number of
> > occurences
> > are greater that the "pg_wal" ones and we were to define PG_TBLSPC_DIR in
Hi,
On Fri, Aug 16, 2024 at 12:22 AM Shlok Kyal wrote:
>
> On Wed, 7 Aug 2024 at 11:48, Amit Kapila wrote:
> >
> > On Wed, Aug 7, 2024 at 7:42 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Aug 6, 2024 at 1:12 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Sat, Aug 3, 2024 at 1:21 AM Masa
On Tue, 20 Aug 2024 at 08:21, Peter Smith wrote:
>
> On Fri, Aug 16, 2024 at 2:15 PM vignesh C wrote:
> >
>
> Thanks for the review.
>
> >
> > I agree currently there is no test to hit this code. I'm not sure if
> > this is the correct location for the test, should it be included in
> > the 008_d
On Tue, 20 Aug 2024 at 16:10, Amit Kapila wrote:
>
> On Thu, Aug 15, 2024 at 9:31 PM vignesh C wrote:
> >
> > On Thu, 8 Aug 2024 at 16:24, Shlok Kyal wrote:
> > >
> > > On Wed, 31 Jul 2024 at 11:17, Shlok Kyal wrote:
> > > >
> > >
> > > Created a patch for distributing invalidations.
> > > Here
Hi,
On Tue, Aug 20, 2024 at 05:47:57PM +0900, Michael Paquier wrote:
> On Mon, Aug 19, 2024 at 02:11:55PM +, Bertrand Drouvot wrote:
> > I made the changes for pg_tblspc in pg_combinebackup.c as the number of
> > occurences
> > are greater that the "pg_wal" ones and we were to define PG_TBLSP
Hi,
On Tue, Aug 20, 2024 at 05:41:48PM +0900, Michael Paquier wrote:
> On Tue, Aug 20, 2024 at 11:10:46AM +0530, Ashutosh Bapat wrote:
> > Since these are all related changes, doing them at once might make it
> > faster. You may use multiple commits (one for each change)
>
> Doing multiple commit
On 2024-08-18 Su 12:00 PM, Alexander Lakhin wrote:
Hello Andrew,
04.06.2024 14:56, Andrew Dunstan wrote:
but I can't see ../snapshot_too_old/output_iso/regression.diff and
.../snapshot_too_old/output_iso/log/postmaster.log in the log.
will do.
I've discovered a couple of other failu
Hi All,
When we use a graph table and any local table, the server crashes.
Please note, It is happening when using the where clause for the local
table only.
postgres=# SELECT * FROM customers a, GRAPH_TABLE (myshop2 MATCH (c IS
customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders
On Tue, 20 Aug 2024 at 23:25, Ilia Evdokimov
wrote:
> Your proposal is indeed interesting, but I have a question: can't your issue
> be resolved by properly configuring autovacuum instead of developing a new
> feature for ANALYZE?
Basically, no. There's a "tip" in [1] which provides information
Shame on me, I didn't mention one thing in the original email. Actually,
the problem starts for me with "make installcheck-world".
And only then I've run a specific test 041_checkpoint_at_promote.pl. I.e.
the whole sequence of the commands are:
configure --enable_injection_points ...
make world
m
On 20.8.24 10:42, Jelte Fennema-Nio wrote:
On Tue, 20 Aug 2024 at 07:52, Michael Harris wrote:
1. Would such a feature be welcomed? Are there any traps I might not
have thought of?
I think this sounds like a reasonable feature.
2. The existing ANALYZE command has the following struct
On Tuesday, August 20, 2024 12:37 PM Amit Kapila
wrote:
>
> On Mon, Aug 19, 2024 at 4:16 PM Amit Kapila
> Pushed.
Thanks for pushing.
Here are the remaining patches.
0001 adds additional doc to explain the log format.
0002 collects statistics about conflicts in logical replication.
Best Reg
1 - 100 of 120 matches
Mail list logo
