On Tue, 28 Jan 2020 at 12:32, Amit Kapila wrote:
>
> On Tue, Jan 28, 2020 at 12:04 PM Mahendra Singh Thalor
> wrote:
> >
> > On Tue, 28 Jan 2020 at 08:14, Amit Kapila wrote:
> > >
> > > On Tue, Jan 28, 2020 at 2:13 AM Mahendra Singh Thalor
> > > wrote:
> > > >
> > > > On Sat, 25 Jan 2020 at 12:
On Tue, Jan 28, 2020 at 12:04 PM Mahendra Singh Thalor
wrote:
>
> On Tue, 28 Jan 2020 at 08:14, Amit Kapila wrote:
> >
> > On Tue, Jan 28, 2020 at 2:13 AM Mahendra Singh Thalor
> > wrote:
> > >
> > > On Sat, 25 Jan 2020 at 12:11, Amit Kapila wrote:
> > > >
> > > > On Fri, Jan 24, 2020 at 4:58 P
On Tue, 28 Jan 2020 at 08:14, Amit Kapila wrote:
>
> On Tue, Jan 28, 2020 at 2:13 AM Mahendra Singh Thalor
> wrote:
> >
> > On Sat, 25 Jan 2020 at 12:11, Amit Kapila
wrote:
> > >
> > > On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
> > > wrote:
> > > >
> > > > On Thu, 23 Jan 2020 at 15:3
On Tue, Jan 28, 2020 at 11:43 AM Amit Kapila wrote:
>
> On Tue, Jan 28, 2020 at 11:34 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 28, 2020 at 11:28 AM Amit Kapila
> > wrote:
> > >
> > > On Wed, Jan 22, 2020 at 10:30 AM Dilip Kumar
> > > wrote:
> > > >
> > > > On Tue, Jan 14, 2020 at 10:44 AM Am
Hi all,
As mentioned on the thread dealing with concurrent indexing for
temporary relations, it sounds like a good thing to make the code more
defensive if attempting to do a REINDEX CONCURRENTLY with a backend
still holding references to the indexes worked on:
https://www.postgresql.org/message-i
On Tue, Jan 28, 2020 at 11:34 AM Dilip Kumar wrote:
>
> On Tue, Jan 28, 2020 at 11:28 AM Amit Kapila wrote:
> >
> > On Wed, Jan 22, 2020 at 10:30 AM Dilip Kumar wrote:
> > >
> > > On Tue, Jan 14, 2020 at 10:44 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Hmm, I think this can turn out t
On Tue, Jan 28, 2020 at 11:28 AM Amit Kapila wrote:
>
> On Wed, Jan 22, 2020 at 10:30 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 14, 2020 at 10:44 AM Amit Kapila
> > wrote:
> > >
> > >
> > > Hmm, I think this can turn out to be inefficient because we can easily
> > > end up spilling the data eve
On Wed, Jan 22, 2020 at 10:30 AM Dilip Kumar wrote:
>
> On Tue, Jan 14, 2020 at 10:44 AM Amit Kapila wrote:
> >
> >
> > Hmm, I think this can turn out to be inefficient because we can easily
> > end up spilling the data even when we don't need to so. Consider
> > cases, where part of the streame
Hi all,
I was reviewing the libpq code for the recent SSL protocol patch, and
noticed two mistakes with dispsize for the following parameters:
- channel_binding should be at 8, the largest value being "require".
- gssencmode should be at 8.
In those cases the zero-terminator was forgotten in the
On Tue, Dec 3, 2019 at 6:56 AM Mark Dilger wrote:
> On 11/30/19 5:14 PM, Thomas Munro wrote:
> > On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
> >> These two patches (v3) no longer apply cleanly. Could you please
> >> rebase?
> >
> > Hi Mark,
> > Thanks. Here's v4.
>
> Thanks, Thomas.
>
>
Hello.
At Mon, 27 Jan 2020 12:16:02 +0100, Peter Eisentraut
wrote in
> On 2020-01-15 05:02, Kyotaro Horiguchi wrote:
> > FWIW, I restate this (perhaps) more clearly.
> > At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> >> recvoery_target_* is not cleared after startup
Rebased version v.22.
- Added enable_self_join_removal GUC (true is default)
- The joinquals of the relation that is being removed, redistributed in
accordance with the remove_rel_from_query () machinery.
--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Comp
On Thu, 23 Jan 2020 at 15:04, Michael Paquier wrote:
> It seems to me that what you are describing here is a set of
> properties good for a monitoring tool that we don't necessarily need
> to maintain in core. There are already tools able to do that in ways
> I think are better than what we coul
On Mon, Jan 27, 2020 at 11:08:36PM +0900, Kohei KaiGai wrote:
> Hmm. Do we need to deliver another list to inform why these relations are
> trundated?
I got to think more about this one, and being able to control ONLY on
a per-relation basis would be the least surprising approach for the
commands
On Mon, Jan 27, 2020 at 09:49:09AM +0100, Daniel Gustafsson wrote:
>> On 27 Jan 2020, at 07:01, Michael Paquier wrote:
> Ok. I prefer to keep the TLS code collected in fe-secure.c, but I don't have
> strong enough opinions to kick up a fuzz.
They are parameter-related, so fe-connect.c made the m
On Sat, 25 Jan 2020 at 15:41, Amit Kapila wrote:
>
> On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
> wrote:
> >
> > On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor
> > wrote:
> > >
> > > On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
> > > wrote:
> > > >
> > > > Attached the updated
> On Jan 27, 2020, at 6:11 PM, Tom Lane wrote:
>
> and I think it
> makes German better (does 'ß' appear in any month/day names there?),
> so maybe we should just roll with that.
To my knowledge, neither /ß/ nor /ss/ occur in day or month names in German,
neither presently nor in recent tim
Dent John writes:
> I’ve updated the patch, addressed the rescan issue, and restructured the
> tests.
> [ pipeline-functionscan-v4.patch ]
FWIW, this patch doesn't apply to HEAD anymore. The cfbot
has failed to notice because it is still testing the v3 patch.
Apparently the formatting of this e
On Tue, Jan 28, 2020 at 2:13 AM Mahendra Singh Thalor
wrote:
>
> On Sat, 25 Jan 2020 at 12:11, Amit Kapila wrote:
> >
> > On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
> > wrote:
> > >
> > > On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor
> > > wrote:
> > > >
> > > > On Wed, 22 Jan
On Tue, Dec 24, 2019 at 3:10 PM Thomas Munro wrote:
> On Sat, Dec 21, 2019 at 2:10 PM Shawn Debnath wrote:
> > On Fri, Dec 20, 2019 at 12:05:34PM +1300, Thomas Munro wrote:
> > > I think we should probably just remove the unusual ResetLatch() call,
> > > rather than adding a CFI(). See attached.
Peter Eisentraut writes:
> For the record, the correct form of that would appear to be
> select to_date('Ιανουάριος', 'TMMonth');
> with the accent. I had tried different variations of that and they all
> failed.
OK, so for anyone who is as confused as I was, the main point here
seems to be thi
On Mon, Jan 27, 2020 at 10:09:30AM -0500, Robert Haas wrote:
> I recognize that your commit message explains this change by saying
> that this code will now never be reached except as a result of a short
> read, but I don't think that will necessarily be clear to future
> readers of those code, or
On Tue, Jan 21, 2020 at 3:06 PM Luis Carril wrote:
>
> Yes we can support --include-foreign-data without parallel option and
> later add support for parallel option as a different patch.
>
> Hi,
>
> I've attached a new version of the patch in which an error is emitted if
> the parallel backup
Hello,
I noticed MemoryContextIsValid() called by various kinds of memory context
routines checks its node-tag as follows:
#define MemoryContextIsValid(context) \
((context) != NULL && \
(IsA((context), AllocSetContext) || \
IsA((context), SlabContext) || \
IsA((context), Gen
On Mon, Jan 27, 2020 at 4:47 PM Thomas Munro wrote:
> OK, I kept only the small comment change from that little fixup patch,
> and pushed this.
>
> > I had proposed as alternative way in initial email and also later,
> > didn't receive comment on that, so re-posting.
>
> > typedef bool (*AMCheckF
On Wed, Nov 13, 2019 at 7:27 PM Ashwin Agrawal wrote:
> On Sun, Nov 10, 2019 at 8:21 PM Thomas Munro wrote:
>> but on another read-through of the main patch
>> I didn't like the comments for CheckForSerializableConflictOut() or
>> the fact that it checks SerializationNeededForRead() again, after
I see that buildfarm member caiman is generating a warning [1]:
jsonb_plpython.c: In function \xe2\x80\x98PLyObject_ToJsonbValue\xe2\x80\x99:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
jsonb_plpython.c:413:13: note: declared here
413 | JsonbValue buf;
On Mon, Jan 27, 2020 at 9:14 AM Andres Freund wrote:
> > The main idea here is to make _bt_compare() delay
> > calling BTreeTupleGetNAtts() until the point after the first attribute
> > turns out to be equal to the _bt_compare() caller's insertion scankey.
> > Many or most calls to _bt_compare() w
On Mon, Jan 27, 2020 at 03:59:58PM +0900, Masahiko Sawada wrote:
> On Mon, 27 Jan 2020 at 14:38, Justin Pryzby wrote:
> > On Sun, Jan 26, 2020 at 12:29:38PM -0800, Andres Freund wrote:
> > > > CONTEXT: while vacuuming relation "public.t_a_idx"
> > >
> > > It'd be a bit nicer if it said index "pub
On Mon, Jan 27, 2020 at 11:01 AM Robert Haas wrote:
> On Fri, Nov 15, 2019 at 8:05 PM Maciek Sakrejda wrote:
> > On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> > > Personally, I don't care very much about backward-compatibility, or
> > > about how hard it is for tools to parse. I want it t
Robert Haas writes:
>>> I do not think that the readability-vs-usefulness tradeoff is going
>>> to be all that good there, anyway. Certainly for testing purposes
>>> it's going to be more useful to examine portions of a structured output.
> I intensely dislike having information that we can't sh
Actually looking again, getRecordTimestamp is looking pretty strange.
It looks much more natural by using nested switch/case blocks, as with
this diff. I think the compiler does a better job this way too.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Sat, 25 Jan 2020 at 12:11, Amit Kapila wrote:
>
> On Fri, Jan 24, 2020 at 4:58 PM Mahendra Singh Thalor
> wrote:
> >
> > On Thu, 23 Jan 2020 at 15:32, Mahendra Singh Thalor
wrote:
> > >
> > > On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
> > > wrote:
> > > >
> > > > Attached the updated vers
On 2020-01-20 2:42 a.m., Daniel Verite wrote:
David Zhang wrote:
Yes, I agree with you. For case 2 "select repeat('111', 100) \g
/mnt/ramdisk/file", it can be easily fixed with more accurate error
message similar to pg_dump, one example could be something like below.
But for case
On 2020-Jan-10, Alvaro Herrera wrote:
> A customer of ours complained that if you have an inactive primary,
> monitoring the apply lag on a standby reports monotonically increasing
> lag. The reason for this is that the apply lag is only updated on
> COMMIT records, which of course don't occur in
> On Jan 27, 2020, at 5:30 AM, Robert Haas wrote:
>
> On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
> wrote:
>> Ok, the tests pass. Here are those two patches again, both regenerated with
>> a fresh invocation of ‘git format-patch’.
>
> Regarding 0006:
>
> +#ifndef FRONTEND
> #include "misca
po 27. 1. 2020 v 10:11 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 24.01.2020 22:39, Pavel Stehule wrote:
>
> I cannot to evaluate your proposal, and I am sure, so you know more about
> this code.
>
> There is a question if we can allow to build local temp index on
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jan 13, 2020 at 01:56:30PM -0500, Stephen Frost wrote:
> > > I think that having ALTER SYSTEM commands in pg_dumpall output
> > > would be a problem. It would cause all kinds of problems whenever
> > > parameters change. Thinking of
On Mon, Jan 27, 2020 at 12:41 PM Andres Freund wrote:
> > I do not think that the readability-vs-usefulness tradeoff is going
> > to be all that good there, anyway. Certainly for testing purposes
> > it's going to be more useful to examine portions of a structured output.
>
> I think I can live w
On Mon, 27 Jan 2020 at 19:00, Robert Haas wrote:
>
> On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
> wrote:
> > Ok, the tests pass. Here are those two patches again, both regenerated
> > with a fresh invocation of ‘git format-patch’.
>
> Regarding 0006:
>
> +#ifndef FRONTEND
> #include "miscadmi
On Fri, Nov 15, 2019 at 8:05 PM Maciek Sakrejda wrote:
> On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> > Personally, I don't care very much about backward-compatibility, or
> > about how hard it is for tools to parse. I want it to be possible, but
> > if it takes a little extra effort, so
On Mon, Jan 27, 2020 at 2:01 AM Takashi Menjo
wrote:
> It sounds reasonable, but I'm sorry that I haven't tested such a program
> yet. I'll try it to compare with my non-volatile WAL buffer. For now, I'm
> a little worried about the overhead of mmap()/munmap() for each WAL segment
> file.
I gue
Hi,
On 2020-01-27 12:15:53 -0500, Tom Lane wrote:
> Maciek Sakrejda writes:
> > On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> >> Personally, I don't care very much about backward-compatibility, or
> >> about how hard it is for tools to parse. I want it to be possible, but
> >> if it takes
Maciek Sakrejda writes:
> On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
>> Personally, I don't care very much about backward-compatibility, or
>> about how hard it is for tools to parse. I want it to be possible, but
>> if it takes a little extra effort, so be it.
> I think these are two se
Hi,
On 2020-01-26 14:49:06 -0800, Peter Geoghegan wrote:
> Andres and I discussed bottlenecks in the nbtree code during the
> recent PgDay SF community event. Andres observed that the call to
> BTreeTupleGetNAtts() in _bt_compare() can become somewhat of a
> bottleneck. I came up with the very sim
On Mon, Jan 27, 2020 at 11:07 AM Tom Lane wrote:
> I have not, but I'm still going to stand by that point. It is not
> credible that the code we will want to share between frontend and
> backend will never contain any user-facing error reports.
It's hard to refute a statement this general; it ca
Hi,
On 2020-01-27 15:42:06 +, Floris Van Nee wrote:
>
> > He reported that the problem went away with the patches applied. The
> > following pgbench SELECT-only result was sent to me privately:
> >
> > before:
> > single: tps = 30300.202363 (excluding connections establishing)
> > al
Robert Haas writes:
> On Mon, Jan 27, 2020 at 10:50 AM Tom Lane wrote:
>> What it sounds to me like you want to do is implement (some equivalent of)
>> elog() but not ereport() for this environment. I'm going to resist that
>> pretty strongly, because I think it will lead directly to abuse of el
On Mon, Jan 27, 2020 at 10:50 AM Tom Lane wrote:
> So? elog() is just a specific degenerate case of ereport(). If we have
> a way to implement ereport() on frontend side then we can surely do
> elog() too.
I suppose that's true.
> What it sounds to me like you want to do is implement (some equ
On Fri, Jan 24, 2020 at 12:22 AM Amit Kapila wrote:
> One thing to note is that there are places in code where we use
> 'table' instead of 'relation' for the same thing in the error messages
> as seen in the below places (the first one uses 'relation', the second
> one uses 'table') and the patch
Robert Haas writes:
> On Mon, Jan 27, 2020 at 10:08 AM Tom Lane wrote:
>> What I keep thinking is that we should stick with ereport() as the
>> reporting notation, and invent a frontend-side implementation of it
>> that covers the cases you mention (ie WARNING and ERROR ... and maybe
>> DEBUG?),
> He reported that the problem went away with the patches applied. The
> following pgbench SELECT-only result was sent to me privately:
>
> before:
> single: tps = 30300.202363 (excluding connections establishing)
> all cores: tps = 1026853.447047 (excluding connections establishing)
On Mon, Jan 27, 2020 at 10:08 AM Tom Lane wrote:
> > Something like:
> > #ifdef FRONTEND
> > #define pg_croak(...) do { pg_log_fatal(__VA_ARGS__); exit(1) } while (0)
> > #define pg_carp(...) pg_log_warning(__VA_ARGS__);
> > #else
> > #define pg_croak(...) elog(ERROR, __VA_ARGS__)
> > #define pg_c
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 result.
Thanks for updating the patches!
I started reading the 0003 patch.
The approach that the 0003 patc
On Fri, Jan 24, 2020 at 11:12 PM Thomas Munro wrote:
> On Wed, Dec 11, 2019 at 2:07 AM Ibrar Ahmed wrote:
> > You are checking file->dirty twice, first before calling the function and
> > within the function too. Same for the Assert. For example.
>
> True. Thanks for the review. Before I post
Robert Haas writes:
> Probably the thorniest problem is the backend's widespread dependence
> on ereport() and elog(). Now, it would not be enormously difficult to
> code up something that will sigsetjmp() and siglongjmp() in front-end
> code just as we do in backend code, but I think it would be
Hi,
Recent developments on the "backup manifest" thread and others have
caused me to take an interest in making more code that has
historically been backend-only accessible in frontend environments
also. I'm pretty sure I'm not alone in having often wished for more
backend-only facilities to be av
2020年1月21日(火) 15:38 Michael Paquier :
>
> On Mon, Jan 20, 2020 at 10:50:21PM +0900, Michael Paquier wrote:
> > I have spent a good amount of time polishing 0001, tweaking the docs,
> > comments, error messages and a bit its logic. I am getting
> > comfortable with it, but it still needs an extra l
Hi Dmitry,
Thanks for the new patch! I tested it and managed to find a case that causes
some issues. Here's how to reproduce:
drop table if exists t;
create table t as select a,b,b%2 as c,10 as d from generate_series(1,5) a,
generate_series(1,1000) b;
create index on t (a,b,c,d);
-- correct
p
Em dom., 26 de jan. de 2020 às 23:48, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
> > On Jan 24, 2020, at 12:48 PM, Ranier Vilela wrote:
> >
> > 3. At function KeepLogSeg (line 9357) the test if (slotSegNo <= 0), the
> var slotSegNo is uint64 and not can be < 0.
>
> There is something
Em dom., 26 de jan. de 2020 às 23:04, Michael Paquier
escreveu:
> On Fri, Jan 24, 2020 at 09:37:25AM -0300, Ranier Vilela wrote:
> > Em sex., 24 de jan. de 2020 às 04:13, Michael Paquier <
> mich...@paquier.xyz>
> > escreveu:
> >> There is some progress. You should be careful about your patches,
On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
wrote:
> Ok, the tests pass. Here are those two patches again, both regenerated with
> a fresh invocation of ‘git format-patch’.
Regarding 0006:
+#ifndef FRONTEND
#include "miscadmin.h"
-#include "utils/jsonapi.h"
+#endif
I suggest
#ifdef FRONTEND
On Mon, Jan 27, 2020 at 5:11 PM Asim Rama Praveen
wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
> The
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
The logic to start WAL receiver early should not be coupled with
recovery_mi
On 2020-01-15 05:02, Kyotaro Horiguchi wrote:
FWIW, I restate this (perhaps) more clearly.
At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi
wrote in
recvoery_target_* is not cleared after startup. If a server crashed
just after the last shutdown checkpoint, any recovery_target_* se
At Mon, 27 Jan 2020 16:55:56 +0900, Michael Paquier wrote
in
> On Sun, Jan 26, 2020 at 06:47:57PM -0800, Mark Dilger wrote:
> > There is something unusual about comparing a XLogSegNo variable in
> > this way, but it seems to go back to 2014 when the replication slots
> > were introduced in commi
Hello, this is rebased then addressed version.
- Now valid rd_firstRelfilenodeSubid causes drop-pending of relcache
as well as rd_createSubid. The oblivion in the last example no
longer happens.
- Revert the (really) useless change of AssertPendingSyncs_RelationCache.
- Fix several comments
> On Wed, Jan 22, 2020 at 10:36:03PM +0100, Dmitry Dolgov wrote:
>
> > Let me try to clarify. After we return the first tuple, so->currPos.buf is
> > pointing to page=1 in my example (it's the only page after all). We've
> > returned item=8. Then the split happens and the items get rearranged as
Hi,
On 2020/01/24 23:44, Amit Langote wrote:
On Fri, Jan 24, 2020 at 6:47 AM Alvaro Herrera wrote:
On 2020-Jan-22, Tatsuro Yamada wrote:
P.S.
Next up is progress reporting for query execution?!
Actually, I think it's ALTER TABLE.
+1. Existing infrastructure might be enough to cover ALTER
On 25.01.2020 18:15, 曾文旌(义从) wrote:
I wonder why do we need some special check for GTT here.
From my point of view cleanup at startup of local storage of temp
tables should be performed in the same way for local and global temp
tables.
After oom kill, In autovacuum, the Isolated local temp ta
On 2019-12-31 00:07, Vik Fearing wrote:
One thing I notice is that the joined columns are still accessible from
their respective table names when they should not be per spec. That
might be one of those "silly restrictions" that we choose to ignore, but
it should probably be noted somewhere, at t
On 24.01.2020 22:39, Pavel Stehule wrote:
I cannot to evaluate your proposal, and I am sure, so you know more
about this code.
There is a question if we can allow to build local temp index on
global temp table. It is different situation. When I work with global
properties personally I prefe
> On 27 Jan 2020, at 07:01, Michael Paquier wrote:
>
> On Fri, Jan 24, 2020 at 12:19:31PM +0100, Daniel Gustafsson wrote:
>> Attached is a v5 of the patch which hopefully address all the comments
>> raised,
>> sorry for the delay.
>
> Thanks for the new version.
Thanks for review and hackery!
73 matches
Mail list logo
