On 2020-02-28 08:45, Michael Paquier wrote:
On Thu, Feb 27, 2020 at 02:37:24PM +0100, Peter Eisentraut wrote:
On 2020-02-27 11:13, Fujii Masao wrote:
Btw., I think the current setup is slightly buggy. The
MaxBackends value that is used to size shared memory is computed as
MaxConnections +
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Tested the pg_dump patch for dumping "ALTER .. DEPENDS ON
On Thu, Feb 27, 2020 at 02:37:24PM +0100, Peter Eisentraut wrote:
> On 2020-02-27 11:13, Fujii Masao wrote:
>>> Btw., I think the current setup is slightly buggy. The
> MaxBackends value that is used to size shared memory is computed as
> MaxConnections + autovacuum_max_workers + 1 +
On Fri, Feb 28, 2020 at 04:01:00PM +0900, Kyotaro Horiguchi wrote:
> Hello, this is a followup thread of [1].
>
> # I didn't noticed that the thread didn't cover -hackers..
>
> When recovery of any type ends, we see several kinds of error messages
> that says "WAL is broken".
Have you
On Thu, 27 Feb 2020 14:35:55 -0700 (MST)
legrand legrand wrote:
> > I have tried to use an other patch with yours:
> > "Planning counters in pg_stat_statements (using pgss_store)"
>
> > setting
> > shared_preload_libraries='pg_stat_statements'
> > pg_stat_statements.track=all
> > restarting the
On Fri, Feb 28, 2020 at 11:29:56AM +0530, Mahendra Singh Thalor wrote:
> Patch looks good to me and it is fixing the assert failure.
Thanks for looking at the patch. Bringing the code to act
consistently with what was done in 246a6c8 still looks like the
correct direction to take, in short don't
Hello, this is a followup thread of [1].
# I didn't noticed that the thread didn't cover -hackers..
When recovery of any type ends, we see several kinds of error messages
that says "WAL is broken".
> LOG: invalid record length at 0/7CB6BC8: wanted 24, got 0
> LOG: redo is not required
> LOG:
On Fri, Feb 28, 2020 at 2:35 PM Richard Guo wrote:
> Hi All,
>
> Currently we will not consider EXPR_SUBLINK when pulling up sublinks and
> this would cause performance issues for some queries with the form of:
> 'a > (SELECT agg(b) from ...)' as described in [1].
>
> So here is a patch as an
On Thu, Feb 27, 2020 at 06:29:34PM +0300, Alexey Kondratov wrote:
> On 2020-02-27 16:41, Alexey Kondratov wrote:
> >
> > New version of the patch is attached. Thanks again for your review.
> >
>
> Last patch (v18) got a conflict with one of today commits (05d8449e73).
> Rebased version is
Hi All,
Currently we will not consider EXPR_SUBLINK when pulling up sublinks and
this would cause performance issues for some queries with the form of:
'a > (SELECT agg(b) from ...)' as described in [1].
So here is a patch as an attempt to pull up EXPR SubLinks. The idea,
which is based on
On Thu, Feb 27, 2020 at 01:01:08PM -0800, Jeff Davis wrote:
> Attached is a patch that exports a new function from logtape.c:
>
>extern LogicalTapeSet *LogicalTapeSetExtend(
> LogicalTapeSet *lts, int nAdditional);
>
> The purpose is to allow adding new tapes dynamically for the
At Thu, 27 Feb 2020 10:51:29 -0800, Andres Freund wrote in
> Hi,
>
> On 2020-02-27 10:01:00 -0800, Andres Freund wrote:
> > If so, should this be done unconditionally? A new option? Included in an
> > existing one somehow?
>
> FWIW, leaving windows, error handling, and other annoyances aside,
On Thu, 16 Jan 2020 at 09:36, Michael Paquier wrote:
>
> On Fri, Jan 10, 2020 at 08:07:48PM +0900, Michael Paquier wrote:
> > Thinking more about it, this has a race condition if a temporary
> > schema is removed after collecting the OIDs in the drop phase. So the
> > updated attached is
On Wed, Feb 26, 2020 at 4:48 PM Masahiko Sawada
wrote:
> On Thu, 13 Feb 2020 at 17:13, Julien Rouhaud wrote:
> > On Thu, Feb 13, 2020 at 8:32 AM Amit Langote
> > wrote:
> > > Maybe we could document that pg_is_user_object() and its internal
> > > counterpart returns true only for objects that
On Fri, Feb 28, 2020 at 11:25 AM Alvaro Herrera
wrote:
> > /*
> > + * If the relation is a partitioned table, we must add up children's
> > + * reltuples.
> > + */
> > + if (classForm->relkind == RELKIND_PARTITIONED_TABLE)
> > + {
> > + List *children;
At Thu, 27 Feb 2020 20:04:41 +0900, Fujii Masao
wrote in
>
>
> On 2020/02/27 17:05, Kyotaro Horiguchi wrote:
> > Thank you for the comment.
> > At Thu, 27 Feb 2020 16:23:44 +0900, Fujii Masao
> > wrote in
> >> On 2020/02/27 15:23, Kyotaro Horiguchi wrote:
> I failed to understand why
Hosoya-san,
Thanks for the new patch.
On Wed, Feb 26, 2020 at 11:33 AM yuzuko wrote:
> Attach the v5 patch. In this patch, pgstat_report_analyze() always reports 0
> as
> msg.m_live_tuples and m_dead_tuples when the relation is partitioned.
Some comments:
+ * PgStat_MsgPartAnalyze
Hello Yuzuko,
> + * Report ANALYZE to the stats collector, too. If the table is a
> + * partition, report changes_since_analyze of its parent because
> + * autovacuum process for partitioned tables needs it. Reset the
> + * changes_since_analyze counter only if we analyzed
On Wed, 26 Feb 2020 at 11:33, yuzuko wrote:
>
> Hi,
>
> Thanks for reviewing the patch.
>
> > > We can make it work correctly but I think perhaps we can skip updating
> > > statistics values of partitioned tables other than n_mod_since_analyze
> > > as the first step. Because if we support also
Hi,
From time to time I run into the limitation that ALTER TYPE does not
allow changing storage strategy. I've written a bunch of data types over
the years - in some cases I simply forgot to specify storage in CREATE
TYPE (so it defaulted to PLAIN) or I expected PLAIN to be sufficient and
then
On 2020-Feb-27, Justin Pryzby wrote:
> The attached allows CREATE/ALTER to specify reloptions on a partitioned table
> which are used as defaults for future children.
>
> I think that's a desirable behavior, same as for tablespaces. Michael
> mentioned that ALTER INDEX ONLY doesn't exist, but
On 2020-Feb-27, Justin Pryzby wrote:
> Originally, the patch only supported "scanning heap", and set the callback
> strictly, to avoid having callback installed when calling other functions
> (like
> vacuuming heap/indexes).
>
> Then incrementally added callbacks in increasing number of places.
Tomas Vondra writes:
> On Sun, Jan 05, 2020 at 12:33:10PM -0500, Tom Lane wrote:
>> I see your point that "check" suggests a read-only operation, but
>> I'm not sure about a better verb. I thought of "amvalidatemembers",
>> but that's not really much better than "check" is it?
> I don't :-(
The attached allows CREATE/ALTER to specify reloptions on a partitioned table
which are used as defaults for future children.
I think that's a desirable behavior, same as for tablespaces. Michael
mentioned that ALTER INDEX ONLY doesn't exist, but that's only an issue if
ALTER acts recursively,
> I have tried to use an other patch with yours:
> "Planning counters in pg_stat_statements (using pgss_store)"
> setting
> shared_preload_libraries='pg_stat_statements'
> pg_stat_statements.track=all
> restarting the cluster and creating the extension
> When trying following syntax:
> create
Andrew Dunstan writes:
> On Thu, Feb 27, 2020 at 1:33 AM Tom Lane wrote:
>> OK, so we need that *and* the AddProject addition you mentioned?
> Yes, the first one builds it, the second one fixes the tests to run correctly.
Thanks, here's a patchset incorporating those fixes. Otherwise
same as
On Thu, Feb 20, 2020 at 02:02:36PM -0300, Alvaro Herrera wrote:
> On 2020-Feb-19, Justin Pryzby wrote:
>
> > Also, I was thinking that lazy_scan_heap doesn't needs to do this:
> >
> > + /* Pop the error context stack while calling vacuum */
> > + error_context_stack =
Attached is a patch that exports a new function from logtape.c:
extern LogicalTapeSet *LogicalTapeSetExtend(
LogicalTapeSet *lts, int nAdditional);
The purpose is to allow adding new tapes dynamically for the upcoming
Hash Aggregation work[0]. HashAgg doesn't know in advance how
I've seen a few requests on how to make FTS search on the absolute value of
integers. This question is usually driven by the fact that the text search
parser interprets a separating hyphen ("partnumber-987") as a minus sign.
There is currently no good answer for this that doesn't involve C
On 2020-02-27 12:26:36 -0800, Andres Freund wrote:
> Hi,
>
> On 2015-09-25 20:35:45 +0200, Fabien COELHO wrote:
> >
> > Hello Tatsuo,
> >
> > > Hmmm... I never use -C. The formula seems ok:
> > >
> > >tps_exclude = normal_xacts / (time_include -
> > >
"ALTER TEXT SEARCH DICTIONARY foobar" can be followed by an open
parenthesis, but that is not offered in tab completion. That is useful,
because otherwise I have to look up the docs to see if I need a SET or
OPTION(S) or WITH or something before it, just to discover I don't.
The attached
Hi,
On 2015-09-25 20:35:45 +0200, Fabien COELHO wrote:
>
> Hello Tatsuo,
>
> > Hmmm... I never use -C. The formula seems ok:
> >
> >tps_exclude = normal_xacts / (time_include -
> >(INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads));
>
> Hmmm... it is not:-)
>
> I
While looking at a recent complaint about bad planning, I was
reminded that jsonb's @> and related operators use "contsel"
as their selectivity estimator. This is really bad, because
(a) contsel is only a stub, yielding a fixed default estimate,
and (b) that default is 0.001, meaning we estimate
Greetings,
* koschasia...@gmail.com (koschasia...@gmail.com) wrote:
> I send this response to remind you of my initial email because it might have
> been lost among others.
Andrey is the one listed as a possible mentor for that project- I've
added him to the CC list. Hopefully he'll get back
Hello once again,
I send this response to remind you of my initial email because it might have
been lost among others.
I also want to know, if I can familiarize myself with your project idea before
even sending my proposal.
Thanks for your time, I understand you receive hundreds of emails.
Hi,
On 2020-02-27 10:01:00 -0800, Andres Freund wrote:
> If so, should this be done unconditionally? A new option? Included in an
> existing one somehow?
FWIW, leaving windows, error handling, and other annoyances aside, this
can be implemented fairly simply. See below.
As an example of the
Hi,
I am trying to run a few benchmarks measuring the effects of patch to
make GetSnapshotData() faster in the face of larger numbers of
established connections.
Before the patch connection establishment often is very slow due to
contention. The first few connections are fast, but after that it
Hi,
that feature for dumping plans with auto explain is already available in
https://github.com/legrandlegrand/pg_stat_sql_plans
This is an hybrid extension combining auto_explain and pg_stat_statements,
adding a planid and tracking metrics even on error, ..., ...
With
On Wed, Feb 26, 2020 at 10:03 PM Fujii Masao
wrote:
> Thanks for committing this nice feature!
You're welcome!
> Here is one minor comment.
>
> + deduplicate_items
> + storage parameter
>
> This should be
>
> deduplicate_items storage parameter
I pushed a fix for this.
Thanks
Enabling BEFORE triggers FOR EACH ROW in partitioned tables is very easy
-- just remove the check against them. With that, they work fine.
The main problem is that the executor is not prepared to re-route the
tuple if the user decides to change the partitioning columns (so you get
the error that
Alvaro Herrera writes:
> Thanks both -- pushed. I also changed regress/sql/triggers to leave
> tables around that have a non-zero tgparentid. This ensures that the
> pg_upgrade test sees such objects, as well as findoidjoins.
> I refrained from doing the findoidjoins dance itself, though; I
On Thu, 27 Feb 2020 at 07:44, Dave Cramer wrote:
>
>
>
> On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
>
>> On 26/02/2020 22:22, Tom Lane wrote:
>> > Dave Cramer writes:
>> >> OK, here is a patch that actually doesn't leave the transaction in a
>> failed
>> >> state but emits the error and
Thanks both -- pushed. I also changed regress/sql/triggers to leave
tables around that have a non-zero tgparentid. This ensures that the
pg_upgrade test sees such objects, as well as findoidjoins.
I refrained from doing the findoidjoins dance itself, though; I got a
large number of false
Hi, hackers!
Attached patches implement several useful jsonpath syntax extensions.
I already published them two years ago in the original SQL/JSON thread,
but then after creation of separate threads for SQL/JSON functions and
JSON_TABLE I forgot about them.
A brief description of the patches:
On 2020-02-27 16:41, Alexey Kondratov wrote:
New version of the patch is attached. Thanks again for your review.
Last patch (v18) got a conflict with one of today commits (05d8449e73).
Rebased version is attached.
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
The
čt 27. 2. 2020 v 15:59 odesílatel DUVAL REMI napsal:
> Hello Pavel.
>
>
>
> That looks pretty good to me !
>
>
>
> I’m adding Philippe Beaudoin who was also interested in this topic.
>
>
>
> Recap : We were looking for a way to separate variable from constants in
> the “Schema Variables”
Hello Pavel.
That looks pretty good to me !
I’m adding Philippe Beaudoin who was also interested in this topic.
Recap : We were looking for a way to separate variable from constants in the
“Schema Variables” proposition from Pavel.
Pavel was saying that there are some limitations regarding the
Hi
> 3) Any way to define CONSTANTs ?
> We already talked a bit about this subject and also Gilles Darold
> introduces it in this mailing-list topic but I'd like to insist on it.
> I think it would be nice to have a way to say that a variable should not
> be changed once defined.
> Maybe it's
On 2020-Feb-27, Michael Paquier wrote:
> On Wed, Feb 26, 2020 at 08:34:26PM +0100, Tomas Vondra wrote:
> > Nope, the RMT for PG12 was announced on 2019/03/30 [1], i.e. shortly
> > before the end of the last CF (and before pgcon). I think there was some
> > discussion about the members at/after
On 2020-02-27 04:52, Michael Paquier wrote:
On Thu, Feb 27, 2020 at 12:43:55AM +0300, Alexander Korotkov wrote:
Regarding text split change, it was made by pgindent. I didn't notice
it belongs to unchanged part of code. Sure, we shouldn't include this
into the patch.
I have read through v17
On 2020-02-27 11:13, Fujii Masao wrote:
Btw., I think the current setup is slightly buggy. The MaxBackends value that
is used to size shared memory is computed as MaxConnections +
autovacuum_max_workers + 1 + max_worker_processes + max_wal_senders, but we
don't track autovacuum_max_workers
Hi
> There is a often problem with taking source of long SQL strings. The
> pg_stat_activity field query is reduced to some short limit and is not too
> practical to increase this limit.
I thought it was "old story", since that track_activity_query_size can be
increased widely:
On Thu, Feb 27, 2020 at 10:43:50AM +0100, Peter Eisentraut wrote:
> This thread is still in the commit fest, but it's apparently gone as far as
> it will, so I've set it to "Committed" for lack of a "partial" status.
Thanks, that sounds right to me. I was just looking at the latest
patch
Hi
On Thu, Feb 27, 2020 at 12:41 PM Tom Lane wrote:
> Aditya Toshniwal writes:
> > On Mon, Feb 24, 2020 at 12:46 PM Andres Freund
> wrote:
> >> This isn't reproducible here. Are you sure that you're running on a
> >> clean installation?
>
> > Yes I did a fresh installation using installer
On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
> On 26/02/2020 22:22, Tom Lane wrote:
> > Dave Cramer writes:
> >> OK, here is a patch that actually doesn't leave the transaction in a
> failed
> >> state but emits the error and rolls back the transaction.
> >
> >> This is far from complete as
On 2020/02/27 17:05, Kyotaro Horiguchi wrote:
Thank you for the comment.
At Thu, 27 Feb 2020 16:23:44 +0900, Fujii Masao
wrote in
On 2020/02/27 15:23, Kyotaro Horiguchi wrote:
I failed to understand why random access while reading from
stream is bad idea. Could you elaborate why?
It
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch applies cleanly and works as expected. Just a few
On 2020/02/27 17:23, Peter Eisentraut wrote:
When certain parameters are changed on a physical replication primary, this
is communicated to standbys using the XLOG_PARAMETER_CHANGE WAL record. The
standby then checks whether its own settings are at least as big as the ones on
the
Hello
Thank you for working on this!
> Where this becomes a serious problem is if you have many standbys and you do
> a failover.
+1
Several times my team would like to pause recovery instead of panic after
change settings on primary. (same thing for create_tablespace_directories
replay
On 2019-12-18 10:55, Alvaro Herrera wrote:
On 2019-Dec-18, Michael Paquier wrote:
Let's take one example. The changes in pg_dump/ like
/progname/prog_name/ have just been done in haste, without actual
thoughts about how the problem ought to be fixed. And in this case,
something which could
My opinion is that this is not particularly useful and not appropriate
to piggy-back onto \conninfo. Connection information including host,
port, database, user name is a well-established concept in PostgreSQL
programs and tools and it contains a delimited set of information.
Knowing what
On 2020-01-26 06:36, Justin Pryzby wrote:
From a3d0b41435655615ab13f808ec7c30e53e596e50 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 25 Jan 2020 21:25:37 -0600
Subject: [PATCH v3 1/4] Remove gettext erronously readded at 580ddce
---
src/backend/access/heap/vacuumlazy.c | 2 +-
1
On 27.02.2020 11:09, Hubert Zhang wrote:
Hi Konstantin,
I also vimdiff nodeAgg.c in your PG13 branch with nodeAgg.c in pg's
main repo.
Many functions has changed from PG96 to PG13, e.g.
'advance_aggregates', 'lookup_hash_entry'
The vectorized nodeAgg seems still follow the PG96 way of
On Thu, Feb 27, 2020 at 09:32:24AM +0100, Sandro Santilli wrote:
> On Wed, Feb 26, 2020 at 11:18:43AM -0500, Chapman Flack wrote:
> > On 2/26/20 10:52 AM, Sandro Santilli wrote:
> >
> > > This part is not clear to me. You're _assuming_ that the unpackaged--xxx
> > > will not make checks, so you
legrand legrand wrote:
> Antonin Houska-2 wrote
> > Right now I recall two problems: 1) is the way I currently store
> > RelOptInfo for the grouped relations correct?, 2) how should we handle
> > types for which logical equality does not imply physical (byte-wise)
> > equality?
> >
> >
Hi
There is a often problem with taking source of long SQL strings. The
pg_stat_activity field query is reduced to some short limit and is not too
practical to increase this limit.
I have a idea to use for solution of this problem stat_collector process.
When the query string is reduced, then
On Wed, Feb 26, 2020 at 11:18:43AM -0500, Chapman Flack wrote:
> On 2/26/20 10:52 AM, Sandro Santilli wrote:
>
> > This part is not clear to me. You're _assuming_ that the unpackaged--xxx
> > will not make checks, so you _drop_ support for it ? Can't the normal
> > extension script also be unsafe
When certain parameters are changed on a physical replication primary,
this is communicated to standbys using the XLOG_PARAMETER_CHANGE WAL
record. The standby then checks whether its own settings are at least
as big as the ones on the primary. If not, the standby shuts down with
a fatal
Hi Konstantin,
I also vimdiff nodeAgg.c in your PG13 branch with nodeAgg.c in pg's main
repo.
Many functions has changed from PG96 to PG13, e.g. 'advance_aggregates',
'lookup_hash_entry'
The vectorized nodeAgg seems still follow the PG96 way of implementing
these functions.
In general, I think
On Thu, Feb 27, 2020 at 04:32:11PM +0900, Michael Paquier wrote:
> On Sat, Feb 22, 2020 at 04:06:57PM +0100, Julien Rouhaud wrote:
> > Sorry, I just realized that I forgot to commit the last changes before
> > sending
> > the patch, so here's the correct v2.
>
> Thanks for the patch.
>
> > + if
Thank you for the comment.
At Thu, 27 Feb 2020 16:23:44 +0900, Fujii Masao
wrote in
> On 2020/02/27 15:23, Kyotaro Horiguchi wrote:
> >> I failed to understand why random access while reading from
> >> stream is bad idea. Could you elaborate why?
> > It seems to me the word "streaming" suggests
71 matches
Mail list logo
