On Tue, 7 Jul 2020 at 17:50, Magnus Hagander wrote:
>
>
>
> On Tue, Jul 7, 2020 at 5:10 AM Amit Kapila wrote:
>>
>> On Tue, Jul 7, 2020 at 7:07 AM Masahiko Sawada
>> wrote:
>> >
>> > On Mon, 6 Jul 2020 at 20:45, Amit Kapila wrote:
>> > >
>> > > > Second, as long as the unique identifier is the
On Tue, 7 Jul 2020 at 15:40, Amit Kapila wrote:
>
> On Fri, Jul 3, 2020 at 12:18 PM Masahiko Sawada
> wrote:
> >
> > On Sat, 20 Jun 2020 at 21:21, Amit Kapila wrote:
> > >
> > > On Fri, Jun 19, 2020 at 1:42 PM Andrey V. Lepikhov
> > > wrote:
> > >
> > > >Also, can you let us know if this
>
On Wed, Jul 8, 2020 at 10:24 AM Fabien COELHO wrote:
>
>
> Hello Anastasia,
>
> My 0.02 €:
>
> > The patch implements following syntax:
> >
> > CREATE TABLE ... PARTITION BY partition_method (list_of_columns)
> > partition_auto_create_clause
> >
> > where partition_auto_create_clause is
> >
> >
Over on [1] someone was asking about chained window paths making use
of already partially sorted input. (The thread is on -general, so I
guessed they're not using PG13.)
However, On checking PG13 to see if incremental sort would help their
case, I saw it didn't. Looking at the code I saw that
Hello Anastasia,
My 0.02 €:
The patch implements following syntax:
CREATE TABLE ... PARTITION BY partition_method (list_of_columns)
partition_auto_create_clause
where partition_auto_create_clause is
CONFIGURATION [IMMEDIATE| DEFERRED] USING partition_bound_spec
and partition_bound_spec
Hallo Peter,
Would it make sense to accumulate in the other direction, older to newer,
so that new attributes are added at the end of the select?
I think that could make sense, but the current style was introduced by
daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Should we revise that?
It seems
Amit-san
On Wednesday, July 8, 2020 11:53 AM, Amit Langote :
> I think the only reason that this is not supported is that I hadn't tested
> such a
> query when developing partition pruning, nor did anyone else suggest doing
> so. :)
Thanks for the information. I'm relieved to hear this reason.
On Sun, Jul 5, 2020 at 8:37 PM Dilip Kumar wrote:
>
> On Tue, Jun 30, 2020 at 10:13 AM Dilip Kumar wrote:
> >
> >
> > Yeah, I have run the regression suite, I can see a lot of failure
> > maybe we can somehow see the diff and confirm that all the failures
> > are due to rollback to savepoint
On Wed, Jul 8, 2020 at 7:28 AM David Rowley wrote:
>
>
> I'd really like to see this thread move forward to a solution and I'm
> not sure how best to do that. I started by reading back over both this
> thread and the original one and tried to summarise what people have
> suggested.
>
Thanks, I
On Thu, Jul 02, 2020 at 05:25:21PM -0400, Tom Lane wrote:
> I guess I'm completely confused about the purpose of these patches.
> Far from coping with the situation of an unseekable file, they appear
> to change pg_restore so that it fails altogether if it can't seek
> its input file. Why would
On 2020-07-08 11:15, Fujii Masao wrote:
On 2020/07/08 11:02, torikoshia wrote:
Hi,
Currently, slot_keep_segs is defined as "XLogRecPtr" in KeepLogSeg(),
but it seems that should be "XLogSegNo" because this variable is
segment number.
How do you think?
I agree that using XLogRecPtr for
Kato-san,
On Wed, Jul 8, 2020 at 10:32 AM kato-...@fujitsu.com
wrote:
> On Tuesday, July 7, 2020 6:31 PM Etsuro Fujita
> wrote:
> > Just to be clear, the condition (c1, c2) < (99, 99) is not equivalent to the
> > condition c1 < 99 and c2 < 99 (see the documentation note in [1]).
>
> Thanks for
On Jul 7, 2020, at 21:32, Andreas Karlsson wrote:
> On 7/7/20 6:51 PM, Thom Brown wrote:
>
>> 10 years later, and I've noticed that both look-behind and negative
>> look-behind have been implemented.
>> Thanks to whomever did this.
>
> I think that it is Tom Lane that you should thank for
On 2020/07/08 10:54, torikoshia wrote:
Hi,
The manual describes the size of pg_stat_activity.query
as below:
| By default the query text is truncated at 1024 characters;
When considering multibyte characters, it seems more
accurate to change the unit from "characters" to "bytes".
Hi Soumyadeep,
On Wed, Jul 8, 2020 at 9:37 AM Soumyadeep Chakraborty
wrote:
> On Tue, Jul 7, 2020 at 7:18 AM Amit Langote wrote:
> > If I change this to return a "heap" slot for partitioned tables, just
> > like for foreign tables, the problem goes away (see the attached). In
> > fact, even
On 2020/07/08 11:02, torikoshia wrote:
Hi,
Currently, slot_keep_segs is defined as "XLogRecPtr" in KeepLogSeg(),
but it seems that should be "XLogSegNo" because this variable is
segment number.
How do you think?
I agree that using XLogRecPtr for slot_keep_segs is incorrect.
But this
>Regarding the attribute name, I was actually considering to just use
>"roident" instead. This is more consistent with pglogical, and that's
>also the field name we use in ReplicationState[OnDisk]. What do you
>think?
Yes that's is the right way, I can see it's 'roident' in
On 2020/07/08 8:12, Masahiro Ikeda wrote:
There is the comment which related function name is not same.
I attached the patch to fix it. Please review.
Thanks for the report and patch! LGTM.
I will commit this later.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology
Hi,
Currently, slot_keep_segs is defined as "XLogRecPtr" in KeepLogSeg(),
but it seems that should be "XLogSegNo" because this variable is
segment number.
How do you think?
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATIONdiff --git a/src/backend/access/transam/xlog.c
On Wed, 8 Jul 2020 at 07:25, Peter Geoghegan wrote:
>
> On Tue, Jul 7, 2020 at 5:55 AM David Rowley wrote:
> > We're certainly not
> > going to get that for PG13, so I do think what we need here is just a
> > simple escape hatch. I mentioned my thoughts in [2], so won't go over
> > it again
Hi,
The manual describes the size of pg_stat_activity.query
as below:
| By default the query text is truncated at 1024 characters;
When considering multibyte characters, it seems more
accurate to change the unit from "characters" to "bytes".
I also searched other "[0-9] characters" in the
On Wed, Jul 08, 2020 at 09:31:24AM +0800, movead...@highgo.ca wrote:
> Thanks for all of that, so many details I still need to pay attention when
> submit a patch.
No problem. We are all here to learn, and nothing can be perfect, if
perfection is even possible :)
Regarding the attribute name,
On Tue, Jul 07, 2020 at 06:36:10PM +0900, Michael Paquier wrote:
> On Tue, Jul 07, 2020 at 09:58:59AM +0200, Daniel Gustafsson wrote:
>> I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
>> paragraph for both GIN and BRIN. LGTM. Adding Alexander who committed in on
>> cc.
On 7/7/20 6:51 PM, Thom Brown wrote:
On Tue, 29 Jun 2010 at 17:49, David E. Wheeler wrote:
On Jun 29, 2010, at 7:44 AM, Thom Brown wrote:
No. Or are you volunteering?
A n00b like me volunteer for that? It's more of a suggestion.
N00bs gotta start somewhere…
10 years later, and I've
Fujita san
On Tuesday, July 7, 2020 6:31 PM Etsuro Fujita wrote:
> Just to be clear, the condition (c1, c2) < (99, 99) is not equivalent to the
> condition c1 < 99 and c2 < 99 (see the documentation note in [1]).
Thanks for sharing this document. I have understood.
> but I don't think the main
>Cool, thanks. I have gone through your patch in details, and updated
>it as the attached. Here are some comments.
>'8000' as OID for the new function was not really random, so to be
>fair with the other patches, I picked up the first random value
>unused_oids has given me instead.
>
>There
>The rationale for this interface is unclear to me. Please explain what
>happens in each case?
>In my proposal, we'd have:
>* Bad value, no --force:
> - program raises error, no work done.
>* Bad value with --force:
> - program raises warning but changes anyway.
>* Good value, no --force:
> -
On 2020-07-06 22:16, Fujii Masao wrote:
On 2020/06/11 14:59, torikoshia wrote:
On 2020-06-10 18:00, Kyotaro Horiguchi wrote:
+ TupleDescInitEntry(tupdesc, (AttrNumber) 8, "last_plan",
This could be a problem if we showed the last plan in this view. I
think "last_plan_type" would be
Hi Amit,
Thanks for your reply!
On Tue, Jul 7, 2020 at 7:18 AM Amit Langote wrote:
>
> Hi Soumyadeep,
>
> Thanks for picking this up.
>
> On Tue, Jul 7, 2020 at 7:46 AM Soumyadeep Chakraborty
> wrote:
> > Upon investigation, it seems that the problem is caused by the
> > following:
> >
> > The
There is the comment which related function name is not same.
I attached the patch to fix it. Please review.
Thanks for the report and patch! LGTM.
I will commit this later.
Thanks for checking.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
On Wed, Jul 8, 2020 at 1:16 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push 0002 if there is no objection.
> > Regarding 0001, I think my new error messages need review.
>
> I do intend to review these, just didn't get to it yet.
OK, that you for noticing. I wouldn't push
Alexander Korotkov writes:
> I'm going to push 0002 if there is no objection.
> Regarding 0001, I think my new error messages need review.
I do intend to review these, just didn't get to it yet.
regards, tom lane
On Mon, Jul 6, 2020 at 3:19 PM Alexander Korotkov wrote:
> The patchset is attached, sorry for the delay.
>
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric value should fit to
On Sun, Jun 7, 2020 at 12:34 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > I'm also wondering whether this is fully correct. Would it be possible for
> > the
> > argument types of the operator/function to differ from the left arg/right
> > arg
> > types? (Perhaps binary compatible?)
>
>
> On 25 Mar 2020, at 06:52, Fujii Masao wrote:
>
> On 2020/01/28 0:24, Fujii Masao wrote:
>> On 2020/01/15 19:18, Paul Guo wrote:
>>> I further fixed the last test failure (due to a small bug in the test, not
>>> in code). Attached are the new patch series. Let's see the CI pipeline
>>>
On Tue, Jul 7, 2020 at 10:12 AM Andres Freund wrote:
> I think it makes no too much sense to plan invent something like
> hash_mem for v13, it's clearly too much work. That's a seperate
> discussion from having something like it for v14.
Can you explain why you believe that to be the case? It
Sergey, Nikita, Alexander, if you can please see this thread and propose
a solution, that'd be very welcome.
On 2020-Jun-06, Tom Lane wrote:
> Peter Eisentraut writes:
> > I'm also wondering whether this is fully correct. Would it be possible for
> > the
> > argument types of the
On Tue, 7 Jul 2020 at 10:01, Daniel Gustafsson wrote:
> > On 7 Jul 2020, at 02:16, Dave Cramer wrote:
>
> > OK, rebased it down to 2 patches, attached.
>
> I took a look at this patchset today. The feature clearly seems like
> something
> which we'd benefit from having, especially if it allows
> On 7 Jul 2020, at 19:53, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> Trying to move this along,
Thanks, this has stalled a bit on my TODO.
>> where would be a good place to define
>> OPENSSL_API_COMPAT? The only place that's shared between frontend and
>> backend code is c.h. The
On 2020-Jul-07, Peter Geoghegan wrote:
> On Tue, Jul 7, 2020 at 1:18 PM Alvaro Herrera
> wrote:
> > Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
> > postgresql.conf files generated by initdb prior to the release that
> > introduces it. But users that need it can
On Tue, Jul 7, 2020 at 1:18 PM Alvaro Herrera wrote:
> Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
> postgresql.conf files generated by initdb prior to the release that
> introduces it. But users that need it can just edit their .confs and
> add the appropriate line,
On 2020-Jul-07, Amit Kapila wrote:
> I don't think this is true. We seem to have introduced three new guc
> variables in a 9.3.3 minor release.
Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
postgresql.conf files generated by initdb prior to the release that
introduces
On Tue, Jul 7, 2020 at 5:55 AM David Rowley wrote:
> FWIW, I'm not a fan of the hash_mem idea. It was my impression that we
> aimed to provide an escape hatch for people we have become accustomed
> to <= PG12 behaviour and hash_mem sounds like it's not that.
The exact scope of the problem is
On Mon, 6 Jul 2020 at 15:55, Ajay Patel wrote:
> Hi Postgres team,
>
> I would like to know if PostgreSQL can be installed and used without any
> issues on Amazon Linux EC2 machines.
>
> https://www.postgresql.org/docs/11/supported-platforms.html
>
> I was going through the documentation and
Peter Eisentraut writes:
> Trying to move this along, where would be a good place to define
> OPENSSL_API_COMPAT? The only place that's shared between frontend and
> backend code is c.h. The attached patch does it that way.
pg_config_manual.h, perhaps?
regards, tom
On 2020-Jul-06, Alvaro Herrera wrote:
> On 2020-Jul-07, Kyotaro Horiguchi wrote:
> > Couldn't we move ConvertToXSegs from xlog.c to xlog_ingernals.h and
> > use it intead of the bare expression?
>
> I was of two minds about that, and the only reason I didn't do it is
> that we'll need to give
On 2020-Jun-24, Andres Freund wrote:
> As I said before, I've utilized being able to do both over a single
> connection (among others to initialize a logical replica using a base
> backup). And I've seen at least one other codebase (developed without my
> input) doing so. I really don't
On 2020-05-30 11:29, Peter Eisentraut wrote:
My proposal would be to introduce OPENSSL_API_COMPAT=10001 into master
after the 13/14 branching, along with any other changes to make it
compile cleanly against OpenSSL 3.0.0. Once that has survived some
scrutiny from the buildfarm and also from
Hi,
On 2020-07-03 10:08:08 -0400, Bruce Momjian wrote:
> Well, the bottom line is that we are designing features during beta.
> People are supposed to be testing PG 13 behavior during beta, including
> optimizer behavior.
I think it makes no too much sense to plan invent something like
hash_mem
Hi,
On 2020-07-07 09:44:41 -0400, Tom Lane wrote:
> Bharath Rupireddy writes:
> > Firstly, pg_start_backup registers nonexclusive_base_backup_cleanup as
> > on_shmem_exit call back which will
> > add this function to the before_shmem_exit_list array which is
> > supposed to be removed on
On Tue, 29 Jun 2010 at 17:49, David E. Wheeler wrote:
>
> On Jun 29, 2010, at 7:44 AM, Thom Brown wrote:
>
> >> No. Or are you volunteering?
> >
> > A n00b like me volunteer for that? It's more of a suggestion.
>
> N00bs gotta start somewhere…
10 years later, and I've noticed that both
On 01/07/2020, 18:40, "Zidenberg, Tsahi" wrote:
> Outline-atomics is a gcc compilation flag that adds runtime detection of
> weather or not the cpu
> supports atomic instructions. CPUs that don't support atomic instructions
> will use the old
> load-exclusive/store-exclusive instructions. If
Peter Eisentraut writes:
> On 2020-07-04 16:16, Tom Lane wrote:
>> I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
>> and the fact that it's theoretically incorrect for the purpose doesn't
>> exactly aid intelligibility either. With a typedef, not only are
>> the uses
On Mon, Jul 6, 2020 at 3:09 PM Amit Kapila wrote:
>
> On Mon, Jul 6, 2020 at 11:44 AM Dilip Kumar wrote:
> >
> > On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
> > >
> >
> > > > > 10. I have got the below failure once. I have not investigated this
> > > > > in detail as the patch is still
Robert Haas writes:
> On Mon, Jul 6, 2020 at 12:10 PM Tom Lane wrote:
>> We did indeed solve this in connection with window functions, cf
>> 0a459cec9. I may be misunderstanding what the problem is here,
>> but I think trying to reuse that infrastructure might help.
> Ah, nice. I didn't
On 2020-Jul-07, Michael Paquier wrote:
> On Mon, Jul 06, 2020 at 10:56:53AM -0400, Alvaro Herrera wrote:
> > I think "routine" was more correct. We introduced that terminology to
> > encompass both functions and procedures, back when real procedures were
> > added. See the definitions in the
On 2020-Jul-07, movead...@highgo.ca wrote:
> >ISTM that a reasonable compromise is that if you use -x (or -c, -m, -O)
> >and the input value is outside the range supported by existing files,
> >then it's a fatal error; unless you use --force, which turns it into
> >just a warning.
>
> I do not
On Sun, Jun 28, 2020 at 1:39 PM Daniel Gustafsson wrote:
> As I mentioned in [1], checking (struct Port)->ssl for NULL to determine
> whether TLS is used for connection is a bit of a leaky abstraction, as
> that's
> an OpenSSL specific struct member. This sets the requirement that all TLS
>
On Mon, Jul 6, 2020 at 12:10 PM Tom Lane wrote:
> We did indeed solve this in connection with window functions, cf
> 0a459cec9. I may be misunderstanding what the problem is here,
> but I think trying to reuse that infrastructure might help.
Ah, nice. I didn't realize that we'd added that. But
Hi Soumyadeep,
Thanks for picking this up.
On Tue, Jul 7, 2020 at 7:46 AM Soumyadeep Chakraborty
wrote:
> Upon investigation, it seems that the problem is caused by the
> following:
>
> The slot passed to the call to ExecProcessReturning() inside
> ExecInsert() is often a virtual tuple table
> On 7 Jul 2020, at 02:16, Dave Cramer wrote:
> OK, rebased it down to 2 patches, attached.
I took a look at this patchset today. The feature clearly seems like something
which we'd benefit from having, especially if it allows for the kind of
extensions that were discussed at the beginning of
Bharath Rupireddy writes:
> Firstly, pg_start_backup registers nonexclusive_base_backup_cleanup as
> on_shmem_exit call back which will
> add this function to the before_shmem_exit_list array which is
> supposed to be removed on pg_stop_backup
> so that we can do the pending cleanup and issue a
út 7. 7. 2020 v 14:55 odesílatel David Rowley napsal:
> On Tue, 7 Jul 2020 at 16:57, Jeff Davis wrote:
> >
> > On Sun, 2020-07-05 at 16:47 -0700, Peter Geoghegan wrote:
> > > Where does that leave the hash_mem idea (or some other similar
> > > proposal)?
> >
> > hash_mem is acceptable to me if
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Tested the tab complete for copy command, it provides the tab
"Daniel Verite" writes:
> Tom Lane wrote:
>> If we start to case-fold É, then the only way to access this table will
>> be by double-quoting its name, which the application probably is not
>> expecting (else it would have double-quoted in the original CREATE TABLE).
> This problem already
On 2020-07-06 15:16, Fujii Masao wrote:
On 2020/07/06 12:12, torikoshia wrote:
On Fri, Jul 3, 2020 at 7:33 PM Fujii Masao
wrote:
Thanks for your review!
I like more specific name like pg_backend_memory_contexts.
Agreed.
When I was trying to add this function as statistics function,
I
On Tue, 7 Jul 2020 at 16:57, Jeff Davis wrote:
>
> On Sun, 2020-07-05 at 16:47 -0700, Peter Geoghegan wrote:
> > Where does that leave the hash_mem idea (or some other similar
> > proposal)?
>
> hash_mem is acceptable to me if the consensus is moving toward that,
> but I'm not excited about it.
Thanks Flavio.
I believe trying is the best way forward. Thank you for the guidance.
Warm regards,
Ajay Patel
> On Jul 7, 2020, at 3:20 AM, Flavio Henrique Araque Gurgel
> wrote:
>
>
>
>> Thank you Flavio, this is helpful.
>>
>> Have you faced any other challenges or any other
Tom Lane wrote:
> CREATE TABLE public."myÉclass" (
>f1 text
> );
>
> If we start to case-fold É, then the only way to access this table will
> be by double-quoting its name, which the application probably is not
> expecting (else it would have double-quoted in the original CREATE
Hi
> GTT Merge the latest PGMaster and resolves conflicts.
>
>
>
I tested it and it looks fine. I think it is very usable in current form,
but still there are some issues:
postgres=# create global temp table foo(a int);
CREATE TABLE
postgres=# insert into foo values(10);
INSERT 0 1
postgres=#
On Tue, Jul 7, 2020 at 9:18 AM Jeff Davis wrote:
>
> On Mon, 2020-07-06 at 15:59 +0530, Amit Kapila wrote:
> > I agree that it's good to wait for actual problems. But the
> > > challenge
> > > is that we can't backport an added GUC.
> > >
> >
> > Is it because we won't be able to edit existing
On 2020-07-04 16:16, Tom Lane wrote:
Peter Eisentraut writes:
Do people prefer a typedef or just writing it out, like it's done in the
Python code?
I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
and the fact that it's theoretically incorrect for the purpose
On Tue, Jul 07, 2020 at 09:58:59AM +0200, Daniel Gustafsson wrote:
> I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
> paragraph for both GIN and BRIN. LGTM. Adding Alexander who committed in on
> cc.
+1.
--
Michael
signature.asc
Description: PGP signature
Kato-san,
On Mon, Jul 6, 2020 at 5:25 PM kato-...@fujitsu.com
wrote:
> I would like to ask about the conditions under which partition pruning is
> performed.
> In PostgreSQL 12, when I executed following SQL, partition pruning is not
> performed.
>
> postgres=# explain select * from a where
Hello, Horiguchi-san
At Monday, July 6, 2020 05:13:40 +, "Kyotaro Horiguchi
" wrote in
> > > after WAL buffer is filled up to the requested position. So when it
> > > crosses segment boundary we know the all past corss segment-boundary
> > > records are stable. That means all we need to
On Tue, Jul 7, 2020 at 5:10 AM Amit Kapila wrote:
> On Tue, Jul 7, 2020 at 7:07 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 6 Jul 2020 at 20:45, Amit Kapila
> wrote:
> > >
> > > > Second, as long as the unique identifier is the slot name there is no
> > > > convenient way to distinguish
On Tue, Jul 7, 2020 at 4:28 PM Amit Langote wrote:
> The median times for the COPY FROM commands above, with and without
> the patch, are as follows:
>
> HEADpatched
> foo58.5 6.5
> foo10 14 10
> foo20 25 18
Sorry, I forgot to mention that these
> On 7 Jul 2020, at 09:17, Guillaume Lelarge wrote:
> Here is a quick issue I found on the BRIN documentation. I'm not a 100% sure
> I'm right but it looks like a failed copy/paste from the GIN documentation.
I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
paragraph
On Mon, 6 Jul 2020 at 15:42, Drouvot, Bertrand wrote:
>
>
> On 7/3/20 4:20 AM, Masahiko Sawada wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe.
> >
> >
> >
>
Hi Bharath,
On Mon, Jun 29, 2020 at 2:21 PM Bharath Rupireddy
wrote:
> For Copy From Binary files, there exists below information for each tuple/row.
> 1. field count(number of columns)
> 2. for every field, field size(column data length)
> 3. field data of field size(actual column data)
>
>
>> Query checks for following restrictions are added:
>
>
> Are all known supported cases listed below?
They are "restrictions" and are not supported.
>
>> - inheritance parent table
>> ...
>> - targetlist containing IVM column
>> - simple subquery is only supported
>>
>
> How to understand 3
> Thank you Flavio, this is helpful.
>
> Have you faced any other challenges or any other problems after installing
> Postgres?
>
No problem related to software installation whatsoever, you'll need to take
care of the same points as any Postgres usage and some cloud specific care
like replication
Hi,
Here is a quick issue I found on the BRIN documentation. I'm not a 100%
sure I'm right but it looks like a failed copy/paste from the GIN
documentation.
Cheers.
--
Guillaume.
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index 4c5eeb875f..55b6272db6 100644
---
> 6 июля 2020 г., в 17:55, Andrey M. Borodin написал(а):
>
>
>
>> 1 июля 2020 г., в 17:05, Daniel Gustafsson написал(а):
>>
>>> On 29 Feb 2020, at 18:24, Andrey M. Borodin wrote:
>>
>>> I've fixed this and added patch with GiST reloption to provide sort support
>>> function.
>>
>> 0002
On 2020-06-30 16:56, Fabien COELHO wrote:
Would it make sense to accumulate in the other direction, older to newer,
so that new attributes are added at the end of the select?
I think that could make sense, but the current style was introduced by
daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Should
> On 6 Jul 2020, at 09:45, Michael Paquier wrote:
> Attached is for now a rebased patch. If there are any comments,
> please feel free. Daniel, Alvaro, does that look fine for you? I am
> letting this stuff aside for a couple of days for the moment.
Reading through I have no comments or
On Fri, Jul 3, 2020 at 12:18 PM Masahiko Sawada
wrote:
>
> On Sat, 20 Jun 2020 at 21:21, Amit Kapila wrote:
> >
> > On Fri, Jun 19, 2020 at 1:42 PM Andrey V. Lepikhov
> > wrote:
> >
> > >Also, can you let us know if this
> > > > supports 2PC in some way and if so how is it different from
Hi,
I found an issue while executing a backup use case(please see [1] for
queries) on postgres version 12.
Firstly, pg_start_backup registers nonexclusive_base_backup_cleanup as
on_shmem_exit call back which will
add this function to the before_shmem_exit_list array which is
supposed to be
88 matches
Mail list logo
