Hi fabien,
>> So overall gain by the patch is around 15%, whereas the last test
>> before the commit was 14%. It seems the patch is still beneficial
>> after the commit.
>
> Yes, that's good!
Yeah!
> I had a quick look again, and about the comment:
>
> /*
> * If partitioning is not enabled
On Sat, 3 Jul 2021 at 11:04, Dean Rasheed wrote:
> Thinking about this more, I think it's best not to risk back-patching.
> It *might* be safe, but it's difficult to really be sure of that. The
> bug itself is pretty unlikely to ever happen in practice, hence the
> lack of prior complaints, and in
On Sat, 3 Jul 2021 at 08:06, Fabien COELHO wrote:
>
> Here is a v4, which:
>
> - moves the stuff to common and fully removes random/srandom (Tom)
> - includes a range generation function based on the bitmask method (Dean)
> but iterates with splitmix so that the state always advances once
On Sat, 3 Jul 2021 at 22:44, Peter Eisentraut
wrote:
> I don't think this is a good change.
> I think we should leave it as is.
I'm inclined to agree.
When I mentioned adding a comment I'd not imagined it would be quite
so verbose. Plus, I struggle to imagine there's any compiler out there
that
Hello Dean,
- moves the stuff to common and fully removes random/srandom (Tom)
- includes a range generation function based on the bitmask method (Dean)
but iterates with splitmix so that the state always advances once (Me)
At the risk of repeating myself: do *not* invent your own sc
On Sat, 3 Jul 2021 at 00:40, Laurenz Albe wrote:
>
> On Fri, 2021-07-02 at 23:31 +1200, David Rowley wrote:
> > I had a look at the patch in [1] and I find it a bit weird that we'd
> > write the following about autovacuum_work_mem in our docs:
> >
> > +
> > +Note that VACUUM has a h
On 7/3/21 6:59 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> Seems reasonable. I don't have a CCA animal any more, but I guess I
>>> could set up a test.
>> I can run a test here --- I'll commandeer sifaka for awhile,
>> since that's the fastest animal I have.
> Done, and here's t
On Sun, 4 Jul 2021 at 10:35, Fabien COELHO wrote:
>
> I did not understand why it is not correct.
>
Well, to make it easier to visualise, let's imagine our word size is
just 3 bits instead of 64 bits, and that the basic prng() function
generates numbers in the range [0,8). Similarly, imagine a sp
On Fri, Jul 02, 2021 at 09:52:10AM -0400, Andrew Dunstan wrote:
> Agreed.
Applied.
--
Michael
signature.asc
Description: PGP signature
Here https://gist.github.com/mingodad/49291e0e9505522c66fcd3fcea4a939d I
posted the postgresql-13.3/src/backend/parser/gram.y with positional
references by named references that is supported by bison for some time now.
It was done with a custom script and some comments are missing, if there
is
On Sat, 17 Apr 2021 at 00:03, Matthias van de Meent
wrote:
> PFA an updated patch. I've updated the wording of the previous patch,
> and also updated this section in alter_table.sgml, but with different
> wording, explictly explaining the process used to validate the altered
> default constraint.
On Sat, 3 Jul 2021 at 06:23, Tom Lane wrote:
> So I'm inclined to propose pushing this and seeing what happens.
Is this really sane?
As much as I would like to see the 65k limit removed, I just have
reservations about fixing it in this way. Even if we get all the
cases fixed in core, there's li
Andrew Dunstan writes:
> On 7/3/21 6:59 PM, Tom Lane wrote:
>> So I think it's ready to go into the buildfarm, modulo any
>> cosmetic work you might want to do.
> Yeah, I'm looking at it now. A couple of things: I think we should
> probably call the setting 'use_clobber_cache_always' since that's
Greetings,
* vignesh C (vignes...@gmail.com) wrote:
> On Wed, Apr 7, 2021 at 12:13 PM osumi.takami...@fujitsu.com
> wrote:
> > Mainly affected by a commit 9de9294,
> > I've fixed minor things to rebase the patch.
> > All modifications I did are cosmetic changes and
> > a little bit of documentati
David Rowley writes:
> Is this really sane?
> As much as I would like to see the 65k limit removed, I just have
> reservations about fixing it in this way. Even if we get all the
> cases fixed in core, there's likely a whole bunch of extensions
> that'll have bugs as a result of this for many ye
Domingo Alvarez Duarte writes:
> Here https://gist.github.com/mingodad/49291e0e9505522c66fcd3fcea4a939d I
> posted the postgresql-13.3/src/backend/parser/gram.y with positional
> references by named references that is supported by bison for some time now.
When is "some time now"?
Currently, we
Now suppose we want a random number in the range [0,6). This is what
happens with your algorithm for each of the possible prng() return
values:
prng() returns 0 -- OK
prng() returns 1 -- OK
prng() returns 2 -- OK
prng() returns 3 -- OK
prng() returns 4 -- OK
prng() returns 5 -- OK
prng()
On Sun, 4 Jul 2021 at 17:03, Fabien COELHO wrote:
>
> > As for determinism, the end result is still fully deterministic.
>
> The result is indeed deterministic of you call the function with the same
> range. However, if you change the range value in one place then sometimes
> the state can advance
Over in [1] it is demonstrated that with CLOBBER_CACHE_ALWAYS enabled,
initdb accounts for a full 50% of the runtime of "make check-world"
(well, actually of the buildfarm cycle, which is not quite exactly
that but close). Since initdb certainly doesn't cost that much
normally, I wondered why it i
As I've been poking around in this area, I find myself growing
increasingly annoyed at the new GUC name
"debug_invalidate_system_caches_always". It is too d*mn long.
It's a serious pain to type in any context where you don't have
autocomplete to help you. I've kept referring to this type of
testi
The important property of determinism is that if I set a seed, and then
make an identical set of calls to the random API, the results will be
identical every time, so that it's possible to write tests with
predictable/repeatable results.
Hmmm… I like my stronger determinism definition more t
Hi hackers,
We recently ran into an issue where the visibility map of a relation was
corrupt, running Postgres 12.4. The error we'd get when running a SELECT * from
this table is:
could not access status of transaction 3704450152
DETAIL: Could not open file "pg_xact/0DCC": No such file or dire
On Sun, Jul 4, 2021 at 1:44 PM Floris Van Nee wrote:
> We recently ran into an issue where the visibility map of a relation was
> corrupt, running Postgres 12.4. The error we'd get when running a SELECT *
> from this table is:
>
> could not access status of transaction 3704450152
> DETAIL: Coul
On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always". It is too d*mn long.
> It's a serious pain to type in any context where you don't have
>
> On Sun, Jul 4, 2021 at 1:44 PM Floris Van Nee
> wrote:
> > We recently ran into an issue where the visibility map of a relation was
> corrupt, running Postgres 12.4. The error we'd get when running a SELECT *
> from this table is:
> >
> > could not access status of transaction 3704450152
> > DET
On Sun, Jul 4, 2021 at 2:26 PM Floris Van Nee wrote:
> > Have you ever used pg_upgrade on this database?
> >
>
> Yes. The last time (from v11 to v12) was in October 2020. The transaction id
> in the tuples (the one PG is trying to check in the tx log) dated from
> February 2021. I do believe (bu
On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
> and the word "always" seems rather confusing --- if it does
> something "always", why is there more than one level? So a simple
> proposal is to rename it to "debug_invalidate_caches".
+1 to remove "always"
--
Justin
>
> I wonder if it's related to this issue:
>
> https://www.postgresql.org/message-
> id/20210423234256.hwopuftipdmp3...@alap3.anarazel.de
>
> Have you increased autovacuum_freeze_max_age from its default? This
> already sounds like the kind of database where that would make sense.
>
autovacuu
On Sun, Jul 04, 2021 at 11:02:01AM -0400, Stephen Frost wrote:
> Rather than RfC, the appropriate status seems like it should be
> Rejected, as otherwise it's just encouraging someone to ultimately waste
> their time rebasing and updating the patch when it isn't going to ever
> actually be committe
On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote:
> My bad. I was talking about the cases when do_pg_stop_backup is called
> while the server is in recovery mode i.e. backup_started_in_recovery =
> RecoveryInProgress(); evaluates to true. I'm not sure in these cases
> whether we sh
On Monday, July 5, 2021 10:32 AM Michael Paquier wrote:
> On Sun, Jul 04, 2021 at 11:02:01AM -0400, Stephen Frost wrote:
> > Rather than RfC, the appropriate status seems like it should be
> > Rejected, as otherwise it's just encouraging someone to ultimately
> > waste their time rebasing and updat
On Thu, Jul 1, 2021 at 10:43 AM Euler Taveira wrote:
>
> Amit, thanks for rebasing this patch. I already had a similar rebased patch in
> my local tree. A recent patch broke your version v15 so I rebased it.
>
> I like the idea of a simple create_estate_for_relation() function (I fixed an
> oversi
At Sun, 4 Jul 2021 14:12:34 -0700, Noah Misch wrote in
> > However, I think we should also give serious consideration to
> > "debug_clobber_cache" or "debug_clobber_cache_always" for continuity
> > with past practice (though it still feels like "always" is a good
> > word to lose now). "debug_cl
On Mon, Jul 5, 2021 at 1:57 AM Tom Lane wrote:
>
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always". It is too d*mn long.
> It's a serious pain to type in any context where you don't have
> autocomp
At Fri, 2 Jul 2021 10:27:21 +0900, Michael Paquier wrote
in
> On Mon, Jun 28, 2021 at 11:01:57AM -0400, Tom Lane wrote:
> > Dunno ... I cannot recall ever having had that as a debugging requirement
> > in a couple of decades worth of PG bug-chasing. If the postmaster is
> > dying, you generally
On Mon, Jul 5, 2021 at 1:57 AM Tom Lane wrote:
>
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always". It is too d*mn long.
> It's a serious pain to type in any context where you don't have
> autocomp
I tried reviewing the remaining patches. It seems to work correctly,
and passes the tests on my laptop.
> In this pattern I flipped PointerGetDatum(a) to PointerGetDatum(ra.lower),
> because it seems to me correct. I've followed rule of thumb: every sort
> function must extract and use "lower"
On 2021/06/30 10:05, Masahiko Sawada wrote:
> On Fri, Jun 25, 2021 at 9:53 AM Masahiro Ikeda
> wrote:
>>
>> Hi Jamison-san, sawada-san,
>>
>> Thanks for testing!
>>
>> FWIF, I tested using pgbench with "--rate=" option to know the server
>> can execute transactions with stable throughput. As s
Fabien COELHO писал 2021-07-04 23:29:
The important property of determinism is that if I set a seed, and
then make an identical set of calls to the random API, the results
will be identical every time, so that it's possible to write tests
with predictable/repeatable results.
Hmmm… I like my s
Le vendredi 2 juillet 2021, 10:39:44 CEST David Rowley a écrit :
> On Fri, 2 Jul 2021 at 19:54, Ronan Dunklau wrote:
> > I don't know if it's acceptable, but in the case where you add both an
> > aggregate with an ORDER BY clause, and another aggregate without the
> > clause, the output for the un
40 matches
Mail list logo
