Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Sun, Apr 10, 2016 at 2:24 PM, Amit Kapila wrote: > On Sun, Apr 10, 2016 at 11:33 AM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov < >> a.korot...@postgrespro.ru> wrote: >> >>> On Sat, Apr 9, 2016 at

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund wrote: > On 2016-04-10 09:03:37 +0300, Alexander Korotkov wrote: > > On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov < > > a.korot...@postgrespro.ru> wrote: > > > > > On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund

Re: [HACKERS] 2016-03 Commitfest

On 4/10/16 11:14 PM, Andres Freund wrote: > On 2016-04-08 11:52:45 -0400, Robert Haas wrote: > >> In view of these circumstances, the RMT has voted to extend the >> deadline for this particular patch by 2.5 days; that is, this patch >> may be committed with RMT approval no later than 2016-04-11

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Sun, Apr 10, 2016 at 3:13 AM, Pavel Stehule wrote: > > Hi > > 2016-03-21 22:13 GMT+01:00 Pavel Stehule : >> >> Hi >> >> 2016-03-21 21:24 GMT+01:00 Merlin Moncure : >>> >>> Patch is trivial (see below), discussion is not :-).

Re: [HACKERS] Execute ignoring cursor?

2016-04-11 16:31 GMT+02:00 nummervet nummervet : > Oh. That doesn't work for me as i generate the query dynamically and don't > know their structure... > Maybe there is an easy way to get the cursor structure (column - value, > column - value)? > Or should i give up on

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

Hi, Tom! On Sun, Apr 10, 2016 at 7:49 AM, Tom Lane wrote: > 1. It doesn't seem like generic_xlog.c has thought very carefully about > the semantics of the "hole" between pd_lower and pd_upper. The mainline > XLOG code goes to some lengths to ensure that the hole stays

Re: [HACKERS] Choosing parallel_degree

On 11/04/2016 15:56, tushar wrote: > On 04/08/2016 08:53 PM, Robert Haas wrote: >> On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila wrote: >>> Other than that, patch looks good and I have marked it as Ready For >>> Committer. Hope, we get this for 9.6. >> Committed. I think

[HACKERS] Re[2]: [HACKERS] Execute ignoring cursor?

Oh. That doesn't work for me as i generate the query dynamically and don't know their structure... Maybe there is an easy way to get the cursor structure (column - value, column - value)? Or should i give up on cursors and try something else? Some Google search hint that hstore could be my

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

Teodor Sigaev writes: >> 2. Unless I'm missing something, contrib/bloom is making no effort >> to ensure that bloom index pages can be distinguished from other pages >> by pg_filedump. That's fine if your expectation is that bloom will always >> be a toy with no use in

Re: [HACKERS] [COMMITTERS] pgsql: Add the "snapshot too old" feature

On Mon, Apr 11, 2016 at 4:27 PM, Alvaro Herrera wrote: > Alexander Korotkov wrote: > > Kevin, > > > > This commit makes me very uneasy. I didn't much care about this patch > > mainly because I didn't imagine its consequences. Now, I see following: > > > > 1) We uglify

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

mainline XLOG replay. Shouldn't generic_xlog.c take the same trouble? Yes, it should. Alexander now works on it. 2. Unless I'm missing something, contrib/bloom is making no effort to ensure that bloom index pages can be distinguished from other pages by pg_filedump. That's fine if your

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

Michael Paquier writes: > Actually, as I look at this code for the first time, I find that > GenericXLogFinish() is a very confusing interface. It makes no > distinction between a page and the meta data associated to this page, > this is controlled by a flag isNew and

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

Michael Paquier writes: > As given out now, we are able to do the following: > - Log a full page > - Log a delta of a full page, which is actually data associated to a page. > - At recovery, replay those full pages with a delta. Right. > What I thought we should be

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

... BTW, with respect to the documentation angle, it seems to me that it'd be better if GenericXLogRegister were renamed to GenericXLogRegisterBuffer, or perhaps GenericXLogRegisterPage. I think this would make the documentation clearer, and it would also make it easier to add other sorts of

Re: [HACKERS] Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-11 23:59:21 -0400, Tom Lane wrote: > Andres Freund writes: > > Will fix (both initialization and use of pg_atomic_fetch_or_u32), and > > expand the documentation on why only atomic read/write are supposed to > > be used. > > FWIW, I'd vote against adding a

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-12 00:32:13 -0400, Tom Lane wrote: > I wrote: > > This commit has broken buildfarm member gaur, and no doubt pademelon > > will be equally unhappy once it catches up to HEAD. > > Spoke too soon, actually: pademelon did not get as far as initdb. > > cc: "bufmgr.c", line 4032: error

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

On Mon, Apr 11, 2016 at 9:58 PM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > *From:* pgsql-hackers-ow...@postgresql.org [mailto: > pgsql-hackers-ow...@postgresql.org] * On Behalf Of *Arcadiy Ivanov > > Currently the parser and lexer are fully fixed at compile-time and not >

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

On 12 April 2016 at 13:28, David G. Johnston wrote: > ​As recently discovered there is more than one reason why an intelligent > driver, like the JDBC standard at least requires in a few instances, > requires knowledge of at least some basic structure​ > > ​of the

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

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 statement text to a sub-parser provided by an > extension that registers

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

Arcadiy Ivanov writes: > Is there any interest and/or tips to allow a pluggable parser or at > least allow some syntactical pluggability by extensions? There is a fair amount of discussion of this in the archives. The short answer is that bison can't do it, and "let's

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

On 12 April 2016 at 13:10, Tom Lane wrote: > > I'm interested in possible solutions to this problem, but it's far > harder than it looks. > > Exactly. Limited extension points where we accept runtime errors and confine the extension points can be OK; e.g. SOME STATEMENT ...

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > Allow Pin/UnpinBuffer to operate in a lockfree manner. This commit has broken buildfarm member gaur, and no doubt pademelon will be equally unhappy once it catches up to HEAD. The reason is that you've caused localbuf.c to perform a whole bunch of

[HACKERS] Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-11 23:24:36 -0400, Tom Lane wrote: > Andres Freund writes: > > Allow Pin/UnpinBuffer to operate in a lockfree manner. > > This commit has broken buildfarm member gaur, and no doubt pademelon > will be equally unhappy once it catches up to HEAD. The reason is that

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

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Arcadiy Ivanov Currently the parser and lexer are fully fixed at compile-time and not amenable to the extensions - extensions are only capable of introducing functions etc. There is, however, an

Re: [HACKERS] 'Create table if not exists as' breaks SPI_execute

Stas Kelvich writes: > SPI_execute assumes that CreateTableAsStmt always have completionTag == > “completionTag”. > But it isn’t true in case of ‘IF NOT EXISTS’ present. Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 April 2016 at 00:39, Justin Clift wrote: > Moving over a conversation from the pgsql-advocacy mailing list. In it > Simon (CC'd) raised the issue of potentially creating a > backwards-compatibility > breaking release at some point in the future, to deal with things

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On Tue, Apr 12, 2016 at 10:54 AM, Craig Ringer wrote: > On 12 April 2016 at 08:36, Michael Paquier wrote: > The only way we really have at the moment is shared_preload_libraries. That's exactly my point. > If you rely on shared_preload_libraries, then "oops, I forgot to

[HACKERS] Parser extensions (maybe for 10?)

I thought I'd float this idea and see if this gets any traction. Please forgive my ignorance if this has been discussed already. Currently the parser and lexer are fully fixed at compile-time and not amenable to the extensions - extensions are only capable of introducing functions etc.

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

On 12 April 2016 at 12:36, Arcadiy Ivanov wrote: > > Is there any interest and/or tips to allow a pluggable parser or at least > allow some syntactical pluggability by extensions? > I think this may allow some projects to move towards becoming an extension > as opposed to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > The issue is likely that either Alexander or I somehow made > MarkLocalBufferDirty() use pg_atomic_fetch_or_u32(), instead of the > proper pg_atomic_read_u32()/pg_atomic_write_u32(). The stack trace I'm seeing is #5 0x7279cc in elog_finish (elevel=6,

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On Mon, Apr 11, 2016 at 11:29 PM, Tom Lane wrote: > Michael Paquier writes: >> Actually, as I look at this code for the first time, I find that >> GenericXLogFinish() is a very confusing interface. It makes no >> distinction between a page and the

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On Tue, Apr 12, 2016 at 9:33 AM, Tom Lane wrote: > ... BTW, with respect to the documentation angle, it seems to me > that it'd be better if GenericXLogRegister were renamed to > GenericXLogRegisterBuffer, or perhaps GenericXLogRegisterPage. > I think this would make the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-11 23:41:10 -0400, Tom Lane wrote: > Andres Freund writes: > > The issue is likely that either Alexander or I somehow made > > MarkLocalBufferDirty() use pg_atomic_fetch_or_u32(), instead of the > > proper pg_atomic_read_u32()/pg_atomic_write_u32(). > > The stack

Re: [HACKERS] Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: >>> The issue is likely that either Alexander or I somehow made >>> MarkLocalBufferDirty() use pg_atomic_fetch_or_u32(), instead of the >>> proper pg_atomic_read_u32()/pg_atomic_write_u32(). > Ok, so the theory above fits. Yah, especially in view of

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Mon, Apr 11, 2016 at 5:16 PM, Etsuro Fujita wrote: > On 2016/04/11 12:30, Michael Paquier wrote: >> >> + if ((cancel = PQgetCancel(entry->conn))) >> + { >> + PQcancel(cancel, errbuf,

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-11 14:40:29 -0700, Andres Freund wrote: > On 2016-04-11 12:17:20 -0700, Andres Freund wrote: > I did get access to the machine (thanks!). My testing shows that > performance is sensitive to various parameters influencing memory > allocation. E.g. twiddling with max_connections changes >

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On 12 April 2016 at 10:09, Michael Paquier wrote: > On Tue, Apr 12, 2016 at 10:54 AM, Craig Ringer > wrote: > > > If you rely on shared_preload_libraries, then "oops, I forgot to put > > myextension in shared_preload_libraries on the

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

I wrote: > This commit has broken buildfarm member gaur, and no doubt pademelon > will be equally unhappy once it catches up to HEAD. Spoke too soon, actually: pademelon did not get as far as initdb. cc: "bufmgr.c", line 4032: error 1521: Incorrect initialization. cc: "bufmgr.c", line 4058:

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

On Mon, Apr 11, 2016 at 8:47 PM, Fujii Masao wrote: > On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada > wrote: >> On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: >>> On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On Tue, Apr 12, 2016 at 9:21 AM, Tom Lane wrote: > Michael Paquier writes: >> What I thought we should be able to do with that should not be only >> limited to indexes, aka to: >> - Be able to register and log full pages >> - Be able to log data

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On 12 April 2016 at 08:36, Michael Paquier wrote: > > > Also, the entire point here is that extensions DON'T > > get to have custom apply routines, because we have no way for > > replay to know about such apply routines. (It surely cannot look > > in the catalogs for

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On Mon, Apr 11, 2016 at 12:01 AM, Andres Freund wrote: >> InitBufferPool() manually fixes up alignment; that should probably be >> removed now. Attached patch does that. >> I also wonder if it doesn't make sense to fix PG_CACHE_LINE_SIZE to >> 64byte on x86. I personally

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Fri, Apr 1, 2016 at 7:53 PM, Karl O. Pinc wrote: > > On Fri, 1 Apr 2016 05:57:33 +0200 > "Shulgin, Oleksandr" wrote: > > > On Apr 1, 2016 02:57, "Karl O. Pinc" wrote: > > > > > > I assume there are no questions about supporting a >

Re: [HACKERS] [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

Hi, On 2016-04-11 07:09:18 -0400, Robert Haas wrote: > Attached patch does that. Thanks. > > Additionally, doesn't this obsolete > > > > /* > > * Preferred alignment for disk I/O buffers. On some CPUs, copies between > > * user space and kernel space are significantly faster if the user

Re: [HACKERS] 2016-03 Commitfest

On Mon, Apr 11, 2016 at 1:35 PM, David Steele wrote: > On 4/10/16 11:14 PM, Andres Freund wrote: > > > On 2016-04-08 11:52:45 -0400, Robert Haas wrote: > > > >> In view of these circumstances, the RMT has voted to extend the > >> deadline for this particular patch by 2.5

[HACKERS] Re[4]: [HACKERS] Execute ignoring cursor?

Ok, now i am getting this: ERROR:  could not identify column "151" in record data type Raise notice show that the column exists. Any other way around it? >Пятница, 8 апреля 2016, 18:24 +03:00 от Pavel Stehule >: > > > >2016-04-08 16:46 GMT+02:00 nummervet nummervet

Re: [HACKERS] [COMMITTERS] pgsql: Add the "snapshot too old" feature

Kevin, This commit makes me very uneasy. I didn't much care about this patch mainly because I didn't imagine its consequences. Now, I see following: 1) We uglify buffer manager interface a lot. This patch adds 3 more arguments to BufferGetPage(). It looks weird. Should we try to find less

Re: [HACKERS] [COMMITTERS] pgsql: Add the "snapshot too old" feature

Alexander Korotkov wrote: > Kevin, > > This commit makes me very uneasy. I didn't much care about this patch > mainly because I didn't imagine its consequences. Now, I see following: > > 1) We uglify buffer manager interface a lot. This patch adds 3 more > arguments to BufferGetPage(). It

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

On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada wrote: > On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: >> On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada >> wrote: >>> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane

Re: [HACKERS] 2016-03 Commitfest

On 04/11/2016 01:35 PM, David Steele wrote: I've marked this committed so the 2016-03 CF is now complete! Thanks to you and everyone else involved in running this CF. You did an excellent job. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Execute ignoring cursor?

2016-04-11 13:11 GMT+02:00 nummervet nummervet : > Ok, now i am getting this: > ERROR: could not identify column "151" in record data type > > Raise notice show that the column exists. > Any other way around it? > > hmm - it doesn't work for generic record - it should be typed

[HACKERS] Preprocessor condition fix

Here is a one-line patch to fix a wrong preprocessor condition in pg_regress, found because the VS 2015 compiler warns on the cast in the 32-bit branch where apparently earlier versions did not. According to git grep, this is the only place where WIN64 is used without the leading underscore.

Re: [HACKERS] Choosing parallel_degree

On 04/08/2016 08:53 PM, Robert Haas wrote: On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila wrote: Other than that, patch looks good and I have marked it as Ready For Committer. Hope, we get this for 9.6. Committed. I think this is likely to make parallel query

Re: [HACKERS] Choosing parallel_degree

On Mon, Apr 11, 2016 at 11:27 AM, Julien Rouhaud wrote: > On 11/04/2016 15:56, tushar wrote: >> On 04/08/2016 08:53 PM, Robert Haas wrote: >>> On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila wrote: Other than that, patch looks good and I have

[HACKERS] plan for beta1 & open issues

The PostgreSQL 9.6 release management team has determined that PostgreSQL 9.6beta1 should wrap on May 9, 2016 for release on May 12,2016, subject to the availability of the packaging team to perform a release at that time. The release management team believes that there are no currently-known

Re: [HACKERS] 2016-03 Commitfest

On Mon, Apr 11, 2016 at 8:37 AM, Andreas Karlsson wrote: > On 04/11/2016 01:35 PM, David Steele wrote: >> I've marked this committed so the 2016-03 CF is now complete! > > Thanks to you and everyone else involved in running this CF. You did an > excellent job. Yeah, David

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

On Mon, Apr 11, 2016 at 5:22 AM, Magnus Hagander wrote: > Well, if we *don't* do the rewrite before we release it, then we have to > instead put information about the new version of the functions into the old > structure I think. I think that you should have done that in the

Re: [HACKERS] 'Create table if not exists as' breaks SPI_execute

> On 11 Apr 2016, at 18:41, Stas Kelvich wrote: > > Hi. > > SPI_execute assumes that CreateTableAsStmt always have completionTag == > “completionTag”. > But it isn’t true in case of ‘IF NOT EXISTS’ present. > > > Sorry, I meant completionTag == “SELECT”. -- Stas

[HACKERS] 'Create table if not exists as' breaks SPI_execute

Hi. SPI_execute assumes that CreateTableAsStmt always have completionTag == “completionTag”. But it isn’t true in case of ‘IF NOT EXISTS’ present. spi-cta.patch Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent

[HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Moving over a conversation from the pgsql-advocacy mailing list. In it Simon (CC'd) raised the issue of potentially creating a backwards-compatibility breaking release at some point in the future, to deal with things that might have no other solution (my wording). Relevant part of that thread

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-04-04 12:45:25 -0400, Robert Haas wrote: > Well, I agree that it's pretty strange that _mdfd_getseg() makes no > such check, but I still don't think I understand what's going on here. > Backends shouldn't be requesting nonexistent blocks from a relation - > higher-level safeguards, like

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

On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: > On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada > wrote: >> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: >>> Jeff Janes writes: When I

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/04/11 12:30, Michael Paquier wrote: + if ((cancel = PQgetCancel(entry->conn))) + { + PQcancel(cancel, errbuf, sizeof(errbuf)); + PQfreeCancel(cancel); + } Wouldn't it be

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

On Mon, Apr 11, 2016 at 6:03 AM, Petr Jelinek wrote: > On 10/04/16 20:47, Christian Ullrich wrote: >>> don't think we need to be too precious about saving a byte or two >>> here. Can one or other of you please prepare a replacement patch based >>> in this discussion? So, I

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

On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: > Jeff Janes writes: >> When I compile now without cassert, I get the compiler warning: > >> syncrep.c: In function 'SyncRepUpdateConfig': >> syncrep.c:878:6: warning: variable 'parse_rc' set but not used

Re: [HACKERS] Some other things about contrib/bloom and generic_xlog.c

On Sun, Apr 10, 2016 at 1:49 PM, Tom Lane wrote: > 1. It doesn't seem like generic_xlog.c has thought very carefully about > the semantics of the "hole" between pd_lower and pd_upper. The mainline > XLOG code goes to some lengths to ensure that the hole stays all-zeroes; >

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

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 an ugly > hack, though I am coming to think

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

On Thu, Apr 7, 2016 at 5:15 AM, Noah Misch wrote: > On Wed, Apr 06, 2016 at 09:17:22AM +0200, Magnus Hagander wrote: > > On Wed, Apr 6, 2016 at 6:42 AM, Noah Misch wrote: > > > On Tue, Apr 05, 2016 at 08:15:16PM +0200, Magnus Hagander wrote: > > > > I've

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund wrote: > >> Could you retry after applying the attached series of patches? >> > > Yes, I will try with these patches and snapshot too old

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Mon, 11 Apr 2016 19:25:20 +0200 "Shulgin, Oleksandr" wrote: > On Mon, Apr 11, 2016 at 7:15 PM, Karl O. Pinc wrote: > > > Not sure about the part > > > where you call PQsetSingleRowMode() again after seeing > > > PGRES_TUPLES_OK: doesn't look to

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-11 22:08:15 +0300, Alexander Korotkov wrote: > On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > > > On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund wrote: > > > >> Could you retry after applying the attached series of

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Justin Clift writes: > Moving over a conversation from the pgsql-advocacy mailing list. In it > Simon (CC'd) raised the issue of potentially creating a > backwards-compatibility > breaking release at some point in the future, to deal with things that > might have no

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, Apr 11, 2016 at 3:23 PM, Robbie Harwood wrote: > I'm sure this won't be a popular suggestion, but in the interest of > advocating for more cryptography: if we land GSSAPI auth+encryption, I'd > like the auth-only codepath to go away. I can't think of a reason that

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On Mon, Apr 11, 2016 at 12:50 PM, Andres Freund wrote: > On 2016-04-04 12:45:25 -0400, Robert Haas wrote: >> Well, I agree that it's pretty strange that _mdfd_getseg() makes no >> such check, but I still don't think I understand what's going on here. >> Backends shouldn't be

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Mon, 11 Apr 2016 15:55:53 +0200 "Shulgin, Oleksandr" wrote: > On Fri, Apr 1, 2016 at 7:53 PM, Karl O. Pinc wrote: > > > > On Fri, 1 Apr 2016 05:57:33 +0200 > > "Shulgin, Oleksandr" wrote: > > > > > On Apr 1, 2016

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Mon, Apr 11, 2016 at 7:15 PM, Karl O. Pinc wrote: > > Should I submit a regression test or something to ensure > that this usage is officially supported? (A grep for > PQsetSingleRowMode in src/test/ finds no hits.) > Can I assume because it's documented it'll continue to work?

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-04-11 13:04:48 -0400, Robert Haas wrote: > You're right, but I think that's more because I didn't say it > correctly than because you haven't done something novel. Could be. > DROP and > relation truncation know about shared buffers, and they go clear > blocks that that might be

Re: [HACKERS] pgsql: Add the "snapshot too old" feature

On Mon, Apr 11, 2016 at 8:20 AM, Alexander Korotkov wrote: > 1) We uglify buffer manager interface a lot. This patch adds 3 more > arguments to BufferGetPage(). It looks weird. Should we try to find less > invasive way for doing this? As already pointed out, I

[HACKERS] Remove unused function from walsender.c

Hi, There is an unused function GetOldestWALSendPointer() in walsender.c. Per comment, it was introduced because we may need it in the future for synchronous replication. Now we have very similar function SyncRepGetOldestSyncRecPtr() in syncrep.c. Which makes me think that

[HACKERS] Removing the TRACE_SORT macro

Currently, debug instrumentation for sorting is only available if the TRACE_SORT macro was defined when PostgreSQL was compiled. It is defined by default, and so in practice it's always available; there is really no upside to disabling it. "18.17. Developer Options" notes this restriction for

Re: [HACKERS] Choosing parallel_degree

On 11/04/2016 17:44, Robert Haas wrote: > On Mon, Apr 11, 2016 at 11:27 AM, Julien Rouhaud > wrote: >> On 11/04/2016 15:56, tushar wrote: >>> >>> I am assuming parallel_degree=0 is as same as not using it , i.e >>> create table fok2(n int) with (parallel_degree=0); =

Re: [HACKERS] Speedup twophase transactions

> On 08 Apr 2016, at 16:09, Stas Kelvich wrote: > > Tried on linux and os x 10.11 and 10.4. > > Still can’t reproduce, but have played around with your backtrace. > > I see in xlodump on slave following sequence of records: > > rmgr: Storage len (rec/tot):

Re: [HACKERS] Removing the TRACE_SORT macro

On Mon, Apr 11, 2016 at 4:43 PM, Peter Geoghegan wrote: > Currently, debug instrumentation for sorting is only available if the > TRACE_SORT macro was defined when PostgreSQL was compiled. It is > defined by default, and so in practice it's always available; there is > really no

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-11 14:40:29 -0700, Andres Freund wrote: > On 2016-04-11 12:17:20 -0700, Andres Freund wrote: > > On 2016-04-11 22:08:15 +0300, Alexander Korotkov wrote: > > > On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov < > > > a.korot...@postgrespro.ru> wrote: > > > > > > > On Mon, Apr 11,

Re: [HACKERS] Removing the TRACE_SORT macro

On Mon, Apr 11, 2016 at 2:54 PM, Robert Haas wrote: > I'm not excited about this change. It doesn't really buy us anything > that I can see. For one thing, I think we've arguably got too much > trace_sort output from sorts now and should look to reduce that > instead of

Re: [HACKERS] Remove unused function from walsender.c

On 11 April 2016 at 08:05, Fujii Masao wrote: > There is an unused function GetOldestWALSendPointer() in walsender.c. > Per comment, it was introduced because we may need it in the future for > synchronous replication. > > Now we have very similar function

Re: [HACKERS] Choosing parallel_degree

On 8 April 2016 at 17:27, Paul Ramsey wrote: > PostGIS is just one voice... > We're listening. > >> Functions have very unequal CPU costs, and we're talking here about > >> using CPUs more effectively, why are costs being given the see-no-evil > >> treatment? This

Re: [HACKERS] Removing the TRACE_SORT macro

On 11 April 2016 at 21:43, Peter Geoghegan wrote: > Currently, debug instrumentation for sorting is only available if the > TRACE_SORT macro was defined when PostgreSQL was compiled. It is > defined by default, and so in practice it's always available; there is > really no

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-11 12:17:20 -0700, Andres Freund wrote: > On 2016-04-11 22:08:15 +0300, Alexander Korotkov wrote: > > On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov < > > a.korot...@postgrespro.ru> wrote: > > > > > On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund wrote: > > > >

Re: [HACKERS] Choosing parallel_degree

On 8 April 2016 at 17:49, Robert Haas wrote: > With the patch, you can - if you wish - substitute > some other number for the one the planner comes up with. I saw you're using AccessExclusiveLock, the reason being it affects SELECTs. That is supposed to apply when

Re: [HACKERS] Removing the TRACE_SORT macro

On Mon, Apr 11, 2016 at 2:35 PM, Simon Riggs wrote: > Yeh, sort has changed enough now that fixes weren't going to backpatch > cleanly, so its a good time to do cleanup. I wonder if the category of "Developer Options" is appropriate for trace_sort. trace_sort is closer to

Re: [HACKERS] Preprocessor condition fix

Christian Ullrich writes: > Here is a one-line patch to fix a wrong preprocessor condition in > pg_regress, found because the VS 2015 compiler warns on the cast in the > 32-bit branch where apparently earlier versions did not. Pushed, thanks. > According to git grep,