On 2023-07-24 12:01, Bharath Rupireddy wrote:
I'm attaching the v3 patch.
I verified it works and it looks good to me.
Thanks to your work, I will be able to implement tests for
custom wait events.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
On Mon, Jul 24, 2023 at 08:31:01AM +0530, Bharath Rupireddy wrote:
> I also added a note atop worker_spi.c that the module also
> demonstrates how to write core (SQL) tests and extended (TAP) tests.
The value of the SQL tests comes down to the DO blocks that emulate
what the TAP tests could equall
On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> After some research, found this happens when the LimitAdditionalPins()
> returns exactly zero.
> In the current master, this will happen e.g. if shared_buffers = 10MB and
> max_worker_processes = 40.
> Then the command "pgbench
On Mon, Jul 24, 2023 at 1:10 PM Michael Paquier wrote:
>
> On Mon, Jul 24, 2023 at 08:31:01AM +0530, Bharath Rupireddy wrote:
> > I also added a note atop worker_spi.c that the module also
> > demonstrates how to write core (SQL) tests and extended (TAP) tests.
>
> In terms of runtime the benefits
On Mon, Jul 24, 2023 at 01:50:45PM +0530, Bharath Rupireddy wrote:
> I disagree with removing SQL tests from the worker_spi module. As said
> upthread, it makes the worker_spi a fully demonstrable
> extension/module - one can just take it, start adding required
> functionality and test-cases (both
On Thu, 20 Jul 2023 at 16:31, Alvaro Herrera wrote:
>
> On 2023-Jul-13, Dean Rasheed wrote:
>
> > I see that it's already been discussed, but I don't like the fact that
> > there is no way to get hold of the new constraint names in psql. I
> > think for the purposes of dropping named constraints,
On 24.07.2023 09:42, Pavel Luzanov wrote:
Is IS_GRANTABLE a key column for ROLE_AUTHORIZATION_DESCRIPTORS?
If not, duplicates is not possible. Right?
The answer is: no.
Duplicate pairs (grantee, role_name) is impossible only with defined key
with this two columns.
If there is no such key or k
On 7/24/23 04:10, Andrey Lepikhov wrote:
> On 20/7/2023 18:46, Tomas Vondra wrote:
>> On 7/20/23 08:37, Andrey Lepikhov wrote:
>>> On 3/10/2022 21:56, Tom Lane wrote:
Revert "Optimize order of GROUP BY keys".
This reverts commit db0d67db2401eb6238ccc04c6407a4fd4f985832 and
sever
On Thu, 20 Jul 2023 at 16:31, Alvaro Herrera wrote:
>
> On 2023-Jul-13, Dean Rasheed wrote:
>
> > Something else I noticed is that the result from "ALTER TABLE ...
> > ALTER COLUMN ... DROP NOT NULL" is no longer easily predictable -- if
> > there are multiple NOT NULL constraints on the column, i
Something else I noticed: the error message from ALTER TABLE ... ADD
CONSTRAINT in the case of a duplicate constraint name is not very
friendly:
ERROR: duplicate key value violates unique constraint
"pg_constraint_conrelid_contypid_conname_index"
DETAIL: Key (conrelid, contypid, conname)=(16540,
On Mon, Jul 24, 2023 at 12:01 PM Amit Kapila wrote:
>
> On Thu, Jul 20, 2023 at 8:22 PM Tomas Vondra
> wrote:
> >
> > OK, I merged the changes into the patches, with some minor changes to
> > the wording etc.
> >
>
> I think we can do 0001-Make-test_decoding-ddl.out-shorter-20230720
> even withou
On 2023-Jul-24, Dean Rasheed wrote:
> Hmm, I don't particularly like that approach, because I think it will
> be difficult to cram any additional details into the table, and also I
> don't know whether having multiple not null constraints for a
> particular column can be entirely ruled out.
>
> I
On Fri, Jul 21, 2023 at 10:42 AM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > Please see attached the patch that does this. Let me know if this patch
> > helps.
>
> I don't like this patch one bit, because it adds a lot of overhead
> (i.e., an extra index_open/close cycle for every btree index
On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
wrote:
>
> 0005, 0006 and 0007 are all related to the initial sequence sync. [3]
> resulted in 0007 and I think we need it. That leaves 0005 and 0006 to
> be reviewed in this response.
>
> I followed the discussion starting [1] till [2]. The second one
On 7/24/23 12:40, Amit Kapila wrote:
> On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
> wrote:
>>
>> 0005, 0006 and 0007 are all related to the initial sequence sync. [3]
>> resulted in 0007 and I think we need it. That leaves 0005 and 0006 to
>> be reviewed in this response.
>>
>> I followed th
On 7/24/23 08:31, Amit Kapila wrote:
> On Thu, Jul 20, 2023 at 8:22 PM Tomas Vondra
> wrote:
>>
>> OK, I merged the changes into the patches, with some minor changes to
>> the wording etc.
>>
>
> I think we can do 0001-Make-test_decoding-ddl.out-shorter-20230720
> even without the rest of the
On 2023-Jul-24, Dean Rasheed wrote:
> Hmm, I'm not so sure. I think perhaps multiple NOT NULL constraints on
> the same column should just be allowed, otherwise things might get
> confusing. For example:
>
create table p1 (a int not null check (a > 0));
create table p2 (a int not null check (a
On 2023-Jul-20, Tomas Vondra wrote:
> From 809d60be7e636b8505027ad87bcb9fc65224c47b Mon Sep 17 00:00:00 2001
> From: Tomas Vondra
> Date: Wed, 5 Apr 2023 22:49:41 +0200
> Subject: [PATCH 1/6] Make test_decoding ddl.out shorter
>
> Some of the test_decoding test output was extremely wide, because
On 24/7/2023 16:56, Tomas Vondra wrote:
On 7/24/23 04:10, Andrey Lepikhov wrote:
On 20/7/2023 18:46, Tomas Vondra wrote:
On 7/20/23 08:37, Andrey Lepikhov wrote:
On 3/10/2022 21:56, Tom Lane wrote:
Revert "Optimize order of GROUP BY keys".
This reverts commit db0d67db2401eb6238ccc04c6407a4fd
On Sat, Jul 22, 2023 at 10:18 AM Amit Kapila wrote:
> >
> > I think it could confuse us if an invalid message is not a printable
> > character.
> >
>
That's a good point.
> Right. I'll push and backpatch this till 15 by Tuesday unless you guys
> think otherwise.
WFM.
--
Best Wishes,
Ashutos
On Thu, Jul 20, 2023 at 8:22 PM Tomas Vondra
wrote:
> >
> > PFA such edits in 0002 and 0006 patches. Let me know if those look
> > correct. I think we
> > need similar changes to the documentation and comments in other places.
> >
>
> OK, I merged the changes into the patches, with some minor cha
On 7/24/23 13:14, Alvaro Herrera wrote:
> On 2023-Jul-20, Tomas Vondra wrote:
>
>> From 809d60be7e636b8505027ad87bcb9fc65224c47b Mon Sep 17 00:00:00 2001
>> From: Tomas Vondra
>> Date: Wed, 5 Apr 2023 22:49:41 +0200
>> Subject: [PATCH 1/6] Make test_decoding ddl.out shorter
>>
>> Some of the t
On Thu, Jul 20, 2023 at 10:19 PM Tomas Vondra
wrote:
>
> FWIW there's two questions related to the switch to XLOG_SMGR_CREATE.
>
> 1) Does smgr_decode() need to do the same block as sequence_decode()?
>
> /* Skip the change if already processed (per the snapshot). */
> if (transactional &&
On 7/24/23 14:04, Andrey Lepikhov wrote:
> On 24/7/2023 16:56, Tomas Vondra wrote:
>> On 7/24/23 04:10, Andrey Lepikhov wrote:
>>> On 20/7/2023 18:46, Tomas Vondra wrote:
On 7/20/23 08:37, Andrey Lepikhov wrote:
> On 3/10/2022 21:56, Tom Lane wrote:
>> Revert "Optimize order of GROU
Michael,
Once again I appreciate your patience with this patchset. Thanks for
your help and reviews.
--
Tristan Partin
Neon (https://neon.tech)
On 2023-Jul-24, Michael Paquier wrote:
> On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> > After some research, found this happens when the LimitAdditionalPins()
> > returns exactly zero.
> > In the current master, this will happen e.g. if shared_buffers = 10MB and
> > max_w
hi.
I am confused with bt_recheck_sibling_links.
>
> ereport(ERROR,
> (errcode(ERRCODE_INDEX_CORRUPTED),
> errmsg("left link/right link pair in index \"%s\" not in agreement",
> RelationGetRelationName(state->rel)),
> errdetail_internal("Block=%u left block=%u left link from block=%u.",
> state
On 2023-Jul-20, Andrew Dunstan wrote:
> On 2023-07-20 Th 05:52, Alvaro Herrera wrote:
> > On 2023-Jul-19, Andrew Dunstan wrote:
> >
> > > The result you report suggest to me that somehow the old version is no
> > > longer a PostgreSQL::Version object. Here's the patch I suggest:
> > Ahh, okay, t
On 7/24/23 14:53, Ashutosh Bapat wrote:
> On Thu, Jul 20, 2023 at 8:22 PM Tomas Vondra
> wrote:
>
>>>
>>> PFA such edits in 0002 and 0006 patches. Let me know if those look
>>> correct. I think we
>>> need similar changes to the documentation and comments in other places.
>>>
>>
>> OK, I merge
On 2023-Jul-24, Tomas Vondra wrote:
> On 7/24/23 13:14, Alvaro Herrera wrote:
> > Do you mind if I get this one pushed later today? Or feel free to push
> > it yourself, if you want. It's an annoying patch to keep seeing posted
> > over and over, with no further value.
>
> Feel free to push.
On 7/24/23 12:40, Amit Kapila wrote:
> On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
> wrote:
>>
>> 0005, 0006 and 0007 are all related to the initial sequence sync. [3]
>> resulted in 0007 and I think we need it. That leaves 0005 and 0006 to
>> be reviewed in this response.
>>
>> I followed the d
Neon provides a quick start mechanism for psql using the following
workflow:
$ psql -h pg.neon.tech
NOTICE: Welcome to Neon!
Authenticate by visiting:
https://console.neon.tech/psql_session/xxx
Upon navigating to the link, the user selects their database to
On 2023-Jul-24, Dean Rasheed wrote:
> Something else I noticed: the error message from ALTER TABLE ... ADD
> CONSTRAINT in the case of a duplicate constraint name is not very
> friendly:
>
> ERROR: duplicate key value violates unique constraint
> "pg_constraint_conrelid_contypid_conname_index"
>
Hi,
On 2023-07-24 15:54:33 +0200, Alvaro Herrera wrote:
> On 2023-Jul-24, Michael Paquier wrote:
>
> > On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> > > After some research, found this happens when the LimitAdditionalPins()
> > > returns exactly zero.
> > > In the current
On Mon, Jul 24, 2023 at 9:26 AM Tristan Partin wrote:
> attached patch
+/*
+ * Restore the default SIGINT behavior while within libpq.
Otherwise, we
+ * can never exit from polling for the database connection. Failure to
+ * restore is non-fatal.
+ */
+
On Mon Jul 24, 2023 at 12:00 PM CDT, Gurjeet Singh wrote:
On Mon, Jul 24, 2023 at 9:26 AM Tristan Partin wrote:
> attached patch
+/*
+ * Restore the default SIGINT behavior while within libpq.
Otherwise, we
+ * can never exit from polling for the database connection. Fa
v2 is attached which fixes a grammatical issue in a comment.
--
Tristan Partin
Neon (https://neon.tech)
From b9ccfc3c84a25b8616fd40495954bb6f77788e28 Mon Sep 17 00:00:00 2001
From: Tristan Partin
Date: Mon, 24 Jul 2023 11:12:59 -0500
Subject: [PATCH v2] Allow SIGINT to cancel psql database recon
v3 is attached which fixes up some code comments I added which I hadn't
attached to the commit already, sigh.
--
Tristan Partin
Neon (https://neon.tech)
From 7f9554944911c77aa1a1900537a91e1e7bd75d93 Mon Sep 17 00:00:00 2001
From: Tristan Partin
Date: Mon, 24 Jul 2023 11:12:59 -0500
Subject: [PA
Hello Arne,
yep, now the warnings have gone. And I must thank you for quite a fun time
I had here testing your patch :) I tried even some weird combinations like
this:
postgres=# create table t("_ __ ___" int);
CREATE TABLE
postgres=# select "__ _ ___" from t;
ERROR: column "__ _ ___" does not ex
Hello,
While discussing the matter of multiple constraints with Vik Fearing, I
noticed that we were throwing an unnecessary error if you used
CREATE TABLE foo (a int NOT NULL NOT NULL);
That would die with "redundant NOT NULL declarations", but current
master doesn't do that; and we don't do it
On 7/24/23 18:42, Alvaro Herrera wrote:
55490 17devel 3166154=# create table foo (a int constraint nn not null);
CREATE TABLE
55490 17devel 3166154=# alter table foo add constraint nn not null a;
ERROR: column "a" of table "foo" is already NOT NULL
Surely this should be a WARNING or INFO? I s
On Saturday, July 15, 2023 7:47:12 PM CEST Tom Lane wrote:
> I'm not sure how big a deal this is in practice: in most situations
> the individual jobs are larger than they are in this toy example,
> plus the initial non-parallelizable part of the restore is a bigger
> bottleneck anyway with this ma
On Sun, 2023-07-23 at 14:04 +0200, Tomas Vondra wrote:
> But I'm getting a bit lost regarding what's the proposed costing
> strategy. It's hard to follow threads spanning days, with various
> other
> distractions, etc.
I'm getting a bit lost in this discussion as well -- for the purposes
of this f
"Tristan Partin" writes:
> v3 is attached which fixes up some code comments I added which I hadn't
> attached to the commit already, sigh.
I don't care for this patch at all. You're bypassing the pqsignal
abstraction layer that the rest of psql goes through, and the behavior
you're implementing
We got a complaint at [1] about how a not-so-unreasonable LDAP
configuration can hit the "authentication file token too long,
skipping" error case in hba.c's next_token(). I think we've
seen similar complaints before, although a desultory archives
search didn't turn one up.
A minimum-change respo
On Mon, Jul 24, 2023 at 10:36 AM Jeff Davis wrote:
> I'm getting a bit lost in this discussion as well -- for the purposes
> of this feature, we only need to know whether to push down a clause as
> an Index Filter or not, right?
I think so.
> Could we start out conservatively and push down as an
Peter Geoghegan writes:
> On Mon, Jul 24, 2023 at 10:36 AM Jeff Davis wrote:
>> Could we start out conservatively and push down as an Index Filter
>> unless there is some other clause ahead of it that can't be pushed
>> down? That would allow users to have some control by writing clauses in
>> th
Greetings,
(Adding David Steele into the CC on this one...)
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> This is a frustrating thread, because despite the last patch solving
> most of the problems we discussed, it doesn't address the
> low-level-backup procedure in a nice way. We'd have to t
On Mon, Jul 24, 2023 at 2:53 PM Tom Lane wrote:
>
> We got a complaint at [1] about how a not-so-unreasonable LDAP
> configuration can hit the "authentication file token too long,
> skipping" error case in hba.c's next_token(). I think we've
> seen similar complaints before, although a desultory
On Mon, 2023-07-24 at 13:58 -0400, Tom Lane wrote:
> Please do not put in any code that assumes that restriction clause
> order is preserved, or encourages users to think it is.
Agreed. I didn't mean to add any extra guarantee of preserving clause
order; just to follow the current way order_qual_c
On Mon, 2023-07-24 at 10:54 -0700, Peter Geoghegan wrote:
> The case in question shows a cheaper plan replacing a more expensive
> plan -- so it's a win by every conventional measure. But, the new
> plan
> is less robust in the sense that I described yesterday: it will be
> much slower than the cur
Jeff Davis writes:
> On Mon, 2023-07-24 at 13:58 -0400, Tom Lane wrote:
>> Please do not put in any code that assumes that restriction clause
>> order is preserved, or encourages users to think it is.
> Agreed. I didn't mean to add any extra guarantee of preserving clause
> order; just to follow
Hi,
Currently InitCatalogCache() has only one Assert() for cacheinfo[]
that checks .reloid. The proposed patch adds sanity checks for the
rest of the fields.
--
Best regards,
Aleksander Alekseev
v1-0001-Check-more-invariants-during-syscache-initializat.patch
Description: Binary data
On Mon, Jul 24, 2023 at 11:37 AM Jeff Davis wrote:
> I see. You're concerned that lowering the cost of an index scan path
> too much, due to pushing down a clause as an Index Filter, could cause
> it to out-compete a more "robust" plan.
The optimizer correctly determines that 3 index scans (plus
On Sat, Jul 22, 2023 at 10:57:03PM -0700, Nathan Bossart wrote:
> On Sat, Jul 22, 2023 at 07:47:50PM -0400, Tom Lane wrote:
>> I wonder whether we can't provide some alternate definition or "skin"
>> for binaryheap that preserves the Datum API for backend code that wants
>> that, while providing a
On Mon, 24 Jul 2023 at 17:42, Alvaro Herrera wrote:
>
> On 2023-Jul-24, Dean Rasheed wrote:
>
> > Something else I noticed: the error message from ALTER TABLE ... ADD
> > CONSTRAINT in the case of a duplicate constraint name is not very
> > friendly:
> >
> > ERROR: duplicate key value violates un
Hi
po 8. 5. 2023 v 14:22 odesílatel Jelte Fennema napsal:
> I'm very much in favor of adding a way to support reporting other GUC
> variables than the current hardcoded list. This can be quite useful to
> support some amount of session state in connection poolers.
>
> Some general feedback on th
On Mon, Jul 24, 2023 at 6:33 AM Alvaro Herrera wrote:
> That's the first thing I proposed actually. I got one vote down from
> Robert Haas[1], but while the idea seems to have had support from Justin
> Pryzby (in \dt++) [2] and definitely did from Peter Eisentraut [3], I do
> not like it too much
Hi,
While recently looking into partition maintenance, I found a case in which
DETACH PARTITION FINALIZE could case deadlocks. This occurs when a
ALTER TABLE DETACH CONCURRENTLY, followed by a cancel, the followed by
an ALTER TABLE DETACH FINALIZE, and this sequence of steps occur in the
middle of
On Mon Jul 24, 2023 at 12:43 PM CDT, Tom Lane wrote:
"Tristan Partin" writes:
> v3 is attached which fixes up some code comments I added which I hadn't
> attached to the commit already, sigh.
I don't care for this patch at all. You're bypassing the pqsignal
abstraction layer that the rest of
Please find attached a patch to jumble savepoint name, to prevent certain
transactional commands from filling up pg_stat_statements.
This has been a problem with some busy systems that use django, which likes
to wrap everything in uniquely named savepoints. Soon, over 50% of
your pg_stat_statements
On Fri, Jul 21, 2023 at 8:52 PM Thomas Munro wrote:
> Idea for future research: Perhaps pg_backup_stop()'s label-file
> output should include the control file image (suitably encoded)? Then
> the recovery-from-label code could completely ignore the existing
> control file, and overwrite it using
Em sex., 21 de jul. de 2023 às 09:13, Karina Litskevich <
litskevichkar...@gmail.com> escreveu:
>
>
> On Wed, Jul 12, 2023 at 1:46 AM Ranier Vilela wrote:
>
>> As there is consensus to keep the no-op assignment,
>> I will go ahead and reject the patch.
>>
>
> In your patch you suggest removing t
On Mon, Jul 24, 2023 at 04:09:23PM -0400, Greg Sabino Mullane wrote:
> Without the patch, the only solution is to keep raising
> pg_stat_statements.max to larger and larger values to compensate for the
> pollution of the
> statement pool.
Yes, that can be painful depending on your workload.
b
On Mon, Jul 24, 2023 at 03:54:33PM +0200, Alvaro Herrera wrote:
> I see Michael marked it as such in the open items
> page, but did not CC Andres, so I'm doing that here now.
Indeed, thanks!
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 24, 2023 at 03:07:07PM -0300, Fabrízio de Royes Mello wrote:
> On Mon, Jul 24, 2023 at 2:53 PM Tom Lane wrote:
>>
>> We got a complaint at [1] about how a not-so-unreasonable LDAP
>> configuration can hit the "authentication file token too long,
>> skipping" error case in hba.c's next_
On Mon, Jul 24, 2023 at 09:58:15PM +0300, Aleksander Alekseev wrote:
> Currently InitCatalogCache() has only one Assert() for cacheinfo[]
> that checks .reloid. The proposed patch adds sanity checks for the
> rest of the fields.
- Assert(cacheinfo[cacheId].reloid != 0);
+ Assert(cachei
On 7/24/23 02:22, Tatsuo Ishii wrote:
What we are talking about here is *defining* a window
frame.
Well, we are defining a "reduced" window frame within a (full) window
frame. A "reduced" window frame is calculated each time when a window
function is called.
Why? It should only be recalculat
On Mon, Jul 24, 2023 at 03:58:31PM -0700, Nathan Bossart wrote:
> On Mon, Jul 24, 2023 at 03:07:07PM -0300, Fabrízio de Royes Mello wrote:
>>> Given the infrequency of complaints, I'm inclined to apply
>>> the more thorough fix only in HEAD, and to just raise MAX_TOKEN
>>> in the back branches. Th
Michael Paquier writes:
> I find the choice to keep err_msg in next_token() a bit confusing in
> next_field_expand(). If no errors are possible, why not just get rid
> of it?
Yeah, I dithered about that. I felt like removing it only to put it
back later would be silly, but then again maybe ther
On Tue, Jul 25, 2023 at 6:04 AM Stephen Frost wrote:
> * Thomas Munro (thomas.mu...@gmail.com) wrote:
> > Here's a new minimal patch that solves only the bugs in basebackup +
> > the simple SQL-facing functions that read the control file, by simply
> > acquiring ControlFileLock in the obvious plac
On Mon, Jul 24, 2023 at 08:21:54PM -0400, Tom Lane wrote:
> Yeah, I dithered about that. I felt like removing it only to put it
> back later would be silly, but then again maybe there won't ever be
> a need to put it back. I'm OK with removing it if there's not
> objections.
Seeing what this cod
I've been working on a variety of improvements to nbtree's native
ScalarArrayOpExpr execution. This builds on Tom's work in commit
9e8da0f7.
Attached patch is still at the prototype stage. I'm posting it as v1 a
little earlier than I usually would because there has been much back
and forth about i
On Tue, Jul 25, 2023 at 8:18 AM Robert Haas wrote:
> (Yeah, I know we have code to verify checksums during a base
> backup, but as discussed elsewhere, it doesn't work.)
BTW the the code you are referring to there seems to think 4KB
page-halves are atomic; not sure if that's imagining page-level
Hi,
On 2023-07-24 09:42:44 -0700, Andres Freund wrote:
> > I don't know this code at all, but I hope that this can be solved with
> > just Anton's proposed patch.
>
> Yes, it's just that off-by-one. I need to check if there's a similar bug for
> local / temp table buffers though.
Doesn't appear
Hi,
Hm, in some cases your patch is better, but in others both the old code
(8692f6644e7) and HEAD beat yours on my machine. TBH, not entirely sure why.
prep:
COPY (SELECT generate_series(1, 200) a, (random() * 10 - 5)::int b,
3243423 c) TO '/tmp/lotsaints.copy';
DROP TABLE lotsaints
On Mon, Jul 24, 2023 at 9:32 PM Tomas Vondra
wrote:
>
> On 7/24/23 12:40, Amit Kapila wrote:
> > On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat
> > wrote:
> >
> > Even after that, see below the value of the sequence is still not
> > caught up. Later, when the apply worker processes all the WAL, th
On Thu, Jul 20, 2023 at 10:47:00PM -0600, Garrett Thornburg wrote:
> Added my v1 patch to add REINDEX to event triggers.
>
> I originally built this against pg15 but rebased to master for the patch
> to hopefully make it easier for maintainers to merge. The rebase was
> automatic so it should be ea
78 matches
Mail list logo
