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
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
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
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
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 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:
> 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
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:/
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
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
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
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
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'
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,
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
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
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 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 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 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 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 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
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 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
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
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
>
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
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 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 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
"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 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
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 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 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: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
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 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
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
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
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
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 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.
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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.
> >>>
>
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
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 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
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
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 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
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, 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
101 - 172 of 172 matches
Mail list logo
