On Fri, May 14, 2021 at 01:05:02AM +, tsunakawa.ta...@fujitsu.com wrote:
> Could you let us imagine more concretely how useful it will be?
> While TRUNCATE can be part of an application's data processing as
> alternative to DELETE, I think VACUUM is purely the data storage
> maintenance that's
On Thu, May 13, 2021 at 07:05:55PM +0530, vignesh C wrote:
> Thanks for the comments, Please find the attached patch having the changes.
Cool, thanks for the new version. I have spent some time
understanding the initial report from Amit as well as what you are
proposing here, and refactoring the
On Fri, May 14, 2021 at 6:31 AM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2021-May-13, Tom Lane wrote:
> >> What do people think about back-patching this? In existing branches,
> >> we've defined it to be an opclass bug if it fails to shorten the leaf
> >> datum enough. But not having
At Fri, 14 May 2021 14:12:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 13 May 2021 17:07:31 -0400, Robert Haas wrote
> in
> > On Mon, May 10, 2021 at 4:35 AM Kyotaro Horiguchi
> > wrote:
> > > It seems to me the issue here is not a race condition but
> > >
On Thu, May 13, 2021 at 9:00 PM Bharath Rupireddy
wrote:
>
> Done that way.
>
> PSA patch.
Your changes look good. About changing the "non-negative integer" to
"greater than or equal to zero", there is another thread [1], I am not
sure that have we concluded anything there yet.
-
At Thu, 13 May 2021 17:07:31 -0400, Robert Haas wrote
in
> On Mon, May 10, 2021 at 4:35 AM Kyotaro Horiguchi
> wrote:
> > It seems to me the issue here is not a race condition but
> > WaitForWALToBecomeAvailable initializing expectedTLEs with the history
> > of a improper timeline. So using
On Fri, May 14, 2021 at 2:37 AM Robert Haas wrote:
>
> So why does this use recoveryTargetTLI instead of receiveTLI only
> conditionally? Why not do it all the time?
>
> The hard thing about this code is that the assumptions are not very
> clear. If we don't know why something is a certain way,
I wrote:
> Maybe we should revert this thing pending somebody doing the work to
> make a version of queryid labeling that actually is negligibly cheap.
> It certainly seems like that could be done; one more traversal of the
> parse tree can't be that expensive in itself. I suspect that the
>
On Fri, 14 May 2021 at 11:22, Tom Lane wrote:
> I recall somebody (David Rowley, maybe? Too lazy to check archives.)
> working on this idea awhile ago, but he didn't get to the point of
> a committable patch.
Yeah. Me. The discussion is in [1].
David
[1]
On Fri, May 14, 2021 at 12:20:00PM +0900, Fujii Masao wrote:
>
>
> On 2021/05/14 9:04, Alvaro Herrera wrote:
> > Here's a first attempt at what was suggested. If you say "auto" it
> > remains auto in SHOW, but it gets enabled if a module asks for it.
> >
> > Not final yet, but I thought I'd
On 2021/05/14 9:04, Alvaro Herrera wrote:
Here's a first attempt at what was suggested. If you say "auto" it
remains auto in SHOW, but it gets enabled if a module asks for it.
Not final yet, but I thought I'd throw it out for early commentary ...
Many thanks! The patch basically looks
On Thu, May 13, 2021 at 7:14 PM Michael Paquier wrote:
> Perhaps that's an awful deal, but based on which facts can you really
> say that this new behavior of needing at least 2% of relation pages
> with some dead items to clean up indexes is not a worse deal in some
> cases?
If I thought that
Hi Greg,
Thanks for you replay and test.
When main process gets the transaction snapshot in
InitializeParallelDSM->GetTransactionSnapshot, the transaction snapshot xmin
is very likely follows active snapshot xmin.
Use gdb it is easy to verify it.
Create env as blow:
On Thu, May 13, 2021 at 09:47:02PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Fri, May 14, 2021 at 3:12 AM Bruce Momjian wrote:
> >> I was surprised it was ~2%.
>
> > Just to be clear, the 2% was a worst case scenario, ie. a very fast
> > read-only query on small data returning a
On Thursday, May 13, 2021 7:43 PM Amit Kapila wrote:
> On Tue, Apr 20, 2021 at 8:36 AM Amit Langote
> wrote:
> > Back in:
> https://www.postgresql.org/message-id/CA%2BHiwqEeU19iQgjN6HF1HTP
> U0L5%2
> > BJxyS5CmxaOVGNXBAfUY06Q%40mail.gmail.com
> >
> > I had proposed to move the map creation from
On Thu, May 13, 2021 at 01:27:44PM -0700, Peter Geoghegan wrote:
> Almost all of the benefit of the optimization is available with the
> current BYPASS_THRESHOLD_PAGES threshold (2% of heap pages have
> LP_DEAD items), which has less risk than a higher threshold. I don't
> think it matters much if
On Thu, 13 May 2021 at 22:13, vignesh C wrote:
> On Wed, May 12, 2021 at 10:15 PM Bharath Rupireddy
> wrote:
>>
>> On Wed, May 12, 2021 at 9:55 PM vignesh C wrote:
>> > While I was reviewing one of the logical decoding features, I found a
>> > few issues in alter subscription drop
On Thu, May 13, 2021 at 09:01:41PM -0500, Justin Pryzby wrote:
> These should be merged:
> > 756ab29124 Allow pageinspect to inspect GiST indexes (Andrey Borodin,
> > Heikki Linnakangas)
> > 9e596b65f4 Add "LP_DEAD item?" column to GiST pageinspect functions
Sorry, this was my error while
On Mon, May 10, 2021 at 09:40:45AM -0500, Justin Pryzby wrote:
> Should any of these be included?
New SQL-accessible functionality should be included:
> 8c15a29745 Allow ALTER TYPE to update an existing type's typsubscript value.
These should be merged:
> 756ab29124 Allow pageinspect to inspect
Julien Rouhaud writes:
> On Fri, May 14, 2021 at 3:12 AM Bruce Momjian wrote:
>> I was surprised it was ~2%.
> Just to be clear, the 2% was a worst case scenario, ie. a very fast
> read-only query on small data returning a single row. As soon as you
> get something more realistic / expensive
I wrote:
> Anyway, here is a patch set teased apart into committable bites,
> and with your other points addressed.
Oh, maybe some docs would be a good thing too ...
regards, tom lane
diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
index
On Fri, May 14, 2021 at 09:40:15AM +0800, Julien Rouhaud wrote:
> On Fri, May 14, 2021 at 8:13 AM Bruce Momjian wrote:
> >
> > On Thu, May 13, 2021 at 08:04:37PM -0400, Álvaro Herrera wrote:
> > > Here's a first attempt at what was suggested. If you say "auto" it
> > > remains auto in SHOW, but
On Thu, May 13, 2021 at 11:59 PM Bruce Momjian wrote:
> On Thu, May 13, 2021 at 02:46:58PM +0900, Amit Langote wrote:
> > How about writing the 2nd line instead as:
> >
> > Updates/deletes on partitioned tables can now use execution-time
> > partition pruning.
> >
> > We don't seem to use the
On Fri, May 14, 2021 at 8:13 AM Bruce Momjian wrote:
>
> On Thu, May 13, 2021 at 08:04:37PM -0400, Álvaro Herrera wrote:
> > Here's a first attempt at what was suggested. If you say "auto" it
> > remains auto in SHOW, but it gets enabled if a module asks for it.
> >
> > Not final yet, but I
On Fri, May 14, 2021 at 3:12 AM Bruce Momjian wrote:
>
> > Maybe we should revert this thing pending somebody doing the work to
> > make a version of queryid labeling that actually is negligibly cheap.
> > It certainly seems like that could be done; one more traversal of the
> > parse tree can't
On Mon, May 10, 2021 at 02:03:08AM -0400, Bruce Momjian wrote:
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
>
> https://momjian.us/pgsql_docs/release-14.html
>
> I need clarification on many items, and the document
On Fri, 14 May 2021 at 12:00, Peter Smith wrote:
> That bug led me to wonder if similar problems might be going
> undetected elsewhere in the code. There is a gcc compiler option [3]
> -Wshadow which informs about the similar scenario where one variable
> is "shadowing" another (e.g. redeclaring
From: Bharath Rupireddy
> I think it will be useful to allow foreign tables to be VACUUMed if
> the underlying FDW supports, currently VACUUM doesn't support foreign
> tables, see [1].
Could you let us imagine more concretely how useful it will be? While TRUNCATE
can be part of an
On Fri, Apr 23, 2021 at 7:56 PM Peter Geoghegan wrote:
> I'm convinced -- decoupling the logic from the one-pass-not-two pass
> case seems likely to be simpler and more useful. For both the one pass
> and two pass/has indexes case.
Attached draft patch does it that way.
--
Peter Geoghegan
Alvaro Herrera writes:
> On 2021-May-13, Tom Lane wrote:
>> What do people think about back-patching this? In existing branches,
>> we've defined it to be an opclass bug if it fails to shorten the leaf
>> datum enough. But not having any defenses against that seems like
>> not a great idea.
On Fri, May 14, 2021 at 10:27 AM David Rowley wrote:
>
> Thanks for the votes. Pushed.
Thanks!
Regards,
Greg Nancarrow
Fujitsu Australia
On Fri, 14 May 2021 at 00:27, Julien Rouhaud wrote:
>
> On Thu, May 13, 2021 at 08:06:18PM +0900, Michael Paquier wrote:
> > On Thu, May 13, 2021 at 08:20:36PM +1200, David Rowley wrote:
> > > Since there's no bug fix here, I thought that there's not much point
> > > in backpatching this.
> >
> >
On Thu, May 13, 2021 at 08:04:37PM -0400, Álvaro Herrera wrote:
> Here's a first attempt at what was suggested. If you say "auto" it
> remains auto in SHOW, but it gets enabled if a module asks for it.
>
> Not final yet, but I thought I'd throw it out for early commentary ...
I certainly like
Here's a first attempt at what was suggested. If you say "auto" it
remains auto in SHOW, but it gets enabled if a module asks for it.
Not final yet, but I thought I'd throw it out for early commentary ...
--
Álvaro Herrera Valdivia, Chile
diff --git
On Thu, May 13, 2021 at 07:19:11PM -0400, Andrew Dunstan wrote:
> On 5/13/21 3:04 PM, Alvaro Herrera wrote:
>> I'm happy to act as committer for that if he wants to step away from it.
>> I'm already used to being lapidated at every corner anyway.
>
> Many thanks Alvaro, among other things for
On Thu, May 13, 2021 at 05:33:33PM -0400, Alvaro Herrera wrote:
> +++ b/doc/src/sgml/maintenance.sgml
> @@ -817,6 +817,11 @@ analyze threshold = analyze base threshold + analyze
> scale factor * number of tu
>
> is compared to the total number of tuples inserted, updated, or deleted
>
Jan Wieck writes:
> On 5/13/21 6:45 PM, Tom Lane wrote:
>> Bumping the version in the commit that changes
>> things is not optional, because if you don't do that then you'll
>> probably burn some other developer also working on HEAD. So
>> I don't want people thinking they can skip this because
On Thu, May 13, 2021 at 07:19:11PM -0400, Andrew Dunstan wrote:
>
> On 5/13/21 3:04 PM, Alvaro Herrera wrote:
> > On 2021-May-13, Stephen Frost wrote:
> >
> >> Or just accept that this is a bit hokey with the 'auto' approach. I get
> >> Bruce has concerns about it but I'm not convinced that it's
Dmitry Astapov writes:
> Am I right in thinking that elimination the join condition is actually
> quite important part of the process?
> Could it possibly be the main reason for =ANY/(x IN (..)) not to be
> optimized the same way?
Yup.
> Is it still hard when one thinks about =ANY or (column in
On 5/13/21 3:04 PM, Alvaro Herrera wrote:
> On 2021-May-13, Stephen Frost wrote:
>
>> Or just accept that this is a bit hokey with the 'auto' approach. I get
>> Bruce has concerns about it but I'm not convinced that it's actually all
>> that bad to go with that.
> Yeah, I think the alleged
Alvaro Herrera writes:
> Hmm, it looks OK to me, but I wonder why you kept the original
> CHECK_FOR_INTERRUPTS()s since these would be done once we've broken out
> of the loop anyway. I tested Dilip's original test case and while we
> still die on OOM, we're able to interrupt it before dying.
With English fixes from Bruce.
I think the note about autovacuum in the reference page for ANALYZE is a
bit out of place, but not enough to make me move the whole paragraph
elsewhere. Maybe we should try to do that sometime.
--
Álvaro Herrera Valdivia, Chile
Officer Krupke, what are we
On 5/13/21 6:45 PM, Tom Lane wrote:
Bumping the version in the commit that changes
things is not optional, because if you don't do that then you'll
probably burn some other developer also working on HEAD. So
I don't want people thinking they can skip this because it was
done at
I think it's good to backpatch the check as it doesn't change acceptable
behavior, just replace infinite loop with the acceptable thing.
On 2021-May-13, Tom Lane wrote:
> What do people think about back-patching this? In existing branches,
> we've defined it to be an opclass bug if it fails to shorten the leaf
> datum enough. But not having any defenses against that seems like
> not a great idea. OTOH, the
Jan Wieck writes:
> Regardless of PG_VERSION doing the job or not, shouldn't there be a bump
> in PG_CONTROL_VERSION whenever there is a structural or semantic change
> in the control file data? And wouldn't the easiest way to ensure that be
> to bump the version with every release?
No, the
On 2021-May-13, Tom Lane wrote:
> Alvaro Herrera writes:
> > (Looking again, the nbtpage.c hunk might have been made obsolete by
> > c34787f91058 and other commits).
>
> OK. Here's a revision that adopts your idea, except that I left
> out the nbtpage.c change since you aren't sure of that
Here's a patch that attempts to prevent the infinite loop in spgdoinsert
by checking whether the proposed leaf tuple is getting smaller at each
iteration.
We can't be totally rigid about that, because for example if the opclass
shortens a 7-byte string to 5 bytes, that will make no difference in
On 5/12/21 10:04 PM, Michael Paquier wrote:
On Wed, May 12, 2021 at 01:30:27PM -0700, Andres Freund wrote:
That said, I don't think it's a good practice to use the control file
version as an identifier for the major version. Who knows, it might be
necessary to add an optional new format in a
On Wed, May 12, 2021 at 4:54 PM Tom Lane wrote:
> Dmitry Astapov writes:
> > I am trying to understand the behaviour of the query planner regarding
> the
> > push-down of the conditions "through" the join.
>
> I think your mental model is wrong. What's actually happening here is
> that the
Hello.
Added a check for standby promotion with the long transaction to the
test (code and docs are unchanged).
Thanks,
Michail.
From c5e1053805c537b50b0922151bcf127754500adb Mon Sep 17 00:00:00 2001
From: Michail Nikolaev
Date: Fri, 14 May 2021 00:32:30 +0300
Subject: [PATCH v3 3/4] test
---
New version, a bit more ambitious. I think it's better to describe
behavior for partitioned tables ahead of inheritance. Also, in the
ANALYZE reference page I split the topic in two: in one single paragraph
we now describe what happens with manual analyze for partitioned tables
and inheritance
On Mon, May 10, 2021 at 4:35 AM Kyotaro Horiguchi
wrote:
> It seems to me the issue here is not a race condition but
> WaitForWALToBecomeAvailable initializing expectedTLEs with the history
> of a improper timeline. So using recoveryTargetTLI instead of
> receiveTLI for the case fixes this issue.
Robert Haas writes:
> On Thu, May 13, 2021 at 2:22 PM Tom Lane wrote:
>> Meh. I'm not convinced that that position ought to apply to amvalidate.
> I am still of the opinion that we ought to apply it across the board,
> for consistency.
The main reason I'm concerned about applying that rule to
On Thu, May 13, 2021 at 5:06 AM Justin Pryzby wrote:
> Why is the allowed range from 0 to 0.05? Why not 0.10 or 1.0 ?
> The old GUC of the same name had max 1e10.
It also had a completely different purpose and default.
> I think a reduced range and a redefinition of the GUC would need to be
On Thu, May 13, 2021 at 2:22 PM Tom Lane wrote:
> Meh. I'm not convinced that that position ought to apply to amvalidate.
I am still of the opinion that we ought to apply it across the board,
for consistency. It makes it easier for humans to know which problems
are known to be reachable and
> On May 13, 2021, at 12:18 PM, Jacob Champion wrote:
>
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
>> The distinction that Theme+Security would make is that capabilities
>> can be categorized by the area of the system:
>> -- planner
>> -- replication
>> -- logging
>> ...
>>
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> > The distinction that Theme+Security would make is that capabilities
> > can be categorized by the area of the system:
> > -- planner
> > -- replication
> > -- logging
> >
On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> The distinction that Theme+Security would make is that capabilities
> can be categorized by the area of the system:
> -- planner
> -- replication
> -- logging
> ...
> but also by the security implications of what is being done:
> --
On Thu, May 13, 2021 at 03:04:30PM -0400, Álvaro Herrera wrote:
> On 2021-May-13, Stephen Frost wrote:
>
> > Or just accept that this is a bit hokey with the 'auto' approach. I get
> > Bruce has concerns about it but I'm not convinced that it's actually all
> > that bad to go with that.
>
>
On Thu, May 13, 2021 at 02:29:09PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > There's a ridiculously simple option here which is: drop the idea that
> > we support an extension redefining the query id and then just make it
> > on/off with the default to be 'on'.
>
> I do not think that
On 2021-May-13, Stephen Frost wrote:
> Or just accept that this is a bit hokey with the 'auto' approach. I get
> Bruce has concerns about it but I'm not convinced that it's actually all
> that bad to go with that.
Yeah, I think the alleged confusion there is overstated.
I'm happy to act as
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > There's a ridiculously simple option here which is: drop the idea that
> > we support an extension redefining the query id and then just make it
> > on/off with the default to be 'on'.
>
> I do not think that
> On May 13, 2021, at 10:41 AM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
>>> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>>> - Group things by which section of postgresql.conf they're in, and
>>> then further restrict some of them as
Stephen Frost writes:
> There's a ridiculously simple option here which is: drop the idea that
> we support an extension redefining the query id and then just make it
> on/off with the default to be 'on'.
I do not think that defaulting it to 'on' is acceptable unless you can
show that the added
On Thu, May 13, 2021 at 02:22:16PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > Per sqlsmith.
> > postgres=# select amvalidate(123);
> > ERROR: cache lookup failed for operator class 123
> > postgres=# \errverbose
> > ERROR: XX000: cache lookup failed for operator class 123
> > LOCATION:
Justin Pryzby writes:
> Per sqlsmith.
> postgres=# select amvalidate(123);
> ERROR: cache lookup failed for operator class 123
> postgres=# \errverbose
> ERROR: XX000: cache lookup failed for operator class 123
> LOCATION: amvalidate, amapi.c:125
> The usual expectation is that sql callable
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, May 13, 2021 at 07:39:45PM +0200, Christoph Berg wrote:
> > Re: Bruce Momjian
> > > Well, now that we have clear warnings when it is misconfigured,
> > > especially when querying the pg_stat_statements view, are these
> > > complaints
On Thu, May 13, 2021 at 07:39:45PM +0200, Christoph Berg wrote:
> Re: Bruce Momjian
> > Well, now that we have clear warnings when it is misconfigured,
> > especially when querying the pg_stat_statements view, are these
> > complaints still valid? Also, how is modifying
> >
On Thu, May 13, 2021 at 01:51:07PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Thu, May 13, 2021 at 01:33:27PM -0400, Stephen Frost wrote:
> > > I'm coming around to have a similar feeling. While having an
> > > alternative query ID might be
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, May 13, 2021 at 01:33:27PM -0400, Stephen Frost wrote:
> > I'm coming around to have a similar feeling. While having an
> > alternative query ID might be useful, I have a hard time seeing it as
> > likely to be a hugely popular
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On May 12, 2021, at 12:58 PM, Robert Haas wrote:
> > - Group things by which section of postgresql.conf they're in, and
> > then further restrict some of them as security-sensitive. This is
> > reasonably close to what you've
On Thu, May 13, 2021 at 01:33:27PM -0400, Stephen Frost wrote:
> I'm coming around to have a similar feeling. While having an
> alternative query ID might be useful, I have a hard time seeing it as
> likely to be a hugely popular feature that is worth a lot of users
> complaining (as we've seen
Re: Bruce Momjian
> Well, now that we have clear warnings when it is misconfigured,
> especially when querying the pg_stat_statements view, are these
> complaints still valid? Also, how is modifying
> shared_preload_libraries zero-config, but modifying
> shared_preload_libraries and
On Thu, May 13, 2021 at 01:17:16PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > The only thing that bugs me is that we're pretty damn late in the
> > process to be engaging in this amount of design.
>
> Indeed. I feel that this feature was forced in before it was really
> ready.
The
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > The only thing that bugs me is that we're pretty damn late in the
> > process to be engaging in this amount of design.
>
> Indeed. I feel that this feature was forced in before it was really
> ready.
I'm coming
Alvaro Herrera writes:
> (Looking again, the nbtpage.c hunk might have been made obsolete by
> c34787f91058 and other commits).
OK. Here's a revision that adopts your idea, except that I left
out the nbtpage.c change since you aren't sure of that part.
I added a macro that allows spgdoinsert
Andrew Dunstan writes:
> The only thing that bugs me is that we're pretty damn late in the
> process to be engaging in this amount of design.
Indeed. I feel that this feature was forced in before it was really
ready.
regards, tom lane
On Thu, May 13, 2021 at 12:45:07PM -0400, Andrew Dunstan wrote:
>
> On 5/13/21 12:18 AM, Fujii Masao wrote:
> >
> >
> >
> > If we do this, compute_query_id=auto seems to be similar to
> > huge_pages=try.
> > When huge_pages=try, whether huge pages is actually used is defined
> > depending
> >
Per sqlsmith.
postgres=# select amvalidate(123);
ERROR: cache lookup failed for operator class 123
postgres=# \errverbose
ERROR: XX000: cache lookup failed for operator class 123
LOCATION: amvalidate, amapi.c:125
The usual expectation is that sql callable functions should return null rather
On 5/13/21 12:18 AM, Fujii Masao wrote:
>
>
>
> If we do this, compute_query_id=auto seems to be similar to
> huge_pages=try.
> When huge_pages=try, whether huge pages is actually used is defined
> depending
> outside PostgreSQL (i.e, OS setting in this case). Neither
> pg_settings.setting nor
>
On Thu, May 13, 2021 at 09:30:55AM -0700, Maciek Sakrejda wrote:
> On Thu, May 13, 2021 at 8:38 AM Julien Rouhaud wrote:
> >
> > On Thu, May 13, 2021 at 08:32:50AM -0700, Maciek Sakrejda wrote:
> > >
> > > The warning makes it clear that there's something wrong, but not how
> > > to fix it
> >
>
Alvaro Herrera writes:
> On 2021-May-13, Tom Lane wrote:
>> BTW, another nasty thing I discovered while testing this is that
>> the CHECK_FOR_INTERRUPTS() at line 2146 is useless, because
>> we're holding a buffer lock there so InterruptHoldoffCount > 0.
>> So once you get into this loop you
On Thu, May 13, 2021 at 8:38 AM Julien Rouhaud wrote:
>
> On Thu, May 13, 2021 at 08:32:50AM -0700, Maciek Sakrejda wrote:
> >
> > The warning makes it clear that there's something wrong, but not how
> > to fix it
>
> I'm confused, are we talking about the new warning in v2 as suggested by
>
On 2021-May-13, Alvaro Herrera wrote:
> The btree code modified was found to be an actual problem in production
> when a btree is corrupted in such a way that vacuum would get an
> infinite loop. I don't remember the exact details but I think we saw
> vacuum running for a couple of weeks, and
> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>
> - Group things by which section of postgresql.conf they're in, and
> then further restrict some of them as security-sensitive. This is
> reasonably close to what you've got, but not exactly what you've got.
> One issue is that it risks
On Thu, May 13, 2021 at 11:35:13PM +0800, Julien Rouhaud wrote:
> On Thu, May 13, 2021 at 10:41:43AM -0400, Bruce Momjian wrote:
> >
> > Well, now that we have clear warnings when it is misconfigured,
> > especially when querying the pg_stat_statements view, are these
> > complaints still valid?
On 2021-May-13, Tom Lane wrote:
> BTW, another nasty thing I discovered while testing this is that
> the CHECK_FOR_INTERRUPTS() at line 2146 is useless, because
> we're holding a buffer lock there so InterruptHoldoffCount > 0.
> So once you get into this loop you can't even cancel the query.
>
On Thu, May 13, 2021 at 08:32:50AM -0700, Maciek Sakrejda wrote:
> > Well, now that we have clear warnings when it is misconfigured,
> > especially when querying the pg_stat_statements view, are these
> > complaints still valid? Also, how is modifying
> > shared_preload_libraries zero-config,
On Thu, May 13, 2021 at 08:32:50AM -0700, Maciek Sakrejda wrote:
>
> The warning makes it clear that there's something wrong, but not how
> to fix it
I'm confused, are we talking about the new warning in v2 as suggested by Pavel?
As it should make things quite clear:
+SELECT count(*) FROM
On Thu, May 13, 2021 at 10:41:43AM -0400, Bruce Momjian wrote:
>
> Well, now that we have clear warnings when it is misconfigured,
> especially when querying the pg_stat_statements view, are these
> complaints still valid?
I'm personally fine with it, and I can send a new version with just the
On Thu, May 13, 2021 at 7:42 AM Bruce Momjian wrote:
>
> On Thu, May 13, 2021 at 12:03:42PM +0800, Julien Rouhaud wrote:
> > On Wed, May 12, 2021 at 11:33:32PM -0400, Bruce Momjian wrote:
> > I don't know what to say. So here is a summary of the complaints that I'm
> > aware of:
> >
> > -
> >
On Thu, May 13, 2021 at 7:00 PM Masahiko Sawada wrote:
> > > Yeah, I get it. Even if users don't specify a parallel option there
> > > are chances that parallelism is picked. So the parallel degree is the
> > > final number of workers that are chosen by the server for vacuuming
> > > indexes.
Pavel Borisov writes:
> [ v4-0001-When-there-are-INCLUDEd-columns-in-SpGist-check-t.patch ]
I don't like this patch one bit --- it's basically disabling a fairly
important SPGiST feature as soon as there are included columns.
What's more, it's not really giving us any better defense against
the
On Thu, May 13, 2021 at 02:46:58PM +0900, Amit Langote wrote:
> How about writing the 2nd line instead as:
>
> Updates/deletes on partitioned tables can now use execution-time
> partition pruning.
>
> We don't seem to use the term "run-time pruning" anywhere else in the
> documentation, and
On Thu, May 13, 2021 at 7:43 PM vignesh C wrote:
> I have separated the Drop publication documentation contents. There
> are some duplicate contents but the readability is slightly better.
> Thoughts?
-ALTER SUBSCRIPTION name
DROP PUBLICATION publication_name [, ...] [ WITH (
On Thu, May 13, 2021 at 12:03:42PM +0800, Julien Rouhaud wrote:
> On Wed, May 12, 2021 at 11:33:32PM -0400, Bruce Momjian wrote:
> I don't know what to say. So here is a summary of the complaints that I'm
> aware of:
>
> -
>
On Thu, May 13, 2021 at 4:58 AM Alvaro Herrera wrote:
>
> You can avoid duplicating the ereport like this:
>
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> +errmsg("option \"%s\" specified more than
> once",
On Thu, May 13, 2021 at 11:25 AM Pengchengliu wrote:
>
> Hi Andres,
> Thanks for you replay.
Er, it's Greg who has replied so far (not Andres).
>
> And If you still cannot reproduce it in 2 minitus. Could you run pgbench
> longer time, such as 30 or 60 minutes.
>
Actually, I did run it,
On Wed, May 12, 2021 at 10:15 PM Bharath Rupireddy
wrote:
>
> On Wed, May 12, 2021 at 9:55 PM vignesh C wrote:
> > While I was reviewing one of the logical decoding features, I found a
> > few issues in alter subscription drop publication.
>
> Thanks!
>
> > Alter subscription drop publication
1 - 100 of 143 matches
Mail list logo
