Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

Michael Paquier wrote: > After sleeping on it, I have put my hands on the postgres_fdw portion and > came up with a largely > simplified flow, resulting in the patch attached. [...] > Ronan, what do you think of those patches? I have nothing more to add, and I > think that they should be > look

Re: [HACKERS] inherit support for foreign tables

On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita wrote: > (2014/07/01 15:13), Ashutosh Bapat wrote: > >> On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> > > We may want to modify use_physical_tlist(), to return false, in case of >> foreign tables. BT

[HACKERS] debugging with child process

hi, can any one help me with the 4th and 5th steps of the following link which is to debug with a child process in postgres. *https://wiki.postgresql.org/wiki/Working_with_Eclipse#Debugging_with_child_processes

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

Le mardi 1 juillet 2014 06:59:49 Albe Laurenz a écrit : > Michael Paquier wrote: > > > After sleeping on it, I have put my hands on the postgres_fdw portion and > > came up with a largely simplified flow, resulting in the patch attached. > > > [...] > > > > Ronan, what do you think of those p

Re: [HACKERS] inherit support for foreign tables

(2014/07/01 16:04), Ashutosh Bapat wrote: On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: Maybe I'm missing something, but what's the point of using the tlist, not reltargetlist? Compliance with other create_*scan_plan() functions. The tlis

Re: [HACKERS] RLS Design

On 29 June 2014 20:42, Stephen Frost wrote: > To try and clarify what this distinction is- > > Dean's approach with GRANT allows specifying the policy to be > used when a given role queries a given table. Through this mechanism, > one role might have access to many different tables, possibly with

Re: [HACKERS] inherit support for foreign tables

Hi, At Tue, 01 Jul 2014 16:30:41 +0900, Etsuro Fujita wrote in <53b263a1.3060...@lab.ntt.co.jp> > I've got the point. > > As I said upthread, I'll work on calculating attr_needed for child > rels, and I hope that that will eliminate your concern. Inheritance tree is expanded far after where a

Re: [HACKERS] Autonomous Transaction (WIP)

On 01 July 2014 12:26, Pavel Stehule Wrote: >>Have you checked the discussion in Developer meeting notes. Please >>check the same at below link: >>http://wiki.postgresql.org/wiki/PgCon_2012_Developer_Meeting#Autonomous_Transactions >Are these notes still valid? >* Why autonomous transaction shoul

Re: [HACKERS] Autonomous Transaction (WIP)

2014-07-01 10:38 GMT+02:00 Rajeev rastogi : > On 01 July 2014 12:26, Pavel Stehule Wrote: > > > > >>Have you checked the discussion in Developer meeting notes. Please > > >>check the same at below link: > > >> > http://wiki.postgresql.org/wiki/PgCon_2012_Developer_Meeting#Autonomous_Transactions

Re: [HACKERS] NUMA packaging and patch

Re: Kevin Grittner 2014-06-09 <1402267501.4.yahoomail...@web122304.mail.ne1.yahoo.com> > @@ -536,6 +539,24 @@ PGSharedMemoryCreate(Size size, bool makePrivate, int > port, >*/ > } > > +#ifdef USE_LIBNUMA > + /* > + * If this is not a private segment and we are

Re: [HACKERS] Array of composite types returned from python

Le dimanche 29 juin 2014 16:54:03 Tom Lane a écrit : > Abhijit Menon-Sen writes: > >> 3) This is such a simple change with no new infrastructure code > >> (PLyObject_ToComposite already exists). Can you think of a reason > >> why this wasn't done until now? Was it a simple miss or purposefully > >

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-30 22:44:58 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund wrote: > > On 2014-06-30 19:22:59 +0200, Andres Freund wrote: > >> On 2014-06-30 12:46:29 -0400, Robert Haas wrote: > >> >, which if I understand you correctly are ARM without GCC > >> > atomics, Spar

Re: [HACKERS] Wait free LW_SHARED acquisition

Hi, Over at -performance Mark Kirkwood tested a recent version of this (http://archives.postgresql.org/message-id/53B283F3.7020005%40catalyst.net.nz) . I thought it's interesting to add the numbers to this thread: > Test: pgbench > Options: scale 500 > read only > Os: Ubuntu 14.04 > Pg:

Re: [HACKERS] WAL replay bugs

Hello, I had a look on this patch. Let me show you some comments about the README, Makefile and buffer_capture_cmp of the second part for the present. A continuation of this comment would be seen later.. - contrib/buffer_capture_cmp/README - 'contains' seems duplicate in the first paragraph.

Re: [HACKERS] better atomics - v0.5

On 2014-07-01 10:44:19 +0530, Amit Kapila wrote: > I think for such usage, we need to rely on barriers wherever there is a > need for synchronisation, recent example I have noticed is in your patch > where we have to use pg_write_barrier() during wakeup. However if we > go by atomic ops definition

Re: [HACKERS] NUMA packaging and patch

On 2014-07-01 11:01:04 +0200, Christoph Berg wrote: > Re: Kevin Grittner 2014-06-09 > <1402267501.4.yahoomail...@web122304.mail.ne1.yahoo.com> > > @@ -536,6 +539,24 @@ PGSharedMemoryCreate(Size size, bool makePrivate, int > > port, > > */ > > } > > > > +#ifdef USE_LIBNUMA >

Re: [HACKERS] NUMA packaging and patch

Andres Freund wrote: > On 2014-07-01 11:01:04 +0200, Christoph Berg wrote: >> How much difference would it make if numactl --interleave=all >> was used instead of using numa_interleave_memory() on the shared >> memory segments? I guess that would make backend-local memory >> also interleaved, but

Re: [HACKERS] Wait free LW_SHARED acquisition

On 07/01/2014 01:08 PM, Andres Freund wrote: Hi, Over at -performance Mark Kirkwood tested a recent version of this (http://archives.postgresql.org/message-id/53B283F3.7020005%40catalyst.net.nz) . I thought it's interesting to add the numbers to this thread: Test: pgbench Options: scale 500

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

I spent some more time on the patch and here are my review comments. .) Patch gets applied through patch -p1 (git apply fails) .) trailing whitespace in the patch at various places .) Unnecessary new line + and - in the patch. (src/backend/rewrite/rewriteManip.c::getInsertSelectQuery()) (src/inc

Re: [HACKERS] NUMA packaging and patch

Re: Kevin Grittner 2014-07-01 <1404213492.98740.yahoomail...@web122306.mail.ne1.yahoo.com> > Andres Freund wrote: > > On 2014-07-01 11:01:04 +0200, Christoph Berg wrote: > > >> How much difference would it make if numactl --interleave=all > >> was used instead of using numa_interleave_memory() o

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

On Tue, Jul 1, 2014 at 4:23 PM, Ronan Dunklau wrote: > The remote_schema parameter can be used for SQL injection. Either we > should go > back to using parameters, or be extra careful. Since the remote schema is > parsed as a name, it is limited to 64 characters which is not that useful > for > a

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Re: Tom Lane 2014-06-23 <17054.1403542...@sss.pgh.pa.us> > > While I'd love to reduce the number of future installations without > > this fix in place, I respect the decision to honor project policy. At > > the same time, this change does not break anything. It introduces new > > environment variab

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 6/29/14, 12:20 PM, Tom Lane wrote: > I'm tempted to just rip out all the useless code rather than fix the > logic bug as such. OTOH, that might complicate updating to more recent > versions of the original Autoconf macro. On the third hand, we've not > bothered to do that in ten years either.

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

I'm sorry to interrupt you, but I feel strong sympathy with Stephen-san. From: "Robert Haas" I don't think that's a valid objection. If we someday have auditing in core, and if it subsumes what pgaudit does, then whatever interfaces pgaudit implements can be replaced with wrappers around the c

Re: [HACKERS] Fresh initdb contains a few deleted B-Tree pages

Why is this even a small concern? Initdb runs the bootstrap SQL which does various SQL operations so it's not surprising there are some updates creating garbage. Iirc we don't even rely on template0 being frozen any more. -- greg

Re: [HACKERS] pg_receivexlog add synchronous mode

On Mon, Jun 30, 2014 at 7:09 PM, wrote: >> Thanks for the review! >> >> +if (secs <= 0) >> +secs = 1;/* Always sleep at least 1 sec */ >> + >> +sleeptime = secs * 1000 + usecs / 1000; >> >> The above is the code which caused that problem. 'usecs' should

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 30 June 2014 16:20, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Jun 30, 2014 at 9:39 AM, Stephen Frost wrote: >> >> I think the fact that pgaudit does X and you think it should do Y is a >> >> perfect example of why we're nowhere close to being ready to push

Re: [HACKERS] pg_xlogdump --stats

On Wed, Jun 4, 2014 at 1:47 PM, Abhijit Menon-Sen wrote: > Here's a patch to make pg_xlogdump print summary statistics instead of > individual records. Thanks! I had a use for this feature so I backported the (first) patch to PostgreSQL 9.3. It's a rush job so it's ugly and may have bugs, but it

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Tom Lane wrote: > If we're going to do it like this, then I think the force flag > should be considered to do nothing except override the clock > check, which probably means it shouldn't be tested in the initial > if() at all. That makes sense, and is easily done.  The only question left is how

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On Tue, Jul 1, 2014 at 8:00 AM, Rushabh Lathia wrote: > .) In map_primary_key_to_list() patch using INDEX_ATTR_BITMAP_IDENTITY_KEY > bitmap to get the keycols. In IndexAttrBitmapKind there is also > INDEX_ATTR_BITMAP_KEY, so was confuse between INDEX_ATTR_BITMAP_KEY and > INDEX_ATTR_BITMAP_IDENTIT

Re: [HACKERS] avoiding tuple copying in btree index builds

On Tue, Jun 17, 2014 at 10:08 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 16, 2014 at 8:10 PM, Tom Lane wrote: >>> On a micro-optimization level, it might be worth passing the TID as >>> ItemPointer not ItemPointerData (ie, pass a pointer until we get to >>> the point of actually in

Re: [HACKERS] WAL format and API changes (9.5)

On Mon, Jun 30, 2014 at 4:51 PM, Heikki Linnakangas wrote: > Another big change in the attached patch version is that XLogRegisterData() > now *copies* the data to a working area, instead of merely adding a > XLogRecData entry to the chain. This simplifies things in xlog.c, now that > the XLogRecD

Re: [HACKERS] Set new system identifier using pg_resetxlog

On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera wrote: > I think it's pretty much a given that pg_resetxlog is a tool that can > have disastrous effects if used lightly. If people changes their sysid > wrongly, they're not any worse than if they change their multixact > counters and start gettin

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-07-01 11:11:12 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera > wrote: > > I think it's pretty much a given that pg_resetxlog is a tool that can > > have disastrous effects if used lightly. If people changes their sysid > > wrongly, they're not any worse than

Re: [HACKERS] Set new system identifier using pg_resetxlog

Robert Haas wrote: > On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera > wrote: > > I think it's pretty much a given that pg_resetxlog is a tool that can > > have disastrous effects if used lightly. If people changes their sysid > > wrongly, they're not any worse than if they change their multixac

Re: [HACKERS] Escaping from blocked send() reprised.

On Mon, Jun 30, 2014 at 11:26 PM, Kyotaro HORIGUCHI wrote: >> 2. I think it would be reasonable to try to kill off the connection >> without notifying the client if we're unable to send the data to the >> client in a reasonable period of time. But I'm unsure what "a >> reasonable period of time"

[HACKERS] Can simplify 'limit 1' with slow function?

The simplified scene: select slowfunction(s) from a order by b limit 1; is slow than select slowfunction(s) from (select s from a order by b limit 1) as z; if there are many records in table 'a'. The real scene. Function ST_Distance_Sphere is slow, the query: SELECT ST_Distance_Sphere(s, ST_Geo

Re: [HACKERS] Set new system identifier using pg_resetxlog

On Tue, Jul 1, 2014 at 11:19 AM, Andres Freund wrote: >> I am, however, kind of frustrated, still, that the pg_computemaxlsn >> patch, which I thought was rather a good idea, was scuttled by the >> essentially that same objection: let's not extend pg_resetxlog & >> friends because people might use

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/29/2014 02:58 PM, Patrick Finnegan wrote: > Last I checked, NetBSD doesn't support any sort of multiprocessor VAX. > Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS > on them. Hi Pat, it's good to see your name in my inbox. NetBSD ran on multiprocessor BI-bus VAX

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/29/2014 10:54 AM, Andres Freund wrote: Is there anyone in the NetBSD/VAX community who would be willing to host a PG buildfarm member? >> >>> I could put together a simh-based machine (i.e., fast) on a vm, if >>> nobody else has stepped up for this. >> >> No other volunteers have

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Sun, Jun 29, 2014 at 10:24:22AM -0400, Tom Lane wrote: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=coypu&dt=2014-06-29%2012%3A33%3A12 > so I'm a bit confused as to what we need to change for VAX. Dave did use NetBSD 6.1 (IIRC), which uses an ancient gcc version. I would suggest to

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/29/2014 03:35 PM, Tom Lane wrote: >>> Hey, right up the river from here! > >> Come on up and hack! There's always something neat going on around >> here. Ever run a PDP-11? B-) > > There were so many PDP-11s around CMU when I was an undergrad that > I remember seeing spare ones being u

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 2014-06-29 12:12, Dave McGuire wrote: On 06/29/2014 03:10 PM, Patrick Finnegan wrote: And it also runs on the 11/780 which can have multiple CPUs... but I've never seen support for using more than one CPU (and the NetBSD page still says "NetBSD/vax can only make use of one CPU on multi-CPU ma

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/25/2014 01:57 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 25, 2014 at 1:05 PM, John Klos wrote: >>> While I wouldn't be surprised if you remove the VAX code because not many >>> people are going to be running PostgreSQL, I'd disagree with the assessment >>> that this port is br

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/29/2014 02:06 PM, Tom Lane wrote: > Well, the issue from our point of view is that a lot of what we care about > testing is extremely low-level hardware behavior, like whether spinlocks > work as expected across processors. It's not clear that a simulator would > provide a sufficiently accur

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund wrote: >> You know, looking at this, I wonder if we shouldn't just remove >> support for ARMv5 instead of making a blind stab at a fix. > > Well, I argued that way for a while ;). We don't even need to really > desupport it, but just say it's not suppo

Re: [HACKERS] RLS Design

On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed wrote: > An annoying complication, however, is how this interacts with column > privileges. Right now "GRANT SELECT(col1) ON t1 TO role1" gives role1 > access to every row in col1, and I think that has to remain the case, > since GRANTs only ever give y

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas wrote: > On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund wrote: >>> You know, looking at this, I wonder if we shouldn't just remove >>> support for ARMv5 instead of making a blind stab at a fix. >> >> Well, I argued that way for a while ;). We don't even

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Tue, Jul 1, 2014 at 1:25 PM, Dilip kumar wrote: > On 01 July 2014 03:48, Alvaro Wrote, > >> > In particular, pgpipe is almost an exact duplicate between them, >> > except the copy in vac_parallel.c has fallen behind changes made to >> > parallel.c. (Those changes would have fixed the Windows w

[HACKERS] buildfarm and "rolling release" distros

I've always been a bit reluctant to accept buildfarm members that are constantly being updated, because it seemed to me that it created something with too many variables. However, we occasionally get requests from people who want to run on such platforms, and I'm also a bit reluctant to turn

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-07-01 11:46:19 -0500, Merlin Moncure wrote: > On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas wrote: > > On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund > > wrote: > >>> You know, looking at this, I wonder if we shouldn't just remove > >>> support for ARMv5 instead of making a blind stab at a

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 30 June 2014 16:20, Stephen Frost wrote: > > eh? The focus of this patch is to add auditing to PG and having very > > clearly drawn auditing requirements of a very large customer isn't > > relevant? I don't follow that logic at all. In f

Re: [HACKERS] PATCH: Allow empty targets in unaccent dictionary

At 2014-06-30 22:06:30 -0400, t...@sss.pgh.pa.us wrote: > > I went ahead and committed this patch, and also some further work to > fix the multicharacter-source problem. I took it on myself to make > the code issue warnings about misformatted lines, too. Thanks, looks good. I found the multichara

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Tue, Jul 1, 2014 at 12:46 PM, Merlin Moncure wrote: > A few years back I ported the postresql client libraries and a few > other pieces of software (in particular subversion) to a lot of > obscure platforms (old sparc, hpux, irix, older aix, etc etc). > Getting a modern gcc working on those pla

Re: [HACKERS] Fresh initdb contains a few deleted B-Tree pages

On Tue, Jul 1, 2014 at 6:02 AM, Greg Stark wrote: > Why is this even a small concern? Initdb runs the bootstrap SQL which does > various SQL operations so it's not surprising there are some updates > creating garbage. Iirc we don't even rely on template0 being frozen any > more. It's not surprisi

Re: [HACKERS] buildfarm and "rolling release" distros

On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: > I've always been a bit reluctant to accept buildfarm members that are > constantly being updated, because it seemed to me that it created something > with too many variables. However, we occasionally get requests from people > who want to ru

Re: [HACKERS] Cluster name in ps output

On 06/29/2014 02:25 PM, Andres Freund wrote: > On 2014-06-29 11:11:14 +0100, Thomas Munro wrote: >> > On 29 June 2014 10:55, Andres Freund wrote: >>> > > So, I'd looked at it with an eye towards committing it and found some >>> > > more things. I've now >>> > > * added the restriction that the clu

Re: [HACKERS] Spinlocks and compiler/memory barriers

Robert Haas writes: > The bottom line is that I love supporting obscure platforms as much as > anyone here, and several other committers are already telling me that > I love it too much. We've got to draw the line somewhere, and I think > refusing to ship newly-written code that we have exactly z

Re: [HACKERS] Can simplify 'limit 1' with slow function?

On Sun, Jun 29, 2014 at 10:05:50PM +0800, gotoschool6g wrote: > The simplified scene: > select slowfunction(s) from a order by b limit 1; > is slow than > select slowfunction(s) from (select s from a order by b limit 1) as z; > if there are many records in table 'a'. > > > The real scene. Functi

Re: [HACKERS] RLS Design

On 1 July 2014 17:42, Robert Haas wrote: > On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed wrote: >> An annoying complication, however, is how this interacts with column >> privileges. Right now "GRANT SELECT(col1) ON t1 TO role1" gives role1 >> access to every row in col1, and I think that has to r

Re: [HACKERS] Escaping from blocked send() reprised.

On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote: > > 1. I think it's the case that there are platforms around where a > > signal won't cause send() to return EINTR and I'd be entirely > > unsurprised if SSL_write() doesn't necessarily return EINTR in that > > case. I'm not su

Re: [HACKERS] replication commands and log_statements

Hi. Do we have any consensus about what to do with these two patches? 1. Introduce a "log_replication_command" setting. 2. Change log_statement to be a list of tokens. If I understand correctly, there weren't any strong objections to the former, but the situation is less clear when it comes to t

Re: [HACKERS] Can simplify 'limit 1' with slow function?

On Tue, Jul 1, 2014 at 2:16 PM, Martijn van Oosterhout wrote: > On Sun, Jun 29, 2014 at 10:05:50PM +0800, gotoschool6g wrote: >> The simplified scene: >> select slowfunction(s) from a order by b limit 1; >> is slow than >> select slowfunction(s) from (select s from a order by b limit 1) as z; >> i

Re: [HACKERS] pg_dump reporing version of server & pg_dump as comments in the output

At 2014-06-17 13:21:34 +0530, jeevan.cha...@enterprisedb.com wrote: > > Anyone has any other views ? I guess nobody has strong feelings either way. I've marked this (i.e. your slightly-revised patch) ready for committer. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Tue, Jul 1, 2014 at 2:52 PM, Tom Lane wrote: > Robert Haas writes: >> The bottom line is that I love supporting obscure platforms as much as >> anyone here, and several other committers are already telling me that >> I love it too much. We've got to draw the line somewhere, and I think >> ref

Re: [HACKERS] Array of composite types returned from python

Hi Ronan. Based on your review, I'm marking this as ready for committer. > The attached patch implements this. Your patch looks sensible enough (thanks for adding tests), but I guess we'll let the reviewer sort out whether to commit the original or your extended version. Thanks. -- Abhijit -

Re: [HACKERS] RLS Design

On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed wrote: > On 1 July 2014 17:42, Robert Haas wrote: >> On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed >> wrote: >>> An annoying complication, however, is how this interacts with column >>> privileges. Right now "GRANT SELECT(col1) ON t1 TO role1" gives r

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

On Tue, Jul 1, 2014 at 8:22 AM, Christoph Berg wrote: > Re: Tom Lane 2014-06-23 <17054.1403542...@sss.pgh.pa.us> >> > While I'd love to reduce the number of future installations without >> > this fix in place, I respect the decision to honor project policy. At >> > the same time, this change does

Re: [HACKERS] Can simplify 'limit 1' with slow function?

Merlin Moncure-2 wrote > On Tue, Jul 1, 2014 at 2:16 PM, Martijn van Oosterhout > < > kleptog@ > > wrote: >> On Sun, Jun 29, 2014 at 10:05:50PM +0800, gotoschool6g wrote: >>> The simplified scene: >>> select slowfunction(s) from a order by b limit 1; >>> is slow than >>> select slowfunction(s) fr

Re: [HACKERS] pg_xlogdump --stats

At 2014-07-01 16:39:57 +0300, ma...@juffo.org wrote: > > > Here's a patch to make pg_xlogdump print summary statistics instead > > of individual records. > > Thanks! I had a use for this feature so I backported the (first) patch > to PostgreSQL 9.3. It's a rush job so it's ugly and may have bugs,

Re: [HACKERS] change alter user to be a true alias for alter role

At 2014-06-27 16:11:21 +0200, vik.fear...@dalibo.com wrote: > > After a week of silence from Jov, I decided to do this myself since it > didn't seem very hard. > > Many frustrating hours of trying to understand why I'm getting > shift/reduce conflicts by the hundreds later, I've decided to give up

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Robert Haas writes: > On Tue, Jul 1, 2014 at 8:22 AM, Christoph Berg wrote: >> I have two comments on the patch: >> >> The choice to make the behavior depend first on PG_OOM_ADJUST_FILE and >> only secondly on PG_OOM_ADJUST_VALUE seems the wrong way round to me. > Of course, we have no guarante

Re: [HACKERS] Spinlocks and compiler/memory barriers

Robert Haas writes: > Despite my concerns about keeping the list of supported atomics short, > and I do have concerns in that area, I'm not really sure that we have > much choice but to go in that direction. We can't accept a >5x > performance hit in the name of portability, and that's literally

Re: [HACKERS] buildfarm and "rolling release" distros

On 02/07/14 06:02, Robert Haas wrote: On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: I've always been a bit reluctant to accept buildfarm members that are constantly being updated, because it seemed to me that it created something with too many variables. However, we occasionally get re

Re: [HACKERS] Can simplify 'limit 1' with slow function?

On Tue, Jul 1, 2014 at 3:06 PM, David G Johnston wrote: > Merlin Moncure-2 wrote >> On Tue, Jul 1, 2014 at 2:16 PM, Martijn van Oosterhout >> < > >> kleptog@ > >> > wrote: >>> On Sun, Jun 29, 2014 at 10:05:50PM +0800, gotoschool6g wrote: The simplified scene: select slowfunction(s) from

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Tue, Jul 1, 2014 at 4:54 PM, Tom Lane wrote: > Robert Haas writes: >> Despite my concerns about keeping the list of supported atomics short, >> and I do have concerns in that area, I'm not really sure that we have >> much choice but to go in that direction. We can't accept a >5x >> performanc

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 01/07/14 11:04, Andres Freund wrote: Since we have a Sun Studio machine in the buildfarm, we shouldn't give up on SPARC completely, but maybe we should only add the cases for sparcv8+ and above? That at least has some chance of getting tested. That we have code for sparcv7 is ridiculous bt

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: > On 01/07/14 11:04, Andres Freund wrote: > > >>Since we have a Sun Studio machine in the buildfarm, we shouldn't give > >>up on SPARC completely, but maybe we should only add the cases for > >>sparcv8+ and above? That at least has some chance

[HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Sun, Jun 29, 2014 at 11:58 AM, Kevin Grittner wrote: > I have reviewed this patch, and think we should do what the patch > is trying to do, but I don't think the submitted patch would > actually work. Just curious, why do you think it won't work. Although the discussion is a bit old, but I'm s

Re: [HACKERS] Wait free LW_SHARED acquisition

On 01/07/14 23:25, Heikki Linnakangas wrote: On 07/01/2014 01:08 PM, Andres Freund wrote: Hi, Over at -performance Mark Kirkwood tested a recent version of this (http://archives.postgresql.org/message-id/53B283F3.7020005%40catalyst.net.nz) . I thought it's interesting to add the numbers to thi

[HACKERS] Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Tue, Jul 1, 2014 at 10:05 AM, Kevin Grittner wrote: > Tom Lane wrote: > >> If we're going to do it like this, then I think the force flag >> should be considered to do nothing except override the clock >> check, which probably means it shouldn't be tested in the initial >> if() at all. > > Tha

Re: [HACKERS] SQL access to database attributes

Vik Fearing writes: > Okay, here is version two of the refactoring patch that documents that > the with-space version is deprecated but still accepted. > The feature patch is not affected by this and so I am not attaching a > new version of that. I've committed this without the changes to expose

Re: [HACKERS] Proposing pg_hibernate

On Sun, Jun 15, 2014 at 2:51 AM, Amit Kapila wrote: > On Thu, Jun 12, 2014 at 9:31 AM, Gurjeet Singh wrote: >> >> I don't have intimate knowledge of recovery but I think the above >> assessment of recovery's operations holds true. If you still think >> this is a concern, can you please provide a

Re: [HACKERS] Spinlocks and compiler/memory barriers

Andres Freund writes: > On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: >> Also if you're struggling for Sun buildfarm animals, recent versions of QEMU >> will quite happily install and run later versions of 32-bit Solaris over >> serial, and 2.0 even manages to give you a cgthree framebuffe

Re: [HACKERS] buildfarm and "rolling release" distros

Robert Haas writes: > On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: >> I've always been a bit reluctant to accept buildfarm members that are >> constantly being updated, because it seemed to me that it created something >> with too many variables. However, we occasionally get requests fr

Re: [HACKERS] pg_xlogdump --stats

On Tue, Jul 1, 2014 at 11:13 PM, Abhijit Menon-Sen wrote: > In CF terms, did you form any opinion while porting the patch I posted > about whether it's sensible/ready for inclusion in 9.5? I didn't look at the code more than necessary to make the build work. As far as functionality goes, it does

Re: [HACKERS] inherit support for foreign tables

On Fri, Jun 20, 2014 at 05:04:06PM +0900, Kyotaro HORIGUCHI wrote: > Attached is the rebased patch of v11 up to the current master. I've been studying this patch. SELECT FOR UPDATE on the inheritance parent fails with a can't-happen error condition, even when SELECT FOR UPDATE on the child foreig

Re: [HACKERS] Proposing pg_hibernate

On Sat, Jun 7, 2014 at 6:48 AM, Cédric Villemain wrote: > Le lundi 3 février 2014 19:18:54 Gurjeet Singh a écrit : > >> Possible enhancements: >> - Ability to save/restore only specific databases. >> - Control how many BlockReaders are active at a time; to avoid I/O >> storms. FWIW, this has been

Re: [HACKERS] Audit of logout

On Mon, Jun 23, 2014 at 5:42 PM, Fujii Masao wrote: > On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 06/13/2014 07:29 AM, Tom Lane wrote: >>> Fujii Masao writes: On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao wrote: >

Re: [HACKERS] buildfarm and "rolling release" distros

On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: > >> I'm also not sure how to designate these machines. The buildfarm server > >> metadata isn't designed for auto-updating build platforms. But no doubt if >

Re: [HACKERS] pg_xlogdump --stats

At 2014-07-02 04:20:31 +0300, ma...@juffo.org wrote: > > As far as functionality goes, it does exactly what I needed it to do; > the output is very clear. Good to hear. > You might also add units (kB/MB) to the table like pg_size_pretty, > although that would make the magnitudes harder to gauge.

Re: [HACKERS] TODO item: immutable date_trunc with timezone arg

On Tue, Jul 01, 2014 at 11:49:43AM +0800, Craig Ringer wrote: > Currently it's unsafe/not possible to use some funtions, like > date_trunc, in immutable functions and expression indexes. > > It'd be really useful to have an immutable version that took the > timezone as an argument. Maybe this is a

Re: [HACKERS] TODO item: immutable date_trunc with timezone arg

On 07/02/2014 11:10 AM, Noah Misch wrote: > On Tue, Jul 01, 2014 at 11:49:43AM +0800, Craig Ringer wrote: >> Currently it's unsafe/not possible to use some funtions, like >> date_trunc, in immutable functions and expression indexes. >> >> It'd be really useful to have an immutable version that took

Re: [HACKERS] 9.5 CF1

Hi. Here's a detailed mid-week update split up by category. I've left out patches marked returned/rejected, committed, or ready for committer. Server features --- Lag & Lead Window Functions Can Ignore Nulls Latest patch currently pending review by Jeff and Álvaro. No updates

Re: [HACKERS] 9.5 CF1

Miscellaneous - contrib/fastbloat - tool for quickly assessing bloat stats for a table Pending review by Jaime. showing index update time on EXPLAIN Pending updated patch by Jaime. idle_in_transaction_session_timeout Marked as ready for committer, but as far as I can tell

Re: [HACKERS] 9.5 CF1

On Tue, Jul 1, 2014 at 10:06 PM, Abhijit Menon-Sen wrote: > Using Levenshtein distance to HINT a candidate column name > No real progress in any direction. Everyone wants the feature, but > nobody is sure how many suggestions would be useful and how many > would be annoying. Expect a

Re: [HACKERS] buildfarm and "rolling release" distros

On 07/02/2014 10:58 AM, Noah Misch wrote: > On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote: >> Robert Haas writes: >>> On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: I'm also not sure how to designate these machines. The buildfarm server metadata isn't designed for aut

Re: [HACKERS] pg_xlogdump --stats

On 07/02/2014 09:20 AM, Marti Raudsepp wrote: > You might also add units (kB/MB) to the table like pg_size_pretty, > although that would make the magnitudes harder to gauge. What 'du' does, or a subset of, may be worthwhile. -k: kB -b: blocks -m: MB -h: human-readable auto-scaling though I thin

Re: [HACKERS] 9.5 CF1

Functions - min/max support for inet datatypes Pending review by Muhammad Asif Naeem. Selectivity estimation for inet operators Dilip Kumar plans to post a review this week. There are two "ready for committer" patches in this category. Clients --- Gaussian distribution pgbe

Re: [HACKERS] 9.5 CF1

System administration - pg_hibernator Nice feature, some discussion, no code reviews. Status not entirely clear, but updated patch available. Monitoring & control Reducing impact of hints/cleanup for SELECTs Pending performance review by Emanu

  1   2   >