Hi,
On Sun, Feb 20, 2022 at 07:23:56PM +0900, Dong Wook Lee wrote:
> Hi hackers,
> I've read in this blog (
> http://big-elephants.com/2015-10/writing-postgres-extensions-part-i/)
> and I wrote an extension about base36_encode with c code
> but when I executed a query like this below I got a warni
in the pg_hba.conf file are immediately
> applied by subsequent new connections.
I also find this comment a bit misleading. Wouldn't it be better to have a
similar statement for pg_ident, or at least a note that it applies to both
files?
>From 61437776c103b7a3520ab6486cc5f1e88df0f80a
Hi,
On Thu, Feb 24, 2022 at 04:50:59PM +, Jacob Champion wrote:
> On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> > I don't quite see the additional value that this API brings as
> > MyProcPort is directly accessible, and contrib modules like
> > postgres_fdw and sslinfo just use t
On Thu, Feb 24, 2022 at 08:44:08PM +, Jacob Champion wrote:
>
> Yeah... I was following a similar track with the initial work last
> year, but I dropped it when the cost of implementation started to grow
> considerably. At the time, though, it looked like some overhauls to the
> stats framewor
Hi,
On Thu, Feb 24, 2022 at 09:18:26PM -0800, Andres Freund wrote:
>
> On 2022-02-25 13:01:26 +0800, Julien Rouhaud wrote:
> > On Thu, Feb 24, 2022 at 08:44:08PM +, Jacob Champion wrote:
> > >
> > > Yeah... I was following a similar track with the initial work
Hi,
On Fri, Feb 25, 2022 at 12:23:27AM +0530, Nitin Jadhav wrote:
> > I think the change to ImmediateCheckpointRequested() makes no sense.
> > Before this patch, that function merely inquires whether there's an
> > immediate checkpoint queued. After this patch, it ... changes a
> > progress-repor
Hi,
The final commitfest for pg15 will start in a few days, and I didn't see any
discussion on it or anyone volunteering to be a CFM.
I thought it would be a good idea to send this reminder now and avoid the same
situation as the last commitfest, to avoid unnecessary pain for the CFM(s).
Is ther
Hi,
On Fri, Feb 25, 2022 at 02:06:29PM +0100, Magnus Hagander wrote:
> Here's a patch to add the sum of timings for JIT counters to
> pg_stat_statements, as a way to follow-up on if JIT is doing a good or
> a bad job in a configuration.
+1, it seems like something quite useful.
> I decided to on
On Fri, Feb 25, 2022 at 04:19:27PM +0100, Magnus Hagander wrote:
>
> So just to be clear, you're basically thinking:
>
> jit_count = count of entries where jit_functions>0
> jit_functions =
> jit_optimizatinos = count of entries where time spent on jit_optimizations > 0
>
> etc?
Yes exactly, s
Hi,
On Fri, Feb 25, 2022 at 04:16:01PM +0100, Magnus Hagander wrote:
> This patch adds a configuration parameter jit_warn_above_fraction that
> will cause a warning to be logged if the fraction of time spent on
> doing JIT is bigger than the specified one. For example, this can be
> used to track
On Fri, Feb 25, 2022 at 08:53:50PM +0530, Nitin Jadhav wrote:
> >
> > I'm not sure what Matthias meant, but as far as I know there's no
> > fundamental
> > difference between checkpoint with and without the CHECKPOINT_IMMEDIATE
> > flag,
> > and there's also no scheduling for multiple checkpoints
On Fri, Feb 25, 2022 at 05:38:45PM +0100, Magnus Hagander wrote:
>
> Per some off-list discussion with Julien, we have clearly been talking
> in slightly different terms. So let's summarize the options into what
> theÿ́d actually be:
>
> Option 0: what is int he patch now
>
> Option 1:
> jit_count
On Fri, Feb 25, 2022 at 06:49:42PM +0100, Matthias van de Meent wrote:
>
> The point I was trying to make was "If cps->ckpt_flags is
> CHECKPOINT_IMMEDIATE, we hurry up to start the new checkpoint that is
> actually immediate". That doesn't mean that this checkpoint was
> created with IMMEDIATE or
On Sat, Feb 26, 2022 at 02:30:36AM +0800, Julien Rouhaud wrote:
> On Fri, Feb 25, 2022 at 06:49:42PM +0100, Matthias van de Meent wrote:
> >
> > The point I was trying to make was "If cps->ckpt_flags is
> > CHECKPOINT_IMMEDIATE, we hurry up to start the new ch
Hi,
On Sat, Feb 26, 2022 at 03:04:43PM +0900, Michael Paquier wrote:
> On Wed, Feb 23, 2022 at 09:44:58AM -0800, Nathan Bossart wrote:
> > On Wed, Feb 23, 2022 at 12:59:59PM +0800, Julien Rouhaud wrote:
> >> 0001 adds a new pg_ident_file_mappings view, which is bas
On Sat, Feb 26, 2022 at 02:42:33PM +0900, Michael Paquier wrote:
> On Fri, Feb 25, 2022 at 01:58:55PM -0600, David Steele wrote:
> > On 2/25/22 12:39, Greg Stark wrote:
> >> I would like to volunteer.
>
> > I've been hoping somebody would volunteer, so I'm all in favor of you being
> > CF.
>
> Gr
On Sat, Feb 26, 2022 at 03:36:19PM +0900, Michael Paquier wrote:
> On Sat, Feb 26, 2022 at 02:27:15PM +0800, Julien Rouhaud wrote:
>
> > Note that in order to do so we would need to expose quite a lot more about
> > hba
> > internals, like tokenize_file() and parse_hba_li
Hi,
On Sat, Feb 26, 2022 at 06:25:22AM -0700, David G. Johnston wrote:
> On Sat, Feb 26, 2022 at 5:42 AM Shay Rojansky wrote:
>
> > FWIW I've received feedback from a SQL Server engineer that one definitely
> > should *not* depend on such ordering there, and that future optimizations
> > (e.g. p
On Sat, Feb 26, 2022 at 06:37:21PM -0600, Justin Pryzby wrote:
> Can I suggest to update the CF APP to allow:
> | Target version: 16
>
> I also suggest to update patches to indicate which are (not) being considered
> for v15.
I don't really understand what that field is supposed to mean. But now
On Sun, Feb 27, 2022 at 06:10:45PM +0900, Michael Paquier wrote:
> On Sat, Feb 26, 2022 at 01:39:42PM -0800, Andres Freund wrote:
> > I suspect the easiest is to just convert that usleep to a WaitLatch().
> > That'd
> > require adding a new enum value to WaitEventTimeout in 14. Which probably is
>
Hi,
On Sun, Feb 27, 2022 at 08:45:13PM +0900, Dong Wook Lee wrote:
>
> I found some redundant function calls in
> pg_stat_statements.c/pg_stat_statements_internal(),
> There is no need to call GetUserId() again because the value was
> previously obtained.
Indeed. I doubt it will make any real d
Hi,
On Sun, Feb 27, 2022 at 10:42:25AM +0100, Jille Timmermans wrote:
>
> First time PostgreSQL contributor here :)
Welcome!
> I wanted to be able to allocate a bunch of numbers from a sequence at once.
> Multiple people seem to be struggling with this
> (https://stackoverflow.com/questions/896
Hi,
On Mon, Feb 28, 2022 at 10:21:23AM +0530, Bharath Rupireddy wrote:
>
> Another thought for my review comment:
> > 1) Can't we use pg_is_in_recovery to determine if it's a restartpoint
> > or checkpoint instead of having a new function
> > pg_stat_get_progress_checkpoint_type?
>
> I don't thi
On Sun, Feb 27, 2022 at 09:17:13PM +0100, Daniel Gustafsson wrote:
> > On 27 Feb 2022, at 18:42, Tom Lane wrote:
>
> > I'd rather keep all the ModifyTable code in one .c file, even if that one is
> > bigger than our usual practice.
>
> Agreed, I also prefer a (too) large file over a set of .c #i
Hi,
On Wed, Feb 23, 2022 at 09:44:58AM -0800, Nathan Bossart wrote:
>
> > Finally I also added 0003, which is a POC for a new pg_hba_matches()
> > function,
> > that can help DBA to understand why their configuration isn't working as
> > they
> > expect. This only to start the discussion on tha
On Mon, Feb 28, 2022 at 06:03:54PM +0530, Bharath Rupireddy wrote:
> On Mon, Feb 28, 2022 at 12:02 PM Julien Rouhaud wrote:
> >
> > I suggested upthread to store the starting timeline instead. This way you
> > can
> > deduce whether it's a restartpoint or a che
On Mon, Feb 28, 2022 at 05:00:05PM +0100, Peter Eisentraut wrote:
> On 25.02.22 14:06, Magnus Hagander wrote:
> > +OUT jit_generation_time float8,
> > +OUT jit_inlining_time float8,
> > +OUT jit_optimization_time float8,
> > +OUT jit_emission_time float8
>
> Perhaps those should be
Hi,
On Tue, Mar 01, 2022 at 10:11:03AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 28 Feb 2022 17:01:10 +0300, Sergei Kornilov wrote in
> > Hello
> > I just spotted in src/include/access/xlog.h:
> > extern XLogRecPtr CalculateMaxmumSafeLSN(void);
> >
> > This function doesn't seem to be used anyw
Hi,
On Tue, Mar 01, 2022 at 04:45:48PM +0900, Michael Paquier wrote:
>
> Hmm. The diffs of 0001 are really hard to read. Do you know why this
> is happening? Is that because some code has been moved around?
Yes, I followed the file convention to put the static functions first and then
the expo
There is an ask in that review for a second pass
> > over the docs by a native speaker, any takers?
>
> Patch has a new name, "session variables, LET command"
>
> There's been a *lot* of work on this patch so I'm loath to bump it.
> The last review was from J
On Wed, Mar 02, 2022 at 05:40:00PM +0300, Aleksander Alekseev wrote:
> Hi Tom.
>
> Yeah, there's plenty of precedent for that coding if you look around.
> > I've not read the whole patch, but this snippet seems fine to me
> > if there's also an #undef at the end of the function.
>
> No, there is no
On Wed, Mar 02, 2022 at 11:58:28AM -0500, Greg Stark wrote:
>
> But I'm unclear exactly what the consequences in the commitfest app
> are of specific state changes. As I understand it there are basically
> two alternatives:
>
> 1) Returned with feedback -- does this make it harder for an author to
== PARAM_VARIABLE)
+ {
+ appendStringInfo(context->buf, "%s",
+generate_session_variable_name(param->paramvarid));
+ return;
+ }
A bit more work seems to be needed for deparsing session variables:
# create variable myvar text;
CREATE VARIABLE
# create view myview as select myvar;
CREATE
On Thu, Mar 03, 2022 at 03:06:52PM +0800, Julien Rouhaud wrote:
> Hi,
>
> On Wed, Mar 02, 2022 at 06:03:06AM +0100, Pavel Stehule wrote:
> >
> > I lost commit with this change. I am sending updated patch.
Also, another thing is the size of the patch. It's prob
On Thu, Mar 03, 2022 at 04:24:03PM +0300, Aleksander Alekseev wrote:
>
> Thanks! Does anyone know if cfbot understands .patch.gz and/or .tgz ?
There's a FAQ link on the cfbot main page that answers this kind of questions.
On Thu, Mar 03, 2022 at 01:37:35PM +, Dave Page wrote:
>
> Then someone will complain if their patch is 2.1MB! How often are messages
> legitimately over 1MB anyway, even with a patch? I don't usually moderate
> -hackers, so I don't know if this is a common thing or not.
It's not common, most
On Thu, Mar 03, 2022 at 10:17:06AM -0500, Tom Lane wrote:
> Pavel Borisov writes:
> >> The mail system doesn't have the capability to apply different moderation
> >> rules for people in that way I'm afraid.
>
> > Maybe then 2MB for everyone?
>
> Maybe your patch needs to be split up? You're goi
On Wed, Mar 2, 2022 at 7:15 PM Nitin Jadhav
wrote:
>
> > > > As mentioned upthread, there can be multiple backends that request a
> > > > checkpoint, so unless we want to store an array of pid we should store
> > > > a number
> > > > of backend that are waiting for a new checkpoint.
>
> It's a go
Hi,
On Wed, Feb 16, 2022 at 03:25:40PM +0100, Peter Eisentraut wrote:
>
> All that preliminary work has been completed, so here is a new patch.
>
> There isn't actually much left here now except all the new DDL and
> command-line options to set this up and documentation for those. I have
> given
On Thu, Jan 06, 2022 at 05:05:32PM +0800, Julien Rouhaud wrote:
>
> Anyway, the only committer that showed some interest in the feature is
> Michael,
> and he seemed ok in principle with the "alias-implementation" approach.
> Michael, did you have a look at this version
On Sat, Mar 05, 2022 at 06:10:44PM -0800, Zhihong Yu wrote:
>
> Looking at pg_stat_statements, there doesn't seem to be timestamp column
> for when the underlying query is performed.
> Since the same query can be run multiple times, the absence of timestamp
> column makes finding the most recent in
On Sun, Mar 06, 2022 at 12:37:00PM -0800, Zhihong Yu wrote:
> The current design of pg_stat_statements doesn't have the concept of
> observation.
>
> By observation I mean scenarios where pg_stat_statements is read by people
> doing performance tuning.
>
> Here is one example (same query, q, is con
On Mon, Mar 07, 2022 at 10:36:24AM +0900, Michael Paquier wrote:
> On Mon, Mar 07, 2022 at 09:31:33AM +1100, Peter Smith wrote:
> > PSA patch to fix a comment typo.
> >
> > (The 'OR' should not be uppercase - that keyword is irrelevant here).
>
> I was looking at the whole routine, and your sugge
On Mon, Mar 07, 2022 at 11:27:14AM +0900, Michael Paquier wrote:
> On Sat, Mar 05, 2022 at 07:31:53PM +0900, Michael Paquier wrote:
> > I got a short look at what was proposed in the patch a couple of
> > months ago, and still found the implementation confusing with the way
> > aliases are handled,
On Sun, Mar 06, 2022 at 07:10:49PM -0800, Zhihong Yu wrote:
> On Sun, Mar 6, 2022 at 6:23 PM Julien Rouhaud wrote:
>
> > On Sun, Mar 06, 2022 at 12:37:00PM -0800, Zhihong Yu wrote:
> > >
> > > Here is one example (same query, q, is concerned).
> > > At
Hi,
On Thu, Feb 03, 2022 at 12:59:03AM +0300, Ekaterina Sokolova wrote:
>
> I apply the new version of patch.
>
> I wanted to measure overheads, but could't choose correct way. Thanks for
> idea with auto_explain.
> I loaded it and made 10 requests of pgbench (number of clients: 1, of
> threads: 1
On Mon, Mar 07, 2022 at 06:35:45AM +0100, Pavel Stehule wrote:
>
> this patch should be rejected. There is no consensus.
Thanks for the confirmation, I will take care of it!
Hi,
On Mon, Jan 17, 2022 at 01:44:02PM +, Simon Riggs wrote:
>
> Re-attached, so that the CFapp isn't confused between the multiple
> patches on this thread.
Thanks a lot for working on this!
The patch is simple and overall looks good to me. A few comments though:
+/*
+ * Single-item cach
On Mon, Mar 07, 2022 at 01:27:40PM +, Simon Riggs wrote:
> > +/*
> > + * Single-item cache for results of SubTransGetTopmostTransaction. It's
> > worth having
> > + * such a cache because we frequently find ourselves repeatedly checking
> > the
> > + * same XID, for example when scanning a t
Hi,
On Mon, Mar 07, 2022 at 09:42:26AM -0800, Zhihong Yu wrote:
> Hi,
> Currently the query id for pg_stat_statements gets calculated based on the
> parse nodes specifics.
> This means that the user cannot add a comment to a SQL query to test
> something. (though some other RDBMS allows this pract
On Mon, Mar 07, 2022 at 01:40:34PM +0100, Magnus Hagander wrote:
>
> I wonder if there might be an interesting middle ground, or if that is
> making it too much. That is, we could have an
> Option 3:
> jit_count
> total_jit_time - for sum of functions+inlining+optimization+emission time
> min_jit_t
Hi,
On Tue, Mar 08, 2022 at 06:15:43PM +1300, Thomas Munro wrote:
> On Wed, Dec 29, 2021 at 5:29 PM Thomas Munro wrote:
> > https://github.com/macdice/postgres/tree/recovery-prefetch-ii
>
> Here's a rebase. This mostly involved moving hunks over to the new
> xlogrecovery.c file. One thing that
On Tue, Mar 08, 2022 at 08:57:23PM +0530, Nitin Jadhav wrote:
>
> I just wanted to avoid extra calculations just to show the progress in
> the view. Since it's a good metric, I have added an additional field
> named 'next_flags' to the view which holds all possible flag values of
> the next checkp
On Thu, Mar 10, 2022 at 10:52:41AM +0100, Peter Eisentraut wrote:
> On 05.03.22 09:38, Julien Rouhaud wrote:
> > @@ -168,18 +175,6 @@ DefineCollation(ParseState *pstate, List *names, List
> > *parameters, bool if_not_e
> > errmsg("collation \&
On Fri, Mar 11, 2022 at 06:31:13PM +1300, Thomas Munro wrote:
> On Wed, Mar 9, 2022 at 7:47 PM Julien Rouhaud wrote:
> >
> > This could use XLogRecGetBlock? Note that this macro is for now never used.
> > xlogreader.c also has some similar forgotten code that could use
On Fri, Mar 11, 2022 at 02:41:23PM +0530, Nitin Jadhav wrote:
>
> Ok. I agree that it is difficult to interpret it correctly. So even if
> say that a new checkpoint has been explicitly requested, the user may
> not understand that it affects current checkpoint behaviour unless the
> user knows the
On Fri, Mar 11, 2022 at 04:59:11PM +0530, Nitin Jadhav wrote:
> > That "throttled" flag should be the same as having or not a "force" in the
> > flags. We should be consistent and report information the same way, so
> > either
> > a lot of flags (is_throttled, is_force...) or as now a single fiel
On Mon, Mar 14, 2022 at 06:15:59PM +1300, Thomas Munro wrote:
> On Fri, Mar 11, 2022 at 9:27 PM Julien Rouhaud wrote:
> > > > Also, is it worth an assert (likely at the top of the function) for
> > > > that?
> > >
> > > How could I assert that En
On Mon, Mar 14, 2022 at 03:16:50PM +0530, Nitin Jadhav wrote:
> > > I am not suggesting
> > > removing the existing 'flags' field of pg_stat_progress_checkpoint
> > > view and adding a new field 'throttled'. The content of the 'flags'
> > > field remains the same. I was suggesting replacing the 'ne
On Mon, Mar 14, 2022 at 01:50:50PM +0100, Peter Eisentraut wrote:
> On 05.03.22 09:38, Julien Rouhaud wrote:
> > I say it works because I did manually check, as far as I can see there isn't
> > any test that ensures it.
> >
> > I'm using this naive scenario:
Hi,
On Tue, Mar 15, 2022 at 12:54:58PM +0530, Prabhat Sahu wrote:
>
> Kindly check the below scenario with INTERVAL datatype.
>
> postgres=# select interval '01 20:59:59' + interval '00 05:00:01' as
> interval;
> interval
>
> 1 day 26:00:00
> (1 row)
>
> Any operation with
Hi,
On Tue, Mar 15, 2022 at 09:31:19AM +0800, lupeng wrote:
>
> When I audit the Postgresql database recently, I found that after configuring
> the log type as csv, the output log content is as follows: "database
> ""lp_db1"" does not exist","DROP DATABASE lp_db1;",,"dropdb,
> dbcommands.c:841
Hi,
On Wed, Mar 16, 2022 at 11:16:58AM +0800, zk.wang wrote:
> Generally, we should define struct in the header file(.h). But I found struct
> "DR_intorel" in createas.c and it doesn't seem to be properly defined. May be
> it should define in createas.h.
We put struct declarations in header files
Hi,
The cfbot says that the patch doesn't apply anymore, so here's a v3 with the
changes mentioned below.
On Tue, Mar 01, 2022 at 05:19:50PM +0800, Julien Rouhaud wrote:
>
> If you prefer to interleave static and non static function I can change it.
Change the split to not r
Hi,
On Thu, Mar 17, 2022 at 11:16:24PM -0700, Paul Martinez wrote:
>
> Adding and removing indexes is a regular part of database maintenance,
> but in a large database, removing an index can be a very risky operation.
> Removing the wrong index could have disastrous consequences for
> performance,
On Thu, Mar 17, 2022 at 02:14:52PM +0100, Peter Eisentraut wrote:
> On 17.03.22 13:01, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
> > Thank you to all the developers.
> > I found that the description of the pg_database.daticulocale column was not
> > written in the documentation.
> > The attached s
(moving to -hackers)
On Fri, Mar 18, 2022 at 03:40:51PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 18, 2022 at 02:36:48PM +0800, Julien Rouhaud wrote:
> > On Fri, Mar 18, 2022 at 06:15:47PM +1300, Thomas Munro wrote:
> > >
> > > No idea what's happening here
Hi,
On Fri, Mar 18, 2022 at 07:43:47PM +0400, Pavel Borisov wrote:
> Hi, hackers!
> I've noticed that CF bot hasn't been running active branches from yesterday:
> https://github.com/postgresql-cfbot/postgresql/branches/active
>
> Also, there is no new results on the current CF page on cputube.
>
On Fri, Mar 18, 2022 at 04:04:10PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Another option is that we just don't do the check in initdb. As the
> > tests show, you will then get an error from the backend call, so it's
> > really just a question of when the error is reported.
>
> +1 .
improvement. I can work on that next week if
needed.
[1]
https://www.postgresql.org/message-id/20220318000140.vzri3qw3p4aeb...@alap3.anarazel.de
>From f3884b483884a4e39b577dc01b72bab5176964bb Mon Sep 17 00:00:00 2001
From: Julien Rouhaud
Date: Fri, 18 Mar 2022 16:20:01 +0800
Subject: [PATCH v2] Fix
On Sat, Mar 19, 2022 at 04:46:13PM -0500, Justin Pryzby wrote:
> On Thu, Mar 03, 2022 at 03:06:52PM +0800, Julien Rouhaud wrote:
> > Hi,
> >
> > On Wed, Mar 02, 2022 at 06:03:06AM +0100, Pavel Stehule wrote:
> > >
> > > I lost commit with this change. I am
On Sun, Mar 20, 2022 at 11:03:38AM +0100, Peter Eisentraut wrote:
> On 19.03.22 05:14, Julien Rouhaud wrote:
> > On Fri, Mar 18, 2022 at 03:09:59PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2022-03-18 20:28:58 +0100, Peter Eisentraut wrote:
>
On Sun, Mar 20, 2022 at 01:58:01PM +0100, Matthias van de Meent wrote:
>
> I noticed that two of my patches (37/3543 and 37/3542) both failed due
> to a bad commit on master (076f4d9). The issue was fixed an hour later
> with b61e6214; but the pipeline for these patches hasn't run since.
> Because
Hi,
On Sun, Mar 20, 2022 at 05:36:38PM +1300, Thomas Munro wrote:
> On Fri, Mar 18, 2022 at 9:59 AM Thomas Munro wrote:
> > I'll push 0001 today to let the build farm chew on it for a few days
> > before moving to 0002.
>
> Clearly 018_wal_optimize.pl is flapping and causing recoveryCheck to
> f
Hi,
Please don't top-post here. See
https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics.
On Tue, Mar 22, 2022 at 09:37:46AM +, Niyas Sait wrote:
>
> Yes, we could look into providing a build machine. Do you have any
> reference to what the CI system looks like now for Po
Hi,
On Tue, Mar 22, 2022 at 03:21:20PM +0300, Aleksander Alekseev wrote:
>
> The v3-0001 patch LGTM.
>
> Since v3-0002 adds a new view and alters pg_proc.dat shouldn't it also
> increase CATALOG_VERSION_NO? Not sure if we generally do this in the
> patches or expect the committer to make the chang
Hi,
On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>
> Pushed with slight adjustments - the LOAD was unnecessary as was the
> setting of client_min_messages - the latter would have made buildfarm
> animals unhappy.
For the record this just failed on my buildfarm animal:
https://
Hi,
On Wed, Mar 23, 2022 at 11:03:46AM +0900, Michael Paquier wrote:
>
> Pushing forward with 0001 by the end of the CF is the part that has no
> controversy IMO, and I have no objections to it. Now, after looking
> at this part, I found a few things, as of:
> - HbaToken, the set of elements in
Hi,
Sorry for showing up this late, but I'm a bit confused with the new situation.
Unless I'm missing something, the new situation is that the system is supposed
to prevent access to MaxBackends during s_p_l_pg_init, for reasons I totally
agree with, but without doing anything for extensions that
On Wed, Mar 23, 2022 at 08:32:39AM -0400, Robert Haas wrote:
> On Wed, Mar 23, 2022 at 12:53 AM Julien Rouhaud wrote:
> > Unless I'm missing something, the new situation is that the system is
> > supposed
> > to prevent access to MaxBackends during s_p_l_pg_init, for r
Hi,
Someone raised an interested point recently on pg_stat_kcache extension for
handling nested statements, which also applies to pg_stat_statements.
The root issue is that when pg_stat_statements tracks nested statements,
there's no way to really make sense of the counters, as top level statemen
On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud wrote:
>
> > Someone raised an interested point recently on pg_stat_kcache extension for
> > handling nested statements, which also applies to
On Wed, Dec 02, 2020 at 03:52:37PM +0900, Fujii Masao wrote:
>
> On 2020/12/02 15:32, Julien Rouhaud wrote:
> > On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> > > On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud wrote:
> > >
> > &g
On Wed, Dec 02, 2020 at 06:23:54AM -0800, Nikolay Samokhvalov wrote:
> On Tue, Dec 1, 2020 at 10:32 PM Julien Rouhaud wrote:
>
> > On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote:
> > > If all top-level records in pg_stat_statements have "tru
On Wed, Dec 02, 2020 at 05:13:56PM +0300, Sergei Kornilov wrote:
> Hello
>
> > - add a parent_statement_id column that would be NULL for top level queries
>
> Will generate too much entries... Every FK for each different delete/insert,
> for example.
> But very useful for databases with a lot of
On Thu, Dec 03, 2020 at 11:40:22AM +0300, Sergei Kornilov wrote:
> Hello
>
> > To get an increase in the number of records that means that the same
> > statement
> > would appear at top level AND nested level. This seems a corner case with
> > very low
> > (neglectible) occurence rate.
>
> +1
> I
;, VERSION 'X.Y') DATABASE mydb;
to only rebuild indexes depending on a specific version of libc.
>From 5acf42e15c0dc8b185547ff9cb9371a86a057ec9 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud
Date: Thu, 3 Dec 2020 15:54:42 +0800
Subject: [PATCH v1] Add a new COLLATION option to REINDE
On Thu, Dec 03, 2020 at 04:53:59PM +0800, Julien Rouhaud wrote:
> On Thu, Dec 03, 2020 at 11:40:22AM +0300, Sergei Kornilov wrote:
> > Hello
> >
> > > To get an increase in the number of records that means that the same
> > > statement
> > > would appear
On Fri, Dec 04, 2020 at 12:06:10PM +0300, Sergei Kornilov wrote:
> Hello
>
> Seems we need also change PGSS_FILE_HEADER.
Indeed, thanks! v2 attached.
>From 1da24926d9645ee997aabd2907482a29332e3729 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud
Date: Fri, 4 Dec 2020 13:33:51 +
On Mon, Dec 14, 2020 at 3:45 PM Michael Paquier wrote:
>
> On Thu, Dec 03, 2020 at 05:31:43PM +0800, Julien Rouhaud wrote:
> > Now that we have the infrastructure to track indexes that might be corrupted
> > due to changes in collation libraries, I think it would be a good
On Fri, Dec 04, 2020 at 06:09:13PM +0800, Julien Rouhaud wrote:
> On Fri, Dec 04, 2020 at 12:06:10PM +0300, Sergei Kornilov wrote:
> > Hello
> >
> > Seems we need also change PGSS_FILE_HEADER.
>
> Indeed, thanks! v2 attached.
There was a conflict on PGSS_FILE_HEAD
On Sun, Oct 18, 2020 at 4:12 PM Julien Rouhaud wrote:
>
> On Sun, Oct 18, 2020 at 12:20 PM Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > > Wait ... what? I've been thinking that this GUC is just to enable or
> > > disable the computation of qu
On Fri, Jan 8, 2021 at 4:02 PM 曾文旌 wrote:
>
> > 2021年1月7日 22:16，Bruce Momjian 写道：
> >
> > On Thu, Jan 7, 2021 at 05:44:01PM +0800, 曾文旌 wrote:
> >> I've been following this topic for a long time. It's been a year since the
> >> last response.
> >> It was clear that our customers wanted this feat
On Sat, Feb 20, 2021 at 09:28:39PM +1300, Thomas Munro wrote:
> Hello,
>
> Andrew Gierth pointed out that I left behind some outdated advice
> about RAID spindles in the GUC's extra description field, in commit
> b09ff536. Let's just drop that description. Patch attached.
+1.
On Mon, Feb 22, 2021 at 7:52 AM Andres Freund wrote:
>
> On 2021-02-21 19:05:03 +0100, Daniele Varrazzo wrote:
> > One of the HikariCP configuration parameters is "maxLifetime", whose
> > description is: "This property controls the maximum lifetime of a
> > connection in the pool. [...] **We stron
Hi,
Thanks for the review!
On Mon, Feb 8, 2021 at 12:14 AM Zhihong Yu wrote:
>
> Hi,
> For index_has_deprecated_collation(),
>
> + object.objectSubId = 0;
>
> The objectSubId field is not accessed by
> do_check_index_has_deprecated_collation(). Does it need to be assigned ?
Indeed it's not s
Hi,
On Wed, Feb 24, 2021 at 8:21 PM talk to ben wrote:
>
> The documentation describes how a return code > 125 on the restore_command
> would prevent the server from starting [1] :
>
> "
> It is important that the command return nonzero exit status on failure. The
> command will be called reque
Hi,
On Thu, Feb 25, 2021 at 12:11 AM mariakatosvich
wrote:
>
> From what I heard on this topic, the goal is to reduce
> the amount of time necessary to reindex a system so as REINDEX only
> works on indexes whose dependent collation versions are not known or
> works on indexes in need of a collat
On Thu, Feb 25, 2021 at 7:25 PM Benoit Lobréau wrote:
>
> Le mer. 24 févr. 2021 à 14:52, Julien Rouhaud a écrit :
>>
>> I thought that this behavior was documented, especially for the lack
>> of update of pg_stat_archiver. If it's not the case then we should
>&g
Hi,
On Wed, Feb 24, 2021 at 09:34:59PM +0300, Darafei "Komяpa" Praliaskouski wrote:
> Hello,
>
> The PostGIS project needed this from time to time. Would be great if
> reindex by opclass can be made possible.
>
> We changed the semantics of btree at least twice (in 2.4 and 3.0), fixed
> some ND
1 - 100 of 1688 matches
Mail list logo
