On Sun, Mar 02, 2025 at 02:23:54PM +0100, Julien Tachoires wrote:
> On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
> > With the help of the new TAM routine 'relation_options', table access
> > methods can with this patch define their own relopti
On Thu, Mar 27, 2025 at 09:02:02PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-03-28 09:44:58 +0900, Michael Paquier wrote:
> > On Thu, Mar 27, 2025 at 12:06:45PM -0400, Robert Haas wrote:
> > > On Thu, Mar 27, 2025 at 11:58 AM Andres Freund wrote:
> > > > So, today we have the weird situation t
On Tue, Mar 25, 2025 at 01:17:22AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
> >> 2. Tools that are not entitled to set the value of the GUC are forced
> >> to be prepared to cope with any setting.
Hi,
On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
>
> I'm not opining one way or the other on whether squashing an IN list
> is desirable. My point is that a GUC is a poor way to make --- or
> really, avoid making --- such decisions. The reasons we took away
> from previous experimen
On Fri, Mar 07, 2025 at 08:52:26AM -0500, Robert Haas wrote:
> On Thu, Mar 6, 2025 at 7:03 PM Julien Rouhaud wrote:
> > Honestly, it's been years of people complaining on one thing or another
> > about
> > lapwing without ever asking for a change. Was it really
On Thu, Mar 06, 2025 at 06:25:29PM -0500, Robert Haas wrote:
> On Thu, Mar 6, 2025 at 5:12 PM Julien Rouhaud wrote:\
> > I indeed don't want to keep lapwing up unless there is any value. Note
> > that it
> > started to fail on 2 branches after the last buildfarm clien
On Thu, Mar 06, 2025 at 02:28:20PM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-03-06 14:13:40 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > On Thu, Mar 6, 2025 at 1:07 PM Tom Lane wrote:
> > >> Maybe invent a build-farm.conf option like "newest_branch_to_build"?
> >
> > > Yes, that would
On Tue, Mar 04, 2025 at 10:18:49AM -0500, Tom Lane wrote:
>
> But yeah, I thought we were overdue for a buildfarm release.
> I'm pleased to see that Andrew just pushed one.
FWIW I installed the client version 19.1 this morning and forced a run on HEAD
and lapwing is back to green.
On Tue, Mar 04, 2025 at 08:33:46AM -0500, Robert Haas wrote:
> On Mon, Mar 3, 2025 at 6:09 PM Julien Rouhaud wrote:
> > Well, AFAIK the usual habit when something is broken and a buildfarm cilent
> > upgrade is needed is to warn the buildfarm owners. There was an email
&g
688/
Thank you. After taking a look at the patch itself and the email thread,
it seems this patch does not add custom reloptions to table AMs, see
[1].
[1]: https://www.postgresql.org/message-id/1823308.yXV3o4JbTB%40thinkpad-pgpro
--
Julien Tachoires
november, did I miss something?
>
> OK, thanks. The owner is pgbuildf...@rjuju.net, which I'm guessing
> might be Julien Rouhaud, but not sure?
Yes it's me. I'm not sure why it's such a mystery as I've been answering for
it for many years. Having an alias is u
On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
> With the help of the new TAM routine 'relation_options', table access
> methods can with this patch define their own reloptions
> parser/validator.
>
> These reloptions can be set via the following co
w.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
[2]
https://www.postgresql.org/message-id/flat/caff0-cg4kzhdtyhmsonwixnzj16gwzpduxan8yf7pddub+g...@mail.gmail.com
[3]
https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979
On Fri, Feb 14, 2025 at 03:56:32PM +0100, Dmitry Dolgov wrote:
> > On Fri, Feb 14, 2025 at 10:39:45PM GMT, Julien Rouhaud wrote:
> > There seems to be an off-by-1 error in parameter numbering when merging
> > them.
>
> There are indeed three constants, but the second is no
On Fri, Feb 14, 2025 at 03:20:24PM +0100, Dmitry Dolgov wrote:
>
> Btw, there was another mistake in the last version introducing
> "$1 /*, ... */" format, the constant position has to be of course
> calculated as usual.
I'm not sure what you mean here, but just in case:
> +SELECT * FROM test_me
On Fri, Feb 14, 2025 at 10:36:48AM +0100, Álvaro Herrera wrote:
> On 2025-Feb-14, Julien Rouhaud wrote:
>
> > Since the merging is a yes/no option (I think there used to be some
> > discussions
> > about having a threshold or some other fancy modes), maybe you could inste
Hi,
On Fri, Feb 14, 2025 at 09:36:08AM +0100, Dmitry Dolgov wrote:
> > On Thu, Feb 13, 2025 at 05:08:45PM GMT, Sami Imseih wrote:
> > This case with an array passed to aa function seems to cause a regression
> > in pg_stat_statements query text. As you can see the text is incomplete.
>
> I've alre
On Wed, Feb 12, 2025 at 03:47:14PM -0600, Nathan Bossart wrote:
> On Wed, Feb 12, 2025 at 09:38:04AM -0600, Nathan Bossart wrote:
> > In any case, I don't see a problem with removing "volatile" now, so I'll
> > plan on committing this later today if there are no objections.
>
> Committed.
Thanks.
On Wed, Feb 12, 2025 at 01:57:47PM +0100, Alvaro Herrera wrote:
> On 2025-Feb-12, Julien Rouhaud wrote:
>
> > > FWIW, I think options to tweak queryId computation is something that
> > > should be in core. It was discussed earlier in the context of IN
> > >
Hi,
While reading some code in fmgr.c I noticed that the save_nestlevel variable is
declared as volatile. I'm assuming that's because a long time ago it was
modified in the PG_TRY / PG_CATCH block but it doesn't look needed anymore.
Trivial patch attached.
diff --git a/src/backend/utils/fmgr/fmg
On Tue, Feb 11, 2025 at 08:57:46PM -0600, Sami Imseih wrote:
> > Of course some people may want to keep the current behavior, if they have
> > limited number of temp tables or similar, so I had a GUC for that. I don't
> > think that the community would really welcome such GUC for core-postgres,
>
On Wed, Feb 12, 2025 at 10:59:04AM +0900, Michael Paquier wrote:
> On Wed, Feb 12, 2025 at 09:20:53AM +0800, Julien Rouhaud wrote:
> >
> > FTR my main motivation was to be able to deal with queries referencing
> > temporary relations, as if your application creates a lot of th
s last part
> impacts some extensions and I have been maintaining one a bit
> (pg_hint_plan).
I agree that fingerprint is a good improvement.
>
> Also adding Julien in CC,
> as he has some out-of-core extension code that depends on the jumbling
> structures if I recall correctly.
Hi,
On Sat, Feb 08, 2025 at 07:47:23AM +0100, Pavel Stehule wrote:
> Hi
>
> when I worked on strict expr check patch I found so syntax for named
> arguments of cursors supports only our legacy proprietary syntax `argname
> := value`
>
> https://www.postgresql.org/docs/current/plpgsql-cursors.html
On Sun, Jan 19, 2025 at 03:32:19AM +0800, 赵庭海(庭章) wrote:
>
> I'm sorry I left out some details earlier. I found that the garbage collect
> backend process was in the loop of gc_qtexts while for a long time. The main
> backtrace is below.
>
> ```
> #0 0x7fc528d6aba0 in __write_nocancel () from
On Fri, Jan 17, 2025 at 11:01:41AM -0500, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + t
Hi,
On Thu, Jan 16, 2025 at 10:19:49AM +0800, 赵庭海(庭章) wrote:
> Hi all,
> Recently, I have noticed a potential problem in the pg_stat_statements
> extension. When the garbage collection is triggered within this extension,
> if there is a significant amount of data to be written to the
> pgss_query
Hi,
On Fri, Jan 10, 2025 at 01:04:14PM +0100, Magnus Hagander wrote:
> In an effort to make at least a couple of more people realize they have to
> run ALTER EXTENSION UPDATE after they've upgraded an extension, as well as
> make it a bit easier to realize when you have to do it, I propose we add
Hi,
On Mon, Jan 06, 2025 at 06:49:06PM +0900, torikoshia wrote:
>
> > **However, I think the general direction has merit**: Changing this
> > patch to
> > use `ru_inblock`/`ru_oublock` gives very useful insights. `ru_inblock`
> > is 0 when everything is in page cache, and it is very high when stuf
On Fri, Dec 20, 2024 at 11:23 PM Tom Lane wrote:
>
> Could we get that animal updated to
> some newer OS version?
There is already adder animal that is running debian sid on i386. The
only remaining interest in lapwing is to have older versions of
everything, so if that's useless I can just tras
On Wed, 9 Oct 2024, 21:22 Ashutosh Bapat,
wrote:
> On Wed, Oct 9, 2024 at 4:22 AM Julien Rouhaud wrote:
> >
> > On Wed, Oct 9, 2024 at 12:40 AM Ashutosh Bapat
> > wrote:
> > >
> > > On Tue, Oct 8, 2024 at 7:57 PM Julien Rouhaud
> wrote:
> >
On Wed, Oct 9, 2024 at 12:40 AM Ashutosh Bapat
wrote:
>
> On Tue, Oct 8, 2024 at 7:57 PM Julien Rouhaud wrote:
> >
> > Hi,
> >
> > I was looking at the CREATE FOREIGN TABLE documentation to see if IDENTITY
> > columns were supported, and according to
Hi,
I was looking at the CREATE FOREIGN TABLE documentation to see if IDENTITY
columns were supported, and according to the doc they're not: only GENERATED
ALWAYS AS ( expr ) STORED is supported.
However, a quick test shows that this is supported (same as serial datatype),
and apparently behaves
Hi Tomas,
Le lun. 23 sept. 2024 à 18:13, Tomas Vondra a écrit :
>
> Hi,
>
> I've spent a bit more time on this, mostly running tests to get a better
> idea of the practical benefits.
Thank you for your code review and testing!
> Firstly, I think there's a bug in ReorderBufferCompress() - it's l
On Sat, 14 Sept 2024, 23:44 Tom Lane, wrote:
> Julien Rouhaud writes:
> > On Sat, 14 Sept 2024, 12:39 Tom Lane, wrote:
> >> Hmm ... I agree that para is out of date, but is there anything to
> >> salvage rather than just delete it?
>
> > I thought about it
On Sat, 14 Sept 2024, 12:39 Tom Lane, wrote:
> Julien Rouhaud writes:
> > While adapting in pg_stat_kcache the fix for buggy nesting level
> calculation, I
> > noticed that one comment referencing the old approach was missed.
> Trivial
> > patch attached.
>
> Hm
17 00:00:00 2001
From: Julien Rouhaud
Date: Sat, 14 Sep 2024 12:18:19 +0800
Subject: [PATCH v1] Remove obsolete comment in pg_stat_statements
Commit 76db9cb6368 removed the use of multiple nesting counters but missed an
associated comment.
---
contrib/pg_stat_statements/pg_stat_statements.c
Le lun. 15 juil. 2024 à 12:28, Tomas Vondra
a écrit :
>
> On 7/15/24 20:50, Julien Tachoires wrote:
> > The last patch of this set is still in WIP, it adds the machinery
> > required for setting the compression methods as a subscription option:
> > CREATE SUBSCRIPTION ...
Le ven. 7 juin 2024 à 05:59, Tomas Vondra
a écrit :
>
> On 6/6/24 12:58, Julien Tachoires wrote:
> > ...
> >
> > When compiled with LZ4 support (--with-lz4), this patch enables data
> > compression/decompression of these temporary files. Each transaction
> >
Le jeu. 6 juin 2024 à 07:24, Alvaro Herrera a écrit :
>
> On 2024-Jun-06, Amit Kapila wrote:
>
> > On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> > >
> > > When the content of a large transaction (size exceeding
> > > logical_decoding_wo
Le jeu. 6 juin 2024 à 06:40, Amit Kapila a écrit :
>
> On Thu, Jun 6, 2024 at 6:22 PM Julien Tachoires wrote:
> >
> > Le jeu. 6 juin 2024 à 04:13, Amit Kapila a écrit :
> > >
> > > On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> > > >
Le jeu. 6 juin 2024 à 04:13, Amit Kapila a écrit :
>
> On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> >
> > When the content of a large transaction (size exceeding
> > logical_decoding_work_mem) and its sub-transactions has to be
> > reordered during l
Hi,
When the content of a large transaction (size exceeding
logical_decoding_work_mem) and its sub-transactions has to be
reordered during logical decoding, then, all the changes are written
on disk in temporary files located in pg_replslot/.
Decoding very large transactions by multiple replicatio
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 Mon, May 13, 2024 at 07:11:53PM GMT, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote:
> >> Hmmm, depending on the extension it can extensively call/use postgres code
> >> so would be nice if we can differentiate if the code is called from
On Mon, Feb 26, 2024 at 01:56:44PM +0530, Robert Haas wrote:
> On Sun, Feb 25, 2024 at 5:00 PM Julien Rouhaud wrote:
> > Yeah, trying to find a generalized solution seems like worth investing some
> > time to avoid having a bunch of CHECK_FOR_XXX() calls scattered in the code
>
On Mon, Feb 26, 2024 at 12:19:42PM +0530, Ashutosh Bapat wrote:
> On Sun, Feb 25, 2024 at 5:00 PM Julien Rouhaud wrote:
> >
> > > > On Fri, Feb 23, 2024 at 7:50 PM Julien Rouhaud
> > > > wrote:
> > > > >
> > > > > Bu
On Fri, Feb 23, 2024 at 11:00:41PM +0100, Alvaro Herrera wrote:
>
> Another, similar but not quite: if you do
>
> SET search_path TO foo;
> SELECT * FROM t1;
> SET search_path TO bar;
> SELECT * FROM t1;
>
> and you have both foo.t1 and bar.t1, you'll get two identical-looking
> queries in pg_stat_
On Sat, Feb 24, 2024 at 08:56:41AM -0500, James Coleman wrote:
> On Fri, Feb 23, 2024 at 10:23 AM Robert Haas wrote:
> >
> > On Fri, Feb 23, 2024 at 7:50 PM Julien Rouhaud wrote:
> > >
> > > But it doesn't have to be all or nothing right? I mean eac
Hi,
On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
>
> - alias
>
> Currently, two queries like
>
> SELECT * FROM t1 AS foo
> SELECT * FROM t1 AS bar
>
> are counted together by pg_stat_statements -- that might be ok, but they
> both get listed under whichever one is run first, s
Hi,
On Fri, Feb 23, 2024 at 10:22:32AM +0530, Robert Haas wrote:
> On Thu, Feb 22, 2024 at 6:25 AM James Coleman wrote:
> > This is potentially a bit of a wild idea, but I wonder if having some
> > kind of argument to CHECK_FOR_INTERRUPTS() signifying we're in
> > "normal" as opposed to "critical
On Tue, Feb 13, 2024 at 05:28:32PM +0900, Michael Paquier wrote:
> On Tue, Feb 13, 2024 at 01:13:43AM +0900, Yugo NAGATA wrote:
> > I attached an updated patch that adds comments noting to use
> > IsQueryIdEnabled()
> > instead of accessing the variables directly.
>
> Sounds good to me, thanks.
Hi,
On Fri, Feb 09, 2024 at 03:38:23PM +0900, Yugo NAGATA wrote:
>
> I found the comment on query_id_enabled looks inaccurate because this is
> never set to true when compute_query_id is ON.
>
> /* True when compute_query_id is ON, or AUTO and a module requests them */
> bool query_id_enab
rebase the patch without success. Unfortunately, this is out of my league.
Magnus, please let me know if I can help.
Have a nice day,
Julien
Hi,
On Thu, Jan 18, 2024 at 11:01 PM Magnus Hagander wrote:
>
> I did. Here it is, and also including that suggested docs fix as well
> as a rebase on current master.
+if (MyClientConnectionInfo.authn_id)
+strlcpy(lbeentry.st_auth_identity,
MyClientConnectionInfo.authn_id, NAMEDATALE
On Sun, Dec 31, 2023 at 2:28 PM Michael Paquier wrote:
>
> On Sat, Dec 30, 2023 at 08:39:47PM +0100, Peter Eisentraut wrote:
> > Ok, I have committed these two patches.
>
> Please note that the buildfarm has turned red, as in:
> https://buildfarm.postgresql.org/cgi-bin/show_stagxe_log.pl?nm=pipit&
On Wed, Dec 27, 2023 at 8:53 PM Peter Eisentraut wrote:
>
> On 27.12.23 09:08, Julien Rouhaud wrote:
> >
> > I was a bit surprised by that so I checked locally. It does work as
> > expected provided that you set pg_stat_statements.track to all:
>
> Ok, here is an
Hi,
On Tue, Dec 26, 2023 at 10:03 PM Peter Eisentraut wrote:
>
> On 24.12.23 03:03, Michael Paquier wrote:
> > - Use a DO block of a PL function, say with something like that to
> > ensure an amount of N queries? Say with something like that after
> > tweaking pg_stat_statements.track:
> > CREAT
Hi,
On Sun, Dec 17, 2023 at 03:09:10PM +, Sukhbir Singh wrote:
>
> I am Sukhbir Singh, a B.Tech undergraduate, and I am in my pre-final year at
> Punjab Engineering College (PEC). I am new to open source but know Python,
> PostgreSQL, C, Javascript and node.js. I would love to contribute to yo
Hi,
On Wed, Jan 19, 2022 at 09:30:11AM +0100, Peter Eisentraut wrote:
>
> To use exclusion constraints in practice, you often need to install the
> btree_gist extension, so that you can combine for example a range type check
> and normal scalar key columns into one constraint.
>
> [...]
>
> There
Hi,
On Sat, Nov 25, 2023 at 02:45:07AM +0200, Alexander Korotkov wrote:
>
> I've reviewed this patch. I think this is the feature of high demand.
> New columns (stats_since and minmax_stats_since) to the
> pg_stat_statements view, enhancing the granularity and precision of
> performance monitoring
Hi,
On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:
>
> When I thought about global temporary tables, I got one maybe interesting
> idea. The one significant problem of global temporary tables is place for
> storing info about size or column statistics.
>
> I think so these data can
On Wed, Nov 15, 2023 at 01:53:13PM +0100, Daniel Gustafsson wrote:
> > On 11 Nov 2023, at 10:26, Julien Rouhaud wrote:
>
> > I was adding support for the new pg_stat_statements JIT deform_counter in
> > PoWA
> > when I realized that those were added after
ect position so let's be consistent.
Trivial patch attached.
>From 0144620d2de75d321e5273416fdab5df671b92f0 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud
Date: Sat, 11 Nov 2023 17:11:35 +0800
Subject: [PATCH v1] Fix documentation for pg_stat_statements JIT
deform_counter
Oversight
On Tue, Oct 24, 2023 at 6:57 PM Peter Eisentraut wrote:
>
> On 24.10.23 09:58, Andrei Zubkov wrote:
> > During last moving to the current commitfest this patch have lost its
> > reviewers list. With respect to reviewers contribution in this patch, I
> > think reviewers list should be fixed.
>
> I
On Thu, Oct 5, 2023 at 11:11 PM Jon Erdman wrote:
>
> As a second more general question: could my original idea (i.e. sans
> event trigger) be implemented in an extension somehow, or is that not
> technically possible (I suspect not)?
It should be easy to do using the ProcessUtility_hook hook, de
> issues c) one variable change (flush_lsn_changed to
> > confirmed_flush_has_changed) d) corrected few comments in the test
> > file. Thanks to Peter for providing few offline comments.
> >
>
> The latest version looks good to me. Julien, Ashutosh, and others,
> unless
Hi,
On Thu, Aug 24, 2023 at 12:55:30PM -0700, Gurjeet Singh wrote:
> Currently, psql exits if a database connection is not established when
> psql is launched.
>
> Sometimes it may be useful to launch psql without connecting to the
> database. For example, a user may choose to start psql and then
On Sat, 19 Aug 2023, 14:16 Amit Kapila, wrote:
> It's entirely possible for a logical slot to have a confirmed_flush
> LSN higher than the last value saved on disk while not being marked as
> dirty. It's currently not a problem to lose that value during a clean
> shutdown / restart cycle but to
On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 10:46:58AM +0800, Julien Rouhaud wrote:
> >
> > Agreed, it should be as trivial to implement as for the 2pc commands :)
>
> Perhaps not as much, actually, because I was just reminded
On Sat, Aug 12, 2023 at 01:20:03PM +0200, Dmitry Dolgov wrote:
> > On Sat, Aug 12, 2023 at 09:28:19AM +0800, Julien Rouhaud wrote:
> > On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
> > >
> > > Another confusing example was this one at t
On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
>
> Another confusing example was this one at the end of set_session_variable:
>
> + /*
> + * XXX While unlikely, an error here is possible. It wouldn't leak
> memory
> + * as the allocated chunk has already been correctl
Hi,
On Thu, Aug 10, 2023 at 04:30:40PM +0900, Masahiko Sawada wrote:
> On Thu, Aug 10, 2023 at 2:27 PM Amit Kapila wrote:
> >
> > Sawada-San, Julien, and others, do you have any thoughts on the above point?
>
> IIUC during the old cluster running in the middle of pg_upgrad
On Wed, Aug 09, 2023 at 10:29:56AM -0500, Tristan Partin wrote:
> On Wed Aug 9, 2023 at 10:02 AM CDT, Peter Eisentraut wrote:
> >
> > This patch has apparently upset one buildfarm member with a very old
> > compiler:
> > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=lapwing&br=HEAD
>
On Mon, Aug 07, 2023 at 12:42:33PM +0530, Amit Kapila wrote:
> On Mon, Aug 7, 2023 at 11:29 AM Julien Rouhaud wrote:
> >
> > Unless I'm missing something I don't see what prevents something to connect
> > using the replication protocol and issue any query or even c
On Mon, Aug 07, 2023 at 09:24:02AM +0530, Amit Kapila wrote:
>
> I think autovacuum is not enabled during the upgrade. See comment "Use
> -b to disable autovacuum." in start_postmaster(). However, I am not
> sure if there can't be any additional WAL from checkpointer or
> bgwriter. Checkpointer has
On Sun, Aug 06, 2023 at 01:37:42PM +0800, jacktby jacktby wrote:
>
> I need to build a new datatype. It can contains different datatypes, like
> ‘(1,’a’,2.0)’,it’s a (interger,string,float) tuple type
Is there any reason why you can't simply rely on the record datatype?
> and Then I need to
> add
On Sun, 6 Aug 2023, 12:34 jacktby jacktby, wrote:
> I’m trying to add a new operator for my pg application like greater_equals
> called “<~>", how many files I need to
> modify and how to do it? Can you give me an example?
>
you can look at some contrib for some examples of custom operator (and
Hi,
On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote:
> Hi, I’m trying to
> develop a new grammar for pg, can
+you give me a code example to reference?
It's unclear to me whether you want to entirely replace the flex/bison parser
with something else or just add some new bison rule.
If th
On Tue, Aug 01, 2023 at 11:37:49AM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 10:22:09AM +0800, Julien Rouhaud wrote:
> > Looking at the rest of the ignored patterns, the only remaining one would be
> > DEALLOCATE, which AFAICS doesn't have a query_jumble_ignore t
On Tue, Aug 01, 2023 at 11:00:32AM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 09:28:08AM +0800, Julien Rouhaud wrote:
>
> > FTR we had to entirely ignore all those statements in powa years ago to try
> > to
> > make the tool usable in such case for some users
Hi,
On Tue, Aug 01, 2023 at 09:38:14AM +0900, Michael Paquier wrote:
>
> 31de7e6 has silenced savepoint names in the query jumbling, and
> something similar can be done for 2PC transactions once the GID is
> ignored in TransactionStmt. This leads to the following grouping in
> pg_stat_statements,
Hi,
On Wed, Jun 07, 2023 at 11:02:09AM +0800, 謝東霖 wrote:
> Thank you, Julien, for letting me know that cfbot doesn't test txt files.
> Much appreciated!
Thanks for posting this v2!
So unsurprisingly the cfbot is happy with this patch, since it doesn't change
the behavior at a
Hi,
On Thu, Jul 13, 2023 at 03:17:17PM +0800, フブキダイスキ wrote:
> After I create the same name index on the heap table and the temporary
> table, I can only get the temporary table's index by \di+.
>
> create table t1(c1 int);
> create temp table t2(c1 int);
>
> create index idx1 on t1(c1);
> \di
On Wed, 12 Jul 2023, 23:15 Ashutosh Bapat,
wrote:
> Hi All,
> https://www.postgresql.org/docs/current/datatype-numeric.html gives me
> "bad gateway" error. Attached screen shot. Date/Time datatype
> documentation is accessible at
> https://www.postgresql.org/docs/current/datatype-datetime.html.
>
Hi,
On Thu, Jul 06, 2023 at 10:14:46AM +0800, jian he wrote:
>
> In:
> https://git.postgresql.org/cgit/postgresql.git/tree/contrib/pg_freespacemap/pg_freespacemap.c
>
> rel = relation_open(relid, AccessShareLock);
>
> if (blkno < 0 || blkno > MaxBlockNumber)
> ereport(ERROR,
> (errcode(ERRCODE_INV
> > 2018. The owner of both machines is added in CC. I guess that we
> > this stuff could just remove --with-openssl from the configure
> > switches.
>
> lapwing has reported a failure and runs a Debian 7, so adding Julien
> in CC about the removal of --with-openssl or s
On Mon, Jul 03, 2023 at 12:01:55PM +0300, Heikki Linnakangas wrote:
> On 01/07/2023 10:49, Julien Rouhaud wrote:
> >
> > I just noticed that the comment for PG_CACHE_LINE_SIZE still says that "it's
> > currently used in xlog.c", which hasn't been true for q
Hi,
I just noticed that the comment for PG_CACHE_LINE_SIZE still says that "it's
currently used in xlog.c", which hasn't been true for quite some time.
PFA a naive patch to make the description more generic.
>From a554ee9ca3558c1cc67b2f4024c13b26aacff3c9 Mon Sep 17 00:
On Wed, Jun 28, 2023 at 05:17:14PM +0800, Julien Rouhaud wrote:
> >
> > Table t1 and t2 both has 2 columns: c1, c2, when CTE join select *, the
> > result target list seems to lost one’s column c1.
> > But it looks good when select cte1.* and t1.* explicitly .
> >
Hi,
On Wed, Jun 28, 2023 at 04:52:34PM +0800, Zhang Mingli wrote:
>
> Mini repo
>
> create table t1(c1 int, c2 int);
> CREATE TABLE
> create table t2(c1 int, c2 int);
> CREATE TABLE
> explain with cte1 as (insert into t2 values (1, 2) returning *) select * from
> cte1 join t1 using(c1);
> QUERY
On Wed, Jun 14, 2023 at 02:08:03PM +0300, Aleksander Alekseev wrote:
>
> Unfortunately I'm not familiar with the problem in respect of naptime
> Julien is referring to. If you know what this problem is and how to
> fix it, go for it. I'll review and test the code then. I c
On Tue, Jun 13, 2023 at 12:34:09PM +0300, Aleksander Alekseev wrote:
>
> > I agree that the current code
> > could lead folks to think that PushActiveSnapshot must go after
> > SPI_connect, but wouldn't the reverse ordering just give folks the opposite
> > impression?
>
> This is the exact reason w
On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote:
>
> Well, if we're gonna do it we should do it for v16, rather than
> change the data structure twice. It wouldn't be hard exactly:
>
> /*
> * Clear fields that should not be set in a subquery RTE. Note that we
> * leave the
On Wed, Jun 07, 2023 at 03:42:25PM +0800, jiye wrote:
> we will update all commits with latest version certaintly, but we must
> confirm that this issue is same with it currently we can not confirm this
> issue can be fixed by revert 2aa6e331ead7f3ad080561495ad4bd3bc7cd8913 this
> commit, so i just
On Wed, Jun 07, 2023 at 03:12:44PM +0800, jiye wrote:
> actually out test instance include 2aa6e331ead7f3ad080561495ad4bd3bc7cd8913
> this commit, not yet reverted this commit.
Are you saying that you're doing tests relying on a version that's missing
about 3 years of security and bug fixes? You
On Tue, Jun 06, 2023 at 03:30:02PM -0400, Robert Haas wrote:
> On Mon, Jun 5, 2023 at 1:50 AM jiye wrote:
>
> > we can not get determinate test case as this issue reproduce only once,
> > and currently autovaccum can works as we using vacuum freeze for each
> > tables of each database.
> >
> > our
On Tue, 6 Jun 2023, 16:18 謝東霖, wrote:
> Thank you to Julien Rouhaud and Tender Wang for the reviews.
>
> Julien's detailed guide has proven to be incredibly helpful, and I am
> truly grateful for it.
> Thank you so much for providing such valuable guidance!
>
> I have
a
>> similar way, potentially everywhere system() is called.
>
>
> Are there instructions for how I can run these other test suites? The
> installation notes that Julien linked, and the Postgres wiki Developer FAQ
> [1] only seem to mention "make check". I would be happy to t
Hi,
On Mon, Jun 05, 2023 at 09:47:30AM -0400, Evan Jones wrote:
> This makes "make check" work on Mac OS X. Without this patch, on Mac OS X a
> default "./configure; make; make check" fails with errors like:
>
> dyld[65265]: Library not loaded: /usr/local/pgsql/lib/libpq.5.dylib
> Referenced fr
1 - 100 of 1104 matches
Mail list logo
