[HACKERS] Consolidate 'unique array values' logic into a reusable function?

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

[HACKERS] Draft release notes for next week's back-branch releases

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

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Oddity with NOT IN

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

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

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

Re: [HACKERS] Possible duplicate release of buffer lock.

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 >

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

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

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

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

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

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

Re: [HACKERS] Heap WARM Tuples - Design Draft

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,

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

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

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

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

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

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

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

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

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

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

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

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

Re: [HACKERS] Quorum commit for multiple synchronous replication.

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

Re: [HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

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

[HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

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,

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

​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

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

As an extra data point, if you try this in Python (psycopg2) you get an exception: psycopg2.ProgrammingError: autocommit cannot be used inside a transaction I think this exception is a legitimate response. If the user switches on autocommit mode inside a transaction, it was most likely not on

Re: [HACKERS] Possible duplicate release of buffer lock.

On Fri, Aug 5, 2016 at 11:27 AM, Kyotaro HORIGUCHI wrote: > Hello, > > If concurrent deletion (marking half-dead, specifically) can't > happen, P_ISDELETED() won't be seen in the loop but we may > consider it as a skippable condition to continue VACUUM. But >

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

2016-08-06 7:29 GMT+02:00 Amit Kapila : > On Thu, Aug 4, 2016 at 7:46 PM, Pavel Stehule > wrote: > > > 2016-08-04 15:37 GMT+02:00 Amit Kapila : > >> > >> > I dislike automatic commit or rollback here. > >> > > >> > >>