Re: [HACKERS] Multiple false-positive warnings from Valgrind

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

Re: [HACKERS] Making clausesel.c Smarter

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

Re: [HACKERS] Table collision in join.sql and aggregates.sql

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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

Re: [HACKERS] TPC-H Q20 from 1 hour to 19 hours!

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

[HACKERS] Re: [COMMITTERS] pgsql: Avoid GatherMerge crash when there are no workers.

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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,

Re: [HACKERS] logical replication launcher crash on buildfarm

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,

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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(), >

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] [POC] A better way to expand hash indexes.

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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

Re: [HACKERS] crashes due to setting max_parallel_workers=0

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,

Re: [HACKERS] TPC-H Q20 from 1 hour to 19 hours!

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 >

Re: [HACKERS] logical replication launcher crash on buildfarm

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

Re: [HACKERS] logical replication launcher crash on buildfarm

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

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] partitioned tables and contrib/sepgsql

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

Re: [HACKERS] [PATCH] SortSupport for macaddr type

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.

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

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

Re: [HACKERS] WIP: Covering + unique indexes.

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] postgres_fdw IMPORT SCHEMA and partitioned tables

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

Re: [HACKERS] Table collision in join.sql and aggregates.sql

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

[HACKERS] Table collision in join.sql and aggregates.sql

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] LWLock optimization for multicore Power machines

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 >>

Re: [HACKERS] Partitioning vs ON CONFLICT

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

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] Partitioning vs ON CONFLICT

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

Re: [HACKERS] Documentation improvements for partitioning

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

Re: [HACKERS] Partitioning vs ON CONFLICT

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) >

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

"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

Re: [HACKERS] Foreign tables don't enforce the partition constraint

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

Re: [HACKERS] Partitioning vs ON CONFLICT

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

Re: [HACKERS] Partitioned tables and relfilenode

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] postgres_fdw IMPORT SCHEMA and partitioned tables

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] postgres_fdw IMPORT SCHEMA and partitioned tables

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

Re: [HACKERS] postgres_fdw IMPORT SCHEMA and partitioned tables

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 -

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

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

Re: [HACKERS] postgres_fdw IMPORT SCHEMA and partitioned tables

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] [PATCH] few fts functions for jsonb

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

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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, >

Re: [HACKERS] [PATCH] SortSupport for macaddr type

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,

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

[HACKERS] parallel explain analyze support not exercised

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;

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] brin autosummarization -- autovacuum "work items"

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

Re: [HACKERS] bumping HASH_VERSION to 3

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 >

[HACKERS] parallel bitmapscan isn't exercised in regression tests

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]

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] partitioned tables and contrib/sepgsql

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] delta relations in AFTER triggers

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

Re: [HACKERS] WIP: Covering + unique indexes.

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

Re: [HACKERS] bumping HASH_VERSION to 3

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

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

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

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

[HACKERS] [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command

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

Re: [HACKERS] bumping HASH_VERSION to 3

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

Re: [HACKERS] delta relations in AFTER triggers

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

[HACKERS] bumping HASH_VERSION to 3

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

Re: [HACKERS] partitioned tables and contrib/sepgsql

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,

Re: [HACKERS] Somebody has not thought through subscription locking considerations

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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.

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] GUC for cleanup indexes threshold.

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

[HACKERS] merge psql ef/ev sf/sv handling functions

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

Re: [HACKERS] WIP: Covering + unique indexes.

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

Re: [HACKERS] delta relations in AFTER triggers

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

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

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

Re: [HACKERS] WIP: Covering + unique indexes.

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

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

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

Re: [HACKERS] delta relations in AFTER triggers

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, >

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] WIP: Covering + unique indexes.

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

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

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

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

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

Re: [HACKERS] Allow to specify #columns in heap/index_form_tuple

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

Re: [HACKERS] REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article)

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

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

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   2   >