On Fri, Mar 31, 2017 at 11:54 PM, Pavan Deolasee
wrote:
>
> On Fri, Mar 31, 2017 at 11:16 PM, Robert Haas wrote:
>>
>> Now, I understand you to be suggesting a flag at
>> table-creation time that would, maybe, be immutable after that, but
>> even then - are we going to run completely unmodified
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 scram_bui
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 pattern here was that records whic
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 we've been merging our code with 9.6, a couple
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 back-patched.
>>>
>>> Hmm culicidae st
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 evaluated the performance of this query
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
https://coverage.postgresql.org/src/backend/executor/nodeGatherMerge.c.gco
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, this time only in parallel worker
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, changed to BGW_MAXLEN.
> >>>
>
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 was to be inline with
>>> the btree code.
>>
>> That's not a bad goal
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 any good reason not to just use
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(),
> > but sure, OK. Committed and
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 _bt_killitems() doesn't have
> any similar argumen
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 shouldn't be doing anything diff
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 my machine which is strange. L
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 still fails, this time only in
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, it appears to be the case that b
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
> patch.
Yeah, I don't think this p
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 Enterprise PostgreSQL Company
--
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 not right. You don't want to mat
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 did we end up with
_hash
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 heap_drop_with_catalog() when do
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 the
> sepgsql handling of partitio
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. I've attached a new
> three
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 heap_drop_with_catalog() when do
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 swap (and it
>> goes through per
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 down (just tried on
9.3, g
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 tupledesc to
> pass it to index_for
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 performDeletion so through dependency info w
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 from an old server against a newer one will
>>> do weird stuff.
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 tables T1, T2, and T3
> for
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 suspect the only safe solution is
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
>> IsCatalogRelation or similar
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 example, which is going to be fatal
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
>> implementation of pg_atomic_
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 messed it up once, I'm incl
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 have found
>> the reason for this crash. This is
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 an interesting p
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 that is worthwhile
or maybe it's
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)
> */
>
> Part of the quest
"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 else is confused.
> ​After going back-and-forth on
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 user error. Having the *local* se
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 'false' for
> speculative when ExecSe
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 the logic works in parseRelOption
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 tuples lack any means of indicating the
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 know what kind of policy we've committed to
>
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
> retrieve the tuples us
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 going to require context
>> they have
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 know what kind of pol
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 - because
otherwise using postgres_fdw
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 of
> requests can be record
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 mailing list (pgsql-hackers@postgre
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 effectively record that
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
> regconfig as the first argumen
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 tracking interesting attributes seems ok
>> too
>> > after the performance issue
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,
> the additional columns will be treated as nu
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 in the midst
>> of vacuum full'
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;
EX
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 really truncating the
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 TopMemoryCo
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
> 293e24e507838733aba4748b514536af2d39d7f2 instead of keeping
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]
https:/
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 tuple's nulls bitmap will b
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 been updated to work with RLS yet, either,
>>> but we didn't regard that as an open item f
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 equivalent of the natts field that
>>> exists in HeapTu
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 is apparently not checked early
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 coverage
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 that this is an unreasonably
>> dan
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 can use the feature
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 don't you share your thoughts
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
293e24e507
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 cleanup/pruning tuples from the
> > heap. So the risk o
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 would say
that touches of system ca
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
c
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 nominally backward-compatible.
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 related
>> function names, where that seemed sensi
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 included (ie there's no e
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 cha
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, or if we did the
>> resolution was just to document it.
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
doing trying to acquire ShareRowExclusiveLock on pg_subsc
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.
regards, tom
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 generated tuple.
>> I was thinking about
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 right.
>
> I took a look at this today. I think
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 1
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 s
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 struct.
>
>> I know, but EphemeralNamedRelation starts to get kinda long,
>>
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 applications, but it's hard to see how
> >> removal of a permission
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 thoughts and doubts till the "last
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 applications, but it's hard to see how
> >> removal of a permissio
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,
> especially when making the normal sorts of concatenations.
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 this morning, and wo
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 thinking about that this morning, and wo
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 li
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 from the heap is
> very low.
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 timestamp or
> boolean values and
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 such a thing. Certainly
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 break a working application ---
>> especially wh
1 - 100 of 172 matches
Mail list logo