On Fri, Sep 18, 2020 at 6:02 PM Ajin Cherian wrote:
>
I have reviewed v4-0001 patch and I have a few comments. I haven't
yet completely reviewed the patch.
1.
+ /*
+ * Process invalidation messages, even if we're not interested in the
+ * transaction's contents, since the various caches need to
On Fri, Sep 18, 2020 at 05:22:15PM +0900, Michael Paquier wrote:
> Okay, after looking at that, here is v3. This includes range checks
> as well as errno checks based on strtol(). What do you think?
This fails in the CF bot on Linux because of pg_logging_init()
returning with errno=ENOTTY in the
On Sun, Sep 20, 2020 at 6:36 AM Thomas Munro wrote:
>
> On Thu, Sep 17, 2020 at 5:41 AM Julien Rouhaud wrote:
> > On Tue, Sep 15, 2020 at 2:26 PM Peter Eisentraut
> > wrote:
> > > I'm confused now. I think we had mostly agreed on the v28 patch set,
> > > without this additional AM flag. There
On Tue, Sep 15, 2020 at 10:57:04PM +1200, David Rowley wrote:
> On Fri, 31 Jul 2020 at 20:41, Pierre Ducroquet wrote:
> >
> > In a recent audit, I noticed that application developers have a tendency to
> > abuse the distinct clause. For instance they use an ORM and add a distinct
> > at
> > the t
On Sat, Sep 19, 2020 at 5:06 PM Thomas Munro wrote:
> In the meantime, from the low-hanging-fruit department, here's a new
> version of the SLRU-fsync-offload patch. The only changes are a
> tweaked commit message, and adoption of C99 designated initialisers
> for the function table, so { [SYNC_H
On 9/19/20 12:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Here's how cross version upgrade testing works. It uses a cached version of
>> the binaries and data directory. The cache is only refreshed if there's a
>> buildfarm run on that branch. If not, the cached version will just sit the
>> One limitation of this approach is that \set can't span lines, so
>> writing complex queries would be kinda painful. But that would
>> be a good limitation to address separately; \set isn't the only
>> metacommand where can't-span-lines is a problem sometimes.
>> If you seriously want to pursue
Hi!
The beta-tester of PG13 reported a inconsistency in our current jsonpath
datetime() method implementation. By the standard format strings in datetime()
allows only characters "-./,':; " to be used as separators in format strings.
But our to_json[b]() serializes timestamps into XSD format wit
> On Sep 19, 2020, at 3:58 PM, John Naylor wrote:
>
> On Sat, Sep 19, 2020 at 1:46 PM Mark Dilger
> wrote:
>
>> 0002 and 0003 look good to me. I like the way you cleaned up a bit with the
>> unicode_norm_props struct, which makes the code a bit more tidy, and on my
>> compiler under -O2 i
On Sat, Sep 19, 2020 at 1:46 PM Mark Dilger
wrote:
> 0002 and 0003 look good to me. I like the way you cleaned up a bit with the
> unicode_norm_props struct, which makes the code a bit more tidy, and on my
> compiler under -O2 it does not generate any extra runtime dereferences, as
> the comp
On Thu, Sep 17, 2020 at 5:41 AM Julien Rouhaud wrote:
> On Tue, Sep 15, 2020 at 2:26 PM Peter Eisentraut
> wrote:
> > I'm confused now. I think we had mostly agreed on the v28 patch set,
> > without this additional AM flag. There was still some discussion on
> > what the AM flag's precise seman
On Sat, Sep 19, 2020 at 6:07 AM Fujii Masao wrote:
> - pgstat_report_wait_start(WAIT_EVENT_RECOVERY_PAUSE);
> - pg_usleep(100L);/* 1000 ms */
> - pgstat_report_wait_end();
> + WaitLatch(NULL, WL_EXIT_ON_PM_DEATH | WL_TIMEOUT, 1000,
>
I wrote:
> I was able to partially reproduce whelk's failure here. I got a
> couple of cases of "cannot freeze committed xmax", which then leads
> to the second NOTICE diff; but I couldn't reproduce the first
> NOTICE diff. That was out of about a thousand tries :-( so it's not
> looking like a p
John Naylor writes:
> I believe it's actually "lower than Op", and since POSTFIXOP is gone
> it doesn't seem to matter how low it is. In fact, I found that the
> lines with INDENT and UNBOUNDED now work as the lowest precedence
> declarations. Maybe that's worth something?
> Following on Peter E.
On Sat, 19 Sep 2020 at 19:20, Tom Lane wrote:
> Denis Gantsev writes:
> > I have a working proposal for a small feature, which I would describe in
> > one sentence as
> > "named parametrized queries".
>
> I can see the use of being able to insert parameters into a "macro",
> and you're right tha
On Thu, Sep 10, 2020 at 03:58:31PM +0900, Michael Paquier wrote:
> On Wed, Sep 09, 2020 at 09:37:42AM -0500, Justin Pryzby wrote:
> > I've added a few more.
>
> I have done an extra round of review on this patch series, and applied
> what looked obvious to me (basically the points already discusse
On Thu, Sep 10, 2020 at 12:19:55PM -0700, Yaroslav wrote:
> Disclaimer: I'm not a native speaker, so not sure those are actually
> incorrect, and can't offer non-trivial suggestions.
https://www.postgresql.org/message-id/flat/CAKFQuwZh3k_CX2-%2BNcZ%3DFZss4bX6ASxDFEXJTY6u4wTH%2BG8%2BKA%40mail.gmail
> On Sep 18, 2020, at 9:41 AM, John Naylor wrote:
>
> Attached is version 4, which excludes the output file from pgindent,
> to match recent commit 74d4608f5. Since it won't be indented again, I
> also tweaked the generator script to match pgindent for the typedef,
> since we don't want to los
Andrew Dunstan writes:
> Here's how cross version upgrade testing works. It uses a cached version of
> the binaries and data directory. The cache is only refreshed if there's a
> buildfarm run on that branch. If not, the cached version will just sit there
> till kingdom come. So all this should
On 9/19/20 10:43 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 9/18/20 6:05 PM, Tom Lane wrote:
>>> Done, you should be able to remove @#@ (NONE, bigint) from the
>>> kill list.
>> crake tests pg_upgrade back to 9.2, so I had to mangle those static
>> repos for non-live branches like this:
On Thu, Sep 10, 2020 at 01:37:10PM +0900, Michael Paquier wrote:
> On Wed, Sep 09, 2020 at 09:00:50PM -0500, Justin Pryzby wrote:
> > What would you want the checkpointer's ps to say ?
> >
> > Normally it just says:
> > postgres 3468 3151 0 Aug27 ?00:20:57 postgres: checkpointer
>
Amit Kapila writes:
> I think our assumption that changing the tests to have temp tables
> will make them safe w.r.t concurrent activity doesn't seem to be
> correct. We do set OldestXmin for temp tables aggressive enough that
> it allows us to remove all dead tuples but the test case behavior lie
Andrew Dunstan writes:
> On 9/18/20 6:05 PM, Tom Lane wrote:
>> Done, you should be able to remove @#@ (NONE, bigint) from the
>> kill list.
> crake tests pg_upgrade back to 9.2, so I had to mangle those static
> repos for non-live branches like this:
Oh, hm. Now that you mention that, I see sn
On Sun, Jul 12, 2020 at 08:57:00PM -0500, Justin Pryzby wrote:
> On Thu, Jun 04, 2020 at 10:30:47AM -0700, Andres Freund wrote:
> > On 2020-05-08 02:25:45 -0500, Justin Pryzby wrote:
> > > Seems to me it should, at least conditionally. At least if there's a
> > > function
> > > scan or a relation
On Sat, Sep 19, 2020 at 4:03 AM Tom Lane wrote:
>
> Robert Haas writes:
> > Cool, thanks to both of you for looking. Committed.
>
> Hmph, according to whelk this is worse not better:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=whelk&dt=2020-09-18%2017%3A42%3A11
>
> I'm at a loss t
On 9/18/20 6:05 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> Yeah, probably worth doing. It's a small enough change and it's only in
>>> the test suite.
>> OK, I'll go take care of that in a bit.
> Done, you should be able to remove @#@ (NONE, bigint) from the
> kill list.
>
>
On Sat, Sep 19, 2020 at 4:28 PM Peter Eisentraut
wrote:
>
> On 2020-09-19 11:37, Amit Kapila wrote:
> > I think we can change the documentation for parallel option to explain
> > it better. How about: "Perform index vacuum and index cleanup phases
> > of VACUUM in parallel using integer background
On 2020-09-19 11:37, Amit Kapila wrote:
I think we can change the documentation for parallel option to explain
it better. How about: "Perform index vacuum and index cleanup phases
of VACUUM in parallel using integer background workers (for the
details of each vacuum phase, please refer to Table 2
On Sat, Sep 19, 2020 at 1:58 PM Peter Eisentraut
wrote:
>
> If I read the code correctly, the VACUUM PARALLEL option is capped by
> the active max_parallel_maintenance_workers setting. So if I write
> VACUUM (PARALLEL 5), it will still only do 2 by default. Is that
> correct?
Yeah, but there is
If I read the code correctly, the VACUUM PARALLEL option is capped by
the active max_parallel_maintenance_workers setting. So if I write
VACUUM (PARALLEL 5), it will still only do 2 by default. Is that
correct? The documentation (VACUUM man page) seems to indicate a
different behavior.
I h
On Tue, Sep 8, 2020 at 7:02 PM Amit Kapila wrote:
>
> On Tue, Sep 8, 2020 at 7:53 AM Masahiko Sawada
> wrote:
I have fixed these review comments in the attached patch.
>
> Comments on the latest patch:
> =
> 1.
> +CREATE VIEW pg_stat_replication_slots AS
> +SELEC
+1 !
An other way is to log evictions, it provides informations about time and
amount :
for (i = 0; i < nvictims; i++)
{
hash_search(pgssp_hash, &entries[i]->key, HASH_REMOVE, NULL);
}
pfree(entries);
/* trace when evicting entries, if app
Bonjour Michaël,
https://www.postgresql.org/message-id/CAMN686ExUKturcWp4POaaVz3gR3hauSGBjOCd0E-Jh1zEXqf_Q%40mail.gmail.com
Since then, the patch is failing to apply. As this got zero activity
for the last six months, I am marking the entry as returned with
feedback in the CF app.
Hmmm… I
33 matches
Mail list logo
