On Sat, Mar 24, 2018 at 1:36 AM, Peter Geoghegan wrote:
>
> Fair enough. Attached patch shows what I'm on about. This should be
> applied on top of 0001_merge_v23e_onconflict_work.patch +
> 0002_merge_v23e_main.patch. I'm not expecting an authorship credit for
> posting this patch.
>
Thanks for
On Fri, Mar 23, 2018 at 11:15 PM, Peter Geoghegan wrote:
> I agree that this is very similar, as far as the RTEs go. What is
> dissimilar is the fact that there is hard-coded knowledge of both
> through parsing, planning, and execution. It's everything, taken
> together.
>
> ResultRelInfo has a ri
On Fri, Mar 23, 2018 at 4:56 AM, Pavan Deolasee
wrote:
> postgres=# insert into target as t select sid from source s join target t on
> t.ttid = s.sid;
> ERROR: column t.ttid does not exist
> LINE 1: ...rget as t select sid from source join target t on t.ttid = s...
>
On Sat, Mar 24, 2018 at 8:39 AM, Vimal Rathod wrote:
>
> Thank you for replying to my message in very short time. As you have said, I
> looked into the url and found that I am interested in doing
> TOAST'ing in Slices Project. Can you give me some more details about this
> project other than the o
On 24 March 2018 at 01:15, Amit Langote wrote:
> In the updated patch (that is, after incorporating your changes), I have
> moved this partsupfunc switching to the caller of partkey_datum_from_expr
> instead of doing it there. New patch also checks that returned function
> OID is valid, which if
On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote:
> Yeah, sometimes that kind of stuff change performance characteristics,
> but I think what is going on here is that create_projection_plan is
> causing the lower node to build physical tlist which takes some
> additional time. I have tried bel
-- Forwarded message --
From: "Vimal Rathod"
Date: 23-Mar-2018 9:51 PM
Subject: Re: GSOC 2018 Ideas
To: "Jaime Soler"
Cc:
Thank you for replying to my message in very short time. As you have said,
I looked into the url and found that I am interested in doing
TOAST'ing in Slices P
On Thu, Mar 08, 2018 at 11:14:59PM -0800, Noah Misch wrote:
> On Thu, Mar 08, 2018 at 02:00:23PM -0500, Robert Haas wrote:
> > I also wonder why we're all convinced that this urgently needs to be
> > changed. I agree that the default configuration we ship is not the
> > most secure configuration t
On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov
wrote:
>> * There is minor formatting issue in this part of code. Some spaces need
>> to be replaced with tabs.
>> +IndexTuple
>> +index_truncate_tuple(Relation idxrel, IndexTuple olditup)
>> +{
>> + TupleDesc itupdesc =
>> CreateTupleDescCopy
I made a bunch of further edits and I think this v10 is ready to push.
Before doing so I'll give it a final look, particularly because of the
new elog(ERROR) I added. Post-commit review is of course always
appreciated.
Most notable change is because I noticed that if you mention an
intermediate p
On Fri, Mar 23, 2018 at 11:06:48AM +, Simon Riggs wrote:
> Your assumption that I would commit a new patch that was 29 mins old
> is frankly pretty ridiculous, so yes, lets keep calm.
When a committer says that a patch is "ready for commit" and that he
calls for "last objections", I am underst
+1
If pgss had a PlanId column (just after QueryId), that would be wonderfull
;o)
Question: Is there a simple way to "un-normalize" the query (I mean rebuild
the original query as it was before normalization) ?
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers
On 24 March 2018 at 01:42, Jim Finnerty wrote:
> Distinctness can also be preserved across joins, so if you have a 'snowflake
> query' type join, where all the joins are to a unique key, then the
> distinctness of the other side of the join is preserved. For example, a
> SELECT DISTINCT * FROM fa
On 24 March 2018 at 05:55, Melanie Plageman wrote:
> I was just wondering, since get_primary_key_attnos opens pg_constraint and
> just skips attributes with other constraint types than primary, what would
> be the reason we wouldn't just also open pg_attribute and check for the
> non-nullness of t
On 22 March 2018 at 18:58, David Rowley wrote:
> On 21 March 2018 at 16:29, Melanie Plageman wrote:
>> The new status of this patch is: Waiting on Author
>
> Thanks for reviewing this. I've attached an updated patch. I'll set
> back to waiting for review again.
I've attached another version of
Hi!
Some help you could get from
https://github.com/postgrespro/memstat
Vladimir Sitnikov wrote:
Hi,
I investigate an out of memory-related case for PostgreSQL 9.6.5, and it
looks like MemoryContextStatsDetail + gdb are the only friends there.
--
Teodor Sigaev E-mail: t
On Fri, Mar 23, 2018 at 6:55 AM, Simon Riggs wrote:
> Peter, if you have the code and you consider it important that this
> subfeature is in PostgreSQL, why not post the code so we can commit
> it?
Fair enough. Attached patch shows what I'm on about. This should be
applied on top of 0001_merge_v2
Andres Freund writes:
> On 2018-03-23 15:12:43 -0400, Tom Lane wrote:
>> Well, in the cases I'm thinking of at the moment, there's no handy Node
>> to point at, just module-private structs like PLpgSQL_function.
> Well, the cases Vladimir were concerned about seem less clear
> though. It'd be nic
On 2018-03-23 15:12:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
> >> + MemoryContextSetIdentifier(func_cxt, function->fn_signature);
> >>
> >> This would cost an extra char * field in struct MemoryContextData,
> >> which is slightly annoyi
Andres Freund writes:
> On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
>> + MemoryContextSetIdentifier(func_cxt, function->fn_signature);
>>
>> This would cost an extra char * field in struct MemoryContextData,
>> which is slightly annoying but it doesn't exactly seem like a killer.
>> Then the
Hi,
On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
> func_cxt = AllocSetContextCreate(TopMemoryContext,
> "PL/pgSQL function context",
> ALLOCSET_DEFAULT_SIZES);
> plpgsql_compile_tmp_cxt = MemoryContextSwitchTo(func_
On Fri, Mar 23, 2018 at 7:58 PM, Andres Freund wrote:
> Hi,
>
> On 2018-03-23 14:54:46 -0400, Tom Lane wrote:
> > So I see somebody at 2ndQ has set up a bunch of ppc64le buildfarm
> > members, which I applaud. But they're all failing on the 9.3 branch,
> > because we lack support for that archit
Hi,
On 2018-03-23 14:54:46 -0400, Tom Lane wrote:
> So I see somebody at 2ndQ has set up a bunch of ppc64le buildfarm
> members, which I applaud. But they're all failing on the 9.3 branch,
> because we lack support for that architecture in that branch.
>
> Does anyone have the stomach for trying
So I see somebody at 2ndQ has set up a bunch of ppc64le buildfarm
members, which I applaud. But they're all failing on the 9.3 branch,
because we lack support for that architecture in that branch.
Does anyone have the stomach for trying to add such support? The minimum
requirement would be to ba
2018-03-23 18:55 GMT+01:00 Fabien COELHO :
>
> Hello Daniel,
>
> Do you know when you'll have an updated patch that addresses the minor
>>> issues brought up in review and the concern above?
>>>
>>
>> Here's an update addressing the issues discussed:
>>
>> - fieldsep and recordsep are used, no mor
2018-03-23 12:59 GMT+01:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > It should not be hard. All formats can has '|' like now, and csv can
> have a
> > ',' - then if field separator is not explicit, then default field
> separator
> > is used, else specified field separator is used.
> >
>
Andres Freund writes:
> On 2018-03-23 18:05:38 +, Vladimir Sitnikov wrote:
>> For instance, I assume statament cache is stored in some sort of a hash
>> table, so there should be a way to enumerate it in a programmatic way. Of
>> course it would take time, however I do not think it creates cpu
Hello Daniel,
Do you know when you'll have an updated patch that addresses the minor
issues brought up in review and the concern above?
Here's an update addressing the issues discussed:
- fieldsep and recordsep are used, no more fieldsep_csv
- the command line option is --csv without short o
On 2018-03-23 18:05:38 +, Vladimir Sitnikov wrote:
> Andres>The overhead required for it (in cycles, in higher memory usage due
> to
> additional bookeeping
>
> Does that mean the memory contexts are unparseable? (there's not enough
> information to enumerate contents)
You can enumerate them
Andres>The overhead required for it (in cycles, in higher memory usage due
to
additional bookeeping
Does that mean the memory contexts are unparseable? (there's not enough
information to enumerate contents)
What if memory dump is produced by walking the C structures?
For instance, I assume statam
Hi,
On 2018-03-23 16:18:52 +, Vladimir Sitnikov wrote:
> Hi,
>
> I investigate an out of memory-related case for PostgreSQL 9.6.5, and it
> looks like MemoryContextStatsDetail + gdb are the only friends there.
>
> MemoryContextStatsDetail does print some info, however it is rarely
> possible
I think this documentation change:
+ leaving the old cluster untouched. At present, this is supported
on Linux
-
would be better by changing "untouched" to "unmodified".
Also, it would be nice if users could easily know if pg_upgrade is goi
On Thu, Mar 22, 2018 at 5:20 PM, David Rowley
wrote:
> The problem is that in order to properly invalidate cached plans we
> must record the constraint OIDs which the plan depends on. We can do
> that for PK and UNIQUE constraints, unfortunately, we can't do it for
> NOT NULL constraints as, at
On 3/13/18 12:34 PM, David Steele wrote:
> Updated the patch to change die() to BAIL_OUT() and use append_to_file()
> as suggested for another test patch.
Updated patch now that the unlogged table exclusions have been committed
[1].
Thanks,
--
-David
da...@pgmasters.net
[1]
https://www.postgre
Hi David,
Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele:
> On 3/23/18 5:36 AM, Michael Banck wrote:
> > Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele:
> > >
> > > +if (phdr->pd_checksum != checksum)
> > >
> > > I've attached a patch that adds basic retry func
Hi Peter,
On 3/23/18 10:36 AM, Peter Eisentraut wrote:
> I have committed a basic pg_resetwal test suite as part of another
> patch, so please adjust accordingly.
>
> It looks to me like your pg_resetwal tests contain a bit of useless
> copy-and-paste. For example, you are not using use Config,
On 3/23/18 12:14 PM, Teodor Sigaev wrote:
>
> Thank you, pushed
Thank you, Teodor! I'll rebase the temp table exclusion patch and
provide an updated patch soon.
--
-David
da...@pgmasters.net
Hi,
I investigate an out of memory-related case for PostgreSQL 9.6.5, and it
looks like MemoryContextStatsDetail + gdb are the only friends there.
MemoryContextStatsDetail does print some info, however it is rarely
possible to associate the used memory with business cases.
For insance:
CachedP
On 23.03.2018 18:45, Alvaro Herrera wrote:
Konstantin Knizhnik wrote:
rd_projidx is not a list, it is Bitmapset. It is just one of many bitmap
sets in RelationData:
Yes, but the other bitmapsets are of AttrNumber of the involved column.
They new one is of list_nth() counters for items in the
Thank you, pushed
David Steele wrote:
On 1/29/18 8:10 PM, Masahiko Sawada wrote:
On Tue, Jan 30, 2018 at 5:45 AM, Adam Brightwell
If it is agreed that the temp file exclusion should be submitted as a
separate patch, then I will mark 'ready for committer'.
Agreed, please mark this patch as
On 22.03.2018 23:53, Alvaro Herrera wrote:
The whole IsProjectionFunctionalIndex looks kinda bogus/ugly to me. Set
the boolean to false, but keep evaluating anyway? But then, I thought
the idea was to do this based on the reloption, not by comparing the
expression cost to a magical (unmodifia
Hi,
On 2018-03-23 15:58:55 +, Vladimir Sitnikov wrote:
> I've got a problem with PostgreSQL 9.6.5: backend gets killed by OOM
> killer, and it shuts the DB down.
> Of course, the OOM case is to be investigated (MemoryContextStatsDetail,
> etc), however I wonder if DB can be more robust.
Confi
Hi,
I've got a problem with PostgreSQL 9.6.5: backend gets killed by OOM
killer, and it shuts the DB down.
Of course, the OOM case is to be investigated (MemoryContextStatsDetail,
etc), however I wonder if DB can be more robust.
The sad thing is a single backend crash results in the DB shutdown, s
On 23 March 2018 at 15:39, Konstantin Knizhnik
wrote:
>
>
> On 22.03.2018 23:37, Alvaro Herrera wrote:
>>
>> The rd_projidx (list of each nth element in the index list that is a
>> projection index) thing looks odd. Wouldn't it make more sense to have
>> a list of index OIDs that are projection i
Konstantin Knizhnik wrote:
> rd_projidx is not a list, it is Bitmapset. It is just one of many bitmap
> sets in RelationData:
Yes, but the other bitmapsets are of AttrNumber of the involved column.
They new one is of list_nth() counters for items in the index list.
That seems weird and it scares
Chapman Flack wrote:
> Hi,
>
> Can somebody confirm or correct what I (think I)'ve gleaned from
> the code?
>
> - Commit timestamps are always WAL logged, and so in principle
> determinable after the fact (with some amount of effort), regardless
> of the track_commit_timestamp setting. (I gue
On 22.03.2018 23:37, Alvaro Herrera wrote:
The rd_projidx (list of each nth element in the index list that is a
projection index) thing looks odd. Wouldn't it make more sense to have
a list of index OIDs that are projection indexes?
rd_projidx is not a list, it is Bitmapset. It is just one
you may have a look at https://wiki.postgresql.org/wiki/GSoC_2018 and tell
us if you like some of them
2018-03-23 15:32 GMT+01:00 Vimal Rathod :
> Hey there,
>
> I am Vimal currently pursuing my undergraduate degree in computer science ,I
> would love to work with you via
> the GSoC program thi
Hi,
Can somebody confirm or correct what I (think I)'ve gleaned from
the code?
- Commit timestamps are always WAL logged, and so in principle
determinable after the fact (with some amount of effort), regardless
of the track_commit_timestamp setting. (I guess this must have long
been true, t
On 5 March 2018 at 16:37, Nikhil Sontakke wrote:
>>
>> I will re-submit with "git format-patch" soon.
>>
> PFA, patches in "format-patch" format.
>
> This patch set also includes changes in the test_decoding plugin along
> with an additional savepoint related test case that was pointed out on
> t
On 2018-03-23 11:06:48 +, Simon Riggs wrote:
> Your assumption that I would commit a new patch that was 29 mins old
> is frankly pretty ridiculous, so yes, lets keep calm.
Uh.
On Sat, Mar 10, 2018 at 7:41 AM, Yura Sokolov wrote:
> 08.03.2018 03:42, Tomas Vondra пишет:
>> One reason against building the hash table in GetSnapshotData is that
>> we'd build it even when the snapshot is never queried. Or when it is
>> queried, but we only need to check xmin/xmax.
>
> Thank y
Hi Michael,
On 3/23/18 5:36 AM, Michael Banck wrote:
> Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele:
>>
>> +if (phdr->pd_checksum != checksum)
>>
>> I've attached a patch that adds basic retry functionality. It's not
>> terrible efficient since it rereads the entire buffer
On Thu, Mar 22, 2018 at 12:28 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/21/18 03:40, Michael Paquier wrote:
> >>> Moreover, I wonder whether we shouldn't remove the branch where
> >>> conn->connhost is NULL. When would that be the case? The current
> >>> behavior is
On Sat, 2018-03-17 at 18:24 +0100, Magnus Hagander wrote:
> > The error message "certificate authentication failed for user XYZ:
> >
> > client certificate contains no user name" is the result of calling
> >
> > CheckCertAuth when the user presented a certificate without a CN in
> > it.
>
> That
On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> Incidently the fix looks quite simple. See patch attached.
>
> ISTM this patch effectively proposes to make procedures have their own
> namespace yet still live in pg_proc. That is the worst of all possible
> worlds IMO
I have committed a basic pg_resetwal test suite as part of another
patch, so please adjust accordingly.
It looks to me like your pg_resetwal tests contain a bit of useless
copy-and-paste. For example, you are not using use Config, nor
$tempdir, and you run $node->stop right after $node->start. P
Thanks for these changes. I'm going over this now, with intention to
push it shortly.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hey there,
I am Vimal currently pursuing my undergraduate degree in computer
science ,I would love to work with you via
the GSoC program this summer.
I wanted to know which all projects I can work on. I have good
knowledge in c,java,python,SQL and other web development languages.Can
anyone sugges
Ashutosh Bapat writes:
> Incidently the fix looks quite simple. See patch attached.
ISTM this patch effectively proposes to make procedures have their own
namespace yet still live in pg_proc. That is the worst of all possible
worlds IMO. Somewhere early in this patch series, I complained that
p
I suggest a patch where pgbench client sessions are not disconnected because of
serialization or deadlock failures and these failures are mentioned in reports.
In details:
- transaction with one of these failures continue run normally, but its result
is rolled back;
- if there were these failur
Hi!
> 8 февр. 2018 г., в 22:45, Peter Geoghegan написал(а):
>
> On Thu, Feb 8, 2018 at 6:05 AM, Andrey Borodin wrote:
>> I do not see a reason behind hashing the seed.
>
> It made some sense when I was XOR'ing it to mix. A uniform
> distribution of bits seemed desirable then, since random() wo
On 23 March 2018 at 11:26, Pavan Deolasee wrote:
>
>
> On Fri, Mar 23, 2018 at 6:45 AM, Peter Geoghegan wrote:
>>
>> On Thu, Mar 22, 2018 at 6:02 PM, Alvaro Herrera
>> wrote:
>> > Incremental development is a good thing. Trying to do everything in a
>> > single commit is great when time is infi
Pushed. Thanks for all the review.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Kyotaro HORIGUCHI wrote:
> A disucssion on psql batch mode was held in another branch of
> this thread. How do we treat that?
There's a batch mode for pgbench in a patch posted in [1],
with \beginbatch and \endbatch commands, but nothing
for psql AFAICS.
psql is more complicated because c
On Fri, Mar 23, 2018 at 8:22 AM, Etsuro Fujita
wrote:
>> I think for bulk
>> inserts we'll need an API that says "here's a row, store it or buffer
>> it as you like" and then another API that says "flush any buffered
>> rows to the actual table and perform any necessary cleanup". Or maybe
>> in p
On 2018/03/23 20:07, Pavan Deolasee wrote:
> On Fri, Mar 23, 2018 at 12:57 PM, Amit Langote wrote:
>> Also, it seems that the delta patch I sent in the last email didn't
>> contain all the changes I had to make. It didn't contain, for example,
>> replacing adjust_and_expand_inherited_tlist() with
(2018/03/23 21:02), Robert Haas wrote:
On Fri, Mar 23, 2018 at 7:55 AM, Etsuro Fujita
wrote:
Maybe I'm missing something, but I think the proposed FDW API could be used
for the COPY case as well with some modifications to core. If so, my
question is: should we support COPY into foreign tables
Thanks for the review.
On 2018/03/21 6:29, Robert Haas wrote:
> On Tue, Mar 20, 2018 at 7:07 AM, Amit Langote
> wrote:
>> On 2018/03/16 21:55, Amit Langote wrote:
>>> Attached updated patches.
>>
>> Attached is further revised version.
>>
>> Of note is getting rid of PartitionPruneContext usage i
On Fri, Mar 23, 2018 at 7:55 AM, Etsuro Fujita
wrote:
> Maybe I'm missing something, but I think the proposed FDW API could be used
> for the COPY case as well with some modifications to core. If so, my
> question is: should we support COPY into foreign tables as well? I think
> that if we suppo
Pavel Stehule wrote:
> It should not be hard. All formats can has '|' like now, and csv can have a
> ',' - then if field separator is not explicit, then default field separator
> is used, else specified field separator is used.
>
> You can see my idea in attached patch
With that patch, c
On Fri, Mar 23, 2018 at 4:43 AM, Peter Geoghegan wrote:
> On Thu, Mar 22, 2018 at 11:42 AM, Pavan Deolasee
> wrote:
> > A slightly improved version attached.
>
> You still need to remove this change:
>
> > diff --git a/src/include/miscadmin.h b/src/include/miscadmin.h
> > index a4574cd533..dbfb5
(2018/03/23 4:09), Robert Haas wrote:
On Tue, Feb 27, 2018 at 7:01 AM, Etsuro Fujita
Attached is a new version of the patch set.
I took a look at this patch set today but I really don't think we
should commit something so minimal. It's got at least four issues
that I see:
1. It still doesn't
Hi Robert,
On pgsql-committers Andres reported one concern about test case failure
with installcheck with local settings.
(Sorry, I have not subscribed to that mailing list and thus not able to
reply there).
Attached patch which fixes that.
However, I am not sure whether it is expected to have s
Hi!
Patch seems good, but I found one bug in it, in fact, nobody
checks serializible conflict with fastupdate=on:
gininsert()
{
if (GinGetUseFastUpdate())
{
/* two next lines are GinCheckForSerializableConflictIn() */
if (!GinGetUseFastUpdate())
On Fri, Mar 23, 2018 at 6:45 AM, Peter Geoghegan wrote:
> On Thu, Mar 22, 2018 at 6:02 PM, Alvaro Herrera
> wrote:
> > Incremental development is a good thing. Trying to do everything in a
> > single commit is great when time is infinite or even merely very long,
> > but if you run out of it, w
Incidently the fix looks quite simple. See patch attached.
With this patch we have a diffs in create_procedure test like
CALL random(); -- error
! ERROR: random() is not a procedure
LINE 1: CALL random();
^
! HINT: To call a function, use SELECT.
CREATE FUNCTION cp_testfunc
On Thu, Mar 22, 2018 at 10:28 PM, Robert Haas wrote:
> On Thu, Mar 22, 2018 at 6:15 AM, Jeevan Chalke
> wrote:
> > Leeks cleaner now. Thanks for refactoring it.
> >
> > I have merged these changes and flatten all previuos changes into the
> main
> > patch.
>
> Committed 0001-0005.
Thanks Rober
On 23 March 2018 at 09:22, Michael Paquier wrote:
> On Fri, Mar 23, 2018 at 09:04:55AM +, Simon Riggs wrote:
>> So it shows clear benefit for both bulk actions and OLTP, with no
>> regressions.
>>
>> No objection exists to the approach used in the patch, so I'm now
>> ready to commit this.
>>
(2018/03/22 18:31), Amit Langote wrote:
On 2018/03/20 20:53, Etsuro Fujita wrote:
Here are comments on executor changes in (the latest version of) the patch:
@@ -421,8 +424,18 @@ ExecInsert(ModifyTableState *mtstate,
ItemPointerData conflictTid;
boolspecConfl
Hi,
Consider following scenario
create function foo(a int) returns integer as $$begin return a; end;
$$ language plpgsql;
create procedure foo(a float) as $$begin end; $$ language plpgsql;
call foo(1);
psql:proc_func_resolution.sql:8: ERROR: foo(integer) is not a procedure
LINE 1: call foo(1);
Hi Andrew and Claudio,
Thanks for the review!
On Fri, Mar 23, 2018 at 10:19 AM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> On Fri, Mar 23, 2018 at 10:20 AM, Claudio Freire
> wrote:
>
>
> This patch looks in pretty good shape. I have been trying hard to
> think of some failure mod
Hi David,
thanks for the review!
Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele:
> On 3/17/18 5:34 PM, Michael Banck wrote:
> > On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> > I think most people (including those I had off-list discussions about
> > this with)
Hi,
BuildTupleFromCStrings() has comment "/* Call the "in" function for
each non-dropped attribute */". It then calls the in function even
when it's going to set that attribute to NULL.
1189 if (!TupleDescAttr(tupdesc, i)->attisdropped)
1190 {
1191 /* Non-dropped attribu
On Fri, Mar 23, 2018 at 09:04:55AM +, Simon Riggs wrote:
> So it shows clear benefit for both bulk actions and OLTP, with no regressions.
>
> No objection exists to the approach used in the patch, so I'm now
> ready to commit this.
>
> Last call for objections?
Please hold on. It is Friday
On 23 March 2018 at 08:35, Pavan Deolasee wrote:
>
>
> On Fri, Mar 9, 2018 at 8:49 PM, Peter Eisentraut
> wrote:
>>
>> On 2/1/18 19:21, Simon Riggs wrote:
>> > If we really can't persuade you of that, it doesn't sink the patch. We
>> > can have the WAL pointer itself - it wouldn't save space but
On 2 February 2018 at 02:17, Michael Paquier wrote:
> On Fri, Feb 02, 2018 at 12:21:49AM +, Simon Riggs wrote:
>> Yes, it would be about 99% of the time.
>
> When it comes to recovery, I don't think that 99% is a guarantee
> sufficient. (Wondering about the maths behind such a number as well.
On Thu, Mar 22, 2018 at 7:09 PM, Teodor Sigaev wrote:
> Patch looks resonable, but I see some place to improvement:
> spg_text_leaf_consistent() only needs to check with text_startswith() if
> reconstucted value came to leaf consistent is shorter than given prefix.
> For example, if level >= leng
On Fri, Mar 9, 2018 at 8:49 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2/1/18 19:21, Simon Riggs wrote:
> > If we really can't persuade you of that, it doesn't sink the patch. We
> > can have the WAL pointer itself - it wouldn't save space but it would
> > at least allevi
Hello.
At Wed, 21 Mar 2018 15:28:07 -0400, David Steele wrote in
<43095b16-14fc-e4d8-3310-2b86eaaab...@pgmasters.net>
> On 3/15/18 1:12 AM, Kyotaro HORIGUCHI wrote:
> > At Mon, 12 Mar 2018 17:34:08 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in >
> > The attached is the patch set
> On 22 Mar 2018, at 22:38, Tom Lane wrote:
> This stuff seems reasonably non-controversial, so pushed.
Thanks!
> BTW, really the point of what I'd mentioned before was to avoid having
> dblink_res_error constructing a message out of fragments, which it's
> still doing. I'd thought perhaps we
On Tue, Mar 20, 2018 at 12:00:47PM +0530, Dilip Kumar wrote:
> Yeah, you are right. Fixed.
So I have been spending a couple of hours playing with your patch, and
tested various configurations manually, like switch the fpw switch to on
and off while running in parallel pgbench. I have also tested
David Rowley wrote:
> > Would it be very difficult to extend that to "if any unique constraints are
> > contained in the DISTINCT clause"?
>
> Unfortunately, it's quite a bit more work to make that happen. It's
> not just unique constraints that are required to make this work. We
> also need to pa
On 21 March 2018 at 00:07, Amit Langote wrote:
> Attached is further revised version.
Hi Amit,
Thanks for sending the v38 patch.
I started reviewing this, but I just ended up starting to hack at the
patch instead. It's still got quite a bit of work to be done as I
think, unfortunately, the cro
On 2018/03/23 13:57, Pavan Deolasee wrote:
> On Fri, Mar 23, 2018 at 10:00 AM, Amit Langote wrote:
>> I managed to apply it by ignoring the errors, but couldn't get make check
>> to pass; attached regressions.diffs if you want to take a look.
>
> Thanks. Are you sure you're using a clean repo? I su
95 matches
Mail list logo
