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
On Mon, Feb 27, 2023 at 02:33:04PM +, gkokola...@pm.me wrote:
> > > - Finally, the "Nothing to do in the default case" comment comes from
> > > Michael's commit 5e73a6048:
> > >
> > > + /*
> > > + * Custom and directory formats are compressed by default with gzip when
> > > + * available, not
On Wed, Apr 12, 2023 at 11:18:36AM +1200, Thomas Munro wrote:
> Can you print *area->control?
(gdb) p *area->control
$1 = {segment_header = {magic = 216163848, usable_pages = 62, size = 1048576,
prev = 1, next = 18446744073709551615, bin = 4, freed = false}, handle = 0,
segment_handles = {0,
On Tue, Apr 11, 2023 at 09:53:00AM -0500, Justin Pryzby wrote:
> On Tue, Apr 11, 2023 at 03:43:12PM +0100, Thom Brown wrote:
> > On Tue, 11 Apr 2023 at 15:39, Justin Pryzby wrote:
> > >
> > > On Tue, Apr 11, 2023 at 03:36:02PM +0100, Thom Brown wrote:
> > > >
Yes, $SUBJECT is correct.
On an old centos6 VM which I'd forgotten about and never removed from
monitoring, I noticed that a process had recently crashed...
Maybe this is an issue which was already fixed, but I looked and find no
bug report nor patch about it. Feel free to dismiss the problem
On Wed, Mar 22, 2023 at 10:00:48AM -0700, Andres Freund wrote:
> I don't know whether others think we should apply it this release, given the
> "late submission", but I tend to think it's not worth caring the complication
> of vacuum_defer_cleanup_age forward.
I don't see any utility in waiting;
On Tue, Apr 11, 2023 at 03:43:12PM +0100, Thom Brown wrote:
> On Tue, 11 Apr 2023 at 15:39, Justin Pryzby wrote:
> >
> > On Tue, Apr 11, 2023 at 03:36:02PM +0100, Thom Brown wrote:
> > > I've attached a patch with a few typo and grammatical fixes.
> >
> > I t
On Tue, Apr 11, 2023 at 03:36:02PM +0100, Thom Brown wrote:
> I've attached a patch with a few typo and grammatical fixes.
I think you actually sent the "git-diff" manpage :(
--
Justin
Reduced from sqlsmith, this query fails under debug_parallel_query=1.
The elog was added at: 55416b26a98fcf354af88cdd27fc2e045453b68a
But (I'm not sure) the faulty commit may be 8edd0e7946 (Suppress Append
and MergeAppend plan nodes that have a single child).
postgres=# SET force_parallel_mode
On Fri, Apr 07, 2023 at 04:14:13AM +0200, Alvaro Herrera wrote:
> On 2023-Apr-06, Justin Pryzby wrote:
> > +ERROR: relation "c" already exists
>
> Do you intend to make an error here ?
These still look like mistakes in the tests.
> Also, I think these ta
On Tue, Mar 28, 2023 at 09:35:30AM +0900, Michael Paquier wrote:
> On Thu, Mar 23, 2023 at 08:50:50PM -0500, Justin Pryzby wrote:
>
> You mean that you abused of it in some custom branch running the CI on
> github? If I may ask, what did you do to make sure that huge pages
>
+VACUUM uses a ring like sequential scans, however, the size this ring
+controlled by the vacuum_buffer_usage_limit GUC. Dirty pages are not removed
should say: ".. the size OF this ring IS .." ?
On Thu, Apr 06, 2023 at 01:33:56AM +0200, Alvaro Herrera wrote:
> - The forms ADD (without USING INDEX),
> + The forms ADD (without USING INDEX,
> and
> + except for the NOT NULL
> column_name
> + form to add a table constraint),
The "except" part seems pretty incoherent to me :(
> +
On Tue, Mar 14, 2023 at 12:16:16AM +0100, Tomas Vondra wrote:
> On 3/9/23 19:00, Tomas Vondra wrote:
> > On 3/9/23 01:30, Michael Paquier wrote:
> >> On Thu, Mar 09, 2023 at 12:39:08AM +0100, Tomas Vondra wrote:
> >>> IMO we should fix that. We have a bunch of buildfarm members running on
> >>>
On Thu, Apr 06, 2023 at 05:34:30PM +0200, Tomas Vondra wrote:
> I looked at the long mode patch again, updated the commit message and
> pushed it. I was wondering if long_mode should really be bool -
> logically it is, but ZSTD_CCtx_setParameter() expects int. But I think
> that's fine.
Thanks!
On Mon, Apr 03, 2023 at 11:26:09PM +0200, Tomas Vondra wrote:
> On 4/3/23 21:17, Justin Pryzby wrote:
> > On Sat, Apr 01, 2023 at 10:26:01PM +0200, Tomas Vondra wrote:
> >>> Feel free to mess around with threads (but I'd much rather see the patch
> >>> prog
On Sat, Apr 01, 2023 at 10:26:01PM +0200, Tomas Vondra wrote:
> > Feel free to mess around with threads (but I'd much rather see the patch
> > progress for zstd:long).
>
> OK, understood. The long mode patch is pretty simple. IIUC it does not
> change the format, i.e. in the worst case we could
On Mon, Mar 06, 2023 at 01:24:56PM +0100, Daniel Gustafsson wrote:
> > On 27 Jan 2023, at 15:00, Mikhail Gribkov wrote:
>
> > There is a complete framework for disabling various types of the event
> > triggers separately, but, the list of valid GUC values only include 'all'
> > and 'none'. Why
On Sat, Apr 01, 2023 at 01:29:13PM -0400, Melanie Plageman wrote:
> Hi,
>
> I was just doing some cleanup on the main patch in this set and realized
> that it was missing a few things. One of which is forbidding the
> BUFFER_USAGE_LIMIT with VACUUM FULL since VACUUM FULL does not use a
>
On Sat, Apr 01, 2023 at 02:49:44PM +0200, Tomas Vondra wrote:
> On 4/1/23 02:28, Justin Pryzby wrote:
> > On Sat, Apr 01, 2023 at 02:11:12AM +0200, Tomas Vondra wrote:
> >> On 4/1/23 01:16, Justin Pryzby wrote:
> >>> On Tue, Mar 28, 2023 at 06:23:26PM +0200, Tomas V
On Sat, Apr 01, 2023 at 02:11:12AM +0200, Tomas Vondra wrote:
> On 4/1/23 01:16, Justin Pryzby wrote:
> > On Tue, Mar 28, 2023 at 06:23:26PM +0200, Tomas Vondra wrote:
> >> On 3/27/23 19:28, Justin Pryzby wrote:
> >>> On Fri, Mar 17, 2023 at 03:43:31AM +0100, Tomas V
On Sat, Apr 01, 2023 at 01:05:19PM +1300, David Rowley wrote:
> Attached is what I propose in .diff form so that the CFbot can run on
> your v7 patches without picking this up.
But it processes .diff, too
https://wiki.postgresql.org/wiki/Cfbot#Which_attachments_are_considered_to_be_patches.3F
1 - 100 of 2572 matches
Mail list logo
