On 18/09/2020 10:17, Alexander Kukushkin wrote:
At the same time, pg_rewind due to such "fatal" error leaves PGDATA in
an inconsistent state with empty pg_control file, this is totally bad
and easily fixable. We want the specific file to be absent and it is
already absent, why should it be a fata
On Tue, 29 Sep 2020 at 15:03, Masahiko Sawada
wrote:
>
> On Tue, 29 Sep 2020 at 11:37, tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Masahiko Sawada
> > > No. Please imagine a case where a user executes PREPARE TRANSACTION on
> > > the transaction that modified data on foreign servers. The
On Thu, Aug 27, 2020 at 04:53:11PM +0200, Rémi Lapeyre wrote:
> I have two remarks with the state of the current patches:
> - DefGetCopyHeader() duplicates a lot of code from defGetBoolean(),
> should we refactor this so that they can share more of their
> internals? In the current implementation a
po 28. 9. 2020 v 18:43 odesílatel Andrew Dunstan <
andrew.duns...@2ndquadrant.com> napsal:
>
> 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
On Tue, Sep 29, 2020 at 11:29:45AM +0530, Bharath Rupireddy wrote:
> Unfortunately, we have not arrived at a final solution yet, please
> ignore this patch. I will post a new patch, once the solution is
> finalized. I will move it to the next commit fest if okay.
If you are planning to get that ad
Hi all,
prion, that uses -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE,
has just failed with an interesting failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-09-29%2005%3A24%3A11
The assertion failure happens in a parallel worker when attempting to
attach a barrie
On Tue, 29 Sep 2020 at 11:37, tsunakawa.ta...@fujitsu.com
wrote:
>
> 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
On Tue, Sep 29, 2020 at 11:21 AM Michael Paquier wrote:
>
> 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 remo
On Thu, Sep 17, 2020 at 11:41:28AM +0200, Daniel Gustafsson wrote:
> Attached is a v10 rebased to apply on top of HEAD.
I am afraid that this needs a new rebase. The patch is failing to
apply, per the CF bot. :/
--
Michael
signature.asc
Description: PGP signature
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 [C:\projects\postgresql\pg_amcheck.
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, 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 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 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 t
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 n
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 occur
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 i
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
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 prepar
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 happen
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 pg_stat_reset_shared('wal')
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 sav
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 case
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 should
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 function
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, 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 as
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 && !ex
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
> > 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 rid
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 i
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 o
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 list_fortyseco
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 querie
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.
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
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 outco
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 sel
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 fo
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 ther
>100% compatible with the MySQL
It is hardly a justification for a feature or for a change request.
Vladimir
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 it:
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 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
> opclas
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)
> >
> >
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 database
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 (dbid,use
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
>>
Michael Paquier writes:
> It looks like this commit has broken prairiedog as follows:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2020-09-28%2005%3A45%3A55
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
> ../../../src/common
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.
>
>
Peter Smith writes:
> I only have a couple of questions, more for curiosity than anything else.
> 1. Why is there sometimes an extra *tm = &tt; variable introduced?
> (e.g. GetSQLCurrentTime, GetSQLLocalTime). Why not just declare struct
> pg_tm tm; and pass the &tm same as what GetSQLCurrentDate
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 list_fourt
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 configurable
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. Y
"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 g
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 =
> &XL
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 on
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, y
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:
https://travis-ci.org/github/postgresql-cf
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.
C
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 ne
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 cli
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
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 I
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.
>
> > Si
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 running
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 summ
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
>
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
> > sure
> 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 test_json[-
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 to
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 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 plugin
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.
>
>
> BlockNum
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,
> plea
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 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. stream_commit_pr
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
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)
{
ret
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 swi
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 co
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 = to_date(
82 matches
Mail list logo
