On Thu, Aug 27, 2020 at 07:53:23PM -0400, Alvaro Herrera wrote:
> +1 for the general idea, and +1 for \dX being the syntax to use
>
> IMO the per-type columns should show both the type being enabled as
> well as it being built.
>
> (How many more stat types do we expect -- Tomas? I wonder if
d+).
>From 60a4033a04fbaafbb01c2bb2d73bb2fbe4d1da75 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sun, 30 Aug 2020 23:38:17 -0500
Subject: [PATCH 1/1] Show stats target of extended statistics
This can be set since d06215d03, but wasn't shown by psql.
Normal (1-D) stats targets are shown in \d+ table.
---
> diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
> index 47d4c07306..23840bb8e6 100644
> --- a/src/include/nodes/parsenodes.h
> +++ b/src/include/nodes/parsenodes.h
> @@ -3352,6 +3352,7 @@ typedef struct ConstraintsSetStmt
> /* Reindex options */
> #define
On Wed, Sep 02, 2020 at 10:00:12AM +0900, Michael Paquier wrote:
> On Tue, Sep 01, 2020 at 11:48:30AM -0400, Alvaro Herrera wrote:
> > On 2020-Sep-01, Justin Pryzby wrote:
> >> The question isn't whether to use a parenthesized option list. I realized
> >> that
> &
On Tue, Sep 01, 2020 at 09:24:10PM -0500, Justin Pryzby wrote:
> On Wed, Sep 02, 2020 at 10:00:12AM +0900, Michael Paquier wrote:
> > On Tue, Sep 01, 2020 at 11:48:30AM -0400, Alvaro Herrera wrote:
> > > On 2020-Sep-01, Justin Pryzby wrote:
> > >> The question isn't
On Mon, Aug 31, 2020 at 07:47:35AM +, gkokola...@pm.me wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, 31 August 2020 08:00, Justin Pryzby wrote:
>
> > The stats target can be set since commit d06215d03, but wasn't shown by
> > psql.
> > ALTER STATI
This patch seems to be missing a call to RelationAssumeNewRelfilenode() in
reindex_index().
That's maybe the related to the cause of the crashes I pointed out earlier this
year.
Alexey's v4 patch changed RelationSetNewRelfilenode() to accept a tablespace
parameter, but Michael seemed to object
On Thu, Sep 10, 2020 at 11:21:02AM -0400, Robert Haas wrote:
> On Fri, Aug 28, 2020 at 5:55 AM Ashutosh Sharma wrote:
> > Please have a look into the attached patch for the changes and let me know
> > for any other concerns. Thank you.
>
> I have committed this version.
Thanks ; I marked it as
On Mon, Sep 07, 2020 at 08:40:26AM -0500, Justin Pryzby wrote:
Rebasing onto 3965de54e718600a4703233936e56a3202caf73f, I'm left with:
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 8fffc6fe0a..69d143e10c 100644
--- a/doc/src/sgml/release-13.sgml
+++ b/doc/src/sgml
Against all odds, I was able to reproduce this.
begin;
CREATE TABLE t AS SELECT generate_series(1,99)i;
ALTER TABLE t SET (parallel_workers=2, autovacuum_enabled=off);
CREATE INDEX ON t(i);
commit;
SET parallel_leader_participation=off; SET min_parallel_table_scan_size=0; SET
lived context.
Also, my previous revision failed to implement your suggestion to first build
catalog entries with INVALID indexes and to then reindex them. Fixed.
--
Justin
>From 17a14e5ad128024b05ae288a5096148b3f114c98 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 6 Jun 2020 17:42:23 -
On Wed, Sep 09, 2020 at 09:22:00PM +0900, Michael Paquier wrote:
> On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote:
> > Initially I added List *params, and Michael suggested to retire
> > ReindexStmt->concurrent. I provided a patch to do so, initially by leaving
&
I've added a few more.
--
Justin
>From 137321a0d476f66b5e5f21c2f627c407330e50b1 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 30 Mar 2020 19:43:22 -0500
Subject: [PATCH v8 01/14] doc: btree deduplication
commit 0d861bbb702f8aa05c2a4e3f1650e7e8df8c8c27
Author: Peter Geoghe
rator, I think maybe a comma is enough. I
doubt anyone is going to think that you can get a valid command by prefixing
this by "CREATE STATISTICS". Actually, it didn't even occur to me it was valid
command without the stats target - after all, that's not true of indexes.
+"public"
On Wed, Aug 05, 2020 at 04:04:22PM +0200, Dmitry Dolgov wrote:
> > On Sun, Aug 02, 2020 at 12:50:12PM +0200, Pavel Stehule wrote:
> > >
> > > > Maybe this could be salvaged by flushing 0005 in its current form and
> > > > having the jsonb subscript executor do something like "if the current
> > >
On Tue, Sep 08, 2020 at 06:25:03PM +, Jameson, Hunter 'James' wrote:
> Hi, I ran across a small (but annoying) bug in initializing parallel BTree
> scans, which causes the parallel-scan state machine to get confused. The fix
> is one line; the description is a bit longer—
What postgres
On Wed, Sep 09, 2020 at 07:22:30PM -0300, Alvaro Herrera wrote:
> On 2020-Sep-09, Justin Pryzby wrote:
>
> > As for the discussion about a separator, I think maybe a comma is enough. I
> > doubt anyone is going to think that you can get a valid command by prefixing
> > th
On Mon, Aug 31, 2020 at 03:52:44PM +0900, Michael Paquier wrote:
> On Thu, Aug 20, 2020 at 05:09:05PM +0900, Michael Paquier wrote:
> > That could be helpful. Wouldn't it be better to use "end-of-recovery
> > checkpoint" instead? That's the common wording in the code comments.
> >
> > I don't
On Tue, Sep 15, 2020 at 10:01:18AM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Based on a couple of independent reports from users with no idea how
> > to judge the progress of a system recovering from a crash, Christoph
> > and I wondered if we should override update_process_title for the
On Sat, Sep 12, 2020 at 10:35:34AM +0900, Michael Paquier wrote:
> On Fri, Sep 11, 2020 at 07:13:01PM -0500, Justin Pryzby wrote:
> > On Tue, Sep 08, 2020 at 01:31:05PM +0900, Michael Paquier wrote:
> >> - CIC on partitioned relations. (Should we also care about DROP INDEX
On Thu, Sep 03, 2020 at 12:00:17AM +0300, Alexey Kondratov wrote:
> On 2020-09-02 07:56, Justin Pryzby wrote:
> >
> > Done in the attached, which is also rebased on 1d6541666.
> >
> > And added RelationAssumeNewRelfilenode() as I mentioned - but I'm hoping
> > t
On Tue, Sep 01, 2020 at 11:40:18AM -0400, Alvaro Herrera wrote:
> On 2020-Aug-11, Justin Pryzby wrote:
> > On Tue, Aug 11, 2020 at 02:39:45PM +0900, Michael Paquier wrote:
>
> > > The grammar that has been committed was the one that for the most
> > > support, so
On Thu, Sep 03, 2020 at 09:43:51PM -0500, Justin Pryzby wrote:
> And rebased on Michael's commit removing ReindexStmt->concurrent.
Rebased on a6642b3ae: Add support for partitioned tables and indexes in REINDEX
So now this includes the new functionality and test for reindexing a
parti
On Tue, Sep 08, 2020 at 09:02:38PM -0300, Alvaro Herrera wrote:
> On 2020-Sep-08, Justin Pryzby wrote:
>
> > From 992e0121925c74d5c5a4e5b132cddb3d6b31da86 Mon Sep 17 00:00:00 2001
> > From: Justin Pryzby
> > Date: Fri, 27 Mar 2020 17:50:46 -0500
> > Subject:
output.
timezone-aware or time-zone-aware, if you must.
> Allow vacuum commands run by vacuumdb to operate in parallel mode (Masahiko
> Sawada)
=> I think this is still going to be lost/misunderstood/confuse some people.
vacuumdb already supports -j. This allows it to run vacuum(paralle
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 patches since March 10, so I'm planning to set to "Ready" - at
least ready for
On Tue, Sep 08, 2020 at 01:31:05PM +0900, Michael Paquier wrote:
> - CIC on partitioned relations. (Should we also care about DROP INDEX
> CONCURRENTLY as well?)
Do you have any idea what you think that should look like for DROP INDEX
CONCURRENTLY ?
--
Justin
On Fri, Oct 02, 2020 at 04:28:14PM +0900, Michael Paquier wrote:
> > Related: I have always thought that this message meant "recovery will
> > complete
> > Real Soon", but I now understand it to mean "beginning the recovery
> > checkpoint,
> > which is flagged CHECKPOINT_IMMEDIATE" (and may take
On Thu, Oct 15, 2020 at 02:23:01PM +1300, David Rowley wrote:
> On Thu, 15 Oct 2020 at 14:15, Tom Lane wrote:
> > David Rowley writes:
> > > Just for some reference. Some wisdom was shared in [1], which made a
> > > lot of sense to me.
> > > If we apply that, then we just need to decide if
/* don't print information if no JITing happened */
if (!ji || ji->created_functions == 0)
return;
This applies even when (es->format != EXPLAIN_FORMAT_TEXT), which I think is
wrong. Jit use can be determined by cost, so I think jit details should be
shown in
On Wed, Sep 30, 2020 at 04:52:02PM -0700, Soumyadeep Chakraborty wrote:
> Hi Justin,
>
> Attached is a minimal patch that is rebased and removes the
> dependency on Konstantin's earlier patch[1], making it enough to remove
> the extraneous index scans as Justin brought up. Is this the direction
On Tue, Oct 13, 2020 at 01:44:41PM +0200, Laurenz Albe wrote:
> Attached is v3 with improvements.
+
+ Time spent in database sessions in this database, in milliseconds.
+
Should say "Total time spent *by* DB sessions..." ?
I think these counters are only accurate as of the
I'm hoping that Alvaro will comment on this.
On Wed, Sep 30, 2020 at 05:34:50PM -0500, 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 trigger LANGUAGE plpgsql AS
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
> info to commit messages, and added here.
> https://commitfest.postgresql.org/30/2744/
Added an additional patch regarding spaces between
On Tue, Oct 06, 2020 at 11:42:55AM +0900, Michael Paquier wrote:
> On Mon, Oct 05, 2020 at 03:08:32PM -0500, Justin Pryzby wrote:
> > It means that we might do N catalog updates for a partition heirarchy
> > that's N
> > levels deep. Normally, N=2, and we'd clear indiscl
On Mon, Oct 05, 2020 at 05:46:27PM +0900, Michael Paquier wrote:
> On Sat, Sep 26, 2020 at 02:56:55PM -0500, Justin Pryzby wrote:
> > Also, if a partitioned index is clustered, when we clear indisclustered for
> > other indexes, should we also propogate that to their parent index
On Fri, Oct 09, 2020 at 02:53:25PM -0400, Bruce Momjian wrote:
> On Thu, Sep 24, 2020 at 07:55:31PM -0500, Justin Pryzby wrote:
> > This should be caught during --check, or earlier in the upgrade, rather than
> > only after dumping the schema.
> >
> > Typically, the t
On Fri, Oct 09, 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:
> >
> > + * Note, v8.4 has no tablespace_suffix, which is fine so long as the
> &g
On Sat, Sep 19, 2020 at 08:32:15AM -0500, Justin Pryzby wrote:
> On Sun, Jul 12, 2020 at 08:57:00PM -0500, Justin Pryzby wrote:
> > On Thu, Jun 04, 2020 at 10:30:47AM -0700, Andres Freund wrote:
> > > On 2020-05-08 02:25:45 -0500, Justin Pryzby wrote:
> > > > S
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
ot; display still
says "recovering ".
Please change to say "recovery checkpoint" or similar, as I mentioned here.
https://www.postgresql.org/message-id/2020011820.gp26...@telsasoft.com
--
Justin
>From 93c7160f39bf63593e10d7730160668016d7 Mon Sep 17 00:00:00 2001
I stand by these changes which I proposed handful of times since April, but not
yet included by Michael's previous commits.
--
Justin
>From f029efd79c4ad14ae003ed1a1c692931cdc33f1e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 30 Mar 2020 19:43:22 -0500
Subject: [PATCH v6 01/10]
On Fri, Aug 07, 2020 at 02:30:01PM +0200, Pierre Giraud wrote:
> Hi all,
>
> As far as I understand, in the upcoming version 13, information about
> buffers used during planning is now available in the explain plan.
>
> […]
> Planning Time: 0.203 ms
>Buffers: shared hit=14
> […]
>
> For a
On Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:
> As the result of a discussion with Fujita-san off-list, I'm going to
> hold off development until he decides whether mine or Thomas' is
> better.
The latest patch doesn't apply so I set as WoA.
On Mon, Aug 17, 2020 at 11:10:05PM +0530, vignesh C wrote:
> On Sat, Aug 1, 2020 at 8:12 AM vignesh C wrote:
> > > >
> > > > +-- access method column should not be displayed for sequences
> > > > +\ds+
> > > >
> > > > - List of relations
> > > >
> > > >
> > > > - Schema
On Fri, Sep 25, 2020 at 08:49:57AM +, Hou, Zhijie wrote:
> In (/src/backend/replication/backup_manifest.c)
>
> I found the following code:
>
> appendStringInfoString(, "\n");
> appendStringInfoString(, "\"");
Good point. There's another one:
$ git grep -E
bals.sql:27: ERROR: directory
"/home/pryzbyj/tblspc/PG_13_202007201" already in use as a tablespace
>From 3df104610d73833da60bffcc54756a6ecb2f390f Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 24 Sep 2020 19:49:40 -0500
Subject: [PATCH v1] pg_upgrade --check to avoid table
On Sat, Sep 19, 2020 at 12:55:58PM -0500, Justin Pryzby wrote:
> On Thu, Sep 10, 2020 at 12:19:55PM -0700, Yaroslav wrote:
> > Disclaimer: I'm not a native speaker, so not sure those are actually
> > incorrect, and can't offer non-trivial suggestions.
>
> https://www.post
Split one patch about text search, added another one (sequences), added some
info to commit messages, and added here.
https://commitfest.postgresql.org/30/2744/
--
Justin
>From adf050ac6cc7d0905fc1613dce1a04f76a892609 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 22 Sep 2020 21:40
It seems to me that at least schema changes should be
> prevented with a ShareLock in the first transaction building the list
> of elements to cluster.
Thanks for noticing. I chose ShareUpdateExclusiveLock since it's
set-exclusive.
--
Justin
>From e4fe1e422dc2c0ee21ce9df15d5baf24e82
On Fri, Jun 05, 2020 at 05:16:43PM +0200, Antonin Houska wrote:
> Antonin Houska wrote:
>
> > In general, the checks are significantly faster if there are many rows to
> > process, and a bit slower when we only need to check a single row.
>
> Attached is a new version that uses the existing
Added at
https://commitfest.postgresql.org/30/2739/
>From 831246aa6d6837b2b0da7c96ad2f44ffd6cd3951 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 24 Sep 2020 19:49:40 -0500
Subject: [PATCH v2] pg_upgrade --check to avoid tablespace failure mode
---
src/bin/pg_upgrade/check.c |
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 trigger LANGUAGE plpgsql AS $$ begin
raise exception 'except'; end $$;
CREATE TRIGGER tg AFTER INSERT ON t FOR EACH ROW EXECUTE FUNCTION tgf();
ALTER
A VM crashed which is now running PG13.0 on centos7:
Sep 30 19:40:08 database7 abrt-hook-ccpp: Process 17905 (postgres) of user 26
killed by SIGABRT - dumping core
Core was generated by `postgres: telsasoft ts 192.168.122.11(34608) SELECT'.
Unfortunately, the filesystem wasn't large enough
+ * changed to "inprogress-off", the barrier for mvoving to "off" can be
moving
+ * When disabling checksums, data_checksums will be set of "inprogress-off"
set *to*
+ get_namespace_name(RelationGetNamespace(reln)),
RelationGetRelationName(reln),
I think this palloc()s a new copy of the
On Sun, Jul 12, 2020 at 08:57:00PM -0500, Justin Pryzby wrote:
> On Thu, Jun 04, 2020 at 10:30:47AM -0700, Andres Freund wrote:
> > On 2020-05-08 02:25:45 -0500, Justin Pryzby wrote:
> > > Seems to me it should, at least conditionally. At least if there's a
> &g
On Thu, Sep 17, 2020 at 11:38:47AM +0300, Heikki Linnakangas wrote:
> On 15/09/2020 14:36, Heikki Linnakangas wrote:
> > Another patch version, fixed a few small bugs pointed out by assertion
> > failures in the regression tests.
>
> Pushed. Thanks everyone!
+/* FIXME: bump this before pushing!
On Thu, Sep 10, 2020 at 01:37:10PM +0900, Michael Paquier wrote:
> On Wed, Sep 09, 2020 at 09:00:50PM -0500, Justin Pryzby wrote:
> > What would you want the checkpointer's ps to say ?
> >
> > Normally it just says:
> > postgres 3468 3151 0 Aug27 ?00:2
On Thu, Sep 10, 2020 at 12:19:55PM -0700, Yaroslav wrote:
> Disclaimer: I'm not a native speaker, so not sure those are actually
> incorrect, and can't offer non-trivial suggestions.
On Wed, Sep 30, 2020 at 09:16:09PM -0500, Justin Pryzby wrote:
> Our DBs use postgis, and today's crash JOINs to the table with geometry
> columns, but does not use them at all.
I'm wrong here - it does return the geometry columns.
We didn't use JIT with v12, but I've been setting jit=on
On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> The below turned out to be somewhat obsoleted by what you wrote below,
> which I unfortunately hadn't yet read - but I think it's still good
> information, so I'm not gonna delete it:
Right, I understand that RES RAM might includes
On Thu, Sep 10, 2020 at 03:58:31PM +0900, Michael Paquier wrote:
> On Wed, Sep 09, 2020 at 09:37:42AM -0500, Justin Pryzby wrote:
> > I've added a few more.
>
> I have done an extra round of review on this patch series, and applied
> what looked obvious to me (basically
On Wed, May 27, 2020 at 07:40:27PM +0200, Fabien COELHO wrote:
> llvmjit_inline.cpp:59:10: fatal error: llvm/IR/CallSite.h: No such file or
Seems to be the same as here:
On Sun, May 24, 2020 at 09:30:15PM +0300, Victor Yegorov wrote:
> Greetings.
>
> I am getting random failures in `CREATE INDEX USING gist` over ltree column
> while performing pg_restore.
> I get either
> ERROR: stack depth limit exceeded
> or
> ERROR: failed to add item to index page
>
On Mon, May 25, 2020 at 04:41:49PM +0300, Victor Yegorov wrote:
> New index to be created:
> CREATE INDEX i_mp_comments_mpath_gist ON comments.mp_comments USING gist
> (mpath);
I wonder if/how that fails if you create the index before adding data:
CREATE TABLE test_path(path ltree);
CREATE
Rebased onto 7b48f1b490978a8abca61e9a9380f8de2a56f266 and renumbered OIDs.
>From bb41ae268041b7e7771930d533a8ca20a00805c7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 16 Mar 2020 14:12:55 -0500
Subject: [PATCH v18 01/10] Document historic behavior of links to
directories..
Backpa
On Fri, May 29, 2020 at 04:21:00PM +0200, Pavel Stehule wrote:
> one my customer has to specify dumped tables name by name. After years and
> increasing database size and table numbers he has problem with too short
> command line. He need to read the list of tables from file (or from stdin).
+1 -
On Fri, May 29, 2020 at 09:53:14PM -0400, John Bachir wrote:
> Hi Sergei - I just used the recipe on my production database. I didn't
> observe all the expected benefits, I wonder if there were confounding factors
> or if I did something wrong. If you have time, I'd love to get your feedback.
>
On Sun, May 31, 2020 at 01:43:45PM +0600, Антон Пацев wrote:
> Hello!
> When parameter cannot be changed without restarting the server postgresql
> write:
> "LOG: configuration file "/var/lib/postgresql/data/postgresql.auto.conf"
> contains errors; unaffected changes were applied"
> May be not
On Mon, Jun 01, 2020 at 10:49:25AM -0400, John Bachir wrote:
> On Fri, May 29, 2020, at 10:10 PM, Justin Pryzby wrote:
>
> > If you do it right, you can see a DEBUG:
> > postgres=# SET client_min_messages=debug;
> > postgres=# ALTER TABLE tn ALTER i SET NOT NULL ;
> >
On Sat, May 23, 2020 at 06:33:48PM +0200, Vik Fearing wrote:
> > Do we really want default_explain_analyze ?
> > It sounds like bad news that EXPLAIN DELETE might or might not remove rows
> > depending on the state of a variable.
>
> I have had sessions where not using ANALYZE was the exception,
On Sun, Sep 20, 2020 at 05:10:05PM -0400, Tom Lane wrote:
> I wrote:
> > It appears that hyrax (CLOBBER_CACHE_ALWAYS) is not very happy
> > with this:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax=2020-09-19%2021%3A27%3A23
>
> I reproduced that and traced it to a missing
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
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:
> > >
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
en 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 2001
From: Justin Pryzby
Date: Sun, 7 Jun 2020 16:58:42 -0
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 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 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 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';
>
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 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
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
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 Tue, Jul 14, 2020 at 10:08:39PM -0500, Justin Pryzby wrote:
> I'm still missing feedback from committers about the foundation of this
> approach.
Now rebased on top of fix for my own bug report (1d09fb1f).
I also changed argument handling for pg_ls_dir_recurse().
Passing '.' gave an i
We hit this on v13b2 and verified it fails on today's HEAD (ac25e7b039).
explain SELECT 1 FROM sites NATURAL JOIN sectors WHERE sites.config_site_name
!= sectors.sect_name ;
ERROR: could not determine which collation to use for string comparison
I can workaround the issue by DELETEing stats
Reproducer:
postgres=# CREATE TABLE t AS SELECT ''a FROM generate_series(1,99); CREATE
TABLE u AS SELECT ''a FROM generate_series(1,99) ; VACUUM ANALYZE t,u;
postgres=# explain SELECT * FROM t JOIN u ON t.a!=u.a;
ERROR: could not determine which collation to use for string comparison
HINT: Use
sult.
--
Justin
>From c5b356797fc092aec076cca9faa83ea086516350 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 28 Jul 2020 11:56:26 -0500
Subject: [PATCH v2] Tab completion for VACUUM of partitioned tables
---
src/bin/psql/tab-complete.c | 10 +-
1 file changed, 5 insertions
On Mon, Aug 03, 2020 at 11:41:37AM -0400, Robert Haas wrote:
> On Sun, Aug 2, 2020 at 2:11 PM Justin Pryzby wrote:
> > Based on commit logs, I suspect this may be an "older bug", specifically
> > maybe
> > with:
> >
> > |commit 898e5e3290a72d28892326
Rebased and updated for tests added in 13838740f.
--
Justin Pryzby
System Administrator
Telsasoft
+1-952-707-8581
>From 9272dda812d2b959d0bd536e0679f8f8527da7b1 Mon Sep 17 00:00:00 2001
From: Konstantin Knizhnik
Date: Fri, 12 Oct 2018 15:53:51 +0300
Subject: [PATCH v3 1/2] Secondary in
On Sun, Aug 02, 2020 at 12:00:56AM +0200, Daniel Gustafsson wrote:
> > On 10 Jul 2020, at 15:30, Peter Eisentraut
> > wrote:
> >
> > On 2020-05-23 11:14, Vik Fearing wrote:
> >> Here is a patch to provide default gucs for EXPLAIN options.
> >> I have two goals with this patch. The first is
On Fri, Jul 31, 2020 at 04:55:14PM -0500, Justin Pryzby wrote:
> Bcc:
> Subject: Re: display offset along with block number in vacuum errors
> Reply-To:
> In-Reply-To:
>
whoops
> On Wed, Jul 29, 2020 at 12:35:17AM +0530, Mahendra Singh Thalor wrote:
> > > He
On Sat, Aug 01, 2020 at 12:31:53PM +0530, Mahendra Singh Thalor wrote:
> Actually I was waiting for review comments from committer and other
> people also and was planning to send a patch after that. I already
> fixed your comments in my offline patch and was waiting for more
> comments. Anyway,
On Wed, Jul 29, 2020 at 08:35:08PM -0700, Peter Geoghegan wrote:
> AFAICT sort (and IncrSort) don't fail to show a field value if it is
> zero. Rather, they consistently show "space used" (in non-text
> format), which can be either memory or disk space. Technically they
> don't violate the letter
I'm testing with a customer's data on pg13dev and got output for which Peak
Memory doesn't look right/useful. I reproduced it on 565f16902.
CREATE TABLE p(i int) PARTITION BY RANGE(i);
CREATE TABLE p1 PARTITION OF p FOR VALUES FROM (0)TO(1000);
CREATE TABLE p2 PARTITION OF p FOR VALUES FROM
On Wed, Aug 05, 2020 at 09:53:44AM +0900, Amit Langote wrote:
> On Wed, Aug 5, 2020 at 9:52 AM Amit Langote wrote:
> > On Wed, Aug 5, 2020 at 9:32 AM Justin Pryzby wrote:
> > > On Wed, Aug 05, 2020 at 09:26:20AM +0900, Amit Langote wrote:
> > > > On Wed, Aug 5,
On Wed, Aug 05, 2020 at 01:44:17PM +1200, David Rowley wrote:
> On Wed, 5 Aug 2020 at 13:21, Justin Pryzby wrote:
> >
> > I'm testing with a customer's data on pg13dev and got output for which Peak
> > Memory doesn't look right/useful. I reproduced it on 565f16902.
&
On Fri, Aug 07, 2020 at 12:16:11PM +0900, Amit Langote wrote:
> Curiously, Justin mentioned upthread that the crash occurred during
> BIND of a prepared query, so it better had been that a custom plan was
> being executed, because a generic one based on fewer partitions would
> be thrown away due
601 - 700 of 2601 matches
Mail list logo
