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:
>
Hello, This is about a document fix of local_preload_libraries
for the versions 9.3 and earlier to at least 8.4.
There's inconsistency between documentation about
local_preload_libraries for 9.3 and earlier and their behavior.
The 9.3 document for local_preload_libraries says that:
http://www.p
On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund wrote:
> Imagine the situation for the buffer header spinlock which is one of the
> bigger performance issues atm. We could aim to replace all usages of
> that with clever and complicated logic, but it's hard.
>
> The IMO reasonable (and prototyped) w
On 14/07/01 23:13, Robert Haas wrote:
> 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_A
Performance
---
scalable LWLocks
Generic atomics implementation
Both under active discussion.
KNN-GiST with recheck
Partial sort
Some earlier discussion, but no conclusions, and as far as I know
nobody is working on these patches at the moment.
lowering array_agg memory requi
On Tue, Jul 1, 2014 at 7:18 AM, Fujii Masao wrote:
> On Tue, Jul 1, 2014 at 5:51 AM, Heikki Linnakangas
> wrote:
> > Thanks for the review!
> >
> >
> > On 06/27/2014 09:12 AM, Michael Paquier wrote:
> >>
> >> Looking at this patch, it does not compile when assertions are enabled
> >> because of
Ronan Dunklau writes:
> Le dimanche 29 juin 2014 16:54:03 Tom Lane a =E9crit :
>> 1. While I think the patch does what it intends to, it's a bit distressing
>> that it will invoke the information lookups in PLyObject_ToComposite over
>> again for *each element* of the array. We probably ought to
SQL commands
Event triggers: object creation support
Enormous patch, no reviews, no reviewers, but it's known to work
already. Does anyone want to have a look at this? (I thought it
was being reviewed, and didn't realise otherwise until a couple
of days ago. Sorry abou
Security
Row-security based on Updatable security barrier views
Lots of discussion that I haven't dared to look at properly yet. I
gather there's still plenty of design-level work needed, and this
is not in any imminent danger of being committed.
Replication & Recovery
--
On Wed, Jun 25, 2014 at 10:39 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
>
> I came up with the attached. There were several bugs:
>
>
I tested for the original bug report and patch definitely fixes that. I
don't feel qualified enough with SP-Gist to really comment on the other
bugs
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
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
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
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
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
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
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
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
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
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.
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
>
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:
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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: 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
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: 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
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
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
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
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
>
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
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.
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:
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
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
> >
1 - 100 of 110 matches
Mail list logo