On Fri, May 03, 2024 at 04:32:25PM +0300, Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > Note that the error that led to "EXCLUDING IDENTITY" is being discused
> > over here:
> > https://www.postgresql.org/message-id/3b
On Fri, May 24, 2024 at 09:26:54AM -0400, Robert Haas wrote:
> On Thu, Jul 6, 2023 at 4:15 PM Justin Pryzby wrote:
> But then I realized, reading another email, that Justin already knew
> that the behavior would change, or at least I'm 90% certain that he
> knows that.
You give
It occurred to me that psql \dP+ should show the AM of partitioned
tables (and other partitioned rels).
Arguably, this could've been done when \dP was introduced in v12, but
at that point would've shown the AM only for partitioned indexes.
But it makes a lot of sense to do it now that partitioned
o be computed for the
individual partitions.
"CREATE TABLE ... PARTITION OF" command doesn't copy extended
statistics. This commit makes createPartitionTable() behave
consistently.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/ZiJW1g2nbQs9ekwK%40pryzbyj2023
---
doc/src/sgml/ref/alter
On Wed, May 08, 2024 at 09:00:10PM +0300, Alexander Korotkov wrote:
> On Fri, May 3, 2024 at 4:32 PM Alexander Korotkov
> wrote:
> > On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote:
> > > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> > > >
On Tue, May 07, 2024 at 10:55:28AM +1200, Thomas Munro wrote:
> On Tue, May 7, 2024 at 6:21 AM Justin Pryzby wrote:
> > FWIW: both are running zfs-2.2.3 RPMs from zfsonlinux.org.
> ...
> > Yes, they're running centos7 with the indicated kernels.
>
> So far we've got:
pg_dump -Fc |pg_restore -l -N schema:
| 2; 3079 18187 EXTENSION - pg_buffercache
Without -N schema also shows:
| 2562; 0 0 COMMENT - EXTENSION pg_buffercache
I mean literal s-c-h-e-m-a, but I suppose anything else will work the
same.
BTW, I noticed that pg_restore -v shows that duplicate
On Sat, Jan 21, 2023 at 02:45:40AM +0100, Matthias van de Meent wrote:
> > Would you do anything different in the master branch, with no
> > compatibility constraints ? I think the progress reporting would still
> > be limited to one row per backend, not one per CopyFrom().
>
> I think I would
On Mon, May 06, 2024 at 10:51:08AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-06 12:37:26 -0500, Justin Pryzby wrote:
> > On Mon, May 06, 2024 at 10:04:13AM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2024-05-06 09:05:38 -0500, Justin
On Mon, May 06, 2024 at 10:04:13AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-06 09:05:38 -0500, Justin Pryzby wrote:
> > In March, I noticed that a backend got stuck overnight doing:
> >
> > backend_start| 2024-03-27 22:34:12.774195-07
> > xact_start
On Mon, May 06, 2024 at 06:34:16PM +0200, Alvaro Herrera wrote:
> On 2024-May-06, Justin Pryzby wrote:
>
> > > (Do you really want the partition to be
> > > created without the primary key already there?)
> >
> > Why not ? The PK will be added when I attach
On Mon, May 06, 2024 at 05:56:54PM +0200, Alvaro Herrera wrote:
> On 2024-May-04, Alvaro Herrera wrote:
> > On 2024-May-03, Justin Pryzby wrote:
> >
> > > But if it's created with LIKE:
> > > postgres=# CREATE TABLE t1 (LIKE t);
> > > postgres=#
In March, I noticed that a backend got stuck overnight doing:
backend_start| 2024-03-27 22:34:12.774195-07
xact_start | 2024-03-27 22:34:39.741933-07
query_start | 2024-03-27 22:34:41.997276-07
state_change | 2024-03-27 22:34:41.997307-07
wait_event_type | IO
wait_event
On another thread [0], Alexander Lakhin pointed out, indirectly, that
partitions created using LIKE+ATTACH now have different not-null constraints
from partitions created using PARTITION OF.
postgres=# CREATE TABLE t (i int PRIMARY KEY) PARTITION BY RANGE (i);
postgres=# CREATE TABLE t1 PARTITION
On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote:
> Hi!
>
> 30.04.2024 23:15, Justin Pryzby пишет:
> > Is this issue already fixed ?
> > I wasn't able to reproduce it. Maybe it only happened with earlier
> > patch versions applied ?
>
> I think this
On Thu, Apr 11, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote:
> 11.04.2024 16:27, Dmitry Koval wrote:
> >
> > Added correction (and test), see
> > v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch.
>
> Thank you for the correction, but may be an attempt to merge into implicit
On Tue, Apr 30, 2024 at 01:52:02PM -0400, Robert Haas wrote:
> On Thu, Apr 18, 2024 at 12:52 PM Justin Pryzby wrote:
> > I'm not totally clear on what's intended in v17 - maybe it'd be dead
> > code, and maybe it shouldn't even be applied to master branch. But I do
> > thin
I sent a list of user-facing elogs here, a few times.
ZDclRM/jate66...@telsasoft.com
And if someone had expressed an interest, I might have sent a longer
list.
On Sun, Apr 28, 2024 at 10:07:01AM +0800, Andy Fan wrote:
> 's/estimiatedcluases/estimatedclauses/' typo error in the
> commit message is not fixed since I have to regenerate all the commits
Maybe you know this, but some of these patches need to be squashed.
Regenerating the patches to address
On Sun, Apr 28, 2024 at 08:18:42AM -0500, Justin Pryzby wrote:
> > I will explore this. Do we copy extended stats when we do CREATE
> > TABLE ... PARTITION OF? I think we need to do the same here.
>
> Right, they're not copied because an extended stats objs on the paren
On Sun, Apr 28, 2024 at 04:04:54AM +0300, Alexander Korotkov wrote:
> Hi Justin,
>
> Thank you for your review. Please check v9 of the patchset [1].
>
> On Wed, Apr 24, 2024 at 11:26 PM Justin Pryzby wrote:
> > This patch also/already fixes the schema issue I reported. T
On Mon, Apr 22, 2024 at 01:31:48PM +0300, Alexander Korotkov wrote:
> Hi!
>
> On Fri, Apr 19, 2024 at 4:29 PM Alexander Korotkov
> wrote:
> > On Fri, Apr 19, 2024 at 2:26 AM Dmitry Koval wrote:
> > > 18.04.2024 19:00, Alexander Lakhin wrote:
> > > > leaves a strange constraint:
> > > > \d+ t*
On Fri, Apr 19, 2024 at 01:59:31PM +0200, Alvaro Herrera wrote:
> BTW because of a concern from Justin that the NO INHERIT stuff will
> cause errors in old server versions, I started to wonder if it wouldn't
> be better to add these constraints in a separate line for compatibility,
> so for
On Thu, Apr 11, 2024 at 10:20:53PM -0400, Robert Haas wrote:
> On Thu, Apr 11, 2024 at 9:54 PM Alexander Korotkov
> wrote:
> > I think we shouldn't unconditionally copy schema name and
> > relpersistence from the parent table. Instead we should throw the
> > error on a mismatch like CREATE
Here are some additional fixes to docs.
>From 6da8beaa5a2b78e785e5b6519894f8357002d916 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 18 Apr 2024 15:40:44 -0500
Subject: [PATCH] doc review for ALTER TABLE ... SPLIT/MERGE PARTITION
---
doc/src/sgml/ddl.sgml | 4 ++--
On Thu, Dec 14, 2017 at 08:51:06AM +0700, Ali Akbar wrote:
> Patch for adding check in pg_upgrade.
[...]
On Fri, Sep 29, 2023 at 11:36:42AM -0500, Justin Pryzby wrote:
> On Fri, Sep 29, 2023 at 09:16:35AM +0900, Michael Paquier wrote:
> > You mean when upgrading from an instance of
On Thu, Apr 18, 2024 at 06:23:30PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-18, Justin Pryzby wrote:
>
> > BTW, this works up to v16 (although maybe it should not):
> >
> > | CREATE TABLE ip(id int PRIMARY KEY); CREATE TABLE ic(id int) INHERITS
> > (ip); ALTER T
On Tue, Apr 16, 2024 at 08:11:49PM +0200, Alvaro Herrera wrote:
> This is still missing some cleanup and additional tests, of course.
> Speaking of which, I wonder if I should modify pg16's tests so that they
> leave behind tables set up in this way, to immortalize pg_upgrade
> testing.
That
On Tue, Apr 16, 2024 at 08:11:49PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-15, Alvaro Herrera wrote:
>
> > - Fourth thought: we do as in the third thought, except we also allow
> > DROP CONSTRAINT a constraint that's marked "local, inherited" to be
> > simply an inherited constraint (remove
On Mon, Apr 15, 2024 at 03:47:38PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-15, Justin Pryzby wrote:
>
> > I think there are other issues related to b0e96f3119 (Catalog not-null
> > constraints) - if I dump a v16 server using v17 tools, the backup can't
> > be restored i
On Wed, Apr 10, 2024 at 04:23:44PM -0500, Nathan Bossart wrote:
> The attached proof-of-concept patch demonstrates what I have in mind.
> Instead of trying to dynamically change the global process table, etc., I'm
> proposing that we introduce a new GUC that sets the effective maximum
> number of
Forking: <20230829172828.5qi2pfbladvfgvsg@alvherre.pgsql>
Subject: Re: Strange presentaion related to inheritance in \d+
On Tue, Aug 29, 2023 at 07:28:28PM +0200, Alvaro Herrera wrote:
> On 2023-Aug-29, Kyotaro Horiguchi wrote:
>
> > Attached is the initial version of the patch. It prevents
On Tue, Apr 02, 2024 at 04:23:45PM +0800, Andy Fan wrote:
>
> 0001 is your patch, I just rebase them against the current master. 0006
> is not much relevant with current patch, and I think it can be committed
> individually if you are OK with that.
Your 002 should also remove listidx to avoid
On Mon, Apr 08, 2024 at 01:34:37AM +0300, Alexander Korotkov wrote:
> Hi!
>
> On Mon, Apr 1, 2024 at 9:38 AM Andrei Lepikhov
> wrote:
> > On 28/3/2024 16:54, Alexander Korotkov wrote:
> > > The current patch has a boolean guc enable_or_transformation.
> > > However, when we have just a few ORs
On Sun, Mar 31, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
> Hello Alvaro,
>
> 28.03.2024 18:58, Alvaro Herrera wrote:
> > Grumble. I don't like initialization at declare time, so far from the
> > code that depends on the value. But the alternative would have been to
> > assign right
On Thu, Mar 21, 2024 at 01:07:01PM +0100, Alvaro Herrera wrote:
> Given that Michaël is temporarily gone, I propose to push the attached
> tomorrow.
Thanks.
On Tue, Mar 26, 2024 at 12:05:47PM +0100, Alvaro Herrera wrote:
> On 2024-Mar-26, Alexander Lakhin wrote:
>
> > Hello Alvaro,
> >
> >
39a59dd99b292014b73be85342
ebfe2dbd6b624e2a428e14b7ee9322cc096f63f7 - prevent DROP AM
Authors: Justin Pryzby, Soumyadeep Chakraborty
---
doc/src/sgml/catalogs.sgml | 5 +-
doc/src/sgml/ref/alter_table.sgml | 8 ++
doc/src/sgml/ref/create_table.sgml | 4 +
src/backend/
On Fri, Mar 01, 2024 at 10:56:50AM +0900, Michael Paquier wrote:
> On Thu, Feb 29, 2024 at 08:51:31AM -0600, Justin Pryzby wrote:
> > On Wed, Feb 28, 2024 at 05:08:49PM +0900, Michael Paquier wrote:
> >> I have implemented that so as we keep the default, historical
> >>
On Wed, Feb 28, 2024 at 05:08:49PM +0900, Michael Paquier wrote:
> On Wed, Feb 21, 2024 at 08:46:48AM +0100, Peter Eisentraut wrote:
> > Yes, I think most people agreed that that would be the preferred behavior.
>
> Challenge accepted. As of the patch attached.
Thanks for picking it up. I find
On Wed, Feb 14, 2024 at 03:37:03AM +, Hayato Kuroda (Fujitsu) wrote:
> Attached patch modified the test accordingly. Also, it contains some
> optimizations.
> This can pass the test on my env:
What optimizations? I can't see them, and since the patch is described
as rearranging test cases
On Tue, Jan 02, 2024 at 03:58:25PM +0530, Amit Kapila wrote:
> Pushed.
pg_upgrade/t/004_subscription.pl says
|my $mode = $ENV{PG_TEST_PG_UPGRADE_MODE} || '--copy';
..but I think maybe it should not.
When you try to use --link, it fails:
https://cirrus-ci.com/task/4669494061170688
|Adding
ch cf and set it WoA, I'd appreciate
> that.
The patches are rebased. A couple were merged since I last rebased them
~10 months ago. The freebsd patch will probably be obsoleted by a patch
of Thomas.
On Mon, Mar 13, 2023 at 07:39:52AM +0100, Peter Eisentraut wrote:
> On 03.02.23 15:26, Justin Pry
Up to now, the explain " " (two space) format is not mixed with "=".
And, other places which show "Memory" do not use "=". David will
remember prior discussions.
https://www.postgresql.org/message-id/20200402054120.gc14...@telsasoft.com
On Wed, Dec 27, 2023 at 09:02:25AM -0600, Justin Pryzby wrote:
> We had this:
>
> < 2023-12-25 04:06:20.062 MST telsasoft >ERROR: could not open file
> "pg_tblspc/16395/PG_16_202307071/16384/121010871": Input/output error
> < 2023-12-25 04:06:20.062 MST telsaso
On Fri, Jul 22, 2022 at 03:26:47PM -0400, Tom Lane wrote:
> Hmph. I wonder if we shouldn't change that, because it's a lie.
> The value isn't actually coming from the config file, at least
> not yet.
On Thu, Jul 06, 2023 at 03:15:20PM -0500, Justin Pryzby wrote:
> On Sat, Oct 29, 2
On Thu, Dec 28, 2023 at 11:33:16AM +1300, Thomas Munro wrote:
> I guess the large object usage isn't directly relevant (that module's
> EOXact stuff seems to be finished before TRANS_COMMIT, but I don't
> know that code well). Everything later is supposed to be about
> closing/releasing/cleaning
We had this:
< 2023-12-25 04:06:20.062 MST telsasoft >ERROR: could not open file
"pg_tblspc/16395/PG_16_202307071/16384/121010871": Input/output error
< 2023-12-25 04:06:20.062 MST telsasoft >STATEMENT: commit
< 2023-12-25 04:06:20.062 MST telsasoft >WARNING: AbortTransaction while in
COMMIT
If postgres starts, and one of its children is immediately killed, and
the cluster is also told to stop, then, instead, the whole system gets
wedged.
$ initdb -D ./pgdev.dat1
$ pg_ctl -D ./pgdev.dat1 start -o '-c port=5678'
$ kill -9 2524495; sleep 0.05; pg_ctl -D ./pgdev.dat1 stop -m fast #
@cfbot: rebased
>From a9bb61421c24bd3273a8519362febb4073c297a1 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 21 Jun 2022 22:28:06 -0500
Subject: [PATCH v4] WIP: use BulkInsertState for toast tuples, too
DONE: ALTER, CLUSTER
TODO: copyto, copyfrom?
slot_getsomeat
I found this in our logs, and reproduced it under v11-v16.
CREATE TABLE t(a int, b int);
INSERT INTO t SELECT generate_series(1,999);
CREATE STATISTICS t_stats ON a,b FROM t;
while :; do psql postgres -qtxc "ANALYZE t"; done &
while :; do psql postgres -qtxc "begin; DROP STATISTICS t_stats";
On Fri, Oct 06, 2023 at 08:47:39AM -0700, Andres Freund wrote:
> Hi,
>
> On 2023-10-06 09:20:05 +0900, Michael Paquier wrote:
> > On Thu, Oct 05, 2023 at 11:45:18AM -0500, Justin Pryzby wrote:
> > > This table is what it sounds like: a partition into which CSV logs are
>
On Fri, Oct 06, 2023 at 09:20:05AM +0900, Michael Paquier wrote:
> On Thu, Oct 05, 2023 at 11:45:18AM -0500, Justin Pryzby wrote:
> > This table is what it sounds like: a partition into which CSV logs are
> > COPY'ed. It would've been created around 8am. There's no special
On Thu, Oct 05, 2023 at 07:16:31PM +0200, Matthias van de Meent wrote:
> On Thu, 5 Oct 2023 at 18:48, Justin Pryzby wrote:
> >
> > On an instance running pg16.0:
> >
> > log_time | 2023-10-05 10:03:00.014-05
> > backend_type | autovacuum worker
> &g
On an instance running pg16.0:
log_time | 2023-10-05 10:03:00.014-05
backend_type | autovacuum worker
left | page verification failed, calculated checksum 5074 but
expected 5050
context | while scanning block 119 of relation
"public.postgres_log_2023_10_05_0900"
On Fri, Sep 29, 2023 at 09:16:35AM +0900, Michael Paquier wrote:
> You mean when upgrading from an instance of 9.6 or older as c30f177 is
> not there, right?
No - while upgrading from v15 to v16. I'm not clear on how we upgraded
*to* v15 without hitting the issue, nor how the "not null" got
On Thu, Dec 14, 2017 at 07:18:59PM +0700, Ali Akbar wrote:
> By the way, should i add this patch to the current commitfest?
The patch for pg_upgrade --check got forgotten 6 years ago, but it's a
continuing problem (we hit it again which cost an hour during
pg_upgrade) and ought to be (have been)
This fails since 1349d2790b
commit 1349d2790bf48a4de072931c722f39337e72055e
Author: David Rowley
Date: Tue Aug 2 23:11:45 2022 +1200
Improve performance of ORDER BY / DISTINCT aggregates
ts=# CREATE TABLE t (a int, b text) PARTITION BY RANGE (a);
ts=# CREATE TABLE td PARTITION OF t
On Fri, Sep 01, 2023 at 11:08:51AM -0700, Nathan Bossart wrote:
> > This should probably give a distinct error when syncfs is not supported
> > than when it's truely recognized.
>
> Later versions of the patch should have this.
Oops, right.
> > The patch should handle pg_dumpall, too.
>
> It
> + if (!user_opts.sync_method)
> + user_opts.sync_method = pg_strdup("fsync");
why pstrdup?
> +parse_sync_method(const char *optarg, SyncMethod *sync_method)
> +{
> + if (strcmp(optarg, "fsync") == 0)
> + *sync_method = SYNC_METHOD_FSYNC;
> +#ifdef HAVE_SYNCFS
>
On Thu, Dec 15, 2022 at 10:13:23AM -0600, Justin Pryzby wrote:
> This patch record was "closed for lack of interest", but I think what's
> actually needed is committer review of which approach to take.
On Tue, Aug 01, 2023 at 09:54:34AM +0200, Daniel Gustafsson wrote:
> > On
Since 3d351d916 (pg14), reltuples -1 means that the rel has never been
vacuumed nor analyzed.
But since 4496020e6d (backpatched to pg15), following pg_upgrade, vacuum
can leave reltuples=-1.
commit 4496020e6dfaffe8217e4d3f85567bb2b6927b45
Author: Peter Geoghegan
Date: Fri Aug 19 09:26:06 2022
A production instance crashed like so.
< 2023-07-20 05:41:36.557 MDT >LOG: server process (PID 106001) was
terminated by signal 11: Segmentation fault
[168417.649549] postmaster[106001]: segfault at 12 ip 008f1d40 sp
7ffe885502e0 error 4 in postgres[40+7dc000]
Core was
On Thu, Jun 01, 2023 at 08:50:50AM -0400, Michael Paquier wrote:
> On Wed, May 31, 2023 at 06:35:34PM -0500, Justin Pryzby wrote:
> > What do you think the comment ought to say ? It already says:
> >
> > src/backend/catalog/heap.c- * Make a dependency link to fo
at it's possible for it to be conditional, but I don't
undertand why it's desirable/important ?
It still seems preferable to be unconditional.
On Wed, May 31, 2023 at 06:35:34PM -0500, Justin Pryzby wrote:
>> Why is that desirable ? I'd prefer to see it written with fewer
>> con
On Mon, Mar 27, 2023 at 01:28:24PM +0300, Alexander Pyhalov wrote:
> Justin Pryzby писал 2023-03-26 17:51:
> > On Sun, Dec 04, 2022 at 01:09:35PM -0600, Justin Pryzby wrote:
> > > This currently handles partitions with a loop around the whole CIC
> > > implementation, w
On Mon, Jul 10, 2023 at 09:01:37PM -0500, Justin Pryzby wrote:
> An instance compiled locally, without assertions, failed like this:
>
...
>
> => REINDEX was running, with parallel workers, but deadlocked with
> ANALYZE, and then crashed.
>
> It looks like parallel w
On Tue, Jan 17, 2023 at 11:35:09AM -0600, Justin Pryzby wrote:
> However, this finds two real problems and one false-positive with
> missing regress/isolation tests:
>
> $ for makefile in `find src contrib -name Makefile`; do for testname in `sed
> -r '/^(REGRESS|ISOLATION)
An instance compiled locally, without assertions, failed like this:
< 2023-07-09 22:04:46.470 UTC >LOG: process 30002 detected deadlock while
waiting for ShareLock on transaction 813219577 after 333.228 ms
< 2023-07-09 22:04:46.470 UTC >DETAIL: Process holding the lock: 2103. Wait
queue:
On Sat, Oct 29, 2022 at 10:40 AM Justin Pryzby wrote:
> > > > On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> > > > > It caused no issue when I changed:
> > > > >
> > > > > /* Check th
er?
It seems like you misread the assertion, so I added a comment about it.
Indeed, the assertion addresses the other question you asked later.
That's what I already commented about, and the reason I found it
compelling not to use a boolean.
On Thu, Apr 06, 2023 at 04:57:58PM -0500, Justin Pryzby wrote:
hits the same path every time.
This ought to address your other comments.
--
Justin
>From a726bd7ca8844f6eee639d672afa7edace329caf Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sun, 7 Mar 2021 00:11:38 -0600
Subject: [PATCH] Allow specifying access method of partitioned tables..
..to be
rom 917e5e36d14018b6de457ba9eafe8936c0e88c3c Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subject: [PATCH 1/4] Add pg_am_size(), pg_namespace_size() ..
See also: 358a897fa, 528ac10c7
---
doc/src/sgml/func.sgml | 39 ++
src/backend/utils/adt/dbsize.c |
On Wed, Mar 29, 2023 at 11:03:59PM -0500, Justin Pryzby wrote:
> On Wed, Jul 13, 2022 at 04:49:00PM -0700, Andres Freund wrote:
> > On 2022-07-14 08:46:02 +0900, Michael Paquier wrote:
> > > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > &
On Sun, Apr 30, 2023 at 06:35:30PM +1200, Thomas Munro wrote:
> On Sun, Apr 30, 2023 at 4:11 PM Noah Misch wrote:
> > Speaking of the developer-only status, I find the io_direct name more
> > enticing
> > than force_parallel_mode, which PostgreSQL renamed due to overuse from
> > people
> >
On Thu, Mar 30, 2023 at 12:07:58AM -0500, Justin Pryzby wrote:
> On Mon, Mar 27, 2023 at 11:34:36PM -0500, Justin Pryzby wrote:
> > On Tue, Mar 28, 2023 at 09:13:10AM +0900, Michael Paquier wrote:
> > > On Mon, Mar 20, 2023 at 09:30:50AM +0900, Michael Paquier wrote:
> >
On Wed, Apr 19, 2023 at 08:47:07PM -0400, Melanie Plageman wrote:
> On Wed, Apr 19, 2023 at 8:41 PM Justin Pryzby wrote:
> >
> > On Wed, Apr 19, 2023 at 12:20:51PM -0700, Andres Freund wrote:
> > > On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> > > > On W
On Wed, Apr 19, 2023 at 12:20:51PM -0700, Andres Freund wrote:
> On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> > On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> > > Ultimately this is probably fine. If we wanted to modify one of the
> > &
On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> Ultimately this is probably fine. If we wanted to modify one of the
> existing tests to cover the multi-batch case, changing the select
> count(*) to a select * would do the trick. I imagine we wouldn't want to
> do this because
On Tue, Apr 18, 2023 at 02:06:43PM +1200, David Rowley wrote:
> On Tue, 18 Apr 2023 at 10:10, Justin Pryzby wrote:
> > > - * USER SET values are appliciable only for PGC_USERSET
> > > parameters. We
> > > + * USER SET values are a
On Mon, Apr 17, 2023 at 09:00:00PM +0300, Alexander Lakhin wrote:
> Hello hackers,
>
> Please consider fixing the following unique words/identifiers introduced in
> v16:
Well done.
Note that your patches are overlapping:
3 --- a/src/backend/utils/misc/guc.c
2 ---
On Mon, Apr 17, 2023 at 01:50:30PM -0400, Tom Lane wrote:
> I wrote:
> > Yeah, I just came to the same conclusion. One thing I don't understand
> > yet: log_newpage_range is old (it looks like this back to v12), and
> > that Assert is older, so why doesn't this reproduce further back?
> > Maybe
I hit this assertion while pg_restoring data into a v16 instance.
postgresql16-server-16-alpha_20230417_PGDG.rhel7.x86_64
wal_level=minimal and pg_dump --single-transaction both seem to be
required to hit the issue.
$ /usr/pgsql-16/bin/postgres -D ./pg16test -c maintenance_work_mem=1GB -c
On Wed, Apr 05, 2023 at 09:33:25AM +0200, Peter Eisentraut wrote:
> On 16.03.23 14:52, Peter Eisentraut wrote:
> > On 09.03.23 20:14, Jeff Davis wrote:
> > > > Let's come back to that after dealing with the other two.
> > >
> > > Leaving 0001 open for now.
> >
> > I suspect making a change like
On Sun, Apr 16, 2023 at 10:14:35PM +1200, David Rowley wrote:
> I was just looking at the vacuumdb docs and noticed that I had
> neglected to follow the tradition of adding a note to mention which
> version we added the new option in when I committed the
> --buffer-usage-limit patch.
>
> There
On Sat, Apr 15, 2023 at 11:33:58AM +1200, David Rowley wrote:
> On Sat, 15 Apr 2023 at 10:48, Justin Pryzby wrote:
> >
> > On Sat, Apr 15, 2023 at 10:04:52AM +1200, David Rowley wrote:
> > > Which aggregate function is being called here? Is it a custom
> > > aggr
On Sat, Apr 15, 2023 at 02:19:35PM -0400, Tom Lane wrote:
> PS: I don't quite understand how it managed to get through initdb
> when CREATE DATABASE doesn't work. Maybe there is a different
> code path taken in standalone mode?
ad43a413c4f7f5d024a5b2f51e00d280a22f1874
initdb: When running
On Thu, Apr 13, 2023 at 09:14:01PM -0700, Peter Geoghegan wrote:
> I find that if I run the following test against a standard debug build
> on HEAD, my local installation reliably segfaults:
>
> $ meson test --setup running --suite test_rls_hooks-running
>
> Attached is a "bt full" run from gdb
Maybe you'll find valgrind errors to be helpful.
==17971== Source and destination overlap in memcpy(0x1eb8c078, 0x1d88cb20,
123876054)
==17971==at 0x4C2E81D: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1035)
==17971==by 0x9C705A: memcpy (string3.h:51)
==17971==by 0x9C705A:
On Sat, Apr 15, 2023 at 10:04:52AM +1200, David Rowley wrote:
> On Sat, 15 Apr 2023 at 08:36, Justin Pryzby wrote:
> >
> > I hit this elog() while testing reports under v16 and changed to PANIC
> > to help diagnose.
> >
> > DETAILS: PANIC: invalid memory alloc
I hit this elog() while testing reports under v16 and changed to PANIC
to help diagnose.
DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
CONTEXT: PL/pgSQL function array_weight(real[],real[]) while storing call
arguments into local variables
I can't share the query,
On Thu, Apr 13, 2023 at 09:37:06AM +0900, Michael Paquier wrote:
> > If you don't insist on calling parse(NONE), the only change is to remove
> > the empty #else, which was my original patch.
>
> Removing the empty else has as problem to create an empty if block,
> which could be itself a cause
On Thu, Apr 13, 2023 at 07:23:48AM +0900, Michael Paquier wrote:
> On Tue, Apr 11, 2023 at 08:19:59PM -0500, Justin Pryzby wrote:
> > On Wed, Apr 12, 2023 at 10:07:08AM +0900, Michael Paquier wrote:
> >> Yes, this comment gives no value as it stands. I would be temp
On Mon, Feb 13, 2023 at 07:50:53AM -0600, Justin Pryzby wrote:
> On Thu, May 13, 2021 at 12:01:22PM -0500, Justin Pryzby wrote:
> > postgres=# select amvalidate(123);
> > ERROR: cache lookup failed for operator class 123
> > The usual expectation is that sql callable functio
On Fri, Mar 24, 2023 at 10:46:37AM -0400, Robert Haas wrote:
> On Thu, Mar 23, 2023 at 4:11 PM Robert Haas wrote:
> > On Wed, Mar 22, 2023 at 10:09 PM Thomas Munro
> > wrote:
> > > > BaseBackupSync is not documented
> > > > BaseBackupWrite is not documented
> > >
> > > [Resending with trimmed
On Wed, Apr 12, 2023 at 12:28:25PM +0900, Michael Paquier wrote:
> On Tue, Apr 11, 2023 at 11:12:58PM +0200, Daniel Gustafsson wrote:
> > > On 11 Apr 2023, at 16:53, Justin Pryzby wrote:
> >
> > > I think "logical" should be a here.
> >
>
On Wed, Apr 12, 2023 at 11:49:51AM +1200, Thomas Munro wrote:
> On Wed, Apr 12, 2023 at 11:37 AM Justin Pryzby wrote:
> > $ ls /dev/shm/ |grep 3696856876 || echo not found
> > not found
>
> Oh, of course it would have restarted after it crashed and unlinked
> that...
On Tue, Apr 11, 2023 at 06:09:41PM -0700, Ajay P S wrote:
> I am trying to understand the Plan tree for select queries. Can you
> please help me with the below queries?
>
> 1) Why is there a difference in plan tree for these two queries? User
> table tidx1 has an index on column 'a' .
Based on
> configure | 27 ++
> configure.ac | 2 +
Does meson.build need the corresponding change ?
On Wed, Apr 12, 2023 at 10:07:08AM +0900, Michael Paquier wrote:
> On Tue, Apr 11, 2023 at 07:41:11PM -0500, Justin Pryzby wrote:
> > Maybe I would write it as: "if zlib is unavailable, default to no
> > compression". But I think that's best done in the leading co
On Wed, Mar 15, 2023 at 04:57:34PM +0100, Peter Eisentraut wrote:
> On 15.03.23 15:56, Justin Pryzby wrote:
> > I'm surprised if there's any question about the merits of making
> > documentation easily available for review. Several people have agreed;
> > one perso
1 - 100 of 2593 matches
Mail list logo
