On Sun, Apr 03, 2022 at 10:07:21PM -0700, Andres Freund wrote:
> On 2022-04-04 00:50:27 -0400, Tom Lane wrote:
> > My pet dinosaur gaur just failed [1] in
> > src/test/recovery/t/022_crash_temp_files.pl, which does this:
> >
> > -
> > my $ret = PostgreSQL::Test::Utils::system_log('pg_ctl',
On Mon, Apr 4, 2022 at 8:33 AM Jeff Davis wrote:
>
> I still may change it to go back to two RmgrTables (one for builtin and
> one for custom) to remove the lingering performance doubts. Other than
> that, and some cleanup, this is pretty close to the version I intend to
> commit.
I just had a
Hi,
On 2022-04-04 00:50:27 -0400, Tom Lane wrote:
> My pet dinosaur gaur just failed [1] in
> src/test/recovery/t/022_crash_temp_files.pl, which does this:
>
> -
> my $ret = PostgreSQL::Test::Utils::system_log('pg_ctl', 'kill', 'KILL', $pid);
> is($ret, 0, 'killed process with KILL');
>
> #
My pet dinosaur gaur just failed [1] in
src/test/recovery/t/022_crash_temp_files.pl, which does this:
-
my $ret = PostgreSQL::Test::Utils::system_log('pg_ctl', 'kill', 'KILL', $pid);
is($ret, 0, 'killed process with KILL');
# Close psql session
$killme->finish;
$killme2->finish;
# Wait till
Hi,
On 2022-03-31 14:20:51 -0700, Jeff Davis wrote:
> If you are still concerned, I can switch back to separate tables to
> eliminate the indirection for built-in rmgrs. Separate rmgr tables
> still require a branch (to decide which table to access), but it should
> be a highly predictable one.
Hi,
On Tue, Mar 01, 2022 at 11:35:32AM +0900, Masahiko Sawada wrote:
> On Wed, Jan 19, 2022 at 5:52 PM Julien Rouhaud wrote:
> >
> > It seems that the regression tests aren't entirely stable, per cfbot:
> > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/36/3298.
> >
> > The
Hi,
On 2022-03-08 20:17:06 -0700, David G. Johnston wrote:
> On Tue, Mar 8, 2022 at 7:32 PM Andres Freund wrote:
>
> > we need a descriptive term / shorthand that
> > describes the type of statistics we currently send to the stats collector.
> >
> > "cumulative stats subsystem"?
> >
> >
> I'm
Hi Zhihong,
On Sun, Apr 3, 2022 at 11:38 PM Zhihong Yu wrote:
> + WRITE_ENUM_FIELD(status, SubqueryScanStatus);
>
> Looks like the new field can be named subquerystatus - this way its purpose
> is clearer.
I agree that “status” is too general. “subquerystatus” might be good,
but I’d like to
On Sat, Apr 2, 2022 at 5:05 AM Jeff Davis wrote:
>
> On Sat, 2022-03-26 at 10:31 +0530, Bharath Rupireddy wrote:
> > Attaching v16 patch-set, only change in v16-0002-pg_walinspect.patch,
> > others remain the same.
>
> I looked more closely at this patch.
Thanks Jeff for reviewing this.
> * It
On Mon, Apr 4, 2022 at 8:41 AM Masahiko Sawada wrote:
>
> On Mon, Apr 4, 2022 at 11:50 AM Amit Kapila wrote:
> >
> > Another minor point is that I think it is better to use DatumGetLSN to
> > read this in GetSubscription as we use LSNGetDatum while storing it. I
> > am not sure if there is any
On Thu, Mar 31, 2022 at 10:49:32PM +1300, Thomas Munro wrote:
> On Mon, Mar 21, 2022 at 9:29 PM Julien Rouhaud wrote:
> > So I finally finished looking at this patch. Here again, AFAICS the
> > feature is
> > working as expected and I didn't find any problem. I just have some minor
> >
On Mon, Apr 4, 2022 at 11:50 AM Amit Kapila wrote:
>
> On Mon, Apr 4, 2022 at 8:01 AM Noah Misch wrote:
> >
> > On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > > On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
> > > > On Sat, Apr 02, 2022 at 08:44:45PM +0900, Masahiko
At Sat, 2 Apr 2022 11:58:55 +0900, Michael Paquier wrote
in
> On Fri, Apr 01, 2022 at 01:22:05PM -0400, Robert Haas wrote:
> > I attach herewith a modest patch to rename these shutdown modes to
> > more accurately correspond to their actual characteristics.
> >
> > Date: Fri, 1 Apr 2022
On Mon, 2022-03-28 at 11:00 -0700, Andres Freund wrote:
> > +/*
> > + * Start up all resource managers.
> > + */
> > +void
> > +StartupResourceManagers()
>
> (void)
Fixed.
> Random idea: Might be worth emitting the id->name mapping just after
> a redo
> location is determined, to make it easier
On Mon, Apr 4, 2022 at 8:01 AM Noah Misch wrote:
>
> On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
> > > On Sat, Apr 02, 2022 at 08:44:45PM +0900, Masahiko Sawada wrote:
> > > > On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila
>
On 4/3/22 20:11, Andres Freund wrote:
> Hi,
>
> On 2022-04-03 18:56:39 -0400, Andrew Dunstan wrote:
>> Haven't found the issue yet :-( It happens on the second call for the
>> partition to json_check_unique_key().
>>
>> Here's a more idiomatic and self-contained query that triggers the problem.
Hi,
On Sun, Apr 03, 2022 at 01:24:40PM +0300, Andrei Zubkov wrote:
>
> On Sun, 2022-04-03 at 17:56 +0800, Julien Rouhaud wrote:
> > Just another minor nitpicking after a quick look:
> >
> > + This field will be zero if ...
> > [...]
> > + this field will contain zero until this statement ...
> >
On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
> > 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
On Sun, Apr 3, 2022 at 11:53 AM Andres Freund wrote:
> We've had bugs in pg_upgrade where post-upgrade xid horizons weren't correctly
> set. We've had bugs were indexes were corrupted during replay.
>
> The latter can be caught by wal_consistency_checking - but that's pretty
> expensive.
>
> It
On Sun, Apr 3, 2022 at 12:05 PM Andres Freund wrote:
> Just saw that you committed: Wee! I think this will be a substantial
> improvement for our users.
I hope so! I think that it's much more useful as the basis for future
work than as a standalone thing. Users of Postgres 15 might not notice
a
On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
>
> 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
On Sun, Apr 3, 2022 at 12:36 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.04.22 20:50, David G. Johnston wrote:
> > However, tables having an identity sequence seem to be unaddressed in
> > this patch. The existing (and unchanged) pg_dump.c code results in:
>
> It is
>> I think it's easier to just say "if feature X is not enabled, then
>> columns XYZ are always zeroes".
>
> Ok, I will come up with a patch in this direction.
Please find attached patch for this.
With the patch, the log line is as follows (actually no line foldings of
course):
Hi,
On 2022-04-03 18:56:39 -0400, Andrew Dunstan wrote:
> Haven't found the issue yet :-( It happens on the second call for the
> partition to json_check_unique_key().
>
> Here's a more idiomatic and self-contained query that triggers the problem.
>
>
> select json_objectagg('10' : ref_0.level2
On Sun, Apr 3, 2022 at 12:36 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.04.22 20:50, David G. Johnston wrote:
> > However, tables having an identity sequence seem to be unaddressed in
> > this patch. The existing (and unchanged) pg_dump.c code results in:
>
> It is
On Mon, Apr 4, 2022 at 11:12 AM Peter Geoghegan wrote:
> We will need a backpatchable fix, since Thomas' recent fix (commit
> cc58eecc5d75a9329a6d49a25a6499aea7ee6fd6) only targeted the master
> branch.
I probably should have made it clearer in the commit message,
cc58eecc5 doesn't fix this
On Sun, Apr 3, 2022 at 1:22 AM John Naylor wrote:
> I can confirm the problem on v10 as well.
We will need a backpatchable fix, since Thomas' recent fix (commit
cc58eecc5d75a9329a6d49a25a6499aea7ee6fd6) only targeted the master
branch.
If we really needed the performance advantage of
On Mon, Apr 4, 2022 at 4:32 AM Andres Freund wrote:
> Would be good to get this committed soon, so we can see further ubsan
> violations introduced in the next few days (and so I can unblock my local dev
> tests :P).
Pushed (with a minor tweak).
On 4/2/22 15:40, Andrew Dunstan wrote:
> 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
On Sun, Apr 3, 2022 at 3:06 PM Tom Lane wrote:
> That buildfarm machine is pretty slow, so I'm not in a hurry to test
> it manually either. However, now that we realize the issue is about
> whether strtod(".") produces EINVAL or not, I think we need to fix
> all the places in datetime.c that are
On Sun, Apr 3, 2022 at 8:22 PM John Naylor wrote:
> On Sun, Apr 3, 2022 at 11:05 AM Thomas Munro wrote:
> > 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 can confirm the problem on v10 as well.
Thanks
On 4/2/22 13:51, Tomas Vondra wrote:
>
>
> 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
On 03.04.22 20:50, David G. Johnston wrote:
However, tables having an identity sequence seem to be unaddressed in
this patch. The existing (and unchanged) pg_dump.c code results in:
It is addressed. For example, run this in PG14:
create unlogged table t1 (a int generated always as identity,
Hi,
Am Donnerstag, dem 10.03.2022 um 15:28 +0100 schrieb Gunnar "Nick"
Bluth:
> Am 10.03.22 um 14:43 schrieb Michael Banck:
> > some minor comments, I didn't look at the added test and I did not
> > test the patch at all, but (as part of the Debian/Ubuntu packaging
> > team) I think this patch is
Joseph Koshakow writes:
> How does this patch look? I don't really have any way to test it on
> AIX.
That buildfarm machine is pretty slow, so I'm not in a hurry to test
it manually either. However, now that we realize the issue is about
whether strtod(".") produces EINVAL or not, I think we
Hi,
On 2022-04-01 10:54:14 -0700, Peter Geoghegan wrote:
> On Thu, Mar 31, 2022 at 11:19 AM Peter Geoghegan wrote:
> > The assert is "Assert(diff > 0)", and not "Assert(diff >= 0)".
>
> Attached is v15. I plan to commit the first two patches (the most
> substantial two patches by far) in the
Hi,
We've had bugs in pg_upgrade where post-upgrade xid horizons weren't correctly
set. We've had bugs were indexes were corrupted during replay.
The latter can be caught by wal_consistency_checking - but that's pretty
expensive.
It seems $subject would have a chance of catching some of these
On Sun, Apr 3, 2022 at 10:19 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> Here is an updated patch that fixes this pg_dump/pg_upgrade issue and
> also adds a few more comments and documentation sentences about what
> happens and what is allowed. I didn't change any
On 01.04.22 18:31, Peter Eisentraut wrote:
Consider that an identity sequence creates an "internal" dependency
and a serial sequence creates an "auto" dependency.
An "internal" dependency means that the internal object shouldn't
really be operated on directly. (In some cases it's allowed
On Sun, Apr 3, 2022 at 12:44 PM Joseph Koshakow wrote:
>
> On Sun, Apr 3, 2022 at 12:30 PM Tom Lane wrote:
> >
> > Joseph Koshakow writes:
> > > So I think we need to check that endptr has moved both after
> > > the call to strtoi64() and strtod().
> >
> > I'm not sure we need to do that
Hi,
On 2022-03-29 12:25:52 +, Imseih (AWS), Sami wrote:
> > I think that's an absolute no-go. Adding locking to progress reporting,
> > particularly a single central lwlock, is going to *vastly* increase the
> > overhead incurred by progress reporting.
>
> Sorry for the late reply.
>
> The
On Sun, Apr 3, 2022 at 12:30 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > So I think we need to check that endptr has moved both after
> > the call to strtoi64() and strtod().
>
> I'm not sure we need to do that explicitly, given that there's
> a check later as to whether endptr is
Hi,
On 2022-03-29 14:48:54 +0800, Hao Wu wrote:
> It's a natural requirement to unregister the callback for transaction or
> subtransaction when the callback is invoked, so we don't have to
> unregister the callback somewhere.
You normally shouldn'd need to do this frequently - what's your use
Hi,
On 2022-04-03 17:46:28 +1200, Thomas Munro wrote:
> 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
Joseph Koshakow writes:
> On Sun, Apr 3, 2022 at 12:03 PM Tom Lane wrote:
>> Oh ... a bit of testing says that strtod() on an empty string
>> succeeds (returning zero) on Linux, but fails with EINVAL on
>> AIX. The latter is a lot less surprising than the former,
>> so we'd better cope.
> I'm
On Sun, Apr 3, 2022 at 12:03 PM Tom Lane wrote:
>
> I wrote:
> > Joseph Koshakow writes:
> >> I think I know that the issue is. It's with `ParseISO8601Number` and
> >> the minutes field "1.".
> >> Previously that function parsed the entire field into a single double,
> >> so "1." would
> >> be
Hi,
On 2022-03-29 11:55:05 -0400, Robert Haas wrote:
> I committed v6 instead.
Coverity complains that this patch added GetDatabasePath() calls without
freeing its return value. Normally that'd be easy to dismiss, due to memory
contexts, but there's no granular resets in
I wrote:
> Joseph Koshakow writes:
>> I think I know that the issue is. It's with `ParseISO8601Number` and
>> the minutes field "1.".
>> Previously that function parsed the entire field into a single double,
>> so "1." would
>> be parsed into 1.0. Now we try to parse the integer and decimal parts
Joseph Koshakow writes:
> On Sun, Apr 3, 2022 at 3:09 AM Tom Lane wrote:
>> Hmm ... buildfarm's not entirely happy [1][2][3]:
> I think I know that the issue is. It's with `ParseISO8601Number` and
> the minutes field "1.".
> Previously that function parsed the entire field into a single double,
Alvaro Herrera writes:
> I think it's easier to just say "if feature X is not enabled, then
> columns XYZ are always zeroes".
+1, that's pretty much what I was thinking.
regards, tom lane
On Sun, Apr 3, 2022 at 3:09 AM Tom Lane wrote:
>
> I wrote:
> > Cool. I've pushed the patch.
>
> Hmm ... buildfarm's not entirely happy [1][2][3]:
>
> diff -U3
> /home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/expected/interval.out
>
On Sun, Apr 3, 2022 at 3:28 AM Etsuro Fujita
wrote:
> On Sun, Mar 13, 2022 at 6:39 PM Etsuro Fujita
> wrote:
> > On Wed, Sep 15, 2021 at 3:40 PM Alexander Pyhalov
> > wrote:
> > > The patch looks good to me and seems to work as expected.
> >
> > I’m planning to commit the patch.
>
> I polished
The cfbot is failing testing this patch. It seems... unlikely given
the nature of the patch modifying an admin function that doesn't even
modify the database that it should be breaking a streaming test.
Perhaps the streaming test is using this function in the testing
scaffolding?
[03:19:29.564] #
Is this a problem with the patch or its tests?
[18:14:20.798] # poll_query_until timed out executing this query:
[18:14:20.798] # SELECT count(1) = 0 FROM pg_subscription_rel WHERE
srsubstate NOT IN ('r', 's');
[18:14:20.798] # expecting this output:
[18:14:20.798] # t
[18:14:20.798] # last
Hi,
I'm checking. It seems that I've missed something while rebasing, we have
had all tests clean before.
On Sun, Apr 3, 2022 at 5:06 AM Andres Freund wrote:
> Hi,
>
> On April 2, 2022 6:20:36 PM PDT, Greg Stark wrote:
> >Hm. It compiles but it's failing regression tests:
> >
> >diff -U3
>
>> My 0.02€:
>>
>> I agree that it would be better to have a more deterministic aggregated log
>> format.
>>
>> ISTM that it should skip failures and lags if no fancy options has been
>> selected, i.e.:
>>
>> [ fails ... retries [ sum_lag ... [ skipped ] ] ?
>
> I think it's easier to just
On 2022-Apr-03, Fabien COELHO wrote:
> > What about this? (a log line is not actually folded)
> > interval_start num_transactions sum_latency sum_latency_2 min_latency
> > max_latency
> > failures serialization_failures deadlock_failures retried retries [ sum_lag
> > sum_lag_2 min_lag max_lag [
>>> Or those three columns always, sum_lag sum_lag_2, min_lag max_lag,
>>> skipped, retried retries?
>>
>> What about this? (a log line is not actually folded)
>> interval_start num_transactions sum_latency sum_latency_2 min_latency
>> max_latency
>> failures serialization_failures
On 2022-Apr-02, Andres Freund wrote:
> 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 scheme for avoiding stats accesses is moot.
Agreed, I don't think
I noticed a definitional problem in 0001 that's also a bug in some
conditions -- namely that the bitmapset "validplans" is never explicitly
initialized to NIL. In the original coding, the BMS was always returned
from somewhere; in the new code, it is passed from an uninitialized
stack variable
On Sun, Mar 13, 2022 at 6:39 PM Etsuro Fujita wrote:
> On Wed, Sep 15, 2021 at 3:40 PM Alexander Pyhalov
> wrote:
> > The patch looks good to me and seems to work as expected.
>
> I’m planning to commit the patch.
I polished the patch a bit:
* Reordered a bit of code in create_append_plan() in
Julien,
On Sun, 2022-04-03 at 17:56 +0800, Julien Rouhaud wrote:
> Just another minor nitpicking after a quick look:
>
> + This field will be zero if ...
> [...]
> + this field will contain zero until this statement ...
>
> The wording should be consistent, so either "will be zero" or "will
>
Hi,
On Sun, Apr 03, 2022 at 12:29:43PM +0300, Andrei Zubkov wrote:
> I've attached v12 of a patch. The only unsolved issue now is the
> following:
>
> On Sun, 2022-04-03 at 15:07 +0800, Julien Rouhaud wrote:
> > +ALTER EXTENSION pg_stat_statements UPDATE TO '1.9';
> > +\d pg_stat_statements
> >
I've attached v12 of a patch. The only unsolved issue now is the
following:
On Sun, 2022-04-03 at 15:07 +0800, Julien Rouhaud wrote:
> +ALTER EXTENSION pg_stat_statements UPDATE TO '1.9';
> +\d pg_stat_statements
> +\d pg_stat_statements_info
> +SELECT
Hi Julien,
On Sun, 2022-04-03 at 15:07 +0800, Julien Rouhaud wrote:
> +static TimestampTz
> +entry_reset(Oid userid, Oid dbid, uint64 queryid, bool minmax_only)
> {
> HASH_SEQ_STATUS hash_seq;
> pgssEntry *entry;
> + Counters *entry_counters;
>
> Do we really need an extra
On Sun, Apr 3, 2022 at 11:05 AM Thomas Munro wrote:
>
> 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 can confirm the problem on v10 as well.
--
John Naylor
EDB: http://www.enterprisedb.com
Or those three columns always, sum_lag sum_lag_2, min_lag max_lag,
skipped, retried retries?
What about this? (a log line is not actually folded)
interval_start num_transactions sum_latency sum_latency_2 min_latency
max_latency
failures serialization_failures deadlock_failures retried
I wrote:
> Cool. I've pushed the patch.
Hmm ... buildfarm's not entirely happy [1][2][3]:
diff -U3
/home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/expected/interval.out
/home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/results/interval.out
---
On Sun, Apr 03, 2022 at 07:32:47AM +0300, Andrei Zubkov wrote:
> v11 attached
+ /* When requested reset only min/max statistics of an entry */ \
+ entry_counters = >counters; \
+ for (int kind = 0; kind < PGSS_NUMKIND; kind++) \
+ { \
+
>> I think the problem is not merely one of documentation, but one of
>> bad design. Up to now it was possible to tell what was what from
>> counting the number of columns in the output; but with this design,
>> that is impossible. That should be fixed. The first thing you have
>> got to do is
70 matches
Mail list logo
