Hi,
Looking at commits f10eab73d and c50d192c, I wondered why we don't
have a reusable in-place unique function. It may be trivial, but we
seem to have a lot of copies and variations in the tree.
Here's a sketch patch that creates a function array_unique which takes
the same arguments as qsort o
I've put up draft notes for 9.5.4 at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3676631c687009c2fadcb35e7d312e9eb8a98182
The website should have them after guaibasaurus's next run, due a couple
hours from now.
As usual, the older branches will have subsets of these notes
Its worth noting that the JDBC's behavior when you switch back to
autocommit is to immediately commit the open transaction.
Personally, I think committing immediately or erroring are unsurprising
behaviors. The current behavior is surprising and obviously wrong.
Rolling back without an error woul
On Sat, Aug 6, 2016 at 2:13 PM, Jim Nasby wrote:
> On 8/6/16 12:57 PM, Andrew Gierth wrote:
>
>> The easy to catch case, I think, is when the targetlist of the IN or NOT
>> IN subquery contains vars of the outer query level but no vars of the
>> inner one and no volatile functions. This can be ch
On Sat, Aug 6, 2016 at 6:46 AM, Amit Kapila wrote:
> I think here some of the factors like how many workers will be used
> for merge phase might impact the performance. Having too many
> workers can lead to more communication cost and having too few workers
> might not yield best results for mer
On 8/6/16 12:57 PM, Andrew Gierth wrote:
The easy to catch case, I think, is when the targetlist of the IN or NOT
IN subquery contains vars of the outer query level but no vars of the
inner one and no volatile functions. This can be checked for with a
handful of lines in the parser or a couple of
> "Andrew" == Andrew Gierth writes:
Andrew> The easy to catch case, I think, is when the targetlist of the
Andrew> IN or NOT IN subquery contains vars of the outer query level
Andrew> but no vars of the inner one and no volatile functions. This
Andrew> can be checked for with a handful of
2016-08-06 20:01 GMT+02:00 Jim Nasby :
> On 8/6/16 12:03 PM, Pavel Stehule wrote:
>
>> It would be very useful if we had some way to warn users about stuff
>> like this. Emitting a NOTICE comes to mind.
>>
>>
>> This can be valid query
>>
>
> Right, but in my experience it's an extremely u
On 8/6/16 12:03 PM, Pavel Stehule wrote:
It would be very useful if we had some way to warn users about stuff
like this. Emitting a NOTICE comes to mind.
This can be valid query
Right, but in my experience it's an extremely uncommon pattern and much
more likely to be a mistake (that
> "Pavel" == Pavel Stehule writes:
>> Well now I feel dumb...
>>
>> It would be very useful if we had some way to warn users about stuff
>> like this. Emitting a NOTICE comes to mind.
Pavel> This can be valid query
It can be, but it essentially never is. The cases where you genuinely
On 8/6/16 10:13 AM, Bruce Momjian wrote:
On Sat, Aug 6, 2016 at 04:04:41PM +0100, Andrew Gierth wrote:
"Bruce" == Bruce Momjian writes:
Bruce> Would it be helpful to output an array of strings representing
Bruce> the index definition?
>> Why would that help, if the point is to enable pro
2016-08-06 18:53 GMT+02:00 Jim Nasby :
> On 8/4/16 4:53 PM, Marko Tiikkaja wrote:
>
>> On 2016-08-04 11:23 PM, Jim Nasby wrote:
>>
>>> I've got a customer that discovered something odd...
>>>
>>> SELECT f1 FROM v1 WHERE f2 not in (SELECT bad FROM v2 WHERE f3 = 1);
>>>
>>> does not error, even thou
On 8/4/16 4:53 PM, Marko Tiikkaja wrote:
On 2016-08-04 11:23 PM, Jim Nasby wrote:
I've got a customer that discovered something odd...
SELECT f1 FROM v1 WHERE f2 not in (SELECT bad FROM v2 WHERE f3 = 1);
does not error, even though bad doesn't exist, but
I'm guessing there's a v1.bad?
This
Anastasia , thank you for your attentive code examine.
2016-08-05 21:19 GMT+05:00 Anastasia Lubennikova :
> First of all, shouldn't we use MAXALIGN(oldsize) instead of oldsize?
> Although, I'm quite sure that it was already aligned somewhere before.
> I doubt that the check (size_diff != MAXALIGN(
Amit Kapila writes:
> Isn't the problem here is that due to some reason (like concurrent
> split), the code in question (loop --
> while (P_ISDELETED(opaque) || opaque->btpo_next != target)) releases
> the lock on target buffer and the caller again tries to release the
> lock on target buffer when
On Sat, Aug 6, 2016 at 04:04:41PM +0100, Andrew Gierth wrote:
> > "Bruce" == Bruce Momjian writes:
>
> Bruce> Would it be helpful to output an array of strings representing
> Bruce> the index definition?
>
> >> Why would that help, if the point is to enable programmatic access
> >> to i
> "Bruce" == Bruce Momjian writes:
Bruce> Would it be helpful to output an array of strings representing
Bruce> the index definition?
>> Why would that help, if the point is to enable programmatic access
>> to information?
Bruce> I was thinking an array of strings would avoid problems
On Sat, Aug 6, 2016 at 01:00:15PM +0100, Andrew Gierth wrote:
> > "Bruce" == Bruce Momjian writes:
>
> >> As far as I understood Andrew's use case, he was specifically *not*
> >> interested in a complete representation of an index definition, but
> >> rather about whether it had certain p
On Sat, Aug 6, 2016 at 10:08:47AM +0530, Pavan Deolasee wrote:
> So, we are only checking the index if the WARM chain was pruned, and we
> can bail out if there is only one index changed. This is looking more
> doable.
>
>
> The duplicate tuples problem that we are focusing on, happ
On Sat, Aug 6, 2016 at 2:16 AM, Peter Geoghegan wrote:
> On Fri, Aug 5, 2016 at 9:06 AM, Robert Haas wrote:
>> There are some somewhat outdated and perhaps naive ideas about this
>> that we wrote up here:
>>
>> https://wiki.postgresql.org/wiki/Parallel_Sort
>
> I'm familiar with that effort. I th
> "Amit" == Amit Kapila writes:
Amit> Sure, that is the reason of crash, but even if we do that it will
Amit> lead to an error "no known snapshots". Here, what is going on is
Amit> that we initialized toast snapshot when there is no active
Amit> snapshot in the backend, so GetOldestSnaps
On Sat, Aug 6, 2016 at 5:51 PM, Andrew Gierth
wrote:
>> "Andreas" == Andreas Seltenreich writes:
>
> 418 if (OldestActiveSnapshot != NULL)
> 419 ActiveLSN = OldestActiveSnapshot->as_snap->lsn;
> 420
> 421 if (XLogRecPtrIsInvalid(RegisteredLSN) || RegisteredLSN > ActiveLSN)
> 422
> "Andreas" == Andreas Seltenreich writes:
418 if (OldestActiveSnapshot != NULL)
419 ActiveLSN = OldestActiveSnapshot->as_snap->lsn;
420
421 if (XLogRecPtrIsInvalid(RegisteredLSN) || RegisteredLSN > ActiveLSN)
422 return OldestActiveSnapshot->as_snap;
This second conditional
On Sat, Aug 6, 2016 at 6:32 PM, Andreas Seltenreich wrote:
> since updating master from c93d873..fc509cd, I see crashes in
> GetOldestSnapshot() on update/delete returning statements.
>
> I reduced the triggering statements down to this:
>
> update clstr_tst set d = d returning d;
>
> Backtrac
> "Bruce" == Bruce Momjian writes:
>> As far as I understood Andrew's use case, he was specifically *not*
>> interested in a complete representation of an index definition, but
>> rather about whether it had certain properties that would be of
>> interest to query-constructing application
On 04/08/16 06:40, Masahiko Sawada wrote:
On Wed, Aug 3, 2016 at 3:05 PM, Michael Paquier
wrote:
On Wed, Aug 3, 2016 at 2:52 PM, Masahiko Sawada wrote:
I was thinking that the syntax for quorum method would use '[ ... ]'
but it will be confused with '( ... )' priority method used.
001 patch a
Michael Paquier writes:
> Andreas, with the patch attached is the assertion still triggered?
> [2. text/x-diff; base-backup-crash-v2.patch]
I didn't observe the crashes since applying this patch. There should
have been about five by the amount of fuzzing done.
regards
Andreas
--
Sent via pgs
Hi,
since updating master from c93d873..fc509cd, I see crashes in
GetOldestSnapshot() on update/delete returning statements.
I reduced the triggering statements down to this:
update clstr_tst set d = d returning d;
Backtrace below.
regards,
Andreas
Program received signal SIGSEGV, Segment
Hi
I tried to dig into this patch (which seems pretty interesting) to help
bring
it in good shape. Here are few random notes, I hope they can be helpful:
> I think we actually need a real API here.
Definitely, there are plenty places in the new code with the same pattern:
* figure out if it's a
29 matches
Mail list logo
