Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Álvaro: I did document and test the extra types you added, but now that I think about it a bit more, it's hard to argue that it's useful to have a table, for example, depend on an extension. There's really nothing about a table that "doesn't work without" an extension. -- Abhijit -- Sent via pg

Re: [HACKERS] Combining Aggregates

On 5 April 2016 at 05:54, Robert Haas wrote: > On Wed, Mar 30, 2016 at 3:34 PM, David Rowley > wrote: > > I wrote 0002 - 0004, these were reviewed by Tomas. > > 0005 is Haribabu's patch: Reviewed by Tomas and I. > > I think it might be a good idea if these patches made less use of > bytea and ex

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Apr 4, 2016 at 2:28 PM, Andres Freund wrote: > Hm, interesting. I suspect that's because of the missing backoff in my > experimental patch. If you apply the attached patch ontop of that > (requires infrastructure from pinunpin), how does performance develop? > I have applied this patch a

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

On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao wrote: > > > Thanks for updating the patch! > > I applied the following changes to the patch. > Attached is the revised version of the patch. > 1. { {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_MASTER, gettext_noop("List of names of pote

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

On 4 April 2016 at 10:35, Simon Riggs wrote: > On 4 April 2016 at 09:28, Fujii Masao wrote: > > >> Barring any objections, I'll commit this patch. >> > > That sounds good. > > May I have one more day to review this? Actually more like 3-4 hours. > What we have here is useful and elegant. I love

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

At 2016-04-05 12:33:56 +0530, a...@2ndquadrant.com wrote: > > Álvaro: I did document and test the extra types you added, but now > that I think about it a bit more, it's hard to argue that it's useful > to have a table, for example, depend on an extension. There's really > nothing about a table tha

Re: [HACKERS] Timeline following for logical slots

On 5 April 2016 at 04:00, Robert Haas wrote: > > In general, I think we'd be a lot better off if we got some kind of > logical replication into core first and then worked on lifting these > types of limitations afterwards. First, I'd like to remind everyone that logical decoding is useful for m

Re: [HACKERS] Combining Aggregates

On 5 April 2016 at 16:54, Robert Haas wrote: > On Wed, Mar 30, 2016 at 3:34 PM, David Rowley > wrote: >> I wrote 0002 - 0004, these were reviewed by Tomas. >> 0005 is Haribabu's patch: Reviewed by Tomas and I. > > I think it might be a good idea if these patches made less use of > bytea and expos

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

On 2016/04/05 16:35, Simon Riggs wrote: > 6. Meaning of k (n1, n2, n3) with N servers > > It's clearly documented that this means k replies IN SEQUENCE. I believe > the typical meaning of would be “any k out of N”, which would be faster > than what we have, e.g. >3 (n1, n2, n3) would release a

Re: [HACKERS] Timeline following for logical slots

On 5 April 2016 at 14:18, Peter Geoghegan wrote: > > I rather agree that an in-core system that solved some of the basic > problems would be a huge step forward, and would motivate people to > work on the harder problems. It's surprising to me that we don't seem > to be much closer to that then

Re: [HACKERS] Timeline following for logical slots

On 2016-04-05 15:51:00 +0800, Craig Ringer wrote: > Review and test responses have been pretty underwhelming for pglogical, and > quite a bit seem to have boiled down to "this should live as an extension, > we don't need it in core". It often feels like we can't win: if we seek to > get it into cor

Re: [HACKERS] Odd oid-system-column handling in postgres_fdw

On 2016/03/16 16:25, Etsuro Fujita wrote: > PG9.5 allows us to add an oid system column to foreign tables, using > ALTER FOREIGN TABLE SET WITH OIDS, but currently, that column reads as > zeroes in postgres_fdw. That seems to me like a bug. So, I'd like to > propose to fix that, by retrieving tha

[HACKERS] Typo in src/interfaces/libpq/fe-connect.c

Hi, I ran into a typo in src/interfaces/libpq/fe-connect.c: s/PQcancelGet/PQgetCancel/ Attached is a patch to fis that typo. Best regards, Etsuro Fujita diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c index 5ad4755..9b2839b 100644 --- a/src/interfaces/libpq/fe-

Re: [HACKERS] raw output from copy

Hi here is cleaned/finished previous implementation of RAW_TEXT/RAW_BINARY formats for COPY statements. The RAW with text formats means unescaped data, but with correct encoding - input/output is realised with input/output function. RAW binary means content produced/received by sending/received f

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

On Mon, Apr 4, 2016 at 5:59 PM, Abhijit Menon-Sen wrote: > At 2016-04-04 17:28:07 +0900, masao.fu...@gmail.com wrote: >> >> Barring any objections, I'll commit this patch. > > No objections, just a minor wording tweak: > > doc/src/sgml/config.sgml: > > "The synchronous standbys will be the standby

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

With this patch, all instances of tableoid, cmin, cmax etc. will get a non-NULL value irrespective of whether they appear on nullable side of the join or not. e.g. select t1.c1, t1.tableoid, t2.c1, t2.tableoid from ft4 t1 left join ft5 t2 on (t1.c1 = t2.c1); run in contrib_regression gives output

Re: [HACKERS] Typo in src/interfaces/libpq/fe-connect.c

On Tue, Apr 5, 2016 at 10:34 AM, Etsuro Fujita wrote: > Hi, > > I ran into a typo in src/interfaces/libpq/fe-connect.c: > s/PQcancelGet/PQgetCancel/ Attached is a patch to fis that typo. > Applied, thanks. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com

Re: [HACKERS] Yet another small patch - reorderbuffer.c:1099

> I recall discussing this code with Andres, and I think that he has > mentioned me this is intentional, because should things be changed for > a reason or another in the future, we want to keep in mind that a list > of TXIDs and a list of sub-TXIDs should be handled differently. I see. If this it

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

On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada wrote: > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI > wrote: >> Hello, thank you for testing. >> >> At Sat, 2 Apr 2016 14:20:55 +1300, Thomas Munro >> wrote in >> >>> >>> Attached latest patch incorporate some review comments so far, and

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

On 5 April 2016 at 08:58, Amit Langote wrote: > So I am suggesting we put an extra keyword in front of the “k”, to > > explain how the k responses should be gathered as an extension to the the > > syntax. I also think implementing “any k” is actually fairly trivial and > > could be done for

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

On Mon, Apr 4, 2016 at 6:45 PM, Andres Freund wrote: > On 2016-04-04 10:35:34 +0100, Simon Riggs wrote: >> On 4 April 2016 at 09:28, Fujii Masao wrote: >> > Barring any objections, I'll commit this patch. > > No objection here either, just one question: Has anybody thought about > the ability to

Re: [HACKERS] Yet another small patch - reorderbuffer.c:1099

On 2016-04-05 12:07:40 +0300, Aleksander Alekseev wrote: > > I recall discussing this code with Andres, and I think that he has > > mentioned me this is intentional, because should things be changed for > > a reason or another in the future, we want to keep in mind that a list > > of TXIDs and a li

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

On 5 April 2016 at 10:10, Fujii Masao wrote: > On Mon, Apr 4, 2016 at 6:45 PM, Andres Freund wrote: > > On 2016-04-04 10:35:34 +0100, Simon Riggs wrote: > >> On 4 April 2016 at 09:28, Fujii Masao wrote: > >> > Barring any objections, I'll commit this patch. > > > > No objection here either, jus

Re: [HACKERS] Yet another small patch - reorderbuffer.c:1099

On 5 April 2016 at 10:12, Andres Freund wrote: > On 2016-04-05 12:07:40 +0300, Aleksander Alekseev wrote: > > > I recall discussing this code with Andres, and I think that he has > > > mentioned me this is intentional, because should things be changed for > > > a reason or another in the future,

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

On 2016-04-05 10:13:50 +0100, Simon Riggs wrote: > The lack of per-database settings is not a blocker for me. Just to clarify: Neither is it for me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgs

Re: [HACKERS] Timeline following for logical slots

> On 05 Apr 2016, at 09:51, Craig Ringer wrote: > > On 5 April 2016 at 04:00, Robert Haas > wrote: > > In general, I think we'd be a lot better off if we got some kind of > logical replication into core first and then worked on lifting these > types of limitations

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

On Tue, Apr 5, 2016 at 4:31 PM, Amit Kapila wrote: > On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao wrote: >> >> >> Thanks for updating the patch! >> >> I applied the following changes to the patch. >> Attached is the revised version of the patch. >> > > 1. >{ > {"synchronous_standby_names",

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

At Tue, 5 Apr 2016 14:24:52 +0900, Amit Langote wrote in <57034c24.1000...@lab.ntt.co.jp> > On 2016/04/05 0:23, Tom Lane wrote: > > Amit Langote writes: > >> On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane wrote: > >>> A related issue, now that I've seen this example, is that altering > >>> FDW-level

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

At Tue, 5 Apr 2016 18:08:20 +0900, Fujii Masao wrote in > On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada > wrote: > > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI > > wrote: > >> Hello, thank you for testing. > >> > >> At Sat, 2 Apr 2016 14:20:55 +1300, Thomas Munro > >> wrote in >

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

On Tue, Apr 5, 2016 at 4:35 PM, Simon Riggs wrote: > On 4 April 2016 at 10:35, Simon Riggs wrote: >> >> On 4 April 2016 at 09:28, Fujii Masao wrote: >> >>> >>> Barring any objections, I'll commit this patch. >> >> >> That sounds good. >> >> May I have one more day to review this? Actually more l

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

At Mon, 4 Apr 2016 22:00:24 +0900, Masahiko Sawada wrote in > > For this case, the tree members of SyncRepConfig are '2[Sby1,', > > 'Sby2', "Sby3]'. This syntax is valid for the current > > specification but will surely get different meaning by the future > > changes. We should refuse this known

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

On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs wrote: > On 5 April 2016 at 08:58, Amit Langote > wrote: > >> >> So I am suggesting we put an extra keyword in front of the “k”, to >> > explain how the k responses should be gathered as an extension to the >> > the >> > syntax. I also think implem

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On 2016/04/05 18:44, Kyotaro HORIGUCHI wrote: > At Tue, 5 Apr 2016 14:24:52 +0900, Amit Langote wrote: >> On 2016/04/05 0:23, Tom Lane wrote: >>> Amit Langote writes: Hm, some kind of PlanInvalItem-based solution could work maybe? >>> >>> Hm, so we'd expect that whenever an FDW consulted the

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

On 5 April 2016 at 11:18, Fujii Masao wrote: > > 1. Header comments in syncrep.c need changes, not just additions. > > Okay, will consider this later. And I'd appreciate if you elaborate what > changes are necessary specifically. Some of the old header comments are now wrong. > > 2. We need

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

On Tue, Apr 5, 2016 at 7:17 PM, Kyotaro HORIGUCHI wrote: > At Tue, 5 Apr 2016 18:08:20 +0900, Fujii Masao wrote > in >> On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada >> wrote: >> > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI >> > wrote: >> >> Hello, thank you for testing. >> >> >> >

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

On 5 April 2016 at 11:23, Fujii Masao wrote: > On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs wrote: > > On 5 April 2016 at 08:58, Amit Langote > > wrote: > > > >> > >> So I am suggesting we put an extra keyword in front of the “k”, to > >> > explain how the k responses should be gathered as

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

On Tue, Apr 5, 2016 at 8:08 PM, Simon Riggs wrote: > On 5 April 2016 at 11:18, Fujii Masao wrote: > >> >> > 1. Header comments in syncrep.c need changes, not just additions. >> >> Okay, will consider this later. And I'd appreciate if you elaborate what >> changes are necessary specifically. > > >

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

Hi, On 04/04/2016 02:25 PM, Tomas Vondra wrote: On 04/04/2016 02:06 PM, Teodor Sigaev wrote: The above-described topic is currently a PostgreSQL 9.6 open item. Teodor, since you committed the patch believed to have created it, you own this open item. If that responsibility lies elsewhere, plea

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

On 5 April 2016 at 12:26, Fujii Masao wrote: > Multiple standbys with the same name may connect to the master. > In this case, users might want to specifiy k<=N. So k<=N seems not invalid > setting. Confusing as that is, it is already the case; k > N could make sense. ;-( However, in most cas

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

On Mon, Apr 4, 2016 at 3:15 PM, Amit Kapila wrote: > On Mon, Apr 4, 2016 at 4:31 PM, Magnus Hagander > wrote: > >> On Fri, Apr 1, 2016 at 6:47 AM, Amit Kapila >> wrote: >> >> >>> Also, I think below part of documentation for pg_start_backup() needs to >>> be modified: >>> >>> >>> >>> pg_st

Re: [HACKERS] Combining Aggregates

On Tue, Apr 5, 2016 at 3:55 AM, David Rowley wrote: >> I think it might be a good idea if these patches made less use of >> bytea and exposed the numeric transition values as, say, a 2-element >> array of numeric. > > Well, if you have a look at NumericAggState you can see it's not quite > as simp

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

On 4/5/16 8:05 AM, Magnus Hagander wrote: PFA a better one (I think), also with the rename and added comments that David was asking for. Barring objections, I will apply this version. This version looks good to me. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] So, can we stop supporting Windows native now?

On Wed, Mar 30, 2016 at 6:49 PM, Josh berkus wrote: > http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/ > > ... could be good news for us ... This is nothing new. Windows has had a unix subsystem (Interix AKA Windows Services for Unix) for quite some tim

Re: [HACKERS] Combining Aggregates

On 6 April 2016 at 01:01, Robert Haas wrote: > On Tue, Apr 5, 2016 at 3:55 AM, David Rowley >> To be really honest, I'm quite worried that if I go and make this >> change then my time might be wasted as I really think making that >> change this late in the day is just setting this up for failure.

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Abhijit Menon-Sen wrote: > At 2016-04-05 12:33:56 +0530, a...@2ndquadrant.com wrote: > > > > Álvaro: I did document and test the extra types you added, but now > > that I think about it a bit more, it's hard to argue that it's useful > > to have a table, for example, depend on an extension. There's

Re: [HACKERS] Combining Aggregates

On Tue, Apr 5, 2016 at 9:30 AM, David Rowley wrote: > On 6 April 2016 at 01:01, Robert Haas wrote: >> On Tue, Apr 5, 2016 at 3:55 AM, David Rowley >>> To be really honest, I'm quite worried that if I go and make this >>> change then my time might be wasted as I really think making that >>> change

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Apr 5, 2016 at 10:26 AM, Dilip Kumar wrote: > > On Mon, Apr 4, 2016 at 2:28 PM, Andres Freund wrote: > >> Hm, interesting. I suspect that's because of the missing backoff in my >> experimental patch. If you apply the attached patch ontop of that >> (requires infrastructure from pinunpin)

Re: [HACKERS] Yet another small patch - reorderbuffer.c:1099

Simon Riggs wrote: > On 5 April 2016 at 10:12, Andres Freund wrote: > > > On 2016-04-05 12:07:40 +0300, Aleksander Alekseev wrote: > > > > I recall discussing this code with Andres, and I think that he has > > > > mentioned me this is intentional, because should things be changed for > > > > a re

Re: [HACKERS] oversight in parallel aggregate

On Mon, Apr 4, 2016 at 10:26 PM, David Rowley wrote: > Does this need to check the parallel flags on the transfn or serialfn? > these'll be executed on the worker process. Possibly we also need the > combinefn/deserialfn/finalfn to be checked too as I see that we do > generate_gather_paths() from

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-05 17:36:49 +0300, Alexander Korotkov wrote: > Could the reason be that we're increasing concurrency for LWLock state > atomic variable by placing queue spinlock there? Don't think so, it's the same cache-line either way. > But I wonder why this could happen during "pgbench -S", becaus

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

On Tue, Apr 5, 2016 at 3:15 PM, Fujii Masao wrote: > > On Tue, Apr 5, 2016 at 4:31 PM, Amit Kapila wrote: > > On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao wrote: > >> > >> > >> Thanks for updating the patch! > >> > >> I applied the following changes to the patch. > >> Attached is the revised vers

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

On Mon, Apr 4, 2016 at 4:28 AM, Fujii Masao wrote: >>> + ereport(LOG, >>> + (errmsg("standby \"%s\" is now the synchronous standby with priority %u", >>> + application_name, MyWalSnd->sync_standby_priority))); >>> >>> s/ the / a / > > I have no objection to this change itself. But we have used thi

Re: [HACKERS] WIP: Covering + unique indexes.

05.04.2016 01:48, Peter Geoghegan : On Mon, Mar 21, 2016 at 9:53 AM, Anastasia Lubennikova wrote: It's a bit more complicated to add it into index creation algorithm. There's a trick with a "high key". /* * We copy the last item on the page into the new page, and then

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

On Tue, Apr 5, 2016 at 7:23 PM, Kyotaro HORIGUCHI wrote: > At Mon, 4 Apr 2016 22:00:24 +0900, Masahiko Sawada > wrote in >> > For this case, the tree members of SyncRepConfig are '2[Sby1,', >> > 'Sby2', "Sby3]'. This syntax is valid for the current >> > specification but will surely get differe

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Apr 5, 2016 at 8:15 PM, Andres Freund wrote: > > On 2016-04-05 17:36:49 +0300, Alexander Korotkov wrote: > > Could the reason be that we're increasing concurrency for LWLock state > > atomic variable by placing queue spinlock there? > > Don't think so, it's the same cache-line either way.

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-05 20:56:31 +0530, Amit Kapila wrote: > This fluctuation started appearing after commit 6150a1b0 which we have > discussed in another thread [1] and a colleague of mine is working on to > write a patch to try to revert it on current HEAD and then see the results. I don't see what that b

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 03/31/2016 09:00 AM, Dmitry Dolgov wrote: On 31 March 2016 at 17:31, Vitaly Burovoy > wrote: it is logical to insert new value if "before", then current value, then new value if "after". Oh, I see now. There is a slightly different logic: `v` i

Re: [HACKERS] Sequence Access Method WIP

On 04/04/16 15:53, Fabrízio de Royes Mello wrote: On Thu, Mar 31, 2016 at 9:19 AM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > Hi, > > new version attached that should fix the issue. It was alignment - honestly don't know what I was thinking using fixed alignment when the AMs can

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Apr 5, 2016 at 9:00 PM, Andres Freund wrote: > > On 2016-04-05 20:56:31 +0530, Amit Kapila wrote: > > This fluctuation started appearing after commit 6150a1b0 which we have > > discussed in another thread [1] and a colleague of mine is working on to > > write a patch to try to revert it on

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

On Tue, Apr 5, 2016 at 5:35 PM, Magnus Hagander wrote: > > > On Mon, Apr 4, 2016 at 3:15 PM, Amit Kapila > wrote: > >> On Mon, Apr 4, 2016 at 4:31 PM, Magnus Hagander >> wrote: >> >>> On Fri, Apr 1, 2016 at 6:47 AM, Amit Kapila >>> wrote: >>> >>> Also, I think below part of documentation

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

> It seems that everything is settled now, so here's the patch introducing the > '<->' and '' operators. I've made the necessary changes to docs & > regression tests. I noticed that I had accidently trimmed whitespaces in docs, this is a better one. -- Dmitry Ivanov Postgres Professional: http:

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Apr 5, 2016 at 11:30 AM, Andres Freund wrote: > On 2016-04-05 20:56:31 +0530, Amit Kapila wrote: >> This fluctuation started appearing after commit 6150a1b0 which we have >> discussed in another thread [1] and a colleague of mine is working on to >> write a patch to try to revert it on cur

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

I've been asked to look at and comment on the SQL API of the feature. I think it's basically sound, although there is one thing that's not clear from the regression tests: what happens if we're inserting into an object and the key already exists? e.g.: select jsonb_insert('{"a": {"b": "value"}}',

[HACKERS] LOCK TABLE .. DEFERRABLE

The intention of this feature is to give the ability to slip into a normal workload for non-urgent maintenance work. In essence, instead of lock waiters being in a Queue, DEFERRABLE causes the current lock statement to always be last. It was discussed at last years pgCon as useful for replication t

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

Andrew Dunstan wrote: > I haven't been following this thread due to pressure of time, so my > apologies in advance if these comments have already been covered. > > I've been asked to look at and comment on the SQL API of the feature. I > think it's basically sound, although there is one thing tha

Re: [HACKERS] Relation extension scalability

On Thu, Mar 31, 2016 at 9:03 AM, Dilip Kumar wrote: > If you need some more information please let me know ? I repeated the testing described in http://www.postgresql.org/message-id/ca+tgmoyouqf9cgcpgygngzqhcy-gcckryaqqtdu8kfe4n6h...@mail.gmail.com on a MacBook Pro (OS X 10.8.5, 2.4 GHz Intel Cor

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-04-05 12:14:35 -0400, Robert Haas wrote: > On Tue, Apr 5, 2016 at 11:30 AM, Andres Freund wrote: > > On 2016-04-05 20:56:31 +0530, Amit Kapila wrote: > >> This fluctuation started appearing after commit 6150a1b0 which we have > >> discussed in another thread [1] and a colleague of mine is

Re: [HACKERS] Relation extension scalability

On Tue, Apr 5, 2016 at 10:02 AM, Robert Haas wrote: > So the first thing here is that the patch seems to be a clear win in > this test. For a single copy, it seems to be pretty much a wash. > When running 4 copies in parallel, it is about 20-25% faster with both > logged and unlogged tables. The

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 04/05/2016 12:42 PM, Teodor Sigaev wrote: I've been asked to look at and comment on the SQL API of the feature. I think it's basically sound, although there is one thing that's not clear from the regression tests: what happens if we're inserting into an object and the key already exists?

Re: [HACKERS] LOCK TABLE .. DEFERRABLE

On 5 April 2016 at 17:43, Rod Taylor wrote: > The intention of this feature is to give the ability to slip into a normal > workload for non-urgent maintenance work. In essence, instead of lock > waiters being in a Queue, DEFERRABLE causes the current lock statement to > always be last. > Good id

Re: [HACKERS] LOCK TABLE .. DEFERRABLE

On 2016-04-05 18:10:11 +0100, Simon Riggs wrote: > I'd prefer to see this as a lock wait mode where it sits in the normal lock > queue BUT other lock requestors are allowed to queue jump past it. That > should be just a few lines changed in the lock conflict checker and some > sleight of hand in th

Re: [HACKERS] LOCK TABLE .. DEFERRABLE

On Tue, Apr 5, 2016 at 1:10 PM, Simon Riggs wrote: > If a lock is successfully obtained on one table, but not on all tables, it >> releases that lock and will retry to get them as a group in the future. >> Since inheritance acts as a group of tables (top + recursive cascade to >> children), this

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

OK, thanks for the clarification. Here's the earlier patch, but with the relevant added docs and tests retained. -- Abhijit >From dfb6ded15246ec65cc911864bfcff285eef1c4d4 Mon Sep 17 00:00:00 2001 From: Abhijit Menon-Sen Date: Tue, 5 Apr 2016 11:55:09 +0530 Subject: =?UTF-8?q?Implement=20"ALTER=20

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Michael Paquier writes: > On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote: >> Here's v12, both here and on my github: >> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12 >> > +#ifdef ENABLE_GSS > + { > + MemoryContext save = CurrentMemoryContext; > + Curren

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

On Tue, Apr 5, 2016 at 5:57 PM, Amit Kapila wrote: > On Tue, Apr 5, 2016 at 5:35 PM, Magnus Hagander > wrote: > >> >> >> On Mon, Apr 4, 2016 at 3:15 PM, Amit Kapila >> wrote: >> >>> On Mon, Apr 4, 2016 at 4:31 PM, Magnus Hagander >>> wrote: >>> On Fri, Apr 1, 2016 at 6:47 AM, Amit Kapila

Re: [HACKERS] Choosing parallel_degree

On 05/04/2016 06:19, Amit Kapila wrote: > > Few more comments: > > 1. > @@ -909,6 +909,17 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | > UNLOGGED ] TABLE [ IF NOT EXI > > > > > +parallel_degree (integer) > + > + > > + Sets the degree of parallelism for an in

Re: [HACKERS] Combining Aggregates

On Tue, Apr 5, 2016 at 10:19 AM, Robert Haas wrote: > I'm going to concede the point that this shouldn't really be a > priority for 9.6, but I might want to come back to it later. It seems to me that if two aggregates are using the same transition function, they ought to also be using the same co

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Apr 5, 2016 at 1:04 PM, Andres Freund wrote: > On 2016-04-05 12:14:35 -0400, Robert Haas wrote: >> On Tue, Apr 5, 2016 at 11:30 AM, Andres Freund wrote: >> > On 2016-04-05 20:56:31 +0530, Amit Kapila wrote: >> >> This fluctuation started appearing after commit 6150a1b0 which we have >> >>

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Robbie Harwood wrote: > Michael Paquier writes: > > > On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote: > >> Here's v12, both here and on my github: > >> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12 > > So you are saving everything in the top memory context. I am fin

Re: [HACKERS] Combining Aggregates

Robert Haas wrote: > Now, let's suppose that the user sets up a sharded table and then > says: SELECT a, SUM(b), AVG(c) FROM sometab. At this point, what we'd > like to have happen is that for each child foreign table, we go and > fetch partially aggregated results. Those children might be runni

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko writes: > Any comments on this patch? I felt that this was more nearly a bug fix than a new feature, so I picked it up even though it's nominally in the next commitfest not the current one. I did not like the code too much as it stood: you were not being paranoid enough about

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

Andrew Dunstan writes: > On 04/05/2016 12:42 PM, Teodor Sigaev wrote: >> I'm agree about covering this case by tests, but I think it should be >> allowed. >> In this case it will work exactly as jsbonb_set > It seems to me a violation of POLA to allow something called "insert" to > do a "replac

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Abhijit Menon-Sen wrote: > OK, thanks for the clarification. Here's the earlier patch, but with > the relevant added docs and tests retained. I'd like to add indexes and materialized views to the set of objects covered (functions and triggers). I'm already doing that, so no need to resubmit; it s

Re: [HACKERS] Combining Aggregates

On Tue, Apr 5, 2016 at 2:52 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> Now, let's suppose that the user sets up a sharded table and then >> says: SELECT a, SUM(b), AVG(c) FROM sometab. At this point, what we'd >> like to have happen is that for each child foreign table, we go and >> fetch

Re: [HACKERS] pgbench more operators & functions

Please note that the checkpointer patch has two open items that perhaps you can help with --- see https://wiki.postgresql.org/wiki/Open_Items Indeed, I just looked at the commitfest, and I did not notice the other threads. I do not have an OSX available, but I'll have a look at the other on

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

On Fri, Mar 25, 2016 at 12:47 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote: >>> Robert Haas writes: It's stupid that we keep spending time and energy figuring out which shared memory data structures require alignment and which ones don't

[HACKERS] Unused macros in src/include/access/transam.h

Hi all, When dealing with some patch review I've noticed there are two macro is not used anywhere: #define TransactionIdStore(xid, dest) (*(dest) = (xid)) #define StoreInvalidTransactionId(dest) (*(dest) = InvalidTransactionId) Regards, -- Fabrízio de Royes Mello Consultoria/Coaching Postgre

Re: [HACKERS] oversight in parallel aggregate

On Mon, Apr 4, 2016 at 9:09 PM, David Rowley wrote: > On 5 April 2016 at 11:59, Robert Haas wrote: >> One of my EDB colleagues, while in the process of refactoring some >> unrelated Advanced Server code, discovered that (1) there's no way to >> mark an aggregate as anything other than parallel-un

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Alvaro Herrera writes: > Robbie Harwood wrote: >> Michael Paquier writes: >> >> > On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote: >> >> Here's v12, both here and on my github: >> >> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12 > >> > So you are saving everything i

Re: [HACKERS] WIP: Covering + unique indexes.

On Tue, Apr 5, 2016 at 7:56 AM, Anastasia Lubennikova wrote: > I would say, this is changed, but it doesn't matter. Actually, I would now say that it hasn't really changed (see below), based on my new understanding. The *choice* to go on one page or the other still exists. > Performing any searc

Re: [HACKERS] Yet another small patch - reorderbuffer.c:1099

On Tue, Apr 5, 2016 at 10:38 AM, Alvaro Herrera wrote: > IMO the code is wrong. There should be a single block comment saying > something like "Remove the node from its containing list. In the FOO > case, the list corresponds to BAR and therefore we delete it because > BAZ. In the QUUX case the

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

On 4/5/16 1:25 AM, Michael Paquier wrote: > Btw, those seem like small things to me, and my comments have been > addressed, so I have switched the patch as ready for committer. I > guess that Stephen would be the one to look at it. I have also run this patch through my tests and didn't find any p

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Robbie Harwood wrote: > Alvaro Herrera writes: > > It seems to me that the right solution for this is to create a new > > memory context which is a direct child of TopMemoryContext, so that > > palloc can be used, and so that it can be reset separately, and that it > > doesn't suffer from resets

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

On Tue, Apr 5, 2016 at 7:58 PM, Robbie Harwood wrote: > > -#if defined(WIN32) && !defined(WIN32_ONLY_COMPILER) > > -/* > > - * MIT Kerberos GSSAPI DLL doesn't properly export the symbols for MingW > > - * that contain the OIDs required. Redefine here, values copied > > - * from src/athena/auth/kr

Re: [HACKERS] large regression for parallel COPY

On Wed, Mar 30, 2016 at 4:10 PM, Andres Freund wrote: > Indeed. On SSDs I see about a 25-35% gain, on HDDs about 5%. If I > increase the size of backend_flush_after to 64 (like it's for bgwriter) > I however do get about 15% for HDDs as well. I tried the same test mentioned in the original post o

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 04/05/2016 03:08 PM, Tom Lane wrote: I think there is potentially some use-case for insert-only semantics for an object target, if you want to be sure you're not overwriting data. So I think "throw an error on duplicate key" is marginally better than "reject object target altogether". But

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Alvaro Herrera wrote: > Abhijit Menon-Sen wrote: > > OK, thanks for the clarification. Here's the earlier patch, but with > > the relevant added docs and tests retained. > > I'd like to add indexes and materialized views to the set of objects > covered (functions and triggers). I'm already doing

[HACKERS] Materialized views vs. primary keys

Folks, Is there a reason other than lack of tuits for this restriction? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.po

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

On Wed, Apr 6, 2016 at 6:15 AM, Magnus Hagander wrote: > On Tue, Apr 5, 2016 at 7:58 PM, Robbie Harwood wrote: >> >> > -#if defined(WIN32) && !defined(WIN32_ONLY_COMPILER) >> > -/* >> > - * MIT Kerberos GSSAPI DLL doesn't properly export the symbols for >> > MingW >> > - * that contain the OIDs r

Re: [HACKERS] Materialized views vs. primary keys

On Tue, Apr 5, 2016 at 6:50 PM, David Fetter wrote: > Is there a reason other than lack of tuits for this restriction? "this" lacks an antecedent. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@

  1   2   >