Hi, hackers
I have a problem about XLogReader callback system
In xlog.c, function StartupXLOG
xlogreader =
XLogReaderAllocate(wal_segment_size, NULL,
XL_ROUTINE(.page_read =
,
On 21/09/2020 16:29, Andrey M. Borodin wrote:
But thing that bothers me now: when we vacuum leaf page, we bump it's
NSN. But we do not bump internal page LSN. Does this means we will
follow rightlinks after vacuum? It seems superflous.
Sorry, I did not understand what you said above. Vacuum
po 28. 9. 2020 v 3:04 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I am sending another patch that tries to allow CachedPlans for CALL
> > statements. I think this patch is very accurate, but it is not nice,
> > because it is smudging very precious reference counting for CachedPlans.
On Mon, Sep 28, 2020 at 3:01 PM Amit Kapila wrote:
>
> On Tue, Sep 22, 2020 at 2:44 PM vignesh C wrote:
> >
> > Thanks Ashutosh for your comments.
> >
> > On Wed, Sep 16, 2020 at 6:36 PM Ashutosh Sharma
> > wrote:
> > >
> > > Hi Vignesh,
> > >
> > > I've spent some time today looking at your
Andy Fan schrieb am 28.09.2020 um 02:54:
> Well, that's very interesting. Specific to my user case,
> SELECT * FROM p WHERE pkey = to_date('2018-12-13', '-mm-dd)';
Why use to_date() at all for a constant value?
Can't you use a standard ANSI date literal (date '2018-12-13')?
Alternatively,
Thanks Andres for the comments.
On Thu, Sep 24, 2020 at 8:11 AM Andres Freund wrote:
>
> > The design:
>
> I think it'd be good if you could explain a bit more why you think this
> safe to do in the way you have done it.
>
> E.g. from a quick scroll through the patch, there's not even a comment
On Mon, Sep 28, 2020 at 8:45 AM Greg Nancarrow wrote:
>
> On Sat, Sep 26, 2020 at 3:30 PM Bharath Rupireddy
> wrote:
>
> > I further checked on full txn id and command id. Yes, these are
> > getting passed to workers via InitializeParallelDSM() ->
> > SerializeTransactionState(). I tried to
On Mon, Sep 28, 2020 at 7:15 AM Tom Lane wrote:
> Andy Fan writes:
> > On Mon, Sep 28, 2020 at 4:46 AM David Rowley
> wrote:
> >> Thanks for showing an interest in partition pruning. Unfortunately,
> >> it's not possible to use stable functions to prune partitions during
> >> planning.
>
> >
Re: Andres Freund
> > > Ok, but given that Debian is currently targeting 22 architectures, I
> > > doubt the PostgreSQL buildfarm covers all of them with the extra JIT
> > > option, so I should probably make sure to do that here when running tests.
> >
> > +1. I rather doubt our farm is
Hi,
In case of CTAS with no data, we actually do not insert the tuples
into the created table, so we can skip checking for the insert
permissions. Anyways, the insert permissions will be checked when the
tuples are inserted into the table.
Attaching a small patch doing $subject.
Thoughts?
With
Dear all
Since always I have used geometric types as a great pedagogical example in
order to understand how indexes work in PostgreSQL so that I can program
our indexes in MobilityDB
https://github.com/MobilityDB/MobilityDB
However, this requires to create tables with a big number of geometries.
On Mon, Sep 28, 2020 at 4:06 PM Bharath Rupireddy
wrote:
>
> On Mon, Sep 28, 2020 at 8:45 AM Greg Nancarrow wrote:
> >
> > On Sat, Sep 26, 2020 at 3:30 PM Bharath Rupireddy
> > wrote:
> >
> > > I further checked on full txn id and command id. Yes, these are
> > > getting passed to workers via
On Sun, Sep 27, 2020 at 7:52 PM Andy Fan wrote:
>
>
> On Mon, Sep 28, 2020 at 9:15 AM Tom Lane wrote:
>>
>> Andy Fan writes:
>> > Well, that's very interesting. Specific to my user case,
>> > SELECT * FROM p WHERE pkey = to_date('2018-12-13', '-mm-dd)';
>> > p has 1500+ partitions and
On 21/09/2020 17:19, Andrey M. Borodin wrote:
21 сент. 2020 г., в 18:29, Andrey M. Borodin написал(а):
It was a conscious decision with incorrect motivation. I was thinking that it will help
to reduce number of "false positive" inspecting right pages. But now I see that:
1. There should be no
On Mon, 28 Sep 2020 at 13:58, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > On Fri, 25 Sep 2020 at 18:21, tsunakawa.ta...@fujitsu.com
> > wrote:
> > > Why does the client backend have to create a new connection cache entry
> > during PREPARE or COMMIT PREPARE? Doesn't the
On 2020-09-17 13:46, Michael Paquier wrote:
On Fri, Jul 31, 2020 at 06:47:48PM +0900, torikoshia wrote:
Oops, sorry about that.
I just fixed it there for now.
The regression tests of the patch look unstable, and the CF bot is
reporting a failure here:
Hi, Anastasia!
> 28 авг. 2020 г., в 23:08, Anastasia Lubennikova
> написал(а):
>
> 1) The first patch is sensible and harmless, so I think it is ready for
> committer. I haven't tested the performance impact, though.
>
> 2) I like the initial proposal to make various SLRU buffers
Peter Smith writes:
> I only have a couple of questions, more for curiosity than anything else.
> 1. Why is there sometimes an extra *tm = variable introduced?
> (e.g. GetSQLCurrentTime, GetSQLLocalTime). Why not just declare struct
> pg_tm tm; and pass the same as what GetSQLCurrentDate does?
Hello,
On 2020-Sep-28, Wang, Shenhao wrote:
> I have a problem about XLogReader callback system
>
> In xlog.c, function StartupXLOG
>
> xlogreader =
> XLogReaderAllocate(wal_segment_size, NULL,
> XL_ROUTINE(.page_read =
> ,
Let me please bump the thread.
Just in case, I'm PgJDBC committer.
PgJDBC receives requests to "support CLOB" from time to time, however, I
believe it is impossible without the support from the database.
To my best knowledge, the database does not have APIs for "streaming large
text data".
The
"Hou, Zhijie" writes:
> May be we can make "int SPI_connect()" => "void SPI_connect()" and fix the
> doc ?
I don't see a lot of value in changing SPI_connect() in isolation.
It's part of an API suite that generally expects functions to
return error codes.
There was a previous thread [1] about
David Rowley writes:
> On Mon, 28 Sep 2020 at 15:35, Tom Lane wrote:
>> Poking around to count remaining uses of those inline functions,
>> I found a few places that should be using the macros instead,
>> and fixed them. After that, I notice that list_tail(),
>> list_third_cell(), and
Bharath Rupireddy writes:
> In case of CTAS with no data, we actually do not insert the tuples
> into the created table, so we can skip checking for the insert
> permissions. Anyways, the insert permissions will be checked when the
> tuples are inserted into the table.
I'd argue this is wrong.
Hi all,
(Moved the discussion to -hackers)
On Mon, Sep 28, 2020 at 03:48:12AM +, Michael Paquier wrote:
> Change SHA2 implementation based on OpenSSL to use EVP digest routines
>
> The use of low-level hash routines is not recommended by upstream
> OpenSSL since 2000, and pgcrypto already
On Wed, Jul 22, 2020 at 7:48 PM vignesh C wrote:
>
> On Tue, Jul 21, 2020 at 3:54 PM Amit Kapila wrote:
> >
>
> > Review comments:
> > ===
> >
> > 0001-Copy-code-readjustment-to-support-parallel-copy
> > 1.
> > @@ -807,8 +835,11 @@ CopyLoadRawBuf(CopyState cstate)
> > else
> >
On Fri, Sep 25, 2020 at 12:02 AM Tom Lane wrote:
> [ cc'ing Peter, since his opinion seems to have got us here in the first
> place ]
>
> Amit Langote writes:
> > On Thu, Sep 24, 2020 at 7:19 AM Tom Lane wrote:
> >> However, while I was looking at it I couldn't help noticing that
> >>
On Mon, Sep 28, 2020 at 2:44 PM Jesse Zhang wrote:
> On Sun, Sep 27, 2020 at 7:52 PM Andy Fan wrote:
> >
> >
> > On Mon, Sep 28, 2020 at 9:15 AM Tom Lane wrote:
> >>
> >> Andy Fan writes:
> >> > Well, that's very interesting. Specific to my user case,
> >> > SELECT * FROM p WHERE pkey =
From: Jamison, Kirk/ジャミソン カーク
> Is my understanding above correct?
No. I simply meant DropRelFileNodeBuffers() calls the following function, and
avoids the optimization if it returns InvalidBlockNumber.
BlockNumber
smgrcachednblocks(SMgrRelation reln, ForkNumber forknum)
{
On Mon, Sep 28, 2020 at 9:23 AM Andy Fan wrote:
> On Mon, Sep 28, 2020 at 2:44 PM Jesse Zhang wrote:
>
>> On Sun, Sep 27, 2020 at 7:52 PM Andy Fan wrote:
>> > On Mon, Sep 28, 2020 at 9:15 AM Tom Lane wrote:
>> >>
>> >> Yeah. It depends on the lc_time setting, and possibly also the
>> timezone
On Mon, Sep 28, 2020 at 6:36 PM Amit Kapila wrote:
>
> On Mon, Sep 28, 2020 at 1:13 PM Ajin Cherian wrote:
> >
> > On Wed, Sep 23, 2020 at 2:39 PM Amit Kapila wrote:
> >
> > I have added a new patch for supporting 2 phase commit semantics in
> > the streaming APIs for the logical decoding
On Tue, Sep 22, 2020 at 2:44 PM vignesh C wrote:
>
> Thanks Ashutosh for your comments.
>
> On Wed, Sep 16, 2020 at 6:36 PM Ashutosh Sharma wrote:
> >
> > Hi Vignesh,
> >
> > I've spent some time today looking at your new set of patches and I've
> > some thoughts and queries which I would like
po 28. 9. 2020 v 11:36 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Sep 25, 2020 at 06:43:38PM +0200, Pavel Stehule wrote:
> >
> > I checked this set of patches and it looks well.
> >
> > I have only one minor comment. I understand the error message, but I am
> not
> >
Hello
Found two more useless "return;" lines from the following code.
.src/backend/regex/regcomp.c
.src/interfaces/libpq/fe-secure.c
Maybe it's better to remove them together?
Previous discussion:
https://www.postgresql.org/message-id/20191128144653.GA27883@alvherre.pgsql
Best Regards,
Tang
On Monday, September 28, 2020 11:50 AM, Tsunakawa-san wrote:
> From: Amit Kapila
> > I agree with the above two points.
>
> Thank you. I'm relieved to know I didn't misunderstand.
>
>
> > > * Then, add a new function, say, smgrnblocks_cached() that simply
> > > returns
> > the cached block
On Mon, Sep 28, 2020 at 10:01 AM Keisuke Kuroda
wrote:
>
> > Okay. Feel free to clarify your questions if you have any? Are you
> > interested in writing a patch for the same?
>
> Thank you! Yes, I would like to write a patch.
> If you already have a discussed thread or patch for this idea,
>
On Mon, Sep 28, 2020 at 1:13 PM Ajin Cherian wrote:
>
> On Wed, Sep 23, 2020 at 2:39 PM Amit Kapila wrote:
>
> I have added a new patch for supporting 2 phase commit semantics in
> the streaming APIs for the logical decoding plugins. I have added 3
> APIs
> 1. stream_prepare
> 2.
On Monday, September 28, 2020 5:08 PM, Tsunakawa-san wrote:
> From: Jamison, Kirk/ジャミソン カーク
> > Is my understanding above correct?
>
> No. I simply meant DropRelFileNodeBuffers() calls the following function,
> and avoids the optimization if it returns InvalidBlockNumber.
>
>
>
> On Fri, Sep 25, 2020 at 06:43:38PM +0200, Pavel Stehule wrote:
>
> I checked this set of patches and it looks well.
>
> I have only one minor comment. I understand the error message, but I am not
> sure if without deeper knowledge I can understand.
>
> +update test_jsonb_subscript set
Michael Paquier writes:
> It looks like this commit has broken prairiedog as follows:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog=2020-09-28%2005%3A45%3A55
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
>
On 8/27/20 4:34 AM, Peter Eisentraut wrote:
> Procedures currently don't allow OUT parameters. The reason for this
> is that at the time procedures were added (PG11), some of the details
> of how this should work were unclear and the issue was postponed. I
> am now intending to resolve this.
>
Amit Langote writes:
> On Fri, Sep 25, 2020 at 12:02 AM Tom Lane wrote:
>> Well, I agree with Peter to that extent, but my opinion is that *none*
>> of these cases ought to be errors. What we're doing here is performing
>> an implicit assignment-level coercion of the expression to the type of
Hi Atsushi,
+1: Your proposal is a good answer for time based performance analysis
(even if parsing durationor blks are not differentiated) .
As it makes pgss number of columns wilder, may be an other solution
would be to create a pg_stat_statements_xxx view with the same key
as pgss
On 9/28/20 9:46 AM, Vladimir Sitnikov wrote:
> Let me please bump the thread.
>
> Just in case, I'm PgJDBC committer.
>
> PgJDBC receives requests to "support CLOB" from time to time, however,
> I believe it is impossible without the support from the database.
> To my best knowledge, the
On Mon, Sep 28, 2020 at 10:35 AM Kyotaro Horiguchi
wrote:
> At Sat, 26 Sep 2020 19:45:39 +0900, Etsuro Fujita
> wrote in
> > Here are some review comments on “ExecAsync stuff” (the 0002 patch):
> >
> > @@ -192,10 +196,20 @@ ExecInitAppend(Append *node, EState *estate, int
> > eflags)
> >
> >
>100% compatible with the MySQL
It is hardly a justification for a feature or for a change request.
Vladimir
On Mon, 28 Sep 2020 at 13:22, David Rowley wrote:
> I'm more leaning towards the fact that the planner picked the seqscan
> path in the first place. Unfotunately I don't have any great ideas on
> how to fix without fudging the costs a bit. Maybe we can make
> var_eq_non_const() divide down the
On Thu, Sep 24, 2020 at 7:50 PM Tomas Vondra
wrote:
>
> On Thu, Sep 24, 2020 at 05:18:03PM -0400, John Naylor wrote:
> >Hmm, how ugly would it be to change the default range size depending
> >on the opclass?
> >
>
> Not sure. What would happen for multi-column BRIN indexes with different
>
Andrew>To the best of my knowledge there is no concrete proposal for the
type
Andrew>of data type / interface you suggest.
To the best of my knowledge, one of the concrete proposals was in the very
first message.
Let me please copy it:
Vladimir> **Here goes the question**: do you think such an
On 9/28/20 4:44 PM, Vladimir Sitnikov wrote:
> Andrew>To the best of my knowledge there is no concrete proposal for
> the type
> Andrew>of data type / interface you suggest.
>
> To the best of my knowledge, one of the concrete proposals was in the very
> first message.
>
> Let me please copy
David Rowley writes:
> Any opinions on this?
This patch scares the heck out of me. It's a pretty much unprincipled
change in a fundamental selectivity estimator, which is going to affect
all sorts of queries not only the particular case you have in mind.
There's no reason to think that the
I wrote:
> list_second_cell() does have uses, although I observe that they
> are almost exclusively in locutions such as
> for_each_cell(lc, rollups, list_second_cell(rollups))
> to iterate over all-but-the-first elements of a list. I wonder if
> we ought to come up with a better notation
On Fri, 25 Sep 2020 at 22:07, Peter Eisentraut
wrote:
>
> I have been analyzing this issue again. We have a few candidate patches
> that do very similar things for avoiding dumping the generation
> expression of table gtest1_1. We can figure out later which one of
> these we like best. But
On Mon, Sep 28, 2020 at 9:17 PM Thomas Kellerer wrote:
> Andy Fan schrieb am 28.09.2020 um 02:54:
> > Well, that's very interesting. Specific to my user case,
> > SELECT * FROM p WHERE pkey = to_date('2018-12-13', '-mm-dd)';
>
> Why use to_date() at all for a constant value?
> Can't you use
On Tue, 29 Sep 2020 at 11:37, Tom Lane wrote:
>
> I wrote:
> > list_second_cell() does have uses, although I observe that they
> > are almost exclusively in locutions such as
> > for_each_cell(lc, rollups, list_second_cell(rollups))
> > to iterate over all-but-the-first elements of a list.
Thanks for chipping in here.
On Tue, 29 Sep 2020 at 12:08, Tom Lane wrote:
>
> David Rowley writes:
> > Any opinions on this?
>
> This patch scares the heck out of me. It's a pretty much unprincipled
> change in a fundamental selectivity estimator, which is going to affect
> all sorts of
On Tue, Sep 29, 2020 at 2:10 AM Tom Lane wrote:
> I think so too, so I pushed it.
Thanks!
Kind Regards,
Peter Smith
Fujitsu Australia
On Tue, 29 Sep 2020 at 12:08, Tom Lane wrote:
>
> David Rowley writes:
> > Any opinions on this?
>
> This patch scares the heck out of me. It's a pretty much unprincipled
> change in a fundamental selectivity estimator, which is going to affect
> all sorts of queries not only the particular
From: Jamison, Kirk/ジャミソン カーク
> I also did not remove the duplicate code from smgrnblocks because Amit-san
> mentioned that when the caching for non-recovery cases is implemented, we
> can use it for non-recovery cases as well.
But the extra code is not used now. The code for future usage
On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda wrote:
>
> On 2020-09-28 12:43, Amit Kapila wrote:
> > On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
> > wrote:
> >>
> >> At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
> >> wrote in
> >> > One other thing that occurred to me today is can't we
On Tue, Sep 29, 2020 at 7:21 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Jamison, Kirk/ジャミソン カーク
>
> Also, as Amit-san mentioned, the cause of the slight performance regression
> when shared_buffers is small needs to be investigated and addressed.
>
Yes, I think it is mainly because extra
David Rowley writes:
> On Tue, 29 Sep 2020 at 11:37, Tom Lane wrote:
>> Concretely, I'm thinking about the attached.
> I had a look over this and I like it. It seems good as it allows
> consumers to choose N programmatically rather than be fixed into using
> list_second_cell() or
On Tue, 29 Sep 2020 at 12:42, Tom Lane wrote:
>
> David Rowley writes:
> > It does seem fairly low risk and having personally experienced
> > backpatching pain, I understand your motivation to backpatch. I
> > certainly wouldn't object to backpacking but will defer to your better
> > judgement
On Tue, Sep 29, 2020 at 5:22 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >100% compatible with the MySQL
>
> It is hardly a justification for a feature or for a change request.
>
> Vladimir
>
>
Glad to see this topic.
The obviously different opinion for this feature is based on
On Mon, Sep 28, 2020 at 12:49:29PM -0400, Tom Lane wrote:
> I experimented and confirmed that explicitly initializing __pg_log_level
> would suppress this build error on prairiedog. However, I'm not sure
> that doing so is a good idea, because it seems to me that this animal
> has accidentally
On 2020-09-28 12:43, Amit Kapila wrote:
On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
wrote:
At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
wrote in
> One other thing that occurred to me today is can't we keep this as
> part of PgStat_GlobalStats? We can use
From: Masahiko Sawada
> No. Please imagine a case where a user executes PREPARE TRANSACTION on
> the transaction that modified data on foreign servers. The backend
> process prepares both the local transaction and foreign transactions.
> But another client can execute COMMIT PREPARED on the
> > May be we can make "int SPI_connect()" => "void SPI_connect()" and fix
> the doc ?
>
> I don't see a lot of value in changing SPI_connect() in isolation.
> It's part of an API suite that generally expects functions to return error
> codes.
>
> There was a previous thread [1] about getting
David Rowley writes:
> Yeah, I understand that part. The pain I was talking about was
> writing a patch for master, trying to apply it to the previous version
> only to find it does not apply. After fixing it up for that version
> trying to apply that patch to the version before that and getting
Hi
In (/src/pl/plpgsql/src/pl_exec.c), I found some code like the following:
PG_CATCH();
{
if (expr->plan && !expr->plan->saved)
expr->plan = NULL;
PG_RE_THROW();
}
PG_END_TRY();
if (expr->plan &&
On Tue, Sep 29, 2020 at 2:01 AM Tom Lane wrote:
> Amit Langote writes:
> > On Fri, Sep 25, 2020 at 12:02 AM Tom Lane wrote:
> >> Well, I agree with Peter to that extent, but my opinion is that *none*
> >> of these cases ought to be errors. What we're doing here is performing
> >> an implicit
At Mon, 28 Sep 2020 08:57:36 +, "k.jami...@fujitsu.com"
wrote in
> On Monday, September 28, 2020 5:08 PM, Tsunakawa-san wrote:
>
> > From: Jamison, Kirk/ジャミソン カーク
> > > Is my understanding above correct?
> >
> > No. I simply meant DropRelFileNodeBuffers() calls the following
On Mon, Sep 28, 2020 at 04:42:39PM -0400, John Naylor wrote:
On Thu, Sep 24, 2020 at 7:50 PM Tomas Vondra
wrote:
On Thu, Sep 24, 2020 at 05:18:03PM -0400, John Naylor wrote:
>Hmm, how ugly would it be to change the default range size depending
>on the opclass?
>
Not sure. What would
On 2020-09-29 11:43, Amit Kapila wrote:
On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda
wrote:
On 2020-09-28 12:43, Amit Kapila wrote:
> On Mon, Sep 28, 2020 at 8:24 AM Kyotaro Horiguchi
> wrote:
>>
>> At Mon, 28 Sep 2020 08:11:23 +0530, Amit Kapila
>> wrote in
>> > One other thing that
On Tuesday, September 29, 2020 10:35 AM, Horiguchi-san wrote:
> FWIW, I (and maybe Amit) am thinking that the property we need here is not it
> is cached or not but the accuracy of the returned file length, and that the
> "cached" property should be hidden behind the API.
>
> Another reason for
On Tue, Jul 21, 2020 at 05:32:44PM +0300, Surafel Temesgen wrote:
> Thank you for looking at it
The patch is failing to apply. Could you send a rebase please?
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 25, 2020 at 11:32:11AM +0200, Matthias van de Meent wrote:
> Updating to WAIT_1 was to set it back to whatever the state was before
> we would get into the loop and start_command was called. I quite
> apparently didn't take enough care to set all fields that could be
> set, though, so
On Mon, Sep 07, 2020 at 08:00:08AM +0200, Peter Eisentraut wrote:
> Some conflicts have emerged, so here is an updated patch.
>
> I have implemented/fixed the inlining of set-returning functions written in
> the new style, which was previously marked TODO in the patch.
The CF bot is telling that
On Mon, Aug 03, 2020 at 04:41:58PM +0530, Bharath Rupireddy wrote:
> IMHO, we are not fully solving the problem with
> idle_in_session_timeout on remote backends though we are addressing
> the main problem partly by letting the remote sessions close by
> themselves.
This patch fails to compile on
On Tue, Aug 25, 2020 at 07:36:53AM -0700, Mark Dilger wrote:
> Removed.
This patch is failing to compile on Windows:
C:\projects\postgresql\src\include\fe_utils/print.h(18): fatal error
C1083: Cannot open include file: 'libpq-fe.h': No such file or
directory
79 matches
Mail list logo
