On Sat, Aug 28, 2021 at 11:00:11AM +0900, Michael Paquier wrote:
> On Fri, Aug 27, 2021 at 08:16:40PM +, Bossart, Nathan wrote:
> > On 8/27/21, 12:39 PM, "Andres Freund" wrote:
> >> One thing I wonder is if this wouldn't better be dealt with in a more
> >> generic
> >> way. While this is the
On Wed, Aug 25, 2021 at 9:49 PM Robert Haas wrote:
>
> On Wed, Aug 25, 2021 at 9:20 AM Peter Eisentraut
> wrote:
> > This change removes the Value struct and node type and replaces them
> > by separate Integer, Float, String, and BitString node types that are
> > proper node types and structs of
On Fri, Aug 27, 2021 at 08:16:40PM +, Bossart, Nathan wrote:
> On 8/27/21, 12:39 PM, "Andres Freund" wrote:
>> One thing I wonder is if this wouldn't better be dealt with in a more generic
>> way. While this is the most problematic runtime computed GUC, it's not the
>> only one. What if we int
On Sat, Aug 28, 2021 at 9:40 AM Michael Paquier wrote:
>
> On Fri, Aug 27, 2021 at 12:28:42PM -0700, Andres Freund wrote:
> > Isn't that just going to end up with extension code erroring out and/or
> > blocking waiting for a bgworker to start?
>
> Well, that's the point to block things during an u
On Sat, Aug 28, 2021 at 3:28 AM Andres Freund wrote:
>
> > On Fri, Aug 27, 2021 at 7:31 AM Michael Paquier wrote:
> >
> > > Wouldn't it be better to block things at the source, as of
> > > RegisterBackgroundWorker()? And that would keep track of the control
> > > we have on bgworkers in a single
On Fri, Aug 27, 2021 at 12:28:42PM -0700, Andres Freund wrote:
> Isn't that just going to end up with extension code erroring out and/or
> blocking waiting for a bgworker to start?
Well, that's the point to block things during an upgrade. Do you have
a list of requirements you'd like to see satis
> 28 авг. 2021 г., в 07:05, Andres Freund написал(а):
>
> However, we have a
> bandaid that deals with possible hangs, by SIGKILLing when processes don't
> shut down (at that point things have already gone quite south, so that's not
> an issue).
Thanks for the explanation. I can see that child
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Egor Rogov (e.ro...@postgrespro.ru) wrote:
> > On 11.02.2021 01:10, Stephen Frost wrote:
> > >* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > >>On 05/02/2021 23:22, Stephen Frost wrote:
> > >>>Unless there's anything else on this, I'll c
> On Aug 23, 2021, at 1:46 PM, Stephen Frost wrote:
>
> I'd much rather we go down the path that Robert had suggested where we
> find a way to make a connection between the tenant role and everything
> that they create, and leave everything that is outside of that box on
> the other side of th
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> As the code in question was only introduced in dc7420c2c92 it seems worth
> backpatching this change as well, otherwise 14 will look different from all
> other branches.
Interestingly, these patches ended up actually introducing a differenc
Greetings,
* Michael Banck (michael.ba...@credativ.de) wrote:
> On Thu, Apr 01, 2021 at 04:00:06PM -0400, Stephen Frost wrote:
> > diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
> > index d171b13236..fe0bdb7599 100644
> > --- a/doc/src/sgml/user-manag.sgml
> > +++ b/doc/s
Hi,
On 2021-08-27 23:51:27 +0300, Denis Smirnov wrote:
> > 26 авг. 2021 г., в 23:39, Tom Lane написал(а):
> >
> > (BTW, I think it's pretty silly to imagine that adding backtrace()
> > calls inside ereport is making things any more dangerous. ereport
> > has pretty much always carried a likelih
> 26 авг. 2021 г., в 23:39, Tom Lane написал(а):
>
> (BTW, I think it's pretty silly to imagine that adding backtrace()
> calls inside ereport is making things any more dangerous. ereport
> has pretty much always carried a likelihood of calling malloc(),
> for example.)
I have taken a look th
On Fri, Aug 27, 2021 at 12:55 PM Stephen Frost wrote:
> > Okay. Plan is now to push these two patches together, later on. The
> > second patch concerns this separate track_io_timing issue. It's pretty
> > straightforward.
> >
> > (No change to the first patch in the series, relative to the v2 from
Hi,
On Fri, Aug 27, 2021, at 13:07, Robert Haas wrote:
> On Fri, Aug 27, 2021 at 3:24 PM Andres Freund wrote:
> > I wonder if we could improve the situation somewhat by using the
> > non-blocking
> > pqcomm functions in a few select places. E.g. if elog.c's
> > send_message_to_frontend() sent it
On Fri, Aug 27, 2021 at 3:24 PM Andres Freund wrote:
> I wonder if we could improve the situation somewhat by using the non-blocking
> pqcomm functions in a few select places. E.g. if elog.c's
> send_message_to_frontend() sent its message via a new pq_endmessage_noblock()
> (which'd use the existi
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Fri, Aug 27, 2021 at 12:30 PM Stephen Frost wrote:
> > I don't particularly care for that explain rule, ultimately, but it's
> > been around longer than I have and so I guess it wins. I'm fine with
> > always showing the read/write for VACU
On Fri, Aug 27, 2021 at 12:30 PM Stephen Frost wrote:
> I don't particularly care for that explain rule, ultimately, but it's
> been around longer than I have and so I guess it wins. I'm fine with
> always showing the read/write for VACUUM and ANALYZE.
>
> Including 'ms' and lower-casing 'Timings
Hi,
On 2021-08-19 19:10:37 -0400, John Naylor wrote:
> I've made a small step in this direction in the attached. It uses a
> template approach to generate type-specific SearchCatCache* functions, for
> now only the 4-key ones. Since there's only a few of those, it's manageable
> to invoke the temp
Hi,
On 2021-08-27 19:27:18 +, Bossart, Nathan wrote:
> +
> + --output-shmem
> +
> +
> +Prints the amount of shared memory required for the given
> +configuration and exits. This can be used on a running server, but
> +the return value reflects th
I noticed that for \dP+ since 1c5d9270e, regclass is written without
"pg_catalog." (Alvaro and I failed to notice it in 421a2c483, too).
+ if (showNested || pattern)
+ appendPQExpBuffer(&buf,
+ ",\n c3.oid::regclass as
\"%s\"",
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Fri, Aug 27, 2021 at 11:35 AM Stephen Frost wrote:
> > > BTW, I noticed one thing about the track_io_time stuff. Sometimes it
> > > looks like this:
> > >
> > > I/O timings:
> > >
> > > i.e., it doesn't show anything at all after the
Hi,
On 2021-08-27 09:34:24 +0800, Julien Rouhaud wrote:
> On Fri, Aug 27, 2021 at 7:31 AM Michael Paquier wrote:
> >
> > Indeed, there is some history here with autovacuum. I have not been
> > careful enough to check that. Still, putting a check on
> > IsBinaryUpgrade in bgworker_should_start_n
Hi,
On 2021-08-27 08:27:38 -0400, Robert Haas wrote:
> On Tue, Aug 24, 2021 at 9:58 PM Fujii Masao
> wrote:
> > to report an error to a client, and then calls AbortCurrentTransaction()
> > to abort the transaction. If secure_write() called by EmitErrorReport()
> > gets stuck, a backend gets stuc
On Fri, Aug 27, 2021 at 11:35 AM Stephen Frost wrote:
> > BTW, I noticed one thing about the track_io_time stuff. Sometimes it
> > looks like this:
> >
> > I/O timings:
> >
> > i.e., it doesn't show anything at all after the colon.
> Reporting zeros seems
> valuable to me in that it shows
Hi,
On 2021-08-23 10:13:03 -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) wrote:
> > I want to know why the interrupt is only handled when ProcDiePending is
> > true, I think query which is supposed to be canceled also should respond to
> > the signal.
>
> Well, if we're h
On Thu, Aug 26, 2021 at 10:28 PM Peter Geoghegan wrote:
> I'll commit this in a day or two, backpatching to 14. Barring any objections.
Actually, we also need to make the corresponding lines for ANALYZE
follow the same convention -- those really should be consistent. As in
the attached revision.
On 2021-08-27 16:40:27 +0200, Magnus Hagander wrote:
> On Fri, Aug 27, 2021 at 8:46 AM Michael Paquier wrote:
> I'd say a lot more than just handy. I don't think the workaround is
> really all that useful.
+1
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost wrote:
> > I generally like the idea though I'm not sure about changing things in
> > v13 as there's likely code out there that's already parsing that data
> > and it might suddenly break if this wa
On Fri, Aug 27, 2021 at 1:19 AM Michael Paquier wrote:
>
> On Thu, Aug 19, 2021 at 03:58:57PM -0700, David G. Johnston wrote:
> > I'm at -0.5 as to whether such a patch would actually be an improvement or
> > whether the added possibilities would just be confusing and, because it is
> > all option
On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost wrote:
> I generally like the idea though I'm not sure about changing things in
> v13 as there's likely code out there that's already parsing that data
> and it might suddenly break if this was changed.
Agreed -- I won't backpatch anything to v13.
>
Andrew Dunstan writes:
> First, this apparently only affects build done with NLS. And in fact
> even on release 11 the performance is much better when run on a non-NLS
> build. So there's lots of work to do here.
Wow ... it would not have occurred to me to check that.
Testing that angle using HE
> >> Good. I was thinking of adding such capability, possibly for handling
> >> connection errors and reconnecting…
> >
> > round-robin and random make sense. I am wondering how round-robin
> > would work with -C, though? Would you just reuse the same connection
> > string as the one chosen at th
Somehow -hackers got left off the cc:
On 8/22/21 6:11 PM, Andrew Dunstan wrote:
> On 8/22/21 5:59 PM, l...@laurent-hasson.com wrote:
>> > -Original Message-
>> > From: Andrew Dunstan
>> > Sent: Sunday, August 22, 2021 17:27
>> > To: Tom Lane ; l...@laurent-hasson.com
>> > Cc: Justin Pr
Bonjour Michaël,
Good. I was thinking of adding such capability, possibly for handling
connection errors and reconnecting…
round-robin and random make sense. I am wondering how round-robin
would work with -C, though? Would you just reuse the same connection
string as the one chosen at the s
On 8/27/21, 7:27 AM, "Daniel Gustafsson" wrote:
> I took another look at this today and pushed it after verifying with a
> pgindent
> run. Thanks!
Thank you!
Nathan
I have reviewed the patch and it looks good to me. However I have one comment.
+ foreach(l, attachrel_children)
+ {
+ Oid partOid = lfirst_oid(l);
+
+ CacheInvalidateRelcacheByRelid(partOid);
+ }
Can
On Fri, Aug 27, 2021 at 8:46 AM Michael Paquier wrote:
>
> On Wed, Aug 11, 2021 at 11:23:52PM +, Bossart, Nathan wrote:
> > I think BootstrapModeMain() makes the most sense. It fits in nicely
> > with the --check logic that's already there. With v3, the following
> > command can be used to r
> On 23 Jul 2021, at 01:39, Bossart, Nathan wrote:
> The patch looks good to me. I am marking it as ready-for-committer.
I took another look at this today and pushed it after verifying with a pgindent
run. Thanks!
--
Daniel Gustafsson https://vmware.com/
I tested the following query (from SQLite documentation):
CREATE TABLE edge(aa INT, bb INT);
WITH RECURSIVE nodes(x) AS (
SELECT 59
UNION
SELECT aa FROM edge JOIN nodes ON bb=x
UNION
SELECT bb FROM edge JOIN nodes ON aa=x
)
SELECT x FROM nodes;
ERROR: 42P19: recursive reference
> On 27 Aug 2021, at 14:15, Nico Rikken wrote:
> I haven't yet tested this, as I'm still in the process of setting up a local
> development environment. I hope somebody else here can help me with the
> quality
> assurance.
This is the mailinglist for the core postgres server, for pgadmin develo
In certain cases like with OpenID Connect, a different scope is needed. This
patch adds an additional variable `OAUTH2_SCOPE` that can be used to configure
the appropriate scope for the deployment. Already there are runtime checks to
ensure that the email claim is included in the user profile, so t
On Fri, Aug 27, 2021 at 10:05 AM Andrey Borodin wrote:
> There is a small bug
> + /*
> +* Take restore_command from the postgresql.conf only if it is not
> already
> +* provided as a command line option.
> +*/
> + if (!restore_wal && restore_command == NULL)
>
On Fri, Aug 27, 2021 at 3:38 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> In the SQL:202x draft, this
> has been formalized by making this implementation-defined and adding
> an option on unique constraint definitions UNIQUE [ NULLS [NOT]
> DISTINCT ] to choose a behavior expl
On Fri, Aug 27, 2021 at 4:57 PM Amit Kapila wrote:
>
> On Fri, Aug 27, 2021 at 11:43 AM vignesh C wrote:
> >
> > On Wed, Aug 25, 2021 at 3:07 PM vignesh C wrote:
> >
> > I have implemented this in the 0003 patch, I have kept it separate to
> > reduce the testing effort and also it will be easier
The SQL standard has been ambiguous about whether null values in
unique constraints should be considered equal or not. Different
implementations have different behaviors. In the SQL:202x draft, this
has been formalized by making this implementation-defined and adding
an option on unique constra
On Tue, Aug 24, 2021 at 9:58 PM Fujii Masao wrote:
> I was thinking that it's valid even if secure_write() doesn't react to
> pg_cancel_backend() because it's basically called outside transaction block,
> i.e., there is no longer transaction to cancel in that case. But there can be
> some cases wh
On Fri, Aug 27, 2021 at 11:43 AM vignesh C wrote:
>
> On Wed, Aug 25, 2021 at 3:07 PM vignesh C wrote:
>
> I have implemented this in the 0003 patch, I have kept it separate to
> reduce the testing effort and also it will be easier if someone
> disagrees with the syntax. I will merge it to the ma
On Fri, Aug 27, 2021 at 1:36 PM Amit Kapila wrote:
>
> On Thu, Aug 26, 2021 at 6:24 PM Masahiko Sawada wrote:
> >
> > On Thu, Aug 26, 2021 at 9:11 PM Amit Kapila wrote:
> > >
> > >
> > > Okay, changed accordingly. Additionally, I have changed the code which
> > > sets timestamp to (unset) when i
On Fri, Aug 27, 2021 at 3:29 PM Amit Kapila wrote:
>
>
> I think the fix is correct but similar changes are required in
> 022_twophase_cascade.pl as well (search for $oldpid in tests). I am
> not completely sure but I think it is better to make this test change
> in back branches as well to make i
On Fri, Aug 13, 2021 at 11:40 AM Dilip Kumar wrote:
>
> On Fri, Aug 13, 2021 at 9:31 AM Amit Kapila wrote:
> >
> > On Thu, Aug 12, 2021 at 8:30 PM Robert Haas wrote:
> > >
> > > On Thu, Aug 12, 2021 at 12:22 AM Amit Kapila
> > > wrote:
> > > > The design of the patch has changed since the init
Michael Paquier writes:
> On Tue, Aug 03, 2021 at 12:48:38PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> The other day I noticed that there's no tab completion after ALTER TABLE
>> … ADD, so here's a patch. In addition to COLUMN and all the table
>> constraint types, it also completes with the lis
On 3/23/21 1:39 AM, Justin Pryzby wrote:
> On Tue, Jan 19, 2021 at 03:03:31PM -0600, Justin Pryzby wrote:
>> On Wed, Dec 30, 2020 at 12:33:56PM +, Simon Riggs wrote:
>>> There are no tests for the new functionality, please could you add some?
>>
>> Did you look at the most recent patch?
>>
>> +
Michael Paquier writes:
> On Wed, Jul 28, 2021 at 01:26:23PM +0200, Daniel Gustafsson wrote:
>> I'm fine with increasing this policy, but I don't have strong feelings. If
>> we
>> feel the perlcritic policy change is too much, I would still prefer to go
>> ahead
>> with the map rewrite part of
On Fri, 27 Aug 2021 at 08:59, Julien Rouhaud wrote:
> On Fri, Aug 27, 2021 at 3:42 AM Magnus Hagander
> wrote:
> >
> > Yeah, but that does move the problem to the other side doesn't it? So
> > if you (as a pure test of course) were to remove the variable
> > completely from the included header a
On Thu, 26 Aug 2021 at 01:51, Alvaro Herrera
wrote:
> On 2021-Aug-25, Magnus Hagander wrote:
>
> > The thing we need the PGDLLIMPORT definition for is to *import* them
> > on the other end?
>
> Oh ... so modules that are willing to cheat can include their own
> declarations of the variables they
On Wed, 25 Aug 2021 at 22:36, Magnus Hagander wrote:
> On Wed, Aug 25, 2021 at 4:06 PM Robert Haas wrote:
> >
> > On Tue, Aug 24, 2021 at 5:06 PM Chapman Flack
> wrote:
> > > The thing is, I think I have somewhere a list of all the threads on
> this
> > > topic that I've read through since the
On Wed, 25 Aug 2021 at 03:13, Robert Haas wrote:
> On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack
> wrote:
> > I don't think that's true of the second proposal in [0]. I don't foresee
> > a noticeable runtime cost unless there is a plausible workload that
> > involves very frequent updates to GUC
On Thu, Aug 5, 2021 at 11:32 AM Amit Langote wrote:
> On Wed, Jul 14, 2021 at 11:16 AM houzj.f...@fujitsu.com
> > On Tuesday, July 13, 2021 2:52 AM Alvaro Herrera
> > wrote:
> > > Did you have a misbehaving test for the ATTACH case?
> >
> > Thanks for the response.
>
> Thank you both.
>
> > Yes,
> + * isnulls is an array of boolean-tuples with key->partnatts booleans values
> + * each. Currently only used for list partitioning, it stores whether a
>
> I think 'booleans' should be 'boolean'.
> The trailing word 'each' is unnecessary.
> bq. Supported new syantx to allow mentioning multiple
> On 27 Aug 2021, at 06:32, Amit Kapila wrote:
> I think we need to backpatch this till 9.6 as this is introduced by
> commit 5aa2350426. Any objections to that?
No, that seems appropriate.
--
Daniel Gustafsson https://vmware.com/
> On 27 Aug 2021, at 08:10, Michael Paquier wrote:
>
> On Wed, Jul 28, 2021 at 01:26:23PM +0200, Daniel Gustafsson wrote:
>> I'm fine with increasing this policy, but I don't have strong feelings. If
>> we
>> feel the perlcritic policy change is too much, I would still prefer to go
>> ahead
>>
> 29 июня 2021 г., в 19:34, Alexey Kondratov
> написал(а):
>
> On Fri, Jun 18, 2021 at 10:06 PM Alexey Kondratov
> wrote:
>> On Fri, Jun 18, 2021 at 5:42 PM Andrey Borodin wrote:
>>>
>>> If we run 'pg_rewind --restore-target-wal' there must be restore_command in
>>> config of target insta
63 matches
Mail list logo
