On Thu, Oct 15, 2020 at 02:51:38PM +1300, David Rowley wrote:
> On Thu, 15 Oct 2020 at 14:43, Justin Pryzby wrote:
> > On Thu, Oct 15, 2020 at 02:23:01PM +1300, David Rowley wrote:
> > > On Thu, 15 Oct 2020 at 14:15, Tom Lane wrote:
> > > > Hmm, I dunno if my opinio
e message.
|pg_restore: error: could not write to large object (result: -1, expected:
16384)
--
Justin
>From 38d1f4ca314b9381a8fe5cbf90d4bc9b390b2fca Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 17 Oct 2020 19:28:25 -0500
Subject: [PATCH v1] print size_t with %zd rather than
On Mon, Oct 19, 2020 at 07:36:29PM +0300, Heikki Linnakangas wrote:
> On 05/10/2020 22:19, Justin Pryzby wrote:
> > On Fri, Sep 25, 2020 at 09:30:00AM -0500, Justin Pryzby wrote:
> > > Split one patch about text search, added another one (sequences), added
> > > some
&g
On Tue, Oct 20, 2020 at 04:04:20PM -0300, Alvaro Herrera wrote:
> On 2020-Sep-30, Justin Pryzby wrote:
>
> > CREATE TABLE t(i int) PARTITION BY RANGE(i);
> > CREATE TABLE t1 PARTITION OF t FOR VALUES FROM (1) TO (10);
> > CREATE OR REPLACE FUNCTION tgf() RETURNS tri
On Tue, Oct 20, 2020 at 03:56:30PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Hmm, next question: should we backpatch a fix for this? (This applies
> > all the way back to 11.) If we do, then we would change behavior of
> > partition creation. It's hard to see that the current behavior
On Thu, Oct 15, 2020 at 07:35:30PM -0400, Bruce Momjian wrote:
> On Fri, Oct 9, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > > In my local branch, I had revised this comment to say:
> > >
On Tue, Oct 20, 2020 at 09:17:22PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > I wonder if pg_upgrade should try to rmdir() the tablespace dirs before
> > restoring global objects, allowing it to succeed, rather than just "failing
> > early".
>
> I&#x
On Tue, Oct 20, 2020 at 09:54:53PM -0300, Alvaro Herrera wrote:
> On 2020-Oct-20, Justin Pryzby wrote:
> > On Tue, Oct 20, 2020 at 03:56:30PM -0400, Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > > Hmm, next question: should we backpatch a fix for this? (This ap
Since this commit, pg_dump CREATEs tables and then ATTACHes them:
|commit 33a53130a89447e171a8268ae0b221bb48af6468
|Author: Alvaro Herrera
|Date: Mon Jun 10 18:56:23 2019 -0400
|
|Make pg_dump emit ATTACH PARTITION instead of PARTITION OF (reprise)
|...
|This change also has the advanta
On Fri, Oct 23, 2020 at 12:29:40AM -0500, Justin Pryzby wrote:
> Since this commit, pg_dump CREATEs tables and then ATTACHes them:
>
> |commit 33a53130a89447e171a8268ae0b221bb48af6468
> |Author: Alvaro Herrera
> |Date: Mon Jun 10 18:56:23 2019 -0400
> |
> |Mak
On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote:
> I needed another distraction so bulk-checked for typos, limited to comments in
> *.[ch].
>
> I'm not passionate about this, but it serves the purpose of reducing the
> overhead of fixing them individually.
I
On Fri, Oct 23, 2020 at 11:09:26PM +0300, Heikki Linnakangas wrote:
> Findings in detail follow.
Are you working on a patch for these ?
Otherwise, since I started something similar in April, I could put something
together based on comments you've gotten here.
--
Justin
On Wed, Oct 07, 2020 at 11:47:07PM +0300, Maksim Kita wrote:
> I like the idea, during prototype I added additional column and modified
> enum_in method. But enum_in is called in contexts that can be important
> for user (like comparisons).
...
> postgres=# ALTER TYPE test_enum DELETE VALUE '2';
>
On Fri, Oct 23, 2020 at 10:45:34AM +0530, Amit Kapila wrote:
> On Fri, Oct 23, 2020 at 8:59 AM Amit Kapila wrote:
> >
> > On Fri, Oct 23, 2020 at 7:42 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, 22 Oct 2020 at 20:34, Amit Kapila wrote:
> > > >
> > > > > > I have modified the description of
On Fri, Oct 23, 2020 at 03:12:51PM +0900, yuzuko wrote:
> Hello,
>
> I reconsidered a way based on the v5 patch in line with
> Horiguchi-san's comment.
>
> This approach is as follows:
> - A partitioned table is checked whether it needs analyze like a plain
> table in relation_needs_vacanalyze
rom 7868fee24f92fb5150735f1f9507cfe9a6ab212c Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 11 Apr 2020 22:57:06 -0500
Subject: [PATCH] remove deprecated v8.2 containment operators
See also:
ba920e1c9182eac55d5f1327ab0d29b721154277
684ad6a92fcc33adebdab65c4e7d72a68ba05408
---
contrib/cube/cub
On Wed, Oct 21, 2020 at 02:02:37PM -0300, Alvaro Herrera wrote:
> On 2020-Oct-21, Justin Pryzby wrote:
>
> > I came up with this, which probably needs more than a little finesse.
>
> Hmm, there are two important changes needed on this: 1) it must not emit
> CREATE lines f
On Tue, Oct 27, 2020 at 09:17:43AM +0530, Amit Kapila wrote:
> On Tue, Oct 27, 2020 at 8:51 AM Justin Pryzby wrote:
> >
> > On Fri, Oct 23, 2020 at 10:45:34AM +0530, Amit Kapila wrote:
> > > On Fri, Oct 23, 2020 at 8:59 AM Amit Kapila
> > > wrote:
> > >
ed indexes, and invalidates
indisclustered when attaching unclustered indexes.
Also, I noticed that CREATE TABLE (LIKE.. INCLUDING INDEXES) doesn't preserve
indisclustered, but I can't say that's an issue.
--
Justin
>From dd4588352f99186f28fc666c497f85a87ac11da2 Mon Sep 17 00:00:00
Forking this thread, since the existing CFs have been closed.
https://www.postgresql.org/message-id/flat/20200914143102.GX18552%40telsasoft.com#58b1056488451f8594b0f0ba40996afd
On Mon, Sep 14, 2020 at 09:31:03AM -0500, Justin Pryzby wrote:
> On Sat, Sep 12, 2020 at 10:35:34AM +0900, Mich
On Tue, Sep 08, 2020 at 02:51:26PM -0500, Justin Pryzby wrote:
> On Sat, Jul 18, 2020 at 03:15:32PM -0500, Justin Pryzby wrote:
> > Still waiting for feedback from a committer.
>
> This patch has been waiting for input from a committer on the approach I've
> taken with the
On Thu, Oct 15, 2020 at 01:21:06PM -0400, Greg Sabino Mullane wrote:
> Improve psql \df to choose functions by their arguments
I think this is a good idea.
This isn't working for arrays:
postgres=# \df aa
public | aa | integer | integer, integer| func
public | aa | int
On Sat, Oct 24, 2020 at 02:59:49PM -0500, Justin Pryzby wrote:
> On Fri, Oct 23, 2020 at 12:29:40AM -0500, Justin Pryzby wrote:
> > Since this commit, pg_dump CREATEs tables and then ATTACHes them:
> >
> > |commit 33a53130a89447e171a8268ae0b221bb48af6468
> > |Author
On Thu, Oct 22, 2020 at 01:29:53PM +0100, Simon Riggs wrote:
> On Fri, 16 Oct 2020 at 22:05, Justin Pryzby wrote:
>
> > > > I made this conditional on BEGIN BULK/SET bulk, so I'll solicit
> > > > comments on that.
>
> I think it would be better
TILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
> > dest=0x2dc1aa8, qc=0 x7fff225f67c0) at utility.c:524
> > #8 0x0093f163 in PortalRunUtility (portal=0x2e22ab0,
> > pstmt=0x2dc19b8, isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1
> > aa8, qc=0x7fff225f67c0) at pquery.c:1159
> > #9 0x0093f380 in PortalRunMulti (portal=0x2e22ab0,
> > isTopLevel=true, setHoldSnapshot=false, dest=0x2dc1aa8, altdest=0x2dc1
> > aa8, qc=0x7fff225f67c0) at pquery.c:1305
> > #10 0x0093e882 in PortalRun (portal=0x2e22ab0,
> > count=9223372036854775807, isTopLevel=true, run_once=true,
> > dest=0x2dc1aa8, altdest=0x2dc1aa8, qc=0x7fff225f67c0) at pquery.c:779
> > #11 0x009389e8 in exec_simple_query (query_string=0x2dc07c0
> > "CREATE TABLE fail PARTITION OF public.sales \nFOR VALUES FROM
> > ('2019-01-15') TO ('2019-02-15');") at postgres.c:1239
> >
> > Regards,
> > Amul Sul
--
Justin Pryzby
System Administrator
Telsasoft
+1-952-707-8581
On Sun, Oct 25, 2020 at 02:48:49PM -0500, Justin Pryzby wrote:
> On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote:
> > I needed another distraction so bulk-checked for typos, limited to comments
> > in
> > *.[ch].
> >
> > I'm not passionate ab
On Fri, Oct 30, 2020 at 03:22:52PM +0900, Michael Paquier wrote:
> On Thu, Oct 29, 2020 at 10:59:52AM +0900, Michael Paquier wrote:
> > REINDEX CONCURRENTLY is by design wanted to provide an experience
> > transparent to the user similar to what a plain REINDEX would do, at
> > least that's the ide
CONCURRENTLY. If it's interrupted, it
leaves INVALID indexes, which can be cleaned up with DROP or REINDEX, same as
CIC on a plain table.
On Sat, Aug 08, 2020 at 01:37:44AM -0500, Justin Pryzby wrote:
> On Mon, Jun 15, 2020 at 09:37:42PM +0900, Michael Paquier wrote:
> > On Mon, Jun 15,
On Wed, Sep 23, 2020 at 07:43:01PM +0300, Alexey Kondratov wrote:
> On 2020-09-09 18:36, Justin Pryzby wrote:
> > Rebased on a6642b3ae: Add support for partitioned tables and indexes in
> > REINDEX
> >
> > So now this includes the new functionality and test for reindex
ils concerning
xmin, xmax, and user data.
@@ -1059,7 +1059,7 @@
The setting of the flags is silently done by VACUUM
and Autovacuum during their bloat and freeze operations.
This is done to speed up future vacuum actions,
-regular accesses to heap pages, and some accesses to
On Sun, Nov 01, 2020 at 10:11:06AM +0900, Michael Paquier wrote:
> On Fri, Oct 30, 2020 at 10:30:13PM -0500, Justin Pryzby wrote:
> > (I'm quoting from the commit message of the patch I wrote, which is same as
> > your patch).
>
> (I may have missed something, but you d
te_index found 2453 heap tuples, 2453 index tuples; inserted 0
missing tuples
|DEBUG: validate_index found 2453 heap tuples, 2453 index tuples; inserted 0
missing tuples
|REINDEX
I think the usual scenario is to have 100-1000 partitions, and 1-10 indexes per
partition. It seems to me that at
On Thu, Oct 29, 2020 at 08:40:31PM +0100, Michael Banck wrote:
> Am Mittwoch, den 28.10.2020, 21:44 -0500 schrieb Justin Pryzby:
> > Forking this thread:
> > https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4...@iki.fi
> > I think these are old-fashio
On Mon, Nov 02, 2020 at 07:53:45AM +0100, Luc Vlaming wrote:
> On 30.10.20 05:51, Justin Pryzby wrote:
> > On Thu, Oct 22, 2020 at 01:29:53PM +0100, Simon Riggs wrote:
> > > On Fri, 16 Oct 2020 at 22:05, Justin Pryzby wrote:
> > >
> > > > > > I mad
@cfbot: rebased
On Tue, Oct 27, 2020 at 07:33:12PM -0500, Justin Pryzby wrote:
> I'm attaching a counter-proposal to your catalog change, which preserves
> indisclustered on children of clustered, partitioned indexes, and invalidates
> indisclustered when attaching unclustered index
On Wed, Oct 28, 2020 at 02:34:02PM -0500, Justin Pryzby wrote:
> On Tue, Sep 08, 2020 at 02:51:26PM -0500, Justin Pryzby wrote:
> > On Sat, Jul 18, 2020 at 03:15:32PM -0500, Justin Pryzby wrote:
> > > Still waiting for feedback from a committer.
> >
> > This patch h
On Thu, Nov 05, 2020 at 10:11:52PM +0500, Andrey Borodin wrote:
> To test that functions are actually called for sorting build we should
> support directive sorting build like "CREATE INDEX ON A USING GIST(B)
> WITH(sorting=surely,and fail if not)".
Maybe you could add a DEBUG1 message for that,
704e5be9233e319
Author: Justin Pryzby
Date: Thu Nov 5 12:06:49 2020 -0600
list_free() in index_get_partition()
which was added at: a6da0047158b8a227f883aeed19eb7fcfbef11fb
diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 239ac017fa..4dfac39adf 1
maintenance (IVM)."
--
Justin
>From 568f8626e2d9ab0deb25ac9e10089a79abecdab0 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 5 Nov 2020 22:54:23 -0600
Subject: [PATCH] incremental view doc fixes
---
doc/src/sgml/catalogs.sgml| 2 +-
.../sgml/ref/create_materialized_view.sgml| 44 +++---
there's a reason why it's written like that, but (min-max)
looks odd, so I wrote it like:
pages_fetched = max - c**2 * (max-min)
> The new status of this patch is: Waiting on Author
>From af1e640af2b1a80430191a38b80dde1f2b750757 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Wed, 8
On Tue, Nov 10, 2020 at 10:17:15AM +, Paul Guo wrote:
> Raw insert could be used on CTAS & Create MatView. For Refresh MatView the
> code is a bit
> different. I did not spend more time on this so not sure raw insert could be
> used for that.
>
> But I think the previous multi insert work co
indexes can immediately
> +use these statistics to determine an index's usefulness.
> +For new expression indexes, it is necessary to run +linkend="sql-analyze">ANALYZE or wait for
> +the autovacuum daemon to analyze
> + the table to generate stat
I saw a bunch of these in my logs:
log_time | 2020-10-25 22:59:45.619-07
database |
left | could not open relation with OID 292103095
left | processing work entry for relation
"ts.child.alarms_202010_alarm_clear_time_idx"
Those happen following a REINDEX job on that index.
I think that
On Fri, Nov 13, 2020 at 01:39:31PM -0300, Alvaro Herrera wrote:
> On 2020-Nov-13, Justin Pryzby wrote:
>
> > I saw a bunch of these in my logs:
> >
> > log_time | 2020-10-25 22:59:45.619-07
> > database |
> > left | could not open relation with OID 2921
On Sat, Nov 14, 2020 at 01:00:00PM +0300, Alexander Lakhin wrote:
> As noted in [1], a sensible solution would be putting the same "retry on
> ERROR_ACCESS_DENIED" action in a wrapper for stat().
> And bed90759f brought in master the _pgstat64() function, where such
> error handling should be place
On Wed, Nov 04, 2020 at 08:23:56PM -0600, Justin Pryzby wrote:
> On Tue, Oct 27, 2020 at 07:33:12PM -0500, Justin Pryzby wrote:
> > I'm attaching a counter-proposal to your catalog change, which preserves
> > indisclustered on children of clustered, partitioned indexes,
On Tue, Nov 03, 2020 at 03:15:27PM +1300, David Rowley wrote:
> On Tue, 3 Nov 2020 at 07:35, Andres Freund wrote:
> >
> > On 2020-11-02 19:43:38 +0200, Heikki Linnakangas wrote:
> > > On 02/11/2020 19:23, Andres Freund wrote:
> > > > On 2020-11-02 11:03:29 +0200, Heikki Linnakangas wrote:
> > > >
On Thu, Nov 12, 2020 at 06:01:02PM -0500, Bruce Momjian wrote:
> On Thu, Nov 12, 2020 at 03:11:43PM -0600, Justin Pryzby wrote:
> > I guess it should say "The system regularly ..."
> >
> > Also, the last sentence begins "For new expression indexes" and en
On Fri, Nov 13, 2020 at 10:03:43AM -0500, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Thu, Nov 12, 2020 at 11:28 PM Tom Lane wrote:
> > > > The changes to the contrib modules appear to be incomplete in some ways.
> > > > In cube, hstore, and seg, there are no cha
t
> is, this does not work, for example:
>
> test=# create table t (a pg_statistic[]);
> ERROR: column "stavalues1" has pseudo-type anyarray
It works during initdb for the reasons that it's allowed for pg_statistic.
--
Justin
>From b9dabd3b773b077e55bb5ea23b89eb3d650029ee Mon Sep 17 00:00:00 20
f option we need created foreign server or accept
+# fail and check error
+
+open $inputfile, '>', "$tempdir/inputfile.txt";
+
+print $inputfile "+f doesnt_exists\n";
+close $inputfile;
+
+command_fails_like(
+ [ "pg_dump", '-p', $port, "-f"
On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
> On Fri, Nov 13, 2020 at 01:39:31PM -0300, Alvaro Herrera wrote:
> > On 2020-Nov-13, Justin Pryzby wrote:
> >
> > > I saw a bunch of these in my logs:
> > >
> > > log_time | 2020-10-25 22
On Thu, Nov 19, 2020 at 03:15:21PM -0300, Alvaro Herrera wrote:
> On 2020-Nov-19, Justin Pryzby wrote:
>
> > On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
>
> > > Your patch didn't actually say "try_relation_open", so didn't work.
>
On Fri, Nov 06, 2020 at 11:18:35PM -0300, Alvaro Herrera wrote:
> On 2020-Oct-24, Justin Pryzby wrote:
>
> > On Fri, Oct 23, 2020 at 12:29:40AM -0500, Justin Pryzby wrote:
>
> > > Now that I look, it seems like this is calling PQexec(), which sends a
> > > sin
On Fri, Nov 20, 2020 at 04:56:38PM +0100, Peter Eisentraut wrote:
> On 2020-10-17 21:21, Justin Pryzby wrote:
> > Added at:https://commitfest.postgresql.org/30/2766/
> >
> > diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
> > index 41
On Sat, Nov 21, 2020 at 08:39:11AM +0100, Peter Eisentraut wrote:
> On 2020-11-20 17:16, Justin Pryzby wrote:
> > It matters if it was planned with jit but executed without jit.
> >
> > postgres=# DEALLOCATE p; SET jit=on; SET jit_above_cost=0; prepare p as
> > sele
On Fri, Nov 20, 2020 at 05:26:54PM +0100, Peter Eisentraut wrote:
> On 2020-10-29 03:44, Justin Pryzby wrote:
> > diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml
> > index 4e833d79ef..be4292ec33 100644
> > --- a/doc/src/sgml/contrib.sgml
> > +++
It was only needed between these:
commit a8677e3ff6bb8ef78a9ba676faa647bba237b1c4
Author: Peter Eisentraut
Date: Fri Apr 13 17:06:28 2018 -0400
Support named and default arguments in CALL
commit f09346a9c6218dd239fdf3a79a729716c0d305bd
Author: Tom Lane
Date: Tue Jan 29 15:48:51 2019 -0
On Mon, Nov 02, 2020 at 12:45:51PM -0600, Justin Pryzby wrote:
> On Mon, Nov 02, 2020 at 07:53:45AM +0100, Luc Vlaming wrote:
> > On 30.10.20 05:51, Justin Pryzby wrote:
> > > On Thu, Oct 22, 2020 at 01:29:53PM +0100, Simon Riggs wrote:
> > > > On Fri, 16 Oc
On Sat, Oct 31, 2020 at 01:36:11PM -0500, Justin Pryzby wrote:
> > > From the grammar perspective ANY option is available for any command
> > > that uses parenthesized option list. All the checks and validations
> > > are performed at the corresponding command code.
&g
On Mon, Nov 23, 2020 at 04:30:26AM +0100, Tomas Vondra wrote:
> 0004 - Seems fine. IMHO not really "silly errors" but OK.
This is one of the same issues you pointed out - shadowing a variable.
Could be backpatched.
On Mon, Nov 23, 2020 at 04:30:26AM +0100, Tomas Vondra wrote:
> > +
On Mon, Nov 23, 2020 at 04:39:57PM -0300, Alvaro Herrera wrote:
> I think this formulation (attached v3) has fewer moving parts.
>
> However, now that I did that, I wonder if this is really the best
> approach to solve this problem. Maybe instead of doing this at the BRIN
> level, it should be ha
On Sun, Nov 07, 2021 at 10:14:00PM +0100, Tomas Vondra wrote:
> I'd probably vote for "session variables". We can call it local/global
> session variables in the future, if we end up implementing that.
By chance, I ran into this pre-existing use of the phrase "session variable".
introduced since 8
On Mon, Nov 08, 2021 at 02:52:28PM -0500, Melanie Plageman wrote:
> On Tue, Nov 2, 2021 at 4:23 PM Justin Pryzby wrote:
> >
> > Several places have a conditional value for the first argument
> > (randomAccess),
> > but your patch changes the behavior to a consta
On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
> * Fix is when creating a new range type with `CREATE TYPE` that could cause
> problems for later event triggers or subsequent executions of the `CREATE
> TYPE`
> command.
I don't know what "is when" means, but it seems wrong.
>
Thread starting here:
https://www.postgresql.org/message-id/20201001021609.GC8476%40telsasoft.com
On Fri, Dec 18, 2020 at 05:56:07PM -0600, Justin Pryzby wrote:
> I'm 99% sure the "bad_alloc" is from LLVM. It happened multiple times on
> different servers (running a similar
postgres=# SELECT log_time , database, user_name, error_severity sev,
left(message,99) FROM postgres_log_2021_11_10_0800 WHERE log_time BETWEEN
'2021-11-10 08:57' AND '2021-11-10 08:58' AND database IS NULL;
log_time | database | user_name | sev |
On Fri, Nov 12, 2021 at 01:51:28PM +0100, Daniel Gustafsson wrote:
> While reading through and working with the hundreds of patches in the CF app a
> small feature/process request struck me: it would be really helpful if the
> patch had a brief abstract outlining what it aims to add or fix (or summ
On Mon, Nov 02, 2020 at 01:50:57PM +1300, David Rowley wrote:
> On Tue, 27 Oct 2020 at 19:40, Amit Langote wrote:
> > Some comments:
>
> Thanks for having a look at this.
>
> I've made some adjustments to those comments and pushed.
commit a929e17e5 doesn't appear in the v14 release notes, but I
On Wed, Oct 13, 2021 at 05:28:30PM +0300, Ekaterina Sokolova wrote:
> Hi, hackers!
>
> • pg_query_state is contrib with 2 patches for core (I hope someday
> Community will support adding this patches to PostgreSQL). It contains
I reviewed this version of the patch - I have some language fixes
>
> Adding to commitfest.
I reviewed the documentation to learn about the feature,
and fixed some typos.
+notpatch.
--
Justin
>From 2f3d2465a93ee6207b2afdab8787cf2eaa2c0bb4 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 13 Nov 2021 12:11:46 -0600
Subject: [PATCH] f!typos
---
do
hours with no apparent issue - good.
It seems like there's an opened question about how RULES should be handled?
--
Justin
>From 119c6c7342ff9410424e94d60dc11b3a5e9d98c9 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 13 Nov 2021 15:47:12 -0600
Subject: [PATCH] f!merge code comme
Hi,
On Mon, Nov 15, 2021 at 10:38:55AM +0900, Tatsuro Yamada wrote:
> postgres=# \dco
> List of constsraints
> Schema | Name | Definition
> | Table
> +-+-
h is set by regress.c. I'm interested to hear from a
reviewer if this is worth pursing like this.
--
Justin
>From cdf439d9ccdec0f26bdd6b86f9f27bd4e55e5b9e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 22 Feb 2020 21:17:10 -0600
Subject: [PATCH 1/3] Add explain(REGRESS)...
This i
On Mon, Nov 15, 2021 at 09:12:49PM +0530, vignesh C wrote:
> The idea here is to implement & expose pg_print_backtrace function, internally
This patch is closely related to this one
https://commitfest.postgresql.org/35/3142/
| Logging plan of the currently running query
I suggest to review that p
On Mon, Nov 15, 2021 at 09:00:13PM +0100, Pavel Stehule wrote:
> Thank you for review and fixes, I try to complete some version for next
> work, and looks so your patch 0001 is broken
>
> gedit reports to me broken unicode \A0\A0\A0\A0\A0
>
> my last patch has 276KB and your patch has 293KB?
On
On Mon, Nov 15, 2021 at 03:23:17PM -0500, Robert Haas wrote:
> On Mon, Nov 15, 2021 at 2:51 PM Stephen Frost wrote:
> > I get that just compressing the entire stream is simpler and easier and
> > such, but it's surely cheaper and more efficient to not decompress and
> > then recompress data that's
On Sun, Aug 29, 2021 at 07:26:42PM -0500, Justin Pryzby wrote:
> On Mon, Jun 28, 2021 at 11:22:01AM +0300, Anna Akenteva wrote:
> > On 2019-11-29 05:32, Michael Paquier wrote:
> > > These comments are unanswered for more than 2 months, so I am marking
> > > this entr
Thanks for updating the patch :)
> Currently, DBAs need the table name to see the constraint information.
Or, they can query pg_constraint or information_schema: check_constraints,
table_constraints.
> - success = listConversions(pattern,
> show_verbose, show_system)
On Wed, Nov 17, 2021 at 03:59:59PM -0300, Euler Taveira wrote:
> On Mon, Nov 15, 2021, at 4:27 AM, Bharath Rupireddy wrote:
> > As there is some interest shown in this thread at [1], I'm attaching a
> > new v3 patch here. Please review it.
> I took a look at this patch. I have a few comments.
>
>
On Wed, Nov 17, 2021 at 02:44:52PM -0500, Jaime Casanova wrote:
> Hi,
>
> Currently docs about pg_upgrade says:
>
> """
>
> The --jobs option allows multiple CPU cores to be used
> for copying/linking of files and to dump and reload database schemas
> in parallel; a good plac
On Wed, Nov 17, 2021 at 06:46:47PM +, Bossart, Nathan wrote:
> On 10/30/21, 2:36 AM, "Bharath Rupireddy"
> wrote:
> > I've added 3 functions pg_ls_logicalsnapdir, pg_ls_logicalmapdir,
> > pg_ls_replslotdir, and attached the patch. The sample output looks
> > like [1]. Please review it further
On Wed, Nov 17, 2021 at 04:01:19PM +0900, Michael Paquier wrote:
> On Sun, Nov 07, 2021 at 01:22:00PM -0600, Justin Pryzby wrote:
> > That may be good enough for test.sh, but if the kludges were moved to a .sql
> > script which was also run by the buildfarm (in stead of its hardcod
e(pg_backend_pid());
+
+CREATE ROLE regress_log_backtrace;
+
+SELECT has_function_privilege('regress_log_backtrace',
+ 'pg_log_backtrace(integer)', 'EXECUTE'); -- no
+
+GRANT EXECUTE ON FUNCTION pg_log_backtrace(integer)
+ TO regress_log_backtrace;
+
+SELECT
On Thu, Nov 18, 2021 at 12:24:14PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Nov 18, 2021 at 11:05 AM Tom Lane wrote:
> >> Yeah, given current usage it would be better to call it the "recovery
> >> process". However, I'm feeling dubious that it's worth the cost to
> >> change. Th
On Thu, Nov 18, 2021 at 12:59:03PM -0500, Melanie Plageman wrote:
> On Mon, Nov 8, 2021 at 3:13 PM Justin Pryzby wrote:
> > On Mon, Nov 08, 2021 at 02:52:28PM -0500, Melanie Plageman wrote:
> > > On Tue, Nov 2, 2021 at 4:23 PM Justin Pryzby wrote:
> > > >
On Wed, Nov 10, 2021 at 09:56:44AM -0600, Justin Pryzby wrote:
> Thread starting here:
> https://www.postgresql.org/message-id/20201001021609.GC8476%40telsasoft.com
>
> On Fri, Dec 18, 2020 at 05:56:07PM -0600, Justin Pryzby wrote:
> > I'm 99% sure the "bad_alloc
On Sun, Nov 21, 2021 at 03:11:03AM +1100, Todd Hubers wrote:
> I have just joined to start a community consultation process for a
> proposal. I just finished the proposal document, I spent time writing a
> Problem and Solution section, and I have done quite a bit of upfront
> exploration of the cod
On Wed, Nov 17, 2021 at 01:45:06PM -0500, Melanie Plageman wrote:
> On Sat, Nov 6, 2021 at 11:04 PM Justin Pryzby wrote:
> >
> > > Rebased patches attached. I will change status back to "Ready for
> > > Committer"
> >
> > The CI showed a crash o
Your regression tests include two errors, which appear to be accidental, and
fixing the error shows that this case is being estimated poorly.
+-- try combining with single-column (and single-expression) statistics
+DROP STATISTICS join_test_2;
+ERROR: statistics object "join_test_2" does not exis
bbe5f48ae9695cb89de4 (an issue I reported the first time I
was looking at this patch).
I think the non-text format timing stuff needs to be within "if (timing)".
I'm curious to hear what you and others think of the refactoring.
It'd be nice if there's a good way
On Tue, Nov 23, 2021 at 06:54:03PM +, Jacob Champion wrote:
> On Wed, 2021-11-17 at 14:34 -0600, Justin Pryzby wrote:
> > On Wed, Nov 17, 2021 at 02:44:52PM -0500, Jaime Casanova wrote:
> > >
> > > - why we read()/write() at all? is not a faster way of copying t
t's wanted, but not usually what "ls" would
show), nor ready to implement recurse.
As before:
On Tue, Apr 06, 2021 at 11:01:31AM -0500, Justin Pryzby wrote:
> The first handful of patches address the original issue, and I think could be
> "ready":
>
> $ git log
Thanks for working on this. I was just trying to find something like
"pg_stat_checkpointer".
You wrote beentry++ at the start of two loops, but I think that's wrong; it
should be at the end, as in the rest of the file (or as a loop increment).
BackendStatusArray[0] is actually used (even though i
On Wed, Nov 24, 2021 at 07:15:59PM -0600, Justin Pryzby wrote:
> There's extraneous blank lines in these functions:
>
> +pgstat_sum_io_path_ops
> +pgstat_report_live_backend_io_path_ops
> +pgstat_recv_resetsharedcounter
> +GetIOPathDesc
> +StrategyRejectBuf
On Fri, Nov 26, 2021 at 12:37:32PM -0800, Peter Geoghegan wrote:
> My preferred approach to this is simple: redefine VACUUM VERBOSE to
> not show incremental output, which seems rather unhelpful anyway.
> I don't think that we need to keep the getrusage() stuff at all, though.
+1
> * VACUUM VERB
On Sat, Nov 27, 2021 at 04:33:07PM +, Arne Roland wrote:
> Hello!
>
> Since I used a lot of my time chasing short lived processes eating away big
> chunks of memory in recent weeks, I am wondering about a decent way to go
> about this.
> The problem I am facing essentially relates to the fac
ar to GUC categories fixed in a55a98477.
Tom was of the impression that there's more loose ends on that thread.
https://www.postgresql.org/message-id/flat/16997-ff16127f6e0d1...@postgresql.org
--
Justin
>From b52bbf317126dbd75a2f8e98ceec4f3beb66f572 Mon Sep 17 00:00:00 2001
From: Justin
On Mon, Nov 29, 2021 at 02:01:35PM +, Arne Roland wrote:
> But my main goal is something else. I can't explain my clients, why a chanced
> statistics due to autovacuum suddenly leads to oom. They would be right to
> question postgres qualification for any serious production system.
What vers
On Mon, Nov 29, 2021 at 01:49:24PM +0100, Guillaume Lelarge wrote:
> One of our customers had a very bad issue while trying to reassign objects
> from user A to user B. He had a lot of them, and the backend got very
> hungry for memory. It finally all went down when the linux kernel decided
> to ki
601 - 700 of 1717 matches
Mail list logo
