On Sun, Apr 3, 2022 at 11:11 AM Andres Freund wrote:
> On 2022-04-03 09:45:13 +1200, Thomas Munro wrote:
> > I think we just need to decide up front if we're in a situation that
> > can't provide datum1/isnull1 (in this case because it's an expression
> > index), and skip the optimised paths.
Hi Greg,
On Sat, 2022-04-02 at 17:38 -0400, Greg Stark wrote:
> The tests for this seem to need adjustments.
>
> [12:41:09.403] test pg_stat_statements ... FAILED 180 ms
> query | reset_ts_match
> ---+
> - SELECT $1,$2 AS "STMTTS2" |
Hi,
Independently of a problem with a recent commit, it seems that
$SUBJECT in all releases (well, I only tested as far back as 11). I
attach an addition to the tests to show this, but here's a stand-alone
repro:
DROP TABLE IF EXISTS clstr_expression;
CREATE TABLE clstr_expression(id serial
On Sun, Apr 3, 2022 at 1:07 PM Greg Stark wrote:
> https://cirrus-ci.com/task/5389918250729472
>
> Failed to start an instance: INVALID_ARGUMENT: Operation with name
> "operation-1648936682461-5dbb2fd37177b-5095285b-b153ee83" failed with
> status = HttpJsonStatusCode{statusCode=INVALID_ARGUMENT}
Hi,
Alvaro, added you because you were the original author for a lot of that
code. Fujii, you touched it last...
6) Should any part of the "reuse_stats" logic in table_recheck_autovac() be
kept?
With the shared memory stats patch, autovacuum can cheaply access individual
stats, so the whole
Hi,
On April 2, 2022 6:20:36 PM PDT, Greg Stark wrote:
>Hm. It compiles but it's failing regression tests:
>
>diff -U3 /tmp/cirrus-ci-build/contrib/dummy_toaster/expected/dummy_toaster.out
>/tmp/cirrus-ci-build/contrib/dummy_toaster/results/dummy_toaster.out
>---
Hm. It compiles but it's failing regression tests:
diff -U3 /tmp/cirrus-ci-build/contrib/dummy_toaster/expected/dummy_toaster.out
/tmp/cirrus-ci-build/contrib/dummy_toaster/results/dummy_toaster.out
--- /tmp/cirrus-ci-build/contrib/dummy_toaster/expected/dummy_toaster.out
2022-04-02
One patch is failing with what looks like a generic Cirrus issue:
https://cirrus-ci.com/task/5389918250729472
Failed to start an instance: INVALID_ARGUMENT: Operation with name
"operation-1648936682461-5dbb2fd37177b-5095285b-b153ee83" failed with
status =
On Sat, Apr 02, 2022 at 08:44:45PM +0900, Masahiko Sawada wrote:
> On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila wrote:
> > On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
> > > Some options:
> > > - Move subskiplsn after subdbid, so it's always aligned anyway. I've
> > > confirmed that this
Greg Stark writes:
> The tests for this seem to need adjustments.
> [12:41:09.403] test pg_stat_statements ... FAILED 180 ms
> diff -U3
> /tmp/cirrus-ci-build/contrib/pg_stat_statements/expected/pg_stat_statements.out
>
This patch was broken by d16773cdc86210493a2874cb0cf93f3883fcda73 "Add
macros in hash and btree AMs to get the special area of their pages"
If it's really just a few macros it should be easy enough to merge but
it would be good to do a rebase given the number of other commits
since February
Hi,
On 2022-04-03 09:45:13 +1200, Thomas Munro wrote:
> On Sun, Apr 3, 2022 at 9:03 AM Andres Freund wrote:
> > It's certainly not pretty that copytup_cluster() can use SortTuples without
> > actually using SortTuples. Afaics it basically only computes isnull1/datum1
> > if
> >
On Sun, Apr 3, 2022 at 9:03 AM Andres Freund wrote:
> It's certainly not pretty that copytup_cluster() can use SortTuples without
> actually using SortTuples. Afaics it basically only computes isnull1/datum1 if
> state->indexInfo->ii_IndexAttrNumbers[0] == 0.
I think we just need to decide up
The tests for this seem to need adjustments.
[12:41:09.403] test pg_stat_statements ... FAILED 180 ms
diff -U3
/tmp/cirrus-ci-build/contrib/pg_stat_statements/expected/pg_stat_statements.out
/tmp/cirrus-ci-build/contrib/pg_stat_statements/results/pg_stat_statements.out
---
Hi,
On 2022-04-02 15:20:27 -0500, Justin Pryzby wrote:
> On Sat, Apr 02, 2022 at 06:41:30PM +0700, John Naylor wrote:
> > On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > > Reproduced locally, using the same few lines from the cluster.sql
> > > test. I'll try to dig more tomorrow...
> >
On Sun, Apr 3, 2022 at 8:20 AM Justin Pryzby wrote:
> @@ -4126,22 +4126,23 @@ copytup_cluster(Tuplesortstate *state, SortTuple
> *stup, void *tup)
> + stup->isnull1 = false;
Looks like I might have failed to grok the scheme for encoding null
into SortTuple objects. It's clearly
Hi,
On 2022-04-03 08:07:58 +1200, Thomas Munro wrote:
> On Sun, Apr 3, 2022 at 12:41 AM John Naylor
> wrote:
> > On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > > Reproduced locally, using the same few lines from the cluster.sql
> > > test. I'll try to dig more tomorrow...
> >
> >
On Sat, Apr 02, 2022 at 06:41:30PM +0700, John Naylor wrote:
> On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > Reproduced locally, using the same few lines from the cluster.sql
> > test. I'll try to dig more tomorrow...
>
> Thanks! Unfortunately I can't reproduce locally with clang
Joseph Koshakow writes:
> On Sat, Apr 2, 2022 at 3:08 PM Tom Lane wrote:
>> I think it's not, at least not for the interesting range of possible
>> values in this code. Given that abs(frac) < 1 to start with, the
>> abs value of usec can't exceed the value of scale, which is at most
>>
On Sun, Apr 3, 2022 at 12:41 AM John Naylor
wrote:
> On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> > Reproduced locally, using the same few lines from the cluster.sql
> > test. I'll try to dig more tomorrow...
>
> Thanks! Unfortunately I can't reproduce locally with clang 13/gcc 11,
>
On Sat, Apr 2, 2022 at 3:08 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > Ok I actually remember now, the issue is with the rounding
> > code in AdjustFractMicroseconds.
> > ...
> > I believe it's possible for `frac -= usec;` to result in a value greater
> > than 1 or less than -1 due to
On 4/2/22 01:25, Jaime Casanova wrote:
> I got a crash running the below query on the regression database:
>
> """
> select pg_catalog.json_object_agg_unique(10,
> cast(ref_0.level2_no as int4))
> over (partition by ref_0.parent_no
> order by
Joseph Koshakow writes:
> I took a stab at this issue and the attached patch (which would be
> applied on top of your v10 patch) seems to fix the issue. Feel
> free to ignore it if you're already working on a fix.
You really only need to flip val/fval in one place. More to the
point, there's
Joseph Koshakow writes:
> Ok I actually remember now, the issue is with the rounding
> code in AdjustFractMicroseconds.
> ...
> I believe it's possible for `frac -= usec;` to result in a value greater
> than 1 or less than -1 due to the lossiness of int64 to double
> conversions.
I think it's
On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
> I think the patch can be salvaged, though. I like the concept
> of converting all the sub-day fields to microseconds immediately,
> because it avoids a host of issues, so I don't want to give that up.
> What I'm going to look into is detecting the
On Sat, Apr 2, 2022 at 2:22 PM Joseph Koshakow wrote:
>
> On Sat, Apr 2, 2022 at 1:29 PM Joseph Koshakow wrote:
> >
> > On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
> > >
> > > Joseph Koshakow writes:
> > > > * The existing code for rounding had a lot of int to double
> > > > casting and
On Sat, Apr 2, 2022 at 1:29 PM Joseph Koshakow wrote:
>
> On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
> >
> > Joseph Koshakow writes:
> > > * The existing code for rounding had a lot of int to double
> > > casting and vice versa. I *think* that doubles are able to completely
> > > represent
On 2/10/22 19:17, Tomas Vondra wrote:
>> I've polished & pushed the first part adding sequence decoding
>> infrastructure etc. Attached are the two remaining parts.
>>
>> I plan to wait a day or two and then push the test_decoding part. The
>> last part (for built-in replication) will need more
Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera
escreveu:
> On 2022-Mar-31, Daniel Gustafsson wrote:
>
> > > On 31 Mar 2022, at 19:38, Ranier Vilela wrote:
> >
> > > I think that there is an oversight at 7103ebb
> > > There is no chance of Assert preventing this bug.
> >
> > This seems
On 3/28/22 15:56, Robert Haas wrote:
On Mon, Mar 21, 2022 at 4:15 PM Joe Conway wrote:
Robert -- any opinion on this? If I am not mistaken it is code that you
are actively working on.
Woops, I only just saw this. I don't mind if you want to change the
calls to is_member_of_role() in
On Fri, Apr 1, 2022 at 8:06 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > * The existing code for rounding had a lot of int to double
> > casting and vice versa. I *think* that doubles are able to completely
> > represent the range of ints. However doubles are not able to represent
> > the
I wrote:
> ... I almost feel that this is
> committable, but there is one thing that is bothering me. The
> part of DecodeInterval that does strange things with signs in the
> INTSTYLE_SQL_STANDARD case (starting about line 3400 in datetime.c
> before this patch, or line 3600 after) used to
Small things here.
1. in VACUUM FULL we only process partitions that are owned by the
invoking user. We don't have this test in the new code. I'm not sure
why do we do that there; is it worth doing the same here?
2. We should silently skip a partition that's a foreign table, I
suppose.
3. We
Thanks, pushed.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)
Hi,
On 2022-04-02 17:02:01 +0200, Alvaro Herrera wrote:
> There's no bug here and this is actually intentional: if the map is
> NULL, this function should not be called.
This made me, again, wonder if we should add a pg_nonnull attibute to c.h. The
compiler can probably figure it out in this
On 2022-Apr-01, Euler Taveira wrote:
> Hi,
>
> While inspecting the MERGE documentation, I noticed that there is an extra
> semicolon in one of the examples that shouldn't be there.
Thanks, pushed.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"The Gord
On 2022-Mar-31, Daniel Gustafsson wrote:
> > On 31 Mar 2022, at 19:38, Ranier Vilela wrote:
>
> > I think that there is an oversight at 7103ebb
> > There is no chance of Assert preventing this bug.
>
> This seems reasonable from brief reading of the code, NULL is a legitimate
> value for the
Hi,
I've been able to test the patch. Here is a recap of the experimentation.
# Setup
All tests have been done witch 3 VMs (PostgreSQL, HAproxy, psql client) on
Debian 11 communicating over private network.
* PostgreSQL have been built with proxy_protocol_11.patch applied on master
branch
Hi,
On Fri, Apr 01, 2022 at 11:46:47PM +0300, Ekaterina Sokolova wrote:
>
> > Most of the comments I have are easy to fix. But I think that the real
> > problem
> > is the significant overhead shown by Ekaterina that for now would apply
> > even if
> > you don't consume the new stats, for
On 2022-04-01 13:22, Robert Haas wrote:
I attach herewith a modest patch to rename these shutdown modes to
more accurately correspond to their actual characteristics.
I've waited for April 2nd to submit this comment, but it seemed to me
that the
suggestion about the first-pass checkpoint in
According to the cfbot this patch needs a rebase
Indeed. v4 attached.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index ebdb4b3f46..d96d2d291d 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -29,7 +29,7 @@ PostgreSQL
Again, after the SendQuery refactoring extraction.
I'm doing this locally, so don't feel obliged to send more of these. ;-)
Good for me :-)
--
Fabien.
This message lost track of the email headers so CFBOT isn't processing the new
patches. Which I'm attempting to remedy now.
https://www.postgresql.org/message-id/flat/ae576cac3f451d318374f2a2e494a...@postgrespro.ru
On Fri, Apr 01, 2022 at 11:46:47PM +0300, Ekaterina Sokolova wrote:
> Hi,
On Sat, 2022-04-02 at 14:11 +0300, Andrei Zubkov wrote:
> On Sat, 2022-04-02 at 18:56 +0800, Julien Rouhaud wrote:
> > Maybe a macro would be better here? I don't know if that's
> > generally
> > ok or
> > just old and not-that-great code, but there are other places
> > relying
> > on macros
> >
On 4/2/22 12:43, Amit Kapila wrote:
> On Sat, Apr 2, 2022 at 5:47 AM Tomas Vondra
> wrote:
>>
>> On 4/1/22 17:02, Tomas Vondra wrote:
>>
>> The only option I see is reworking the decoding so that it does not need
>> the snapshot at all. We'll need to stash the changes just like any other
>>
On 4/2/22 12:35, Amit Kapila wrote:
> On Fri, Apr 1, 2022 at 8:32 PM Tomas Vondra
> wrote:
>>
>> On 3/28/22 07:29, Amit Kapila wrote:
>>> I thought about changing snapshot dealing of
>>> non-transactional sequence changes similar to transactional ones but
>>> that also won't work because it is
On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila wrote:
>
> On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
> >
> > On Sat, Apr 02, 2022 at 04:33:44PM +0900, Masahiko Sawada wrote:
> > > It seems that 0/B0706F72 is not a random value. Two subscriber logs
> > > show the same value. Since 0x70 = 'p',
On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> Reproduced locally, using the same few lines from the cluster.sql
> test. I'll try to dig more tomorrow...
Thanks! Unfortunately I can't reproduce locally with clang 13/gcc 11,
with -Og or -O2 with CFLAGS="-fsanitize=undefined,alignment" ...
On Sat, 2022-04-02 at 18:56 +0800, Julien Rouhaud wrote:
> Maybe a macro would be better here? I don't know if that's generally
> ok or
> just old and not-that-great code, but there are other places relying
> on macros
> when a plain function call isn't that convenient (like here returning
> 0 or
On 4/1/22 16:25, Andrew Dunstan wrote:
> On 4/1/22 15:16, Andrew Dunstan wrote:
>> On 4/1/22 13:44, Nathan Bossart wrote:
>>> On Fri, Apr 01, 2022 at 10:21:50AM -0700, Andres Freund wrote:
right now I am looking at a test added in the shmstats patch that's slow on
CI, on windows only.
On Sat, Apr 02, 2022 at 01:12:54PM +0300, Andrei Zubkov wrote:
> On Fri, 2022-04-01 at 13:01 -0700, Andres Freund wrote:
> > It seems decidedly not great to have four copies of this code. It was
> > already
> > not great before, but this patch makes the duplicated section go from
> > four
> >
On Sat, Apr 2, 2022 at 5:27 PM Thomas Munro wrote:
> It looks like UBsan sees a problem, per BF animal kestrel:
>
> /mnt/resource/bf/build/kestrel/HEAD/pgsql.build/../pgsql/src/backend/utils/sort/tuplesort.c:722:51:
> runtime error: load of value 96, which is not a valid value for type
> 'bool'
On Sat, Apr 2, 2022 at 5:47 AM Tomas Vondra
wrote:
>
> On 4/1/22 17:02, Tomas Vondra wrote:
>
> The only option I see is reworking the decoding so that it does not need
> the snapshot at all. We'll need to stash the changes just like any other
> change, apply them at end of transaction, and the
On Fri, Apr 1, 2022 at 8:32 PM Tomas Vondra
wrote:
>
> On 3/28/22 07:29, Amit Kapila wrote:
> > I thought about changing snapshot dealing of
> > non-transactional sequence changes similar to transactional ones but
> > that also won't work because it is only at commit we decide whether we
> > can
On Sat, Apr 2, 2022 at 9:38 PM John Naylor wrote:
> On Fri, Apr 1, 2022 at 4:43 AM Thomas Munro wrote:
> > On Thu, Mar 31, 2022 at 11:09 PM John Naylor
> > wrote:
> > > In a couple days I'm going to commit the v3 patch "accelerate tuple
> > > sorting for common types" as-is after giving it one
Hi,
On Fri, 2022-04-01 at 13:01 -0700, Andres Freund wrote:
> It seems decidedly not great to have four copies of this code. It was
> already
> not great before, but this patch makes the duplicated section go from
> four
> lines to 20 or so.
Agreed. I've created the single_entry_reset() function
On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
>
> On Sat, Apr 02, 2022 at 04:33:44PM +0900, Masahiko Sawada wrote:
> > It seems that 0/B0706F72 is not a random value. Two subscriber logs
> > show the same value. Since 0x70 = 'p', 0x6F = 'o', and 0x72 = 'r', it
> > might show the next field in
I wrote:
> I started towards incorporating the change in insertion sort threshold
> (part of 0010), but that caused regression test failures, so that will
> have to wait for a bit of analysis and retesting. (My earlier tests
> were done in a separate module.)
The failures seem to be where sort
On Fri, Apr 1, 2022 at 4:43 AM Thomas Munro wrote:
>
> On Thu, Mar 31, 2022 at 11:09 PM John Naylor
> wrote:
> > In a couple days I'm going to commit the v3 patch "accelerate tuple
> > sorting for common types" as-is after giving it one more look, barring
> > objections.
Pushed.
> Hi John,
>
>
Hi,
On 2022-03-25 17:24:18 +0900, Kyotaro Horiguchi wrote:
> > * AFIXME: Should all the stats drop code be moved into pgstat_drop.c?
>
> Or pgstat_xact.c?
I wasn't initially happy with that suggestion, but after running with it, it
looks pretty good.
I also moved a fair bit of code into
Hi,
On 2022-03-25 17:24:18 +0900, Kyotaro Horiguchi wrote:
> > AFIXME: Isn't PGSTAT_MIN_INTERVAL way too long? What is the justification
> > for increasing it?
>
> It is 1000ms in the comment just above but actually 1ms. The
> number came from a discussion that if we have 1000 clients and
On Sat, Apr 02, 2022 at 04:33:44PM +0900, Masahiko Sawada wrote:
> It seems that 0/B0706F72 is not a random value. Two subscriber logs
> show the same value. Since 0x70 = 'p', 0x6F = 'o', and 0x72 = 'r', it
> might show the next field in the pg_subscription catalog, i.e.,
> subconninfo. The
On Sat, Apr 2, 2022 at 1:08 PM Amit Kapila wrote:
>
> On Sat, Apr 2, 2022 at 7:29 AM Noah Misch wrote:
> >
> > On Sat, Apr 02, 2022 at 06:49:20AM +0530, Amit Kapila wrote:
> >
> > After applying datum_to_lsn_skiplsn_1.patch, I get another failure. Logs
> > attached.
> >
>
> The failure is for
On Fri, Apr 01, 2022 at 01:01:53PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-04-01 22:47:02 +0300, Andrei Zubkov wrote:
> > + entry = (pgssEntry *) hash_search(pgss_hash, , HASH_FIND,
> > NULL);
> > +
> > + if (entry) {
> > + /* Found */
> > +
On Fri, Apr 01, 2022 at 10:47:02PM +0300, Andrei Zubkov wrote:
>
> On Fri, 2022-04-01 at 11:38 -0400, Greg Stark wrote:
> > [13:19:51.544] pg_stat_statements.c: In function ‘entry_reset’:
> > [13:19:51.544] pg_stat_statements.c:2598:32: error:
> > ‘minmax_stats_reset’ may be used uninitialized in
On Thu, Mar 31, 2022 at 01:06:10PM +0300, Andrei Zubkov wrote:
>
> On Wed, 2022-03-30 at 17:31 +0800, Julien Rouhaud wrote:
> > Feature wise, I'm happy with the patch. I just have a few comments.
> >
> > Tests:
> >
> > - it's missing some test in sql/oldextversions.sql to validate that the
> >
On Fri, Apr 1, 2022 at 1:52 PM Peter Smith wrote:
>
> On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila wrote:
>
> I think the STATE_CATCHUP guarantees the apply worker must have
> received (or tried to receive) a message. See the previous answer.
>
Sorry, I intend to say till the sync worker has
+1 for the idea of changing the name, as it's really confusing.
I had quick check in the patch and noticed below replacements:
-#define SmartShutdown 1
-#define FastShutdown 2
-#define ImmediateShutdown 3
+#define DumbShutdown 1
+#define SlowShutdown 2
+#define CrappyShutdown 3
About the new
68 matches
Mail list logo
