Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, Apr 19, 2016 at 8:44 PM, Robert Haas wrote: > > On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote: > > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote: > > >> It seems that for read-only workloads,

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Sun, Apr 17, 2016 at 1:22 AM, Magnus Hagander wrote: > On Wed, Apr 13, 2016 at 4:07 AM, Noah Misch wrote: >> >> On Tue, Apr 12, 2016 at 10:08:23PM +0200, Magnus Hagander wrote: >> > On Tue, Apr 12, 2016 at 8:39 AM, Noah Misch wrote:

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Apr 20, 2016 at 1:39 PM, Noah Misch wrote: > On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote: >> Michael Paquier wrote: >> > On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier >> > wrote: >> > > Now, I have produced two patches:

Re: [HACKERS] VS 2015 support in src/tools/msvc

* Michael Paquier wrote: On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote: Both patches behave exactly the same in this test. Of the 102 remaining locales, I get an unexpected codepage for just four: - kk: Expected 1251, used 1252 - kk-KZ: Expected 1251, used

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote: > Michael Paquier wrote: > > On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier > > wrote: > > > Now, I have produced two patches: > > > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of > > >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 18, 2016 at 2:15 PM, Kyotaro HORIGUCHI wrote: > At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada > wrote in >> >> How about if we do all the parsing stuff

Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk

On Tue, Apr 19, 2016 at 06:31:34PM +0300, Yury Zhuravlev wrote: > Now we generate tests for plpython3 of plpython2 tests. I think we should > write independently 2 test suite. > Why is that bad: > 1. Differences between python2 and python3 more than can be solved by > regexps. And these

Re: [HACKERS] pg_dump dump catalog ACLs

On Sun, Apr 17, 2016 at 11:02:28PM -0400, Noah Misch wrote: > On Tue, Apr 05, 2016 at 05:50:18PM -0400, Stephen Frost wrote: > > I'll be doing more testing, review and clean-up (there are some > > whitespace only changes in the later patches that really should be > > included in the earlier

Re: [HACKERS] Timeline following for logical slots

On Sun, Apr 17, 2016 at 10:01:36PM +0800, Craig Ringer wrote: > I made an unfortunate oversight in the logical decoding timeline following > code: it doesn't work for logical decoding from the walsender, because I > left the glue code required out of the final cut of the patch. > Subject: [PATCH]

Re: [HACKERS] EXPLAIN VERBOSE with parallel Aggregate

On Sun, Apr 17, 2016 at 10:22:24AM -0400, Tom Lane wrote: > David Rowley writes: > > On 16 April 2016 at 04:27, Tom Lane wrote: > >> +1 for the latter, if we can do it conveniently. I think exposing > >> the names of the aggregate implementation

Re: [HACKERS] Memory leak in GIN index build

I had the possibility to perform tests on 9.5, and can confirm the memory leak I was seeing is solved with the patch (and that's great :) ) Regards Marc On 18/04/2016 17:53, Julien Rouhaud wrote: > On 18/04/2016 16:33, Tom Lane wrote: >> I poked at this over the weekend, and got more unhappy

Re: [HACKERS] Postgres 9.6 scariest patch tournament

On Tue, Apr 19, 2016 at 04:06:55PM -0400, Tom Lane wrote: > Alvaro Herrera writes: > > Peter Geoghegan wrote: > >> I would have appreciated more scope to say how confident I am in > >> my prediction, and how scary in absolute terms I consider the > >> scariest patches to

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Sat, Apr 16, 2016 at 06:22:47PM +0200, Magnus Hagander wrote: > > On Tue, Apr 12, 2016 at 10:08:23PM +0200, Magnus Hagander wrote: > > > I won't have time to do the bigger rewrite/reordeirng by then, but I can > > > certainly commit to having the smaller updates done to cover the new > > >

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote: > Both patches behave exactly the same in this test. Of the 102 remaining > locales, I get an unexpected codepage for just four: > > - kk: Expected 1251, used 1252 > - kk-KZ: Expected 1251, used 1252 > - sr: Expected

Re: [HACKERS] Postgres 9.6 scariest patch tournament

On Tue, Apr 19, 2016 at 12:37 PM, Alvaro Herrera wrote: > This guy reads my mind. Where's my tinfoil hat? Heh. Well, I'm generally not in favor of communicating concerns without an obligation to defend them, but it could work well in tiny doses. Offering hackers a

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

Dean Rasheed writes: > On 19 April 2016 at 14:38, Tom Lane wrote: >> Yeah, what I was thinking of printing is something like >> >> asind(x), >> asind(x) IN (-90,-30,0,30,90) AS asind_exact, >> ... >> >> with extra_float_digits=3. > OK, that sounds

Re: [HACKERS] Postgres 9.6 scariest patch tournament

Alvaro Herrera writes: > Peter Geoghegan wrote: >> I would have appreciated more scope to say how confident I am in my >> prediction, and how scary in absolute terms I consider the scariest >> patches to be. > It was purposefully ambiguous. Maybe it should have been

Re: [HACKERS] Postgres 9.6 scariest patch tournament

Peter Geoghegan wrote: > On Mon, Apr 18, 2016 at 1:22 PM, Josh berkus wrote: > > We should send the owner of the scariest patch something as a prize. > > Maybe a plastic skeleton or something ... > > I think it was a good idea to call it the scariest patch rather than >

Re: [HACKERS] Postgres 9.6 scariest patch tournament

On Mon, Apr 18, 2016 at 1:22 PM, Josh berkus wrote: > We should send the owner of the scariest patch something as a prize. > Maybe a plastic skeleton or something ... I think it was a good idea to call it the scariest patch rather than something more severe sounding. Having

Re: [HACKERS] Reducing the size of BufferTag & remodeling forks

Andres Freund wrote: > I've actually changed course a bit and I'm trying something different: A > two level structure. One hashtable that maps (RelFileNode, ForkNumber) > to a 'open relation' data structure, and from there a radix tree over > just the block number. To avoid having to look up in

Re: [HACKERS] Parser extensions (maybe for 10?)

2016-04-19 12:49 GMT+02:00 Simon Riggs : > On 12 April 2016 at 06:51, Tom Lane wrote: > >> Craig Ringer writes: >> > The other area where there's room for extension without throwing out the >> > whole thing and rebuilding is

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > On Tue, Apr 19, 2016 at 11:02 AM, Alvaro Herrera > wrote: > > Robert Haas wrote: > > > >> That wouldn't have fixed my problem, which involved rebasing a patch. > > > > True. I note that it's possible to munge a patch mechanically to sort > > out

Re: [HACKERS] snapshot too old, configured by time

On Tue, Apr 19, 2016 at 11:02 AM, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote: > Since this change to BufferGetPage() has caused severe back-patch pain for at least two committers so far, I will revert that

Re: [HACKERS] VS 2015 support in src/tools/msvc

* Alvaro Herrera wrote: Michael Paquier wrote: On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier wrote: Now, I have produced two patches: - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of __crt_locale_data_public in ucrt/corecrt.h. This is definitely

Re: [HACKERS] snapshot too old, configured by time

Andres Freund wrote: > On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote: > > > Since this change to BufferGetPage() has caused severe back-patch > > > pain for at least two committers so far, I will revert that (very > > > recent) change to this patch later today unless I hear an > > >

Re: [HACKERS] Parser extensions (maybe for 10?)

> On 12 Apr 2016, at 07:36, Arcadiy Ivanov wrote: > > [ > DISTRIBUTE BY { REPLICATION | ROUNDROBIN | { [HASH | MODULO ] ( column_name > ) } } | > DISTRIBUTED { { BY ( column_name ) } | { RANDOMLY } | > DISTSTYLE { EVEN | KEY | ALL } DISTKEY ( column_name ) > ] > [ TO {

[HACKERS] Proposal: Remove regress-python3-mangle.mk

Hello. Now we generate tests for plpython3 of plpython2 tests. I think we should write independently 2 test suite. Why is that bad: 1. Differences between python2 and python3 more than can be solved by regexps. And these differences are growing. 2. We must be careful to write tests, so as not

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 19 April 2016 at 14:38, Tom Lane wrote: > Yeah, what I was thinking of printing is something like > > asind(x), > asind(x) IN (-90,-30,0,30,90) AS asind_exact, > ... > > with extra_float_digits=3. The point of this is not necessarily to give > any

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, Apr 19, 2016 at 10:14 AM, Robert Haas wrote: > On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote: >> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote: >>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote: > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote: >> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote: >>> >>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote: >>> >

Re: [HACKERS] snapshot too old, configured by time

On Tue, Apr 19, 2016 at 11:03 AM, Alvaro Herrera wrote: > Kevin Grittner wrote: >> On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote: >> >> > The right thing to do about that is just change it back to the >> > way Kevin had it originally. >> >>

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote: > On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote: >> >> On 2016-04-16 16:44:52 -0400, Noah Misch wrote: >> > That is more controversial than the potential ~2% regression for >> >

Re: [HACKERS] snapshot too old, configured by time

On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote: > Kevin Grittner wrote: > > On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote: > > > > > The right thing to do about that is just change it back to the > > > way Kevin had it originally. > > > > Since this change to

Re: [HACKERS] snapshot too old, configured by time

Kevin Grittner wrote: > On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote: > > > The right thing to do about that is just change it back to the > > way Kevin had it originally. > > Since this change to BufferGetPage() has caused severe back-patch > pain for at least two

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote: > > On 2016-04-16 16:44:52 -0400, Noah Misch wrote: > > That is more controversial than the potential ~2% regression for > > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay releasing > > that way, and Andres[4]

Re: [HACKERS] Parser extensions (maybe for 10?)

> On 2016-04-19 12:20:03 +0300, Aleksander Alekseev wrote: > > Can we guarantee that extensions don't conflict? In fact we can > > since we already do it. If all tests pass there is no conflict. > > How does that follow? Even if you were to test all possible extensions > together - obviously not

Re: [HACKERS] Declarative partitioning

Hi Idlar, Alexander, On Tue, Apr 19, 2016 at 11:26 PM, Alexander Korotkov wrote: > On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote: >> >> Thanks for your new patch! I've tried it and discovered some strange >> behavior for partitioning by

Re: [HACKERS] snapshot too old, configured by time

On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote: > The right thing to do about that is just change it back to the > way Kevin had it originally. Since this change to BufferGetPage() has caused severe back-patch pain for at least two committers so far, I will revert

Re: [HACKERS] Declarative partitioning

On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote: > On 15.04.2016 07:35, Amit Langote wrote: > >> Thanks a lot for the comments. The patch set changed quite a bit since >> the last version. Once the CF entry was marked returned with feedback on >> March 22, I held off

[HACKERS] Avoid parallel full and right join paths.

Tests: create table mytab(x int,x1 char(9),x2 varchar(9)); create table mytab1(y int,y1 char(9),y2 varchar(9)); insert into mytab values (generate_series(1,5),'aa','aaa'); insert into mytab1 values (generate_series(1,1),'aa','aaa'); insert into mytab values

Re: [HACKERS] Parser extensions (maybe for 10?)

On 2016-04-19 12:20:03 +0300, Aleksander Alekseev wrote: > Can we guarantee that extensions don't conflict? In fact we can since > we already do it. If all tests pass there is no conflict. How does that follow? Even if you were to test all possible extensions together - obviously not possible -

Re: [HACKERS] Parser extensions (maybe for 10?)

On 2016-04-19 15:32:07 +0300, Aleksander Alekseev wrote: > > As Tom says, we can't easily break it down into multiple co-operating > > pieces, so lets forget that as unworkable. > > I'm sorry but didn't I just demonstrate the opposite? I doubt it. > If so it's very > easy to prove - give a

Re: [HACKERS] Declarative partitioning

Hi Amit, On 15.04.2016 07:35, Amit Langote wrote: Thanks a lot for the comments. The patch set changed quite a bit since the last version. Once the CF entry was marked returned with feedback on March 22, I held off sending the new version at all. Perhaps, it would have been OK. Anyway here it

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

Dean Rasheed writes: > On 19 April 2016 at 05:16, Noah Misch wrote: >> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote: >>> Hm? The expected answer is exact (30, 45, or whatever) in each case. >>> If we get some residual low-order digits

Re: [HACKERS] Postgres 9.6 scariest patch tournament

On 04/18/2016 04:22 PM, Josh berkus wrote: > > We should send the owner of the scariest patch something as a prize. > Maybe a plastic skeleton or something ... A mouse. -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Parser extensions (maybe for 10?)

> As Tom says, we can't easily break it down into multiple co-operating > pieces, so lets forget that as unworkable. I'm sorry but didn't I just demonstrate the opposite? If so it's very easy to prove - give a counterexample. As I understand approach I described handles cases named by Tom just

Re: [HACKERS] Parser extensions (maybe for 10?)

On Tue, Apr 19, 2016 at 1:49 PM, Simon Riggs wrote: > On 12 April 2016 at 06:51, Tom Lane wrote: > >> Craig Ringer writes: >> > The other area where there's room for extension without throwing out the >> > whole thing and

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/19/2016 01:47 AM, Michael Paquier wrote: On Tue, Apr 19, 2016 at 2:42 PM, Alvaro Herrera wrote: Michael Paquier wrote: On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier wrote: Now, I have produced two patches: -

Re: [HACKERS] snapshot too old, configured by time

On Tue, Apr 19, 2016 at 1:23 AM, Michael Paquier wrote: > On Tue, Apr 19, 2016 at 3:14 AM, Tom Lane wrote: >> Or in short: this is a whole lot further than I'm prepared to go to >> satisfy one customer with a badly-designed application. And from

Re: [HACKERS] Parser extensions (maybe for 10?)

On 12 April 2016 at 06:51, Tom Lane wrote: > Craig Ringer writes: > > The other area where there's room for extension without throwing out the > > whole thing and rebuilding is handling of new top-level statements. We > can > > probably dispatch the

Re: [HACKERS] Coverage report

Hello, Alvaro. > Some people have already heard about this. Yes, we did :) Nice job! > * Should we run something other than "make check-world" As far as I > know, that covers all or almost all the tests we have; are there > things that we should have and are not running? If so, how do we go >

Re: [HACKERS] OS scheduler bugs affecting high-concurrency contention

Hi, On 04/16/2016 04:15 PM, Kevin Grittner wrote: There is a paper that any one interested in performance at high concurrency, especially in Linux, should read[1]. While doing other work, a group of researchers saw behavior that they suspected was due to scheduler bugs in Linux. There were no

Re: [HACKERS] Parser extensions (maybe for 10?)

> no - it is not possible. Not with Bison parser - it cannot work with > unknown syntax - so isn't possible implement one part by parser A, and > second part by parser B. > > But we can parsers P1 and P2. P1 knows string XX, P2 knows YY. Buildin > parser (BP) knows SQL > > We can have registered

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 19 April 2016 at 05:16, Noah Misch wrote: > On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote: >> Noah Misch writes: >> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote: >> >> We could alternatively set extra_float_digits to its max value

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

On Mon, Apr 18, 2016 at 4:48 PM, Michael Paquier wrote: > Another, perhaps, better idea is to add some more extra logic to > pg_conn as follows: > boolis_emergency; > PGresult *emergency_result; > boolis_emergency_consumed; > So as when an OOM shows up,