On Fri, Mar 31, 2017 at 04:40:07PM +0300, Aleksander Alekseev wrote:
> > > And it seems to me that this is caused by the routines of OpenSSL.
> > > When building without --with-openssl, using the fallback
> > > implementations of SHA256 and RAND_bytes I see no warnings generated
> > > by
On Fri, Feb 24, 2017 at 7:00 AM, David Rowley
wrote:
> I've stumbled over an interesting query out in the wild where the
> query was testing a nullable timestamptz column was earlier than some
> point in time, and also checking the column IS NOT NULL.
>
> The use
D'oh! The "temp" declaration had been removed from our test since we don't
use temp tables. I missed that when applying it to the community code.
You can ignore me now.
On Fri, Mar 31, 2017 at 4:01 PM Tom Lane wrote:
> Douglas Doole writes:
> > As
On 01/04/17 04:19, Andres Freund wrote:
> On 2017-03-31 21:30:17 -0400, Robert Haas wrote:
>> On Fri, Mar 31, 2017 at 9:26 PM, Petr Jelinek
>> wrote:
Hmm, I don't know if there's any good reason not to just use strcmp(),
but sure, OK. Committed and
On 04/01/2017 02:57 AM, Robert Haas wrote:
On Fri, Mar 31, 2017 at 7:53 AM, Rafia Sabih
wrote:
So, it looks like in the problematic area, it is not improving much.
Please find the attached file for the query plan of Q20 with and
without patch. I haven't
Hi,
On 2017-04-01 01:22:14 +, Robert Haas wrote:
> Avoid GatherMerge crash when there are no workers.
I think the gather merge code needs a bit more test coverage (sorry to
make this a larger theme today). As shown by
On 2017-03-31 21:30:17 -0400, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 9:26 PM, Petr Jelinek
> wrote:
> >> Hmm, I don't know if there's any good reason not to just use strcmp(),
> >> but sure, OK. Committed and back-patched.
> >
> > Hmm culicidae still fails,
On 2017-04-01 03:57:05 +0200, Petr Jelinek wrote:
> On 01/04/17 03:44, Andres Freund wrote:
> > On 2017-04-01 03:26:01 +0200, Petr Jelinek wrote:
> >> On 01/04/17 02:53, Robert Haas wrote:
> >>> On Fri, Mar 31, 2017 at 8:32 PM, Petr Jelinek
> >>> wrote:
> Right,
Hi,
On Sat, Apr 1, 2017 at 7:06 AM, Ashutosh Sharma wrote:
> On Sat, Apr 1, 2017 at 6:00 AM, Robert Haas wrote:
>> On Fri, Mar 31, 2017 at 6:09 PM, Ashutosh Sharma
>> wrote:
>>> Well, That is another option but the main idea
On 01/04/17 03:44, Andres Freund wrote:
> On 2017-04-01 03:26:01 +0200, Petr Jelinek wrote:
>> On 01/04/17 02:53, Robert Haas wrote:
>>> On Fri, Mar 31, 2017 at 8:32 PM, Petr Jelinek
>>> wrote:
Right, changed to BGW_MAXLEN.
>>>
>>> Hmm, I don't know if there's
On 2017-04-01 03:26:01 +0200, Petr Jelinek wrote:
> On 01/04/17 02:53, Robert Haas wrote:
> > On Fri, Mar 31, 2017 at 8:32 PM, Petr Jelinek
> > wrote:
> >> Right, changed to BGW_MAXLEN.
> >
> > Hmm, I don't know if there's any good reason not to just use strcmp(),
>
On Sat, Apr 1, 2017 at 6:00 AM, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 6:09 PM, Ashutosh Sharma
> wrote:
>> Well, That is another option but the main idea was to be inline with
>> the btree code.
>
> That's not a bad goal in principal, but
On Fri, Mar 31, 2017 at 1:15 AM, Mithun Cy wrote:
> Thanks, I have tried to fix all of the comments.
Thanks.
Hmm, don't the changes to contrib/pageinspect/expected/hash.out
indicate that you've broken something? The hash index has only 4
buckets, so the new code
On Fri, Mar 31, 2017 at 9:26 PM, Petr Jelinek
wrote:
>> Hmm, I don't know if there's any good reason not to just use strcmp(),
>> but sure, OK. Committed and back-patched.
>
> Hmm culicidae still fails, this time only in parallel worker code. This
> didn't happen on
On 01/04/17 02:53, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 8:32 PM, Petr Jelinek
> wrote:
>> Right, changed to BGW_MAXLEN.
>
> Hmm, I don't know if there's any good reason not to just use strcmp(),
> but sure, OK. Committed and back-patched.
>
Hmm culicidae
On Tue, Mar 28, 2017 at 11:08 PM, Tomas Vondra
wrote:
> Maybe. It depends on how valuable it's to keep Gather and GatherMerge
> similar - having nreaders in one and not the other seems a bit weird. But
> maybe the refactoring would remove it from both nodes?
Yeah,
On Fri, Mar 31, 2017 at 7:53 AM, Rafia Sabih
wrote:
> So, it looks like in the problematic area, it is not improving much.
> Please find the attached file for the query plan of Q20 with and
> without patch. I haven't evaluated the performance of this query with
>
On Fri, Mar 31, 2017 at 8:32 PM, Petr Jelinek
wrote:
> Right, changed to BGW_MAXLEN.
Hmm, I don't know if there's any good reason not to just use strcmp(),
but sure, OK. Committed and back-patched.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On 31/03/17 15:42, Robert Haas wrote:
> On Tue, Mar 28, 2017 at 7:39 PM, Petr Jelinek
> wrote:
>> Sigh, forgot git add for the docs, so one more try...
>
> +if (strncmp(worker->bgw_library_name, "postgres", 8) != 0)
> +return NULL;
>
> I think that's
On Fri, Mar 31, 2017 at 6:09 PM, Ashutosh Sharma wrote:
> Well, That is another option but the main idea was to be inline with
> the btree code.
That's not a bad goal in principal, but _bt_killitems() doesn't have
any similar argument.
(Also, speaking of consistency, why
On 01/04/17 01:57, Petr Jelinek wrote:
> On 01/04/17 01:20, Tom Lane wrote:
>> Petr Jelinek writes:
>>> But the pg_subscription_rel is also not accessed on heap_open, the
>>> problematic code is called from heap_drop_with_catalog. And VACUUM FULL
>>> pg_class calls
On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
wrote:
> Attached you will find two patches, which were rebased on master as of
> 156d388 (applied with `git am --revert [patch file]`). The first gets
> rid of some pesky compiler warnings and the second implements
On Fri, Mar 31, 2017 at 3:03 PM, Brandur Leach wrote:
> Thank you Peter for the assist here and great sleuthing in
> the disassembly, and thanks Teodor for committing!
>
> Neha pointed out (thanks as well) a couple typos upthread
> that I hadn't gotten around to fixing.
On 01/04/17 01:57, Petr Jelinek wrote:
> On 01/04/17 01:20, Tom Lane wrote:
>> Petr Jelinek writes:
>>> But the pg_subscription_rel is also not accessed on heap_open, the
>>> problematic code is called from heap_drop_with_catalog. And VACUUM FULL
>>> pg_class calls
On 01/04/17 01:20, Tom Lane wrote:
> Petr Jelinek writes:
>> But the pg_subscription_rel is also not accessed on heap_open, the
>> problematic code is called from heap_drop_with_catalog. And VACUUM FULL
>> pg_class calls heap_drop_with_catalog() when doing the heap
On Sat, Apr 1, 2017 at 1:06 AM, Alvaro Herrera wrote:
> Ashutosh Bapat wrote:
>> Please add this to the next commitfest.
>
> If this cannot be reproduced in 9.6, then it must be added to the
> Open Items wiki page instead.
The behavior reported can be reproduced further
I had a quick look at this on the flight back from PGConf.US.
On Fri, Mar 31, 2017 at 10:40 AM, Anastasia Lubennikova
wrote:
> But I haven't considered the possibility of index_form_tuple() failure.
> Fixed in this version of the patch. Now it creates a copy of
Petr Jelinek writes:
> But the pg_subscription_rel is also not accessed on heap_open, the
> problematic code is called from heap_drop_with_catalog. And VACUUM FULL
> pg_class calls heap_drop_with_catalog() when doing the heap swap (and it
> goes through
On Sat, Apr 1, 2017 at 4:55 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 31, 2017 at 3:31 PM, Andres Freund wrote:
>>> Hm. Wonder if something like that shouldn't be backpatched - because
>>> otherwise using postgres_fdw
Douglas Doole writes:
> As we've been merging our code with 9.6, a couple developers have had
> one-off failures in the join.sql and aggregates.sql test because the tables
> T1, T2 and T3 have the wrong definitions.
> Digging into it, I found that both files create the
On 01/04/17 00:52, Tom Lane wrote:
> Petr Jelinek writes:
>> On 31/03/17 21:00, Tom Lane wrote:
>>> Looking at dependency info isn't going to fix this, it only moves the
>>> unsafe catalog access somewhere else (ie pg_depend instead of
>>> pg_subscription_rel). I
Petr Jelinek writes:
> On 31/03/17 21:00, Tom Lane wrote:
>> Looking at dependency info isn't going to fix this, it only moves the
>> unsafe catalog access somewhere else (ie pg_depend instead of
>> pg_subscription_rel). I suspect the only safe solution is doing an
As we've been merging our code with 9.6, a couple developers have had
one-off failures in the join.sql and aggregates.sql test because the tables
T1, T2 and T3 have the wrong definitions.
Digging into it, I found that both files create the tables T1, T2, and T3
for a short period of time and then
On 31/03/17 21:00, Tom Lane wrote:
> Petr Jelinek writes:
>> On 31/03/17 20:23, Tom Lane wrote:
>>> No, the problematic part is that there is any heap_open happening at
>>> all. That open could very easily result in a recursive attempt to read
>>> pg_class, for
Alexander Korotkov writes:
>> It seems that on this platform definition of atomics should be provided by
>> fallback.h. But it doesn't because I already defined
>> PG_HAVE_ATOMIC_U32_SUPPORT
>> in arch-ppc.h. I think in this case we shouldn't provide ppc-specific
>>
On Fri, Mar 31, 2017 at 5:44 PM, Robert Haas wrote:
> And, indeed, you could get an unique constraint or exclusion error
> because of an index on the child even though it's not global to the
> partitioning hierarchy. So maybe we can support this after all, but
> having
On Sat, Apr 1, 2017 at 1:08 AM, Robert Haas wrote:
> On Mon, Mar 27, 2017 at 5:39 AM, Ashutosh Sharma
> wrote:
>> Thanks for reporting this problem. Could you please let me know on for
>> how long did you run sqlsmith to get this crash. However, I
On Fri, Mar 31, 2017 at 5:33 PM, Peter Geoghegan wrote:
> In my opinion, for the very limited ON CONFLICT DO NOTHING + no
> inference specification case, the implementation should not care about
> the presence or absence of unique indexes within or across partitions.
Hmm. That's
On Tue, Mar 28, 2017 at 6:35 AM, Amit Langote
wrote:
> Attached updated patch.
Committed with editing here and there. I just left out the thing
about UNION ALL views, which seemed to brief a treatment to deserve
its own subsection. Maybe a longer explanation of
On Fri, Mar 31, 2017 at 4:47 PM, Robert Haas wrote:
> /*
> * Open partition indices (remember we do not support ON CONFLICT in
> * case of partitioned tables, so we do not need support information
> * for speculative insertion)
>
"David G. Johnston" writes:
> On Fri, Mar 31, 2017 at 10:40 AM, Tom Lane wrote:
>> I think the benefit is reduction of user confusion. Admittedly, since
>> Paul is the first person I can remember ever having complained about it,
>> maybe nobody
On Fri, Mar 31, 2017 at 5:11 AM, Ashutosh Bapat
wrote:
> Per https://www.postgresql.org/docs/devel/static/sql-createforeigntable.html,
> constraints on the foreign table should represent a constraint that is
> being enforced by the remote server.
Right. This is
On Thu, Mar 30, 2017 at 5:54 AM, Amit Langote
wrote:
> I found out why the crash occurs, but while I was trying to fix it, I
> started growing doubtful about the way this is being handled currently.
>
> Patch to fix the crash would be to pass 'true' instead of
On Fri, Mar 31, 2017 at 4:33 AM, Kyotaro HORIGUCHI
wrote:
> I have no more comment on this. Thank you.
I committed this with a few tweaks. I simplified the wording in the
documentation a bit, removed or adjusted a couple of comments, and
slightly changed the way
On Mar 31, 2017 2:17 PM, "Peter Geoghegan" wrote:
On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>> The patch does actually store truncated/key-only tuples in the hi keys /
>> non-leaf-nodes, which don't need the "included" columns.
>
> Hm. Since index
Robert Haas writes:
> On Fri, Mar 31, 2017 at 3:31 PM, Andres Freund wrote:
>> Hm. Wonder if something like that shouldn't be backpatched - because
>> otherwise using postgres_fdw from an old server against a newer one will
>> do weird stuff. I don't
I don't see why you'd necessarily need to know where in the index the tuple
came from under my proposal. Besides, as I already pointed out, we already
hard code minus infinity handling within internal pages during tuple
comparisons.
Anastasia's patch could modify nbtree in exactly the same way as
On Mon, Mar 27, 2017 at 5:39 AM, Ashutosh Sharma wrote:
> Thanks for reporting this problem. Could you please let me know on for
> how long did you run sqlsmith to get this crash. However, I have found
> the reason for this crash. This is basically happening when trying to
Peter Geoghegan writes:
> On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
>> ... I also think we're setting up a situation where tools
>> like amcheck and pg_filedump are going to be unable to cope, because
>> figuring out what a particular tuple contains is
On Fri, Mar 31, 2017 at 3:31 PM, Andres Freund wrote:
>> Committed after rewording the documentation.
>
> Hm. Wonder if something like that shouldn't be backpatched - because
> otherwise using postgres_fdw from an old server against a newer one will
> do weird stuff. I don't
On 2017-03-31 15:25:19 -0400, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 12:51 AM, Amit Langote
> wrote:
> > Thanks, no more comments from my side.
>
> Committed after rewording the documentation.
Hm. Wonder if something like that shouldn't be backpatched -
On Tue, Mar 21, 2017 at 4:10 PM, Alvaro Herrera
wrote:
> Well, the number of work items is currently fixed; but if you have many
> BRIN indexes, then you'd overflow (lose requests). By using DSA I am
> making it easy to patch this afterwards so that an arbitrary number
On Fri, Mar 31, 2017 at 12:51 AM, Amit Langote
wrote:
> Thanks, no more comments from my side.
Committed after rewording the documentation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
On Fri, Mar 31, 2017 at 3:03 PM, Tom Lane wrote:
> The reason it works fine for heap tuples is that heap tuple headers
> explicitly record the number of attributes in the tuple. Index
> tuples don't.
Per my previous mail, I think we can change things so that Index
tuples
On 30 Mar 2017 23:43, "Dmitry Dolgov" <9erthali...@gmail.com> wrote:
On 31 March 2017 at 00:01, Andrew Dunstan
wrote:
>
> I have just noticed as I was writing/testing the non-existent docs for
> this patch that it doesn't supply variants of to_tsvector that take a
On Thu, Mar 30, 2017 at 4:13 AM, Pavan Deolasee
wrote:
>
>
> On Thu, Mar 30, 2017 at 3:29 PM, Dilip Kumar
> wrote:
>
>> On Wed, Mar 29, 2017 at 11:51 AM, Pavan Deolasee
>> wrote:
>> > Thanks. I think your patch of
Robert Haas writes:
> On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
>> It just seems way too dangerous.
> So, we end up with heap tuples with different numbers of attributes
> all the time, whenever you add a column. It works fine - on decoding,
>
Hello,
Thank you Peter for the assist here and great sleuthing in
the disassembly, and thanks Teodor for committing!
Neha pointed out (thanks as well) a couple typos upthread
that I hadn't gotten around to fixing. I've attached a new
three line patch to sort those out.
Brandur
On Wed, Mar 29,
Petr Jelinek writes:
> On 31/03/17 20:23, Tom Lane wrote:
>> No, the problematic part is that there is any heap_open happening at
>> all. That open could very easily result in a recursive attempt to read
>> pg_class, for example, which is going to be fatal if we're
Hi,
As visible in [1], the explain analyze codepaths of parallel query isn't
exercised in the tests. That used to be not entirely trivial if the
output was to be displayed (due to timing), but we should be able to do
that now that we have the SUMMARY option.
E.g.
SET max_parallel_workers = 0;
I wrote:
> Andres Freund writes:
>> It'd be useful for FieldStore - we'd not have to error out anymore if
>> the number of columns changes (which I previously had "solved" by using
>> MaxHeapAttributeNumber sized values/nulls array).
> Ah, I see. But in that case you're not
Here's a version of this patch which I consider final.
Thanks for your tips on using DSA. No crashes now.
I am confused about not needing dsa_attach the second time around. If I
do that, the dsa handle has been 0x7f'd, which I don't understand since
it is supposed to be allocated in
Robert Haas writes:
> Forcing a reindex in v10 kills three birds
> with one stone:
> - No old, not logged, possibly corrupt hash indexes floating around
> after an upgrade to v10.
> - Can remove the backward-compatibility code added by
>
Hi,
The parallel code-path isn't actually exercised in the tests added in
[1], as evidenced by [2] (they just explain). That imo needs to be
fixed.
Greetings,
Andres Freund
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f35742ccb7aa53ee3ed8416bbb378b0c3eeb6bb9
[2]
On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
> I think you are failing to get the point. I am not on about whether
> we need a few bytes more or less, I am on about whether the patch
> even works. As an example, it's quite unclear what the width of
> such an index
On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
wrote:
> On Mon, Mar 27, 2017 at 12:09 PM, Mike Palmiotto
> wrote:
>> On Mon, Mar 27, 2017 at 11:46 AM, Robert Haas wrote:
>>>
>>> Note that sepgsql hasn't
On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>>> Hm. Since index tuples lack any means of indicating the actual number
>>> of columns included (ie there's no
On 31/03/17 20:23, Tom Lane wrote:
> Petr Jelinek writes:
>> On 31/03/17 19:35, Tom Lane wrote:
>>> At the very least, it would be a good idea to exclude the system
>>> catalogs from logical replication, wouldn't it?
>
>> They are excluded.
>
> Well, the exclusion
Hi Thomas,
On 2017-03-31 17:53:12 +1300, Thomas Munro wrote:
> Thanks very much to Rafia for testing, and to Andres for his copious
> review feedback. Here's a new version. Changes:
I've not looked at that aspect, but one thing I think would be good is
to first add patch that increases
Peter Geoghegan writes:
> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>> Hm. Since index tuples lack any means of indicating the actual number
>> of columns included (ie there's no equivalent of the natts field that
>> exists in HeapTupleHeaders), I think
On Fri, Mar 31, 2017 at 12:20:51PM -0500, Kevin Grittner wrote:
> On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner wrote:
>
> > New version attached. It needs some of these problem cases added
> > to the testing, and a mention in the docs that only C and plpgsql
> > triggers
31.03.2017 20:57, Robert Haas:
On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova
wrote:
First of all, I want to thank you and Robert for reviewing this patch.
Your expertise in postgres subsystems is really necessary for features like
this.
I just wonder, why
On 03/31/2017 02:17 PM, Robert Haas wrote:
Starting a new thread about this to get more visibility.
Despite the extensive work that has been done on hash indexes this
release, we have thus far not made any change to the on-disk format
that is not nominally backward-compatible. Commit
On Fri, Mar 31, 2017 at 11:16 PM, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 10:24 AM, Pavan Deolasee
> wrote:
> > Having worked on it for some time now, I can say that WARM uses pretty
> much
> > the same infrastructure that HOT uses for
Petr Jelinek writes:
> On 31/03/17 19:35, Tom Lane wrote:
>> At the very least, it would be a good idea to exclude the system
>> catalogs from logical replication, wouldn't it?
> They are excluded.
Well, the exclusion is apparently not checked early enough. I
Forwarding message from pgsql-bugs for review
Attached a patch which copies the logic from commit
93a6be63a55a8cd0d73b3fa81eb6a46013a3a974.
In the current implementation we only consider privileges of the foreign
server
in determining whether or not to show the user mapping details. This patch
On Fri, Mar 31, 2017 at 8:17 PM, Robert Haas wrote:
> Starting a new thread about this to get more visibility.
>
> Despite the extensive work that has been done on hash indexes this
> release, we have thus far not made any change to the on-disk format
> that is not
On Fri, Mar 31, 2017 at 12:58 PM, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 1:50 PM, Tom Lane wrote:
>> I would vote for calling the struct typedef EphemeralNamedRelation and
>> using the abbreviation ENR (capitalized that way, not as Enr) in
On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane wrote:
>> The patch does actually store truncated/key-only tuples in the hi keys /
>> non-leaf-nodes, which don't need the "included" columns.
>
> Hm. Since index tuples lack any means of indicating the actual number
> of columns
Starting a new thread about this to get more visibility.
Despite the extensive work that has been done on hash indexes this
release, we have thus far not made any change to the on-disk format
that is not nominally backward-compatible. Commit
293e24e507838733aba4748b514536af2d39d7f2 did make a
On Mon, Mar 27, 2017 at 12:09 PM, Mike Palmiotto
wrote:
> On Mon, Mar 27, 2017 at 11:46 AM, Robert Haas wrote:
>>
>> Note that sepgsql hasn't been updated to work with RLS yet, either,
>> but we didn't regard that as an open item for RLS,
On 31/03/17 19:35, Tom Lane wrote:
> Masahiko Sawada writes:
>> On Fri, Mar 31, 2017 at 9:53 AM, Petr Jelinek
>> wrote:
>>> On 30/03/17 07:25, Tom Lane wrote:
I await with interest an explanation of what "VACUUM FULL pg_class" is
Robert Haas writes:
> You might want to have a read through that patch. I think your
> opinion would be helpful in determining how close that patch is to
> being ready to commit (same for WARM).
Well, now that we have an extra week, maybe I'll find the time.
Andres Freund writes:
> On 2017-03-31 13:44:52 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> The covering indexes patch [1] really needs a version of
>>> heap_form_tuple/index_form_tuple that allows to specify the number of
>>> columns in the to-be
On Fri, Mar 31, 2017 at 11:44 PM, Robert Haas wrote:
> On Wed, Mar 29, 2017 at 2:23 AM, Masahiko Sawada
> wrote:
>> I was thinking that the status of this patch is still "Needs review"
>> because I sent latest version patch[1].
>
> I think you're
Hello,
While reviewing Corey's \if patch, I complained that there was some amount
of copy-paste in "psql/command.c".
Here is an attempt at merging some functions which removes 160 lines of
code.
--
Fabien.diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 94a3cfc..edf875d
31.03.2017 20:47, Andres Freund:
Maybe it would be better to modify index_form_tuple() to accept a new
argument with a number of attributes, then you can just Assert that
this number is never higher than the number of attributes in the
TupleDesc.
Good point.
I agree that this function is a bit
On Fri, Mar 31, 2017 at 1:50 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Thu, Mar 23, 2017 at 7:14 PM, Thomas Munro
>> wrote:
>>> my only other comment would be a bikeshed issue:
>>> Enr isn't a great name for a
On Fri, Mar 31, 2017 at 7:40 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane wrote:
> >> The argument for not back-patching a bug fix usually boils down to
> >> fear of breaking existing
On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova
wrote:
> First of all, I want to thank you and Robert for reviewing this patch.
> Your expertise in postgres subsystems is really necessary for features like
> this.
> I just wonder, why don't you share your
On Fri, Mar 31, 2017 at 10:40 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane wrote:
> >> The argument for not back-patching a bug fix usually boils down to
> >> fear of breaking existing
Kevin Grittner writes:
> On Thu, Mar 23, 2017 at 7:14 PM, Thomas Munro
> wrote:
>> my only other comment would be a bikeshed issue:
>> Enr isn't a great name for a struct.
> I know, but EphemeralNamedRelation starts to get kinda long,
>
On 2017-03-31 13:44:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The covering indexes patch [1] really needs a version of
> > heap_form_tuple/index_form_tuple that allows to specify the number of
> > columns in the to-be generated tuple.
>
> I was thinking about that
On Fri, Mar 31, 2017 at 1:44 PM, Tom Lane wrote:
> Andres Freund writes:
>> The covering indexes patch [1] really needs a version of
>> heap_form_tuple/index_form_tuple that allows to specify the number of
>> columns in the to-be generated tuple.
>
> I was
On 2017-03-31 20:40:59 +0300, Anastasia Lubennikova wrote:
> 30.03.2017 22:11, Andres Freund
> > Any objection from reviewers to push both patches?
>
> First of all, I want to thank you and Robert for reviewing this patch.
> Your expertise in postgres subsystems is really necessary for features
On Fri, Mar 31, 2017 at 10:24 AM, Pavan Deolasee
wrote:
> Having worked on it for some time now, I can say that WARM uses pretty much
> the same infrastructure that HOT uses for cleanup/pruning tuples from the
> heap. So the risk of having a bug which can eat your data
On Thu, Mar 30, 2017 at 10:49 AM, Petr Jelinek
wrote:
> While reading this thread I am thinking if we could just not do WARM on
> TOAST and compressed values if we know there might be regressions there.
> I mean I've seen the problem WARM tries to solve mostly on
Andres Freund writes:
> The covering indexes patch [1] really needs a version of
> heap_form_tuple/index_form_tuple that allows to specify the number of
> columns in the to-be generated tuple.
I was thinking about that this morning, and wondering why exactly it
would need
Robert Haas writes:
> On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane wrote:
>> The argument for not back-patching a bug fix usually boils down to
>> fear of breaking existing applications, but it's hard to see how
>> removal of a permission check could
On 03/31/2017 06:01 PM, Ashutosh Sharma wrote:
It seems like the latest patch(v4) shared by Tomas upthread is an
empty patch. If I am not wrong, please share the correct patch.
Thanks.
OMG, this is the second time I managed to generate an empty patch. I
really need to learn not to do that
1 - 100 of 175 matches
Mail list logo