On 2020-09-18 18:49, Julien Rouhaud wrote:
Did you consider also adding the cumulated number of
evicted entries? This could be useful to know how to configure
pg_stat_statements.max.
Thank you for your comments!
I overlooked the cumulated number of evicted entries.
This statistic looks importa
From: Amit Kapila
> The idea is that we can't use this optimization if the value is not
> cached because we can't rely on lseek behavior. See all the discussion
> between Horiguchi-San and me in the thread above. So, how would you
> ensure that if we don't use Kirk-San's proposal?
Hmm, buggy Linu
On 2020-09-23 03:50, Michael Paquier wrote:
On Tue, Sep 22, 2020 at 11:45:14PM +0200, Peter Eisentraut wrote:
However, I still think the integer type use is a bit inconsistent. In both
cases, using strtoul() and dealing with unsigned integer types between
parsing and final use would be more con
On 2020-09-22 22:42, David Rowley wrote:
On Tue, 22 Sep 2020 at 19:08, David Rowley wrote:
I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc
9.3. I'm unable to see any gains with this, however, the results were
pretty noisy. I only ran pgbench for 60 seconds per query. I'll
Hi Alvaro,
Studying the patch to understand how it works.
On Tue, Aug 4, 2020 at 8:49 AM Alvaro Herrera wrote:
> Why two transactions? The reason is that in order for this to work, we
> make a catalog change (mark it detached), and commit so that all
> concurrent transactions can see the change
Hi
I made a slight update to the patch
> > > I found some more places that should use appendPQExrBufferStr instead
> > of appendPQExpBuffer.
> > >
> > > Here is the patch.
> >
> > Seems like a good idea. Please add it to the next commitfest.
>
> Thanks, added it to the next commitfest.
> https:
From: Jamison, Kirk/ジャミソン カーク
> I revised the patch based from my understanding of Horiguchi-san's comment,
> but I could be wrong.
> Quoting:
>
> "
> + /* Get the number of blocks for the supplied relation's
> fork */
> + nblocks = smgrnblocks(smgr_reln,
>
On Wed, Sep 23, 2020 at 8:04 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Amit Kapila
> > > > > Don't
> > > > > we need to guarantee the cache to be valid while recovery?
> > > > >
> > > >
> > > > One possibility could be that we somehow detect that the value we
> > > > are using is cached one
On Wed, Sep 23, 2020 at 7:56 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> (3)
> if (reln->smgr_cached_nblocks[forknum] == blocknum)
> reln->smgr_cached_nblocks[forknum] = blocknum + 1;
> else
> + {
> + /*
> +* DropRelFileNodeBuffers
On Tue, Sep 22, 2020 at 5:18 PM Ajin Cherian wrote:
>
> On Sun, Sep 20, 2020 at 3:31 PM Dilip Kumar wrote:
>
> > 3.
> >
> > + /*
> > + * If it's ROLLBACK PREPARED then handle it via callbacks.
> > + */
> > + if (TransactionIdIsValid(xid) &&
> > + !SnapBuildXactNeedsSkip(ctx->snapshot_builder, buf
On Fri, 3 Apr 2020 at 17:43, Andrey Lepikhov wrote:
> v.23 in attachment:
Hi,
This is only a partial review as I see the patch still does not
incorporate the self join detection method I mentioned in March 2019
and the one the patch only partially works.
Here's the partial review which contains
On Wednesday, September 23, 2020 11:26 AM, Tsunakawa, Takayuki wrote:
> I looked at v14.
Thank you for checking it!
> (1)
> + /* Get the total number of blocks for the supplied relation's
> fork */
> + for (j = 0; j < nforks; j++)
> + {
> +
On Wed, Sep 23, 2020 at 4:09 PM Michael Paquier wrote:
> On Tue, Sep 22, 2020 at 07:05:36PM -0700, Andres Freund wrote:
> > On 2020-09-23 13:45:51 +1200, Thomas Munro wrote:
> >> I think we should be ensuring that directory entries for newly created
> >> multixact files are durable at checkpoint t
On Tue, Sep 22, 2020 at 07:05:36PM -0700, Andres Freund wrote:
> On 2020-09-23 13:45:51 +1200, Thomas Munro wrote:
>> I think we should be ensuring that directory entries for newly created
>> multixact files are durable at checkpoint time. Please see attached.
>
> Good catch! Probably that should
On Wed, Sep 23, 2020 at 2:27 PM David Rowley wrote:
> I've gone as far as running the recovery tests on the v3-0001 patch
> using a Windows machine. They pass:
Thanks! I pushed that one, because it was effectively a bug fix
(WaitLatch() without a latch was supposed to work).
I'll wait longer fo
From: Amit Kapila
> > > > Don't
> > > > we need to guarantee the cache to be valid while recovery?
> > > >
> > >
> > > One possibility could be that we somehow detect that the value we
> > > are using is cached one and if so then only do this optimization.
> >
> > I basically like this direction.
On Sun, 20 Sep 2020 at 09:29, Thomas Munro wrote:
>
> Although I know from CI that this builds and passes "make check" on
> Windows, I'm hoping to attract some review of the 0001 patch from a
> Windows person, and confirmation that it passes "check-world" (or at
> least src/test/recovery check) th
I looked at v14.
(1)
+ /* Get the total number of blocks for the supplied relation's
fork */
+ for (j = 0; j < nforks; j++)
+ {
+ BlockNumber block = smgrnblocks(smgr_reln,
forkNum[j]);
+ nblocks +
On Wed, Sep 23, 2020 at 10:41:10AM +0900, Michael Paquier wrote:
> I think that this remark is a bit unfair. When it comes to any patch
> in the commit fest, and I have managed a couple of them over the
> years, I have tried to keep a neutral view for all of them, meaning
> that I only let the num
Hi,
On 2020-09-23 13:45:51 +1200, Thomas Munro wrote:
> I think we should be ensuring that directory entries for newly created
> multixact files are durable at checkpoint time. Please see attached.
Good catch! Probably that should probably be backpatched...
Greetings,
Andres Freund
On Tue, Sep 22, 2020 at 05:35:48PM -0400, Tom Lane wrote:
> What exactly do you argue has changed since the previous decision
> that should cause us to change it? In particular, where is the
> additional data to change our minds about the safety of such a thing?
Not sure that's safe, as we also w
On Tue, Sep 22, 2020 at 9:08 AM Thomas Munro wrote:
> On Mon, Sep 21, 2020 at 2:19 PM Thomas Munro wrote:
> > While scanning for comments and identifier names that needed updating,
> > I realised that this patch changed the behaviour of the ShutdownXXX()
> > functions, since they currently flush
On Tue, Sep 22, 2020 at 11:45:14PM +0200, Peter Eisentraut wrote:
> However, I still think the integer type use is a bit inconsistent. In both
> cases, using strtoul() and dealing with unsigned integer types between
> parsing and final use would be more consistent.
No objections to that either, s
Hello hackers,
I think we should be ensuring that directory entries for newly created
multixact files are durable at checkpoint time. Please see attached.
From 89e5b787ea5efd03ced8da46f95f236e03bf4adf Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Wed, 23 Sep 2020 13:02:27 +1200
Subject: [PAT
On Mon, Sep 21, 2020 at 10:41:46AM -0300, Alvaro Herrera wrote:
> "A couple of weeks" of inactivity is not sufficient, in my view, to boot
> a patch out of the commitfest process. Whenever the patch is
> resurrected, it will be a new entry which won't have the history that it
> had accumulated in
Peter Geoghegan writes:
> On Mon, Sep 21, 2020 at 2:09 PM Robert Haas wrote:
>> +REVOKE ALL ON FUNCTION
>> +verify_heapam(regclass, boolean, boolean, cstring, bigint, bigint)
>> +FROM PUBLIC;
>>
>> This too.
> Do we really want to use a cstring as an enum-like argument?
Ugh. We should not be
I wrote:
> Yeah. In a quick scan, it appears that there is only one caller that
> tries to save the result directly. So I considered making that caller
> do a pstrdup and eliminating the extra thrashing in t_readline itself.
> But it seemed too fragile; somebody would get it wrong and then have
>
From: Andrey Lepikhov
> Thank you for this work!
> As I can see, main development difficulties placed in other areas: CSN,
> resolver,
> global deadlocks, 2PC commit... I'm not lawyer too. But if we get remarks from
> the patent holders, we can rewrite our Clock-SI implementation.
Yeah, I unders
On Sat, Aug 29, 2020 at 10:48 AM Mark Dilger
wrote:
> I had an earlier version of the verify_heapam patch that included a
> non-throwing interface to clog. Ultimately, I ripped that out. My reasoning
> was that a simpler patch submission was more likely to be acceptable to the
> community.
I
On Mon, Sep 21, 2020 at 2:09 PM Robert Haas wrote:
> +REVOKE ALL ON FUNCTION
> +verify_heapam(regclass, boolean, boolean, cstring, bigint, bigint)
> +FROM PUBLIC;
>
> This too.
Do we really want to use a cstring as an enum-like argument?
I think that I see a bug at this point in check_tuple() (i
Daniel Gustafsson writes:
>> On 22 Sep 2020, at 23:24, Tom Lane wrote:
>> In the same vein, here's a patch to remove the hard-coded line length
>> limit for tsearch dictionary files.
> LGTM. I like the comment on why not to return buf.data directly, that detail
> would be easy to miss.
Yeah.
On 2020-09-20 05:41, Michael Paquier wrote:
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_loggi
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> Attached patch adds the TOAST to pg_class, and let's open again the
> discussion around it.
What exactly do you argue has changed since the previous decision
that should cause us to change it? In particular, where is the
additional data to chang
> On 22 Sep 2020, at 23:24, Tom Lane wrote:
>
> In the same vein, here's a patch to remove the hard-coded line length
> limit for tsearch dictionary files.
LGTM. I like the comment on why not to return buf.data directly, that detail
would be easy to miss.
cheers ./daniel
Hi,
On Tue, 2020-09-22 at 10:57 +0200, Christoph Berg wrote:
> Note that I'm working on the .deb packages for Debian and Ubuntu. For
> .rpm (RHEL, SLES) you need to get Devrim on board. (I'm putting him
> on Cc.)
Thanks!
To be able to keep up with the other architectures when building
> binarie
In the same vein, here's a patch to remove the hard-coded line length
limit for tsearch dictionary files.
regards, tom lane
diff --git a/src/backend/tsearch/dict_thesaurus.c b/src/backend/tsearch/dict_thesaurus.c
index cb0835982d..64c979086d 100644
--- a/src/backend/tsearc
Hi all,
I know it has been discussed before [1] but one of our customers complained
about something weird on one of their multi-tenancy databases (thousands of
schemas with a lot of objects inside and one user by schema).
So when I checked the problem is because the missing TOAST for pg_class,
an
From: Ashutosh Bapat
> parallelism here has both pros and cons. If one of the servers errors
> out while preparing for a transaction, there is no point in preparing
> the transaction on other servers. In parallel execution we will
> prepare on multiple servers before realising that one of them has
On Tue, 22 Sep 2020 at 19:08, David Rowley wrote:
> I ran another scale=5 TPCH benchmark on v4 against f859c2ffa using gcc
> 9.3. I'm unable to see any gains with this, however, the results were
> pretty noisy. I only ran pgbench for 60 seconds per query. I'll likely
> need to run that a bit longe
On Tue, Sep 22, 2020 at 12:41 PM Robert Haas wrote:
> But now I see that there's no secondary permission check in the
> verify_nbtree.c code. Is that intentional? Peter, what's the
> justification for that?
As noted by comments in contrib/amcheck/sql/check_btree.sql (the
verify_nbtree.c tests), t
Robert Haas writes:
> On Mon, Sep 21, 2020 at 3:53 PM Andres Freund wrote:
>> I think we mostly use it for the few places where we currently expose
>> data as a signed integer on the SQL level, but internally actually treat
>> it as a unsigned data.
> So why is the right solution to that not Dat
Daniel Gustafsson writes:
> [ 0001-Refactor-pg_service.conf-and-pg_restore-TOC-file-par.patch ]
I reviewed this and noticed that you'd missed adding resetStringInfo
calls in some code paths, which made me realize that while
pg_get_line_append() is great for its original customer in hba.c,
it kind
On Mon, Sep 21, 2020 at 3:53 PM Andres Freund wrote:
> On 2020-09-21 14:08:22 -0400, Robert Haas wrote:
> > There is no SQL type corresponding to the C data type uint32, so I'm
> > not sure why we even have DatumGetUInt32. I'm sort of suspicious that
> > there's some fuzzy thinking going on there
On Tue, Sep 22, 2020 at 1:55 PM Mark Dilger
wrote:
> I am inclined to just restrict verify_heapam() to superusers and be done.
> What do you think?
I think that's an old and largely failed approach. If you want to use
pg_class_ownercheck here rather than pg_class_aclcheck or something
like that
Hi
I found another bug
create view xx as WITH recursive destinations (departure, arrival,
connections, cost, itinerary) AS
(SELECT f.departure, f.arrival, 1, price,
CAST(f.departure || f.arrival AS VARCHAR(2000))
FROM flights f
WHERE f.departure = 'New
Hi
út 22. 9. 2020 v 20:01 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> I have implemented the SEARCH and CYCLE clauses.
>
> This is standard SQL syntax attached to a recursive CTE to compute a
> depth- or breadth-first ordering and cycle detection, respectively.
> Thi
On Tue, Sep 22, 2020 at 10:55 AM Mark Dilger
wrote:
> I am inclined to just restrict verify_heapam() to superusers and be done.
> What do you think?
The existing amcheck functions were designed to have execute privilege
granted to non-superusers, though we never actually advertised that
fact. M
> On Sep 21, 2020, at 2:09 PM, Robert Haas wrote:
>
> I think there should be a call to pg_class_aclcheck() here, just like
> the one in pg_prewarm, so that if the superuser does choose to grant
> access, users given access can check tables they anyway have
> permission to access, but not othe
On Tue, Sep 22, 2020 at 9:52 PM Konstantin Knizhnik
wrote:
> On 20.08.2020 10:36, Kyotaro Horiguchi wrote:
> > Come to think of "complex", ExecAsync stuff in this patch might be
> > too-much for a short-term solution until executor overhaul, if it
> > comes shortly. (the patch of mine here as a wh
After further thought about this, I concluded that a much better idea
is to just exclude fmgrprotos.h from the pgindent run. While renaming
these two functions may or may not be worthwhile, it doesn't provide
any sort of permanent fix for fmgrprotos.h, because new typedef conflicts
could arise at
On 22.09.2020 16:40, Konstantin Knizhnik wrote:
On 22.09.2020 15:52, Konstantin Knizhnik wrote:
On 20.08.2020 10:36, Kyotaro Horiguchi wrote:
At Wed, 19 Aug 2020 23:25:36 -0500, Justin Pryzby
wrote in
On Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:
As the result of a
Hi,
Am Dienstag, den 22.09.2020, 16:26 +0200 schrieb Michael Banck:
> Am Mittwoch, den 02.09.2020, 16:50 +0300 schrieb Anastasia Lubennikova:
> > I've looked through the previous discussion. As far as I got it, most of
> > the controversy was about online checksums improvements.
> >
> > The warn
Hi,
Am Mittwoch, den 02.09.2020, 16:50 +0300 schrieb Anastasia Lubennikova:
> On 01.09.2020 13:22, Michael Banck wrote:
> > as a continuation of [1], I've split-off the zero page header case from
> > the last patch, as this one seems less contentious.
> > [1] https://commitfest.postgresql.org/28/2
Daniel Gustafsson writes:
>> On 21 Sep 2020, at 20:55, Tom Lane wrote:
>> Here's a proposed patch to fix it that way.
> +1 on this patch. Do you think it's worth adding a note about this in the
> documentation to save the next one staring at this a few minutes? Something
> along the lines of:
On 22.09.2020 15:52, Konstantin Knizhnik wrote:
On 20.08.2020 10:36, Kyotaro Horiguchi wrote:
At Wed, 19 Aug 2020 23:25:36 -0500, Justin Pryzby
wrote in
On Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:
As the result of a discussion with Fujita-san off-list, I'm going to
On Tue, Sep 22, 2020 at 6:48 AM tsunakawa.ta...@fujitsu.com
wrote:
>
>
> > I think it's not necessarily that all FDW implementations need to be
> > able to support xa_complete(). We can support both synchronous and
> > asynchronous executions of prepare/commit/rollback.
>
> Yes, I think parallel p
On 20.08.2020 10:36, Kyotaro Horiguchi wrote:
At Wed, 19 Aug 2020 23:25:36 -0500, Justin Pryzby wrote
in
On Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:
As the result of a discussion with Fujita-san off-list, I'm going to
hold off development until he decides whether mine
> On 22 Sep 2020, at 11:37, Peter Eisentraut
> wrote:
>
> On 2020-09-18 16:11, Daniel Gustafsson wrote:
>> Since we support ciphers that are now deprecated, we have no other choice
>> than
>> to load the legacy provider.
>
> Well, we could just have deprecated ciphers fail, unless the user loa
> On 21 Sep 2020, at 17:09, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> The pg_service.conf parsing thread [0] made me realize that we have a
>> hardwired
>> line length of max 256 bytes. Lifting this would be in line with recent work
>> for ecpg, pg_regress and pg_hba (784b1ba1a2 and 8f8
On Sun, Sep 20, 2020 at 3:31 PM Dilip Kumar wrote:
> 1.
> + /*
> + * Process invalidation messages, even if we're not interested in the
> + * transaction's contents, since the various caches need to always be
> + * consistent.
> + */
> + if (parsed->nmsgs > 0)
> + {
> + if (!ctx->fast_forward)
>
On Tue, Sep 22, 2020 at 12:02 PM Amit Kapila wrote:
>
> On Tue, Sep 22, 2020 at 8:34 AM Ashutosh Sharma wrote:
> >
> > On Mon, Sep 21, 2020 at 6:58 PM Amit Kapila wrote:
> > >
> > > On Mon, Sep 21, 2020 at 6:27 PM Ashutosh Sharma
> > > wrote:
> > > >
> > > > Thanks Dilip for the patch. AFAIU,
On Thu, Sep 17, 2020 at 11:06 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
>
> On Wed, Sep 16, 2020 at 1:20 PM Greg Nancarrow
wrote:
> >
> > Fortunately I have been given permission to share the exact table
> > definition and data I used, so you can check the behaviour and
On 2020-09-18 16:11, Daniel Gustafsson wrote:
Since we support ciphers that are now deprecated, we have no other choice than
to load the legacy provider.
Well, we could just have deprecated ciphers fail, unless the user loads
the legacy provider in the OS configuration. There might be an argu
Re: Namrata Bhave
> We will be glad to obtain binaries for s390x on RHEL, SLES and Ubuntu
> distros.
Hi Namrata,
thanks for getting back to me.
Note that I'm working on the .deb packages for Debian and Ubuntu. For
.rpm (RHEL, SLES) you need to get Devrim on board. (I'm putting him on
Cc.)
> We
> On Tue, 22 Sep 2020 at 17:00, Hou, Zhijie wrote:
> > I found some more places that should use appendPQExrBufferStr instead
> of appendPQExpBuffer.
> >
> > Here is the patch.
>
> Seems like a good idea. Please add it to the next commitfest.
Thanks, added it to the next commitfest.
https://comm
> On 21 Sep 2020, at 20:55, Tom Lane wrote:
>
> Oh wait, I forgot about the fmgrprotos.h discrepancy.
>
> I wrote:
>> It strikes me that a low-cost workaround would be to rename these
>> C functions. There's no law that their C names must match the
>> SQL names.
>
> Here's a proposed patch to
22.09.2020 03:47, tsunakawa.ta...@fujitsu.com пишет:
Does this make sense from your viewpoint, and can we think that we can use
Clock-SI without infrindging on the patent? According to the patent holder,
the difference between Clock-SI and the patent seems to be fewer than the
similarities
On Tue, 22 Sep 2020 at 17:00, Hou, Zhijie wrote:
> I found some more places that should use appendPQExrBufferStr instead of
> appendPQExpBuffer.
>
> Here is the patch.
Seems like a good idea. Please add it to the next commitfest.
David
On Mon, 21 Sep 2020 at 19:15, Peter Eisentraut
wrote:
>
> On 2020-09-21 05:48, Amit Kapila wrote:
> > What according to you should be the behavior here and how will it be
> > better than current?
>
> I think if I write VACUUM (PARALLEL 5), it should use up to 5 workers
> (up to the number of index
On Fri, 11 Sep 2020 at 02:01, Peter Eisentraut
wrote:
>
> On 2020-09-06 02:24, David Rowley wrote:
> >> I would add DEBUG1 back into the conditional, like
> >>
> >> if (__builtin_constant_p(elevel) && ((elevel) >= ERROR || (elevel) <=
> >> DEBUG1) ? \
> >
> > hmm, but surely we don't want to move
70 matches
Mail list logo
