On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby wrote:
>
[skipped...]
>
> Oh, hmm. So I guess if you do that when the background process is idle it's
> the same as a close?
>
> I think we need some way to safeguard against accidental forkbombs for cases
> where users aren't intending to leave something
>
> Done. Attached is the new version of the patch.
>
> * I'm still not sure the search approach is the right way to go, so I
> modified CreateLocalJoinPath so that it creates a mergejoin path that
> explicitly sorts both the outer and inner relations as in
> sort_inner_and_outer, by using the inf
On Mon, Jan 9, 2017 at 5:01 PM, tushar wrote:
> Thanks Dilip. issue is reproducible if we uses '--enable-cassert' switch
> in the configure. We are able to reproduce it only with --enable-cassert' .
Thanks, Tushar. I have fixed it. The defect was in 0002. I have also
observed another issue rel
Hi
>
> Real support for using variables as identifiers / nothing restricted to
> only accepting a Const.
>
This point is problematic not only from performance perspective.
if you don't use some special syntax and you allow variables as identifier,
then you will got a ambiguous situation quick
On Sat, Jan 7, 2017 at 1:32 PM, Michael Paquier
wrote:
> On Sat, Jan 7, 2017 at 12:04 AM, Magnus Hagander
> wrote:
> > On Wed, Jan 4, 2017 at 10:43 AM, Magnus Hagander
> > wrote:
> >> Meh, just as I was going to respond "committed" I noticed this second
> >> round of review comments. Apologies,
Jim Nasby writes:
> On 1/8/17 11:25 AM, Tom Lane wrote:
>> But I don't understand
>> how you got the sample output shown in the patch. Is this based
>> on some unsubmitted changes in pltcl's error handling?
> Maybe it's a version difference?
> echo 'puts [info patchlevel];exit 0' | tclsh
> 8.6.6
On Fri, Jan 6, 2017 at 12:44 AM, Michael Paquier
wrote:
> > - OIDs - where do I get numbers from? I was kinda choosing them at
> random,
> > unaware if there is some process for keeping track of them. Please point
> me
> > if such thing exists and I'll change them.
>
> You can use src/include/cat
On 1/9/17 7:44 AM, Magnus Hagander wrote:
> So based on that, I suggest we go ahead and make the change to make both
> the values 10 by default. And that we do that now, because that lets us
> get it out through more testing on different platforms, so that we catch
> issues earlier on if they do ar
On 1/9/17 10:50 AM, Vladimir Rusinov wrote:
> pg_is_xlog_replay_paused| pg_is_recovery_paused
All the other xlog_replay names have been changed to wal_replay, so
making this one different is probably not so good.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Dev
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, failed
Pavel,
gstore/gbstore:
The functionality worked as expected - o
On Mon, Jan 9, 2017 at 4:14 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> > pg_is_xlog_replay_paused| pg_is_recovery_paused
>
> All the other xlog_replay names have been changed to wal_replay, so
> making this one different is probably not so good.
>
Oops, forgot about
Hi Ashutosh,
On 01/06/2017 12:54 AM, Ashutosh Sharma wrote:
using pgbench -M prepared -c 10 -j 10 -T 600 -f test.sql test
crashes after a few minutes with
TRAP: FailedAssertion("!(LWLockHeldByMeInMode(((LWLock*)
(&(bufHdr)->content_lock)), LW_EXCLUSIVE))", File: "bufmgr.c", Line: 3781)
Attac
On Sun, Jan 8, 2017 at 4:59 AM, Gavin Flower
wrote:
>> Is this completely unrealistic or is it carved in stone PostgreSQL will
>> always be a C project forever and ever?
>>
> From my very limited understanding, PostgreSQL is more likely to be
> converted to C++!
I'm tempted to snarkily reply that
On Mon, Jan 9, 2017 at 7:50 AM, Amit Kapila wrote:
> Okay, I see the point. I think here UNDO pointer can be marked
> invalid either during page-pruning or vacuum.
I explicitly want to avoid that, because it means re-dirtying the
page. The UNDO pointer becomes invalid by removing the UNDO log t
Kuntal Ghosh wrote:
> Added to next commitfest for tracking. I should've done it earlier.
Yeah -- I hadn't noticed this thread until last week. I intend to apply
this very soon.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Train
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Hmm. The bespoke code for constructing the attno map bothers me;
> >> surely there is existing code that does that? If not, it'd still
> >> make more sense to factor it out, I think, because there will be
> >> other needs for it i
On Fri, Jan 6, 2017 at 11:32 PM, Amit Kapila wrote:
> On Sat, Jan 7, 2017 at 2:33 AM, Robert Haas wrote:
>> It looks to to me like the recent hash index changes have left
>> _hash_addovflpage slightly broken. I think that if that function
>> reaches the point where it calls _hash_getbuf() to fet
On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
wrote:
> On 1/3/17 11:52 PM, Ashutosh Bapat wrote:
>> We will need to make CURRENT_DATABASE a reserved keyword. But I like
>> this idea more than COMMENT ON CURRENT DATABASE.
>
> We already have the reserved key word CURRENT_CATALOG, which is the
>
On Sat, Jan 7, 2017 at 7:45 PM, Jim Nasby wrote:
> Well, now that there's 3 places that need to do almost the same thing, I
> think it'd be best to just centralize this somewhere. I realize that's not
> going to save any significant amount of code, but it would make it crystal
> clear what's going
Alvaro Herrera writes:
> Tom Lane wrote:
>> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
>> in access/common/tupconvert.c. There's a bit of an API mismatch in that
>> it wants to wrap the mapping array in a TupleConversionMap struct; but
>> maybe we could refactor tup
On 1/7/17 8:52 PM, Jim Nasby wrote:
> I've now moved my normal install locations to somewhere I can exclude
> from mds and what-not, but I don't see any way to do that with
> tmp_install. Is there a trick here I'm missing, or should I change
> Makefile.global.in to check for an environment variab
I wrote:
> Pushed with that and some other, mostly-cosmetic changes.
Hmm, looks like the new test cases have turned up a pre-existing bug.
Some of the buildfarm is showing crashes :-(. It looks like all the
unhappy critters are running Tcl 8.4.something, which might be a
coincidence but I bet not
Kuntal Ghosh wrote:
> Hi all,
>
> In brin_doupdate(line 290), REGBUF_STANDARD is used to register
> revmap buffer reference in WAL record. But, revmap buffer page doesn't
> have a standard page layout and it doesn't update pd_upper and
> pd_lower as well.
Hmm. This bug should be causing WAL repl
On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote:
> On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
> wrote:
> > On 1/3/17 11:52 PM, Ashutosh Bapat wrote:
> >> We will need to make CURRENT_DATABASE a reserved keyword. But I like
> >> this idea more than COMMENT ON CURRENT DATABASE.
> >
On 10 January 2017 at 07:40, Robert Haas wrote:
> On Sat, Jan 7, 2017 at 7:45 PM, Jim Nasby wrote:
>> Well, now that there's 3 places that need to do almost the same thing, I
>> think it'd be best to just centralize this somewhere. I realize that's not
>> going to save any significant amount of c
On 1/1/17 4:14 PM, Simon Riggs wrote:
> OK, so here's the patch, plus doc cleanup patch.
I don't think this patch is likely to succeed if we throw in more ideas
in every round.
I think we have or are approaching agreement on moving recovery.conf
into postgresql.conf, making the settings reloadabl
Bruce Momjian wrote:
> On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote:
> > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
> > wrote:
> > > On 1/3/17 11:52 PM, Ashutosh Bapat wrote:
> > >> We will need to make CURRENT_DATABASE a reserved keyword. But I like
> > >> this idea more than
On 1/8/17 2:39 PM, Steve Singer wrote:
> The only concern I have with the functionality is that there isn't a way
> to change the type of a sequence.
If we implement the NEXT VALUE FOR expression (or anything similar that
returns a value from the sequence), then the return type of that
expression
On 1/9/17 1:34 PM, Robert Haas wrote:
> On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
> wrote:
>> On 1/3/17 11:52 PM, Ashutosh Bapat wrote:
>>> We will need to make CURRENT_DATABASE a reserved keyword. But I like
>>> this idea more than COMMENT ON CURRENT DATABASE.
>>
>> We already have the res
On Mon, Jan 9, 2017 at 04:52:46PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote:
> > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
> > > wrote:
> > > > On 1/3/17 11:52 PM, Ashutosh Bapat wrote:
> > > >> We will need to mak
On 1/9/17 2:52 PM, Alvaro Herrera wrote:
> CURRENT_USER is a standards-mandated keyword, but CURRENT_DATABASE is
> not. The closest thing SQL has is CURRENT_CATALOG, which is the string
> that identifies the "current default catalog". This would lead us to
> COMMENT ON DATABASE CURRENT_CATALO
On 1/7/17 10:01 PM, Peter Geoghegan wrote:
> It occurs to me that the comparison caching stuff added by commit
> 0e57b4d8b needs to be considered here, too. When we had to copy the
> string to a temp buffer anyway, in order to add the terminating NUL
> byte expected by strcoll(), there was an oppor
On Mon, Jan 9, 2017 at 12:25 PM, Peter Eisentraut
wrote:
> On 1/7/17 10:01 PM, Peter Geoghegan wrote:
>> It occurs to me that the comparison caching stuff added by commit
>> 0e57b4d8b needs to be considered here, too.
> That might be worth looking into, but it seems a bit daunting to
> construct
On Tue, Dec 27, 2016 at 6:50 PM, Peter Eisentraut
wrote:
> Updated patch attached.
Some more things I noticed following another quick read over the patch:
* I think it's worth looking into ucol_nextSortKeyPart(), and using
that as an alternative to ucol_getSortKey(). It doesn't seem any
harder,
Alvaro Herrera wrote:
> Kuntal Ghosh wrote:
> > Hi all,
> >
> > In brin_doupdate(line 290), REGBUF_STANDARD is used to register
> > revmap buffer reference in WAL record. But, revmap buffer page doesn't
> > have a standard page layout and it doesn't update pd_upper and
> > pd_lower as well.
>
> H
On 1/9/17 1:22 PM, Tom Lane wrote:
I wrote:
Pushed with that and some other, mostly-cosmetic changes.
Hmm, looks like the new test cases have turned up a pre-existing bug.
Some of the buildfarm is showing crashes :-(. It looks like all the
unhappy critters are running Tcl 8.4.something, which
On Thu, Jan 5, 2017 at 5:39 AM, Fabien COELHO wrote:
> Half-persistence (in definition, not in value) is not a key feature needed
> by the use-case.
Well, you don't get to decide that. You've been told by at least
three or four people that they don't want variables to be
transactional, you've be
Alvaro Herrera wrote:
> If you examine the revmap in a replica after running the script below,
> you'd observe it's different than the one in the master. I confirmed
> that the proposed patch fixes the problem.
Pushed. Thanks for the report!
--
Álvaro Herrerahttps://www.2ndQua
On Sun, Jan 8, 2017 at 11:36 AM, Greg Stark wrote:
> On 8 January 2017 at 17:26, Greg Stark wrote:
> > On 5 January 2017 at 19:01, Andres Freund wrote:
> >> That's a bit odd - shouldn't the OS network stack take care of this in
> >> both cases? I mean either is too big for TCP packets (includi
On 1/9/17 3:12 PM, Jim Nasby wrote:
I'm compiling 8.4 now, will see if I can duplicate.
Got a stack trace. The abort happens in TclObjLookupVar:
if (nsPtr->varResProc != NULL || iPtr->resolverPtr != NULL) {
nsPtr itself is NULL.
* thread #1: tid = 0x, 0x00010949bca8
libtcl8.4g.dyli
On Sat, Jan 7, 2017 at 9:01 AM, Thomas Munro
wrote:
> On Tue, Jan 3, 2017 at 10:53 PM, Thomas Munro
> wrote:
>> I will post a new rebased version soon with that and
>> some other nearby problems fixed.
>
> Here is a new WIP patch.
To make this easier to understand and harmonise the logic used in
Jim Nasby writes:
> Got a stack trace. The abort happens in TclObjLookupVar:
Yeah, I found the problem: pltcl_returnnext calls pltcl_build_tuple_result
which may throw elog(ERROR), leaving the Tcl interpreter's state all
screwed up, so that later functions go south. It seems quite accidental
tha
On Sun, Jan 08, 2017 at 06:50:12PM -0600, Jim Nasby wrote:
> On 1/5/17 12:04 AM, David Fetter wrote:
> > +errmsg("UPDATE requires a WHERE clause
> > when require_where.delete is set to on"),
>
> ISTM that message is no longer true.
>
> The second if could also
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> [ pokes around... ] The code I was thinking of is convert_tuples_by_name
> >> in access/common/tupconvert.c. There's a bit of an API mismatch in that
> >> it wants to wrap the mapping array in a TupleConversionMap struct; but
> >>
David Fetter wrote:
> + if (query->commandType == CMD_UPDATE || query->commandType ==
> CMD_DELETE)
> + {
> + /* Make sure there's something to look at. */
> + Assert(query->jointree != NULL);
> + if (query->jointree->quals == NULL)
> +
On Mon, Jan 09, 2017 at 07:52:11PM -0300, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > + if (query->commandType == CMD_UPDATE || query->commandType ==
> > CMD_DELETE)
> > + {
> > + /* Make sure there's something to look at. */
> > + Assert(query->jointree != NULL);
>
On 1/9/17 4:23 PM, Tom Lane wrote:
Jim Nasby writes:
Got a stack trace. The abort happens in TclObjLookupVar:
Yeah, I found the problem: pltcl_returnnext calls pltcl_build_tuple_result
which may throw elog(ERROR), leaving the Tcl interpreter's state all
screwed up, so that later functions go
On Sun, Jan 8, 2017 at 2:52 AM, Joel Jacobson wrote:
> On Sat, Jan 7, 2017 at 8:56 PM, Pavel Stehule wrote:
>>
>> Jim, Marko, Joel - is there a place, features where we can find a partial
>> agreement? If it is, then we can move our view there.
>
> I have decided I definitively want a new langua
On Mon, Jan 9, 2017 at 12:37 AM, Jim Nasby wrote:
> If we're going to create a brand new language then I think it would be
> extremely foolish to keep *any* of the current pain points around. Off the
> top of my head:
>
> - variables must have an identifier (what $ in most languages does). The
>
On 01/09/2017 06:12 PM, Merlin Moncure wrote:
With respect to your company developers specifically? I'm genuinely
curious if you've taken a good look at pl/v8 and why you've determined
it's not suitable to move forward with. It's got a different set of
headaches, but is really fast, and somet
Jim Nasby writes:
> Hmm... I suspect there's more places where this could be a problem. For
> example, pltcl_quote calls palloc, which could ereport as well.
Yeah. I looked at that but couldn't get terribly excited about it,
because AFAICS, Tcl in general is apt to fall over under sufficient
me
On Tue, Jan 10, 2017 at 12:05 AM, Magnus Hagander wrote:
> OK. Pushed. I agree it made it more readable, if nothing else.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hac
On 1/9/17 5:30 PM, Marko Tiikkaja wrote:
This is exactly what we did not want to do with this project. The idea
is to create a language which is really close to PL/PgSQL, but removes
some of the brain diarrhoea currently present.
As a general comment, ISTM it'd be much better to do as much as
On Tue, Jan 10, 2017 at 12:47 AM, Jim Nasby
wrote:
> On 1/9/17 5:30 PM, Marko Tiikkaja wrote:
>
My idea was that the currently unsupported combination of NOT NULL and
>> no DEFAULT would mean "has to be assigned to a non-NULL value before it
>> can be read from, or an exception is thrown". Solve
On 1/9/17 5:12 PM, Merlin Moncure wrote:
Agreed: If you want to break compatibility, pushing a new language is
the better way than GUC. If you got consensus on this, having both
languages side by side supported for a while (maybe 4-5 releases) is
they way to go, and finally the only language is
On 1/9/17 3:01 AM, Pavel Stehule wrote:
You are forgot on function paramaters - somebody can use a function
argument like FOUND, .. So auto variables should to be declared in most
top namespace.
Right, that's why I said it was an alternative. I agree it would be
better to just have 2 explici
On 1/9/17 5:53 PM, Marko Tiikkaja wrote:
My idea was that the currently unsupported combination of NOT
NULL and
no DEFAULT would mean "has to be assigned to a non-NULL value
before it
can be read from, or an exception is thrown". Solves the most
co
On Tue, Jan 10, 2017 at 1:03 AM, Jim Nasby wrote:
> On 1/9/17 5:53 PM, Marko Tiikkaja wrote:
>
>> My idea was that the currently unsupported combination of NOT
>> NULL and
>> no DEFAULT would mean "has to be assigned to a non-NULL value
>> before it
>> can
On 1/9/17 5:38 PM, Tom Lane wrote:
Jim Nasby writes:
Hmm... I suspect there's more places where this could be a problem. For
example, pltcl_quote calls palloc, which could ereport as well.
Yeah. I looked at that but couldn't get terribly excited about it,
because AFAICS, Tcl in general is ap
On 1/9/17 6:07 PM, Marko Tiikkaja wrote:
One use case is NEW and OLD in triggers. Checking to see if one or
the other is set is easier than checking TG_OP. It's also going to
be faster (probably MUCH faster; IIRC the comparison currently
happens via SPI).
This sounds useless.
On 1/9/17 3:15 AM, Pavel Stehule wrote:
The running unsafe PL in own managed processes is good idea - Years, I
have a one diploma theme "better management of unsafe PL in Postgres" -
but still without any interest from students :(. I had two
possibilities to see catastrophic errors related to wr
On 1/9/17 11:51 AM, Robert Haas wrote:
Anyway, with regards to either Rust (which I know very little about)
or C++ (which I know more about) I think it would be more promising to
think about enabling extensions to be written in such languages than
to think about converting the entire source base.
Jim Nasby writes:
> On 1/9/17 5:38 PM, Tom Lane wrote:
>> Yeah. I looked at that but couldn't get terribly excited about it,
>> because AFAICS, Tcl in general is apt to fall over under sufficient
>> memory pressure.
> Though, since a memory error could just as likely come out of tcl, which
> is
On 1/9/17 7:22 AM, amul sul wrote:
On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby wrote:
[skipped...]
Oh, hmm. So I guess if you do that when the background process is idle it's
the same as a close?
I think we need some way to safeguard against accidental forkbombs for cases
where users aren't
On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby wrote:
> I do wonder if there are parts of the codebase that would be much better
> suited to a language other than C, and could reasonably be ported.
> Especially if that could be done in such a way that the net result is still
> C code so we're not addin
On Sat, Jan 7, 2017 at 8:19 PM, Magnus Hagander wrote:
> On Sat, Jan 7, 2017 at 12:31 AM, Michael Paquier
> wrote:
>> There is something I forgot. With this patch,
>> FindStreamingStart()@pg_receivexlog.c is actually broken. In short it
>> forgets to consider files that have been compressed at th
On 18-12-2016 18:30, Peter Eisentraut wrote:
> Updated patch with that fix.
>
Peter, I reviewed and improved your patch.
* I document the new function. Since collation is a database object, I
chose "Database Object Management Functions" section.
* I've added a check to any-encoding database becau
On 2017-01-09 16:02, Anastasia Lubennikova wrote:
include_columns_10.0_v1.patch
The patch applies, compiles, and make check is OK.
It yields nice perfomance gains and I haven't been able to break
anything (yet).
Some edits of the sgml-changes are attached.
Thank you for this very useful i
Hello, Amit, Magnus,
I'm sorry for my late reply. Yesterday was a national holiday in Japan.
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
> PGSharedMemoryReAttach is called after the startup of new process whereas
> pgwin32_Rese
On Mon, Jan 9, 2017 at 11:59 PM, Robert Haas wrote:
> On Fri, Jan 6, 2017 at 11:32 PM, Amit Kapila wrote:
>> On Sat, Jan 7, 2017 at 2:33 AM, Robert Haas wrote:
>>> It looks to to me like the recent hash index changes have left
>>> _hash_addovflpage slightly broken. I think that if that function
On 10 January 2017 at 05:14, Robert Haas wrote:
> 2. The user doesn't need to re-declare the variables you want to use
> at the beginning of every session. This is also the reason why many
> people want global temporary tables. They don't do anything that
> can't be done with local temporary ta
On 10 January 2017 at 09:54, Joel Jacobson wrote:
> One idea of an area that would be most useful from a user-perspective
> is probably all pg_catalog functions that are immutable.
> They should be able to be written without expertise of the PostgreSQL
> internals,
> since they only depend on th
On Sat, Jan 7, 2017 at 7:48 PM, Jim Nasby wrote:
> On 1/5/17 12:55 PM, Jonathon Nelson wrote:
>
>> Attached please find a patch for PostgreSQL 9.4 which changes the
>> maximum amount of data that the wal sender will send at any point in
>> time from the hard-coded value of 128KiB to a user-contro
Greetings,
For reasons which seem likely to be entirely unintentional, pg_restore
will accept a '-1' for -j:
pg_restore -j -1
This seems to result in the parallel state being NULL and so things
don't outright break, but it hardly seems likely to be what the user was
asking for- my guess is that
2017-01-10 2:02 GMT+01:00 Jim Nasby :
> On 1/9/17 6:07 PM, Marko Tiikkaja wrote:
>
>> One use case is NEW and OLD in triggers. Checking to see if one or
>> the other is set is easier than checking TG_OP. It's also going to
>> be faster (probably MUCH faster; IIRC the comparison current
On 1/7/17 6:39 AM, Pavel Stehule wrote:
> ROW_COUNT .. shortcut for GET DIAGNOSTICS row_count = ROW_COUNT.
I don't see the point.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers maili
2017-01-10 5:59 GMT+01:00 Peter Eisentraut :
> On 1/7/17 6:39 AM, Pavel Stehule wrote:
> > ROW_COUNT .. shortcut for GET DIAGNOSTICS row_count = ROW_COUNT.
>
> I don't see the point.
>
A check how much rows was impacted by query is relative often task. So we
can do this task more user friendly.
I happened to notice that we have dead code to parse floating point
numbers in the boostrap scanner/parser. This seems unused since forever
-- or, more precisely, I couldn't find any floats in 8.2's postgres.bki
(the oldest I have around). I would just rip it out, per the attached.
--
Álvaro He
On Tue, Jan 10, 2017 at 1:53 AM, Vladimir Rusinov wrote:
>
> On Mon, Jan 9, 2017 at 4:14 PM, Peter Eisentraut
> wrote:
>>
>> > pg_is_xlog_replay_paused| pg_is_recovery_paused
>>
>> All the other xlog_replay names have been changed to wal_replay, so
>> making this one different is probably
On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer wrote:
> Immutable functions can and do use functionality from all over the
> server. They just don't depend on user-visible mutable _state_
> elsewhere in the server.
OK, fair point, but at least the functionality *could* be written without using
exis
Is there any reason for the exclusion of parent tables from the pg_tables
system catalog view? They do not show up in information_schema.tables as
well. I believe I found where to make the changes and I tested to make sure
it works for my simple case. Attached is my first attempt at patching
anythi
Daniel Verite wrote:
> My tests are OK too but I see an issue with the code in
> enlargeStringInfo(), regarding integer overflow.
> The bit of comment that says:
>
> Note we are assuming here that limit <= INT_MAX/2, else the above
> loop could overflow.
>
> is obsolete, it's now INT_MAX ins
On Tue, Jan 10, 2017 at 2:52 AM, Alvaro Herrera
wrote:
>
> Alvaro Herrera wrote:
>
> > If you examine the revmap in a replica after running the script below,
> > you'd observe it's different than the one in the master. I confirmed
> > that the proposed patch fixes the problem.
>
> Pushed. Thanks
On 01/09/2017 07:22 PM, Dilip Kumar wrote:
Thanks, Tushar. I have fixed it. The defect was in 0002. I have also
observed another issue related to code refactoring, Actually, there
was some code present in 0001 which supposed to be in 0003.
Thanks, I have checked at my end and it is fixed now.
-
On Sat, Jan 7, 2017 at 7:18 AM, Claudio Freire wrote:
> On Fri, Jan 6, 2017 at 2:38 PM, Masahiko Sawada wrote:
>> table_size | indexes | parallel_degree | time
>> +-+-+--
>> 6.5GB | 0 | 1 | 00:00:14
>> 6.5GB | 0
On Wed, Dec 28, 2016 at 11:47 AM, Amit Kapila wrote:
> Attached patch implements the above idea. This will enable
> parallelism for queries containing un-correlated subplans, an example
> of which is as follows:
I have reviewed the patch (pq_pushdown_subplan_v1.patch), Mostly patch
looks clean t
Hello Robert,
Half-persistence (in definition, not in value) is not a key feature
needed by the use-case.
Well, you don't get to decide that.
I do not think that your reprimand is deserved about this point: I did not
decide a subjective opinion, I noted an objective fact.
You've been tol
On Mon, Jan 9, 2017 at 2:18 PM, Masahiko Sawada wrote:
> On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila wrote:
>> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada
>> wrote:
>>> On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier
>>> wrote:
On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada
On Sun, Jan 1, 2017 at 1:17 AM, Peter Eisentraut
wrote:
> On 12/1/16 9:32 PM, Peter Eisentraut wrote:
>> I think it would be better to get rid of objargs and have objname be a
>> general Node that can contain more specific node types so that there is
>> some amount of type tracking. FuncWithArgs
On 2017/01/09 22:36, Ashutosh Bapat wrote:
I wrote:
Done. Attached is the new version of the patch.
Why is this so?
* If the outer cheapest-total path is parameterized by the inner
* rel, we can't generate a nestloop path.
That parameterization means that for each
On Tue, Jan 10, 2017 at 3:46 PM, Amit Kapila wrote:
> On Mon, Jan 9, 2017 at 2:18 PM, Masahiko Sawada wrote:
>> On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila wrote:
>>> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada
>>> wrote:
On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier
wrote:
On Thu, Jan 5, 2017 at 1:58 PM, Michael Paquier
wrote:
> Could you hold on a bit to commit that? I'd like to look at it in more
> details. At quick glance, there is for example no need to use
> CreateTemplateTupleDesc and list the columns both in pg_proc.h and the
> C routine itself. And memset()
On Fri, Jan 6, 2017 at 3:51 PM, Vitaly Burovoy
wrote:
> On 1/4/17, Haribabu Kommi wrote:
> > On Tue, Nov 29, 2016 at 8:36 PM, Haribabu Kommi <
> kommi.harib...@gmail.com>
> > wrote:
> >> Updated patch attached with added cast function from macaddr8 to
> >> macaddr.
> >>
> >> Currently there are
Hi,
I got server crash due to assert failure at ATTACHing overlap rang
partition, here is test case to reproduce this:
CREATE TABLE test_parent(a int) PARTITION BY RANGE (a);
CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES
FROM(100) TO(200);
CREATE TABLE test_parent_part1(a int
2017-01-09 0:37 GMT+01:00 Jim Nasby :
> On 1/8/17 2:52 AM, Joel Jacobson wrote:
>
>> And please kill all these GUCs ideas. The best thing with PostgreSQL
>> is the natural expected behaviour of the default configuration.
>> Contrary to MySQL where you have to enable lots and lots of
>> configurati
[ Re sending to Hackers as the earlier mail failed to deliver to Hackers
mailing list]
On Mon, Jan 9, 2017 at 4:13 PM, Haribabu Kommi
wrote:
>
>
> On Thu, Aug 25, 2016 at 2:46 PM, Haribabu Kommi
> wrote:
>
>> On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas
>> wrote:
>> >
>> > Personally, my prefer
On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila wrote:
> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada
> wrote:
>> On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier
>> wrote:
>>> On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada
>>> wrote:
Yeah, I don't have a good solution for this problem
2017-01-09 1:10 GMT+01:00 Jim Nasby :
> On 1/8/17 12:03 AM, Pavel Stehule wrote:
>
>> BTW, I do wish you could change the label of the scope that
>> arguments went into, so that you could use that label to refer
>> to function parameters. If we allowed that it'd perhaps be
On 9 January 2017 at 08:48, Masahiko Sawada wrote:
> I had not considered necessity of dead lock detection support.
It seems like a big potential win to scan multiple indexes in parallel.
What do we actually gain from having the other parts of VACUUM execute
in parallel? Does truncation happen
2017-01-09 0:39 GMT+01:00 Jim Nasby :
> On 1/7/17 11:44 PM, Pavel Stehule wrote:
>
>> This is not overloading of SQL command - it is like annotations. It is
>> smart idea, so I was not surprised if ANSI/SQL reuses it.
>>
>
> SHas ANSI declared that they will NEVER support := in a SELECT that's not
1 - 100 of 108 matches
Mail list logo
