Hello, this is the revised patch.
> Hmm, that sounds quite resonable in general. But the conflation
> is already found in grouping_planner to some extent.
Although this new patch is not split into unique-index sutff and
others, it removes current_pathkeys from grouping_planner, and
adds pathkeys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 11:20 PM, Josh Berkus wrote:
> On 11/11/2013 06:24 AM, Stephen Frost wrote:
>> * Rafael Martinez (r.m.guerr...@usit.uio.no) wrote:
>>> * We need a pg_dump solution that can generate in one step all
>>> the necessary pieces of information
David Johnston wrote
> The paragraph is unnecessary if the Synopsis section of the SELECT
> documentation is updated to correctly reflect all the valid clauses that
> can be attached to TABLE. The current reading implies that you cannot
> attach anything so when you said LIMIT worked I was surpris
Stephen Frost writes:
> Are there any other changes you have pending for this..? Would be nice
> to see the latest version which you've tested and which patches cleanly
> against master... ;)
I just rebased now, please see attached. I had to pick new OIDs in some
places too, but that's about it.
Hello,
IMHO, there is a serious issue in the script to clean the old data directory
when running pg_upgrade in link mode.
in short: When working with symbolic links, the first step in
delete_old_cluster.sh
is to delete the old $PGDATA folder that may contain tablespaces used by the
new instance
Hi,
I am looking in Postgresql code for the first time. Specifically in
Indexing scheme.
I want to focus on B tree for my testing.
Inside access methods in Backend, I found "Index" folder and "Btree" folder
but i don't know which code to look for. i want to change something in B
tree implementa
Hi,
While trying to find instructions to build documentation, I noticed
that the links in README.git are broken, both redirect to
http://www.postgresql.org/docs/devel/static/
In addition, why isn't INSTALL stored in git?
Cheers,
Colin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Tue, Nov 12, 2013 at 12:19 PM, Colin 't Hart wrote:
> Hi,
>
> While trying to find instructions to build documentation, I noticed
> that the links in README.git are broken, both redirect to
> http://www.postgresql.org/docs/devel/static/
Fixed. Forgotten when we moved the developer docs a whil
On 11/12/2013 07:00 PM, Rohit Goyal wrote:
>
> Inside access methods in Backend, I found "Index" folder and "Btree"
> folder but i don't know which code to look for. i want to change
> something in B tree implementation.
>
Start here:
http://www.postgresql.org/docs/current/static/indexam.html
Tom Lane wrote:
> quite a lot of people have looked at Postgres with Coverity
> already. If Clang is throwing up lots and lots of warnings, the
> odds are *very* high that most of them are false positives.
> Running through such a list to see if there's anything real isn't
> all that exciting a
Kevin Grittner wrote:
> Logic error
> Stack address stored into global variable: 1
I took a look at this one, and it is a totally legitimate use, the
reason for which is explained with this comment:
/*
* check_stack_depth: check for excessively deep recursion
*
* This should be called so
On 5 November 2013 14:28, Leonardo Francalanci wrote:
> Either my sql is not correct (likely), or my understanding of the minmax
> index is
> not correct (even more likely), or the minmax index is not usable in a
> random inputs
> scenario.
Please show the real world SQL you intend to run, so we
* Rafael Martinez (r.m.guerr...@usit.uio.no) wrote:
> Comments?
Create a wiki page for it. :)
Thanks,
Stephen
signature.asc
Description: Digital signature
* Peter Geoghegan (p...@heroku.com) wrote:
> I seem to also recall
> Coverity correctly handling that, although perhaps I'm unfairly
> crediting them with taking advantage of the abort() trick because of
> the state of Postgres when I tried each of those two tools - it might
> be that scan-build *w
On Sat, Nov 9, 2013 at 10:01 AM, Craig Ringer wrote:
> On 11/08/2013 11:03 PM, Robert Haas wrote:
>>> > Separate "READ DELETE" etc would only be interesting if we wanted to let
>>> > someone DELETE rows they cannot SELECT. Since we have DELETE ...
>>> > RETURNING, and since users can write a predi
On Sat, Nov 9, 2013 at 5:52 AM, lucamarletta wrote:
> I'm new in postgresql c function and I start following examples.
>
> I want to write a simple function that have inside an SQL and passing
> parameter evaluete anbd return 2 fields as sum (for now to be simpler).
>
> The function below has prob
Kevin Grittner writes:
> Does anything stand out as something that is particularly worth
> looking into? Does anything here seem worth assuming is completely
> bogus because of the Coverity and Valgrind passes?
I thought most of it was obvious junk: if there were actually
uninitialized-variable
On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera
wrote:
> Attached you can find a very-much-WIP patch to add CREATE info support
> for event triggers (normalized commands). This patch builds mainly on
> two things:
>
> 1. Dimitri's "DDL rewrite" patch he submitted way back, in
>http://www.post
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think Coverity does that, or at least I've seen output from some tool
> that does it.
Coverity does provide the path (including going through multiple
interations of a loop, if applicable). Doesn't make it perfect, sadly,
but I've been trying to feed bac
Hello,
It is a brief design proposal of a feature I'd like to implement on top of
custom-scan APIs. Because it (probably) requires a few additional base
features not only custom-scan, I'd like to see feedback from the hackers.
The cache-only table scan, being in subject line, is an alternative sc
On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch wrote:
> A PANIC will reinitialize everything relevant, largely resolving the problems
> around ERROR during FATAL. It's a heavy-handed solution, but it may well be
> the best solution. Efforts to harden CommitTransaction() and
> AbortTransaction() seem
Kohei KaiGai writes:
> The cache-only table scan, being in subject line, is an alternative scan
> logic towards sequential scan if all the referenced columns are cached.
This seems like a pretty dubious idea to me --- you're talking about
expending large amounts of memory on a single-purpose cach
On Sun, Nov 10, 2013 at 6:12 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> It might be a bit more portable if we replaced the shebang lines on perl
>> scripts with
>> #!/bin/env perl
>
> Perhaps, if we're worried about people keeping perl somewhere other
> than /usr/bin. However, the most
On Sun, Nov 10, 2013 at 8:06 PM, Tom Lane wrote:
> We had a complaint
> http://www.postgresql.org/message-id/e1vjuby-0002a1...@wrigleys.postgresql.org
> about the fact that 9.3 rejects queries with duplicate table aliases like
> this:
>
> select * from tenk1 a left join (int4_tbl a cross join int8
On Mon, Nov 11, 2013 at 3:03 AM, Heikki Linnakangas
wrote:
> On 10.11.2013 01:47, Robert Haas wrote:
>> I think we've tried pretty hard to avoid algorithms where the maximum
>> number of lwlocks that must be held at one time is not a constant, and
>> I think we're in for a bad time of it if we sta
On Tue, Nov 12, 2013 at 9:45 AM, Kohei KaiGai wrote:
> It is a brief design proposal of a feature I'd like to implement on top of
> custom-scan APIs. Because it (probably) requires a few additional base
> features not only custom-scan, I'd like to see feedback from the hackers.
>
> The cache-only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/12/2013 03:28 PM, Stephen Frost wrote:
> * Rafael Martinez (r.m.guerr...@usit.uio.no) wrote:
>> Comments?
>
> Create a wiki page for it. :)
>
What about this to start with?:
https://wiki.postgresql.org/wiki/Pg_dump_improvements
- --
Rafael M
2013/11/12 Tom Lane :
> Kohei KaiGai writes:
>> The cache-only table scan, being in subject line, is an alternative scan
>> logic towards sequential scan if all the referenced columns are cached.
>
> This seems like a pretty dubious idea to me --- you're talking about
> expending large amounts of
G'day list. Didn't get any interest in pgsql-general, thought I'd try
my luck here, which perhaps would be more fitting in case I've
stumbled upon an edge case issue or something...
I've recently upgraded a number of servers from PostgreSQL 9.2.5 to
9.3.1 and have started getting the following err
Hello
here is patch with fault tolerant drop trigger and drop rule support
drop trigger [if exists] trgname on [if exists] tablename;
drop rule [if exists] trgname on [if exists] tablename;
Regards
Pavel
2013/11/11 Pavel Stehule
>
>
>
> 2013/11/11 Tom Lane
>
>> Andres Freund writes:
>> >
On Thu, Oct 24, 2013 at 11:14:14PM +0300, Heikki Linnakangas wrote:
> On 24.10.2013 23:07, Josh Berkus wrote:
> >On 10/24/2013 11:12 AM, Heikki Linnakangas wrote:
> >>On 24.10.2013 20:39, Josh Berkus wrote:
> >>>On 10/24/2013 04:15 AM, Pavan Deolasee wrote:
> If we do what you are suggesting, i
On Wed, Oct 23, 2013 at 10:31:39AM +0530, Amit Kapila wrote:
> On Tue, Oct 22, 2013 at 3:04 AM, Piotr Marcinczyk wrote:
> > Hi,
> >
> > I would like to implement item from TODO marked as easy: "Add \i option
> > to bring in the specified file as a quoted literal". I understand intent
> > of this i
2013/11/12 Robert Haas :
> On Tue, Nov 12, 2013 at 9:45 AM, Kohei KaiGai wrote:
>> It is a brief design proposal of a feature I'd like to implement on top of
>> custom-scan APIs. Because it (probably) requires a few additional base
>> features not only custom-scan, I'd like to see feedback from th
Hi,
On 2013-11-12 10:56:55 -0500, J Smith wrote:
> G'day list. Didn't get any interest in pgsql-general, thought I'd try
> my luck here, which perhaps would be more fitting in case I've
> stumbled upon an edge case issue or something...
Normally the bug report for/the -bugs mailing list is the ri
I spent a bit of time looking into the memory leak reported here:
http://www.postgresql.org/message-id/52376c35.5040...@gmail.com
I think this test case doesn't have much to do with the complainant's
original problem, but anyway it is exposing a genuine leakage issue.
The difficulty is that when p
* J Smith (dark.panda+li...@gmail.com) wrote:
> I've recently upgraded a number of servers from PostgreSQL 9.2.5 to
> 9.3.1 and have started getting the following errors every couple of
> hours along with some failed transactions.
How was this upgrade done? If you used pg_upgrade, what version of
On 2013-11-12 11:18:32 -0500, Tom Lane wrote:
> Or we could say "what the heck are you doing executing tens of
> thousands of DO blocks? Make it into a real live function;
> you'll save a lot of cycles on parsing costs." I'm not sure that
> this is a usage pattern we ought to be optimizing for.
Kohei KaiGai writes:
> 2013/11/12 Tom Lane :
>> There's no possible way you'll finish this for 9.4.
> Yes, I understand it is not possible to submit whole of the patch until
> CF3 deadline. So, I'd like to find out a way to implement it as an
> extension using facilities being supported or to be
On Tue, Nov 12, 2013 at 7:05 AM, Andres Freund wrote:
>> The only hack I currently can think of is to store argv[0] in a global
>> variable and to run the find_other_exec() in the first run through
>> isolation_start_test() :/.
>
> A patch to that end attached.
>
> Alternatively we could add a "st
On 2013-11-12 11:25:03 -0500, Stephen Frost wrote:
> * J Smith (dark.panda+li...@gmail.com) wrote:
> > I've recently upgraded a number of servers from PostgreSQL 9.2.5 to
> > 9.3.1 and have started getting the following errors every couple of
> > hours along with some failed transactions.
>
> How
On Tue, Nov 12, 2013 at 11:25 AM, Stephen Frost wrote:
>
> How was this upgrade done? If you used pg_upgrade, what version of the
> pg_upgrade code did you use? As I recall, there was a bug in older
> versions which could exhibit in this way..
>
> http://wiki.postgresql.org/wiki/20110408pg_upgra
Kevin Grittner wrote:
> Memory Error
> Double free: 1
> Memory leak: 1
These both seemed legitimate to me. Patch attached. Any
objections to applying it? I realize the memory leak is a tiny one
in the regression testing code, so it could never amount to enough
to matter; but it seems wo
On Tue, Nov 12, 2013 at 11:45 AM, Kohei KaiGai wrote:
> Hello,
>
> It is a brief design proposal of a feature I'd like to implement on top of
> custom-scan APIs. Because it (probably) requires a few additional base
> features not only custom-scan, I'd like to see feedback from the hackers.
>
> The
G'day Andres.
On Tue, Nov 12, 2013 at 11:13 AM, Andres Freund wrote:
> Hi,
>
> On 2013-11-12 10:56:55 -0500, J Smith wrote:
>> G'day list. Didn't get any interest in pgsql-general, thought I'd try
>> my luck here, which perhaps would be more fitting in case I've
>> stumbled upon an edge case issu
* Andres Freund (and...@2ndquadrant.com) wrote:
> He referred to using pg_dumpall/pg_dump. But that bug was erroring out
> on pg_clog, not pg_subtrans, right?
Yeah, that was pg_clog. Obviously responded before really looking at
it. :)
> My gut feeling is thats it's related to foreign key locks d
Hi,
Many distros are switching/switched to systemd. In the git repo, we only
have init script for SysV. Would it make sense to add systemd service
script to our tarball as well? This could also standardize the systemd
scripts used in other distros.
http://svn.pgrpms.org/browser/rpm/redhat/9.3/po
* J Smith (dark.panda+li...@gmail.com) wrote:
> We haven't been able to use pg_upgrade as we rely heavily on PostGIS
> and do hard upgrades via pg_dump and postgis_restore.pl when we
> upgrade.
Did you also upgrade to PostGIS 2.x as part of this..? Seems like it'd
be unrelated, but one never know
Hi,
On 2013-11-12 11:46:19 -0500, J Smith wrote:
> > * Does SELECT count(*) FROM pg_prepared_xacts; return 0?
>
> Yes it does.
Could you show the output? Do you actually use prepared xacts actively?
Do you actively use row level locking? Is there high concurrency in that
environment? In short,
Kevin Grittner writes:
> Kevin Grittner wrote:
>> Memory Error
>> Double free: 1
>> Memory leak: 1
> These both seemed legitimate to me. Patch attached. Any
> objections to applying it? I realize the memory leak is a tiny one
> in the regression testing code, so it could never amount
2013/11/12 Claudio Freire :
> On Tue, Nov 12, 2013 at 11:45 AM, Kohei KaiGai wrote:
>> Hello,
>>
>> It is a brief design proposal of a feature I'd like to implement on top of
>> custom-scan APIs. Because it (probably) requires a few additional base
>> features not only custom-scan, I'd like to see
On Mon, Nov 11, 2013 at 12:00 PM, Andres Freund wrote:
> [ updated patch-set ]
I'm pretty happy with what's now patch #1, f/k/a known as patch #3,
and probably somewhere else in the set before that. At any rate, I
refer to 0001-wal_decoding-Add-wal_level-logical-and-log-data-requ.patch.gz.
I th
On Tue, Nov 12, 2013 at 11:54 AM, Stephen Frost wrote:
>
> Did you also upgrade to PostGIS 2.x as part of this..? Seems like it'd
> be unrelated, but one never knows. Any chance you could distill this
> down into a small test case which exhibits the problem? I'm guessing
> 'no', but figured I'd
2013/11/12 Tom Lane :
> Kohei KaiGai writes:
>> 2013/11/12 Tom Lane :
>>> There's no possible way you'll finish this for 9.4.
>
>> Yes, I understand it is not possible to submit whole of the patch until
>> CF3 deadline. So, I'd like to find out a way to implement it as an
>> extension using facili
Yeb Havinga writes:
> On 2013-09-13 18:32, Robert Haas wrote:
>> On Thu, Sep 12, 2013 at 5:29 AM, Yeb Havinga wrote:
>>> We have a function that takes a value and returns a ROW type. With the
>>> function implemented in language SQL, when executing this function in a
>>> large transaction, memory
Kohei KaiGai writes:
> So, are you thinking it is a feasible approach to focus on custom-scan
> APIs during the upcoming CF3, then table-caching feature as use-case
> of this APIs on CF4?
Sure. If you work on this extension after CF3, and it reveals that the
custom scan stuff needs some adjustme
Hi,
On 2013-11-12 12:13:54 -0500, Robert Haas wrote:
> On Mon, Nov 11, 2013 at 12:00 PM, Andres Freund
> wrote:
> > [ updated patch-set ]
>
> I'm pretty happy with what's now patch #1, f/k/a known as patch #3,
> and probably somewhere else in the set before that. At any rate, I
> refer to 0001-
On Tue, Nov 12, 2013 at 12:50 PM, Andres Freund wrote:
> Completely agreed. As evidenced by the fact that the current change
> doesn't update all relevant comments & code. I wonder if we shouldn't
> leave the function the current way and just add a new function for the
> new behaviour.
> The hard
On Mon, Nov 11, 2013 at 1:57 PM, Andres Freund wrote:
> Instead of de-supporting platforms that don't have CAS support or
> providing parallel implementations we could relatively easily build a
> spinlock based fallback using the already existing requirement for
> tas().
> Something like an array
On 2013-11-12 13:21:30 -0500, Robert Haas wrote:
> > The only real problem with that would be that we'd need to remove the
> > spinnlock fallback for barriers, but that seems to be pretty much
> > disliked.
>
> I think this is worth considering.
Ok, cool. The prototype patch I have for that is pr
On 2013-11-12 13:18:19 -0500, Robert Haas wrote:
> On Tue, Nov 12, 2013 at 12:50 PM, Andres Freund
> wrote:
> > Completely agreed. As evidenced by the fact that the current change
> > doesn't update all relevant comments & code. I wonder if we shouldn't
> > leave the function the current way and
In the last year I have created a number of modules providing extra JSON
functionality. I'd like to include some of these in release 9.4.
Candidates for inclusion are:
json_build: which provides extra functionality for building up
non-regualr and arbitrarily complex json, as well as a way of
On Tue, Nov 12, 2013 at 11:55 AM, Andres Freund wrote:
> Hi,
>
> On 2013-11-12 11:46:19 -0500, J Smith wrote:
>> > * Does SELECT count(*) FROM pg_prepared_xacts; return 0?
>>
>> Yes it does.
>
> Could you show the output? Do you actually use prepared xacts actively?
jay:dev@jagger=# select * from
2013/11/12 Tom Lane :
> Kohei KaiGai writes:
>> So, are you thinking it is a feasible approach to focus on custom-scan
>> APIs during the upcoming CF3, then table-caching feature as use-case
>> of this APIs on CF4?
>
> Sure. If you work on this extension after CF3, and it reveals that the
> custo
Hi,
I'm working on adding write support to one of my FDWs. Adding INSERT went
pretty fine, but when adding DELETE/UPDATE I got really confused about how
the update targets are supposed to work.
My understanding of how it's supposed to work is this:
(1) AddForeignUpdateTargets adds columns that
Suppose, some last changes in GIN are broken, 9.3 works fine.
CREATE OR REPLACE FUNCTION generate_tags()
RETURNS int[]
LANGUAGE SQL VOLATILE AS
$$
SELECT ARRAY(
SELECT
(random()*random()*1000)::int4
FROM
generate_series(1, 1 + (random()*random()*100)::i
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane wrote:
> ...
>
> One thought for the Clang people is that most of the reports such as "null
> pointer dereference" presumably mean "I think I see an execution path
> whereby we could get here with a null pointer". If so, it'd be awfully
> helpful if the c
On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
> On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane wrote:
> > ...
> >
> > One thought for the Clang people is that most of the reports such as "null
> > pointer dereference" presumably mean "I think I see an execution path
> > whereby we could get here
On Tue, Nov 12, 2013 at 3:25 PM, Andres Freund wrote:
> On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
>> On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane wrote:
>> > ...
>> > One thought for the Clang people is that most of the reports such as "null
>> > pointer dereference" presumably mean "I thi
On 2013-11-12 15:33:13 -0500, Jeffrey Walton wrote:
> On Tue, Nov 12, 2013 at 3:25 PM, Andres Freund wrote:
> > On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
> >> On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane wrote:
> >> > ...
> >> > One thought for the Clang people is that most of the reports
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane wrote:
> Kevin Grittner writes:
>> Does anything stand out as something that is particularly worth
>> looking into? Does anything here seem worth assuming is completely
>> bogus because of the Coverity and Valgrind passes?
>
> I thought most of it was ob
On Tue, Nov 12, 2013 at 3:35 PM, Andres Freund wrote:
> On 2013-11-12 15:33:13 -0500, Jeffrey Walton wrote:
>> On Tue, Nov 12, 2013 at 3:25 PM, Andres Freund
>> wrote:
>> > On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
>> > ...
>> > It might not recognize our Assert() because it expands as
On Tue, Nov 12, 2013 at 11:47 AM, Devrim GÜNDÜZ wrote:
>
> Hi,
>
> Many distros are switching/switched to systemd. In the git repo, we only
> have init script for SysV. Would it make sense to add systemd service
> script to our tarball as well? This could also standardize the systemd
> scripts use
On 11/12/2013 03:54 PM, Nigel Heron wrote:
On Tue, Nov 12, 2013 at 11:47 AM, Devrim GÜNDÜZ wrote:
Hi,
Many distros are switching/switched to systemd. In the git repo, we only
have init script for SysV. Would it make sense to add systemd service
script to our tarball as well? This could also s
On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane wrote:
> Or we could say "what the heck are you doing executing tens of
> thousands of DO blocks? Make it into a real live function;
> you'll save a lot of cycles on parsing costs." I'm not sure that
> this is a usage pattern we ought to be optimizing f
2013/11/2 Simon Riggs :
> On 29 October 2013 16:10, Peter Geoghegan wrote:
>
>> Presumably someone will get around to implementing a btree index
>> insertion buffer one day. I think that would be a particularly
>> compelling optimization for us, because we could avoid ever inserting
>> index tupl
2013/11/12 Nicolas Barbier :
> In conclusion, use a “B-forest” when:
>
> * The index entries are small (large fan-out).
> * The insertion throughput is high.
> * It’s OK for look-ups to be slow.
> * Extra points when the storage medium has high seek times.
Oops, forgot the most important ones:
*
Robert Haas wrote
> That's a sufficiently astonishing result that it wouldn't be
> surprising for this to get reported as a bug where a simple
> performance gap wouldn't be, and I think if we don't fix it the
> perception will be that we've left that bug unfixed. Now, there are
> lots of things we
On 12 November 2013 21:41, Nicolas Barbier wrote:
> Look-up speed is as follows: Each look-up must look through all
> B-trees.
That can be optimised by using a min max approach, so we need only
look at sub-trees that may contain data.
> Index size: I think (didn’t calculate) that the combined s
On 11/12/13, 8:18 AM, Kevin Grittner wrote:
> Here is the summary of what was reported:
>
> All Bugs: 313
> Does anything stand out as something that is particularly worth
> looking into? Does anything here seem worth assuming is completely
> bogus because of the Coverity and Valgrind passes?
On 11/12/13, 11:47 AM, Devrim GÜNDÜZ wrote:
> Attached is a modified version that will work with the compile defaults.
I think you don't need both a PGDATA environment variable and the -D
option to pg_ctl.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hi,
Thanks for document. It was really helpful.
Now, as index folder contains basically interface for all index type, do I
need to change it, if I want to modify only b tree index algorithm?
Do I need to change only btree index files or Do i have to change index
folder files like indexam.c
Please
On Tue, Nov 12, 2013 at 6:41 PM, Nicolas Barbier
wrote:
> (Note that K B-trees can be merged by simply scanning all of them
> concurrently, and merging them just like a merge sort merges runs.
> Also, all B-trees except for the first level (of size S) can be
> compacted 100% as there is no need to
Peter Eisentraut wrote:
> I have tracked scan-build for some time, and I'm sure that almost
> all of these bugs are false positives at this point.
From poking around, I agree. One particular error I noticed that
it makes a lot is that in a loop it says that an assigned value is
not referenced i
On Tue, Nov 12, 2013 at 6:04 PM, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
>> I have tracked scan-build for some time, and I'm sure that almost
>> all of these bugs are false positives at this point.
>
> From poking around, I agree. One particular error I noticed that
> it makes a lot is
On 8.11.2013 16:13, Albe Laurenz wrote:
> Tom Lane wrote:
>> Albe Laurenz writes:
>>> What I would like to do is add a custom resjunk column (e.g. a
>>> bytea) in AddForeignUpdateTargets that carries a row identifier
>>> from the scan state to the modify state. Would that be possible?
>>> Can I h
Am 11.11.2013 02:06, schrieb Tom Lane:
We had a complaint
http://www.postgresql.org/message-id/e1vjuby-0002a1...@wrigleys.postgresql.org
about the fact that 9.3 rejects queries with duplicate table aliases like
this:
select * from tenk1 a left join (int4_tbl a cross join int8_tbl b) c on unique1
Kevin Grittner escribió:
> These both seemed legitimate to me. Patch attached. Any
> objections to applying it? I realize the memory leak is a tiny one
> in the regression testing code, so it could never amount to enough
> to matter; but it seems worth fixing just to avoid noise in code
> analy
On Tue, Nov 12, 2013 at 5:19 PM, Peter Eisentraut wrote:
> On 11/12/13, 8:18 AM, Kevin Grittner wrote:
>> Here is the summary of what was reported:
>>
>> All Bugs: 313
>
>> Does anything stand out as something that is particularly worth
>> looking into? Does anything here seem worth assuming is
On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
wrote:
> Kevin Grittner escribió:
>
>> These both seemed legitimate to me. Patch attached. Any
>> objections to applying it? I realize the memory leak is a tiny one
>> in the regression testing code, so it could never amount to enough
>> to matter
On 11/12/2013 01:35 PM, Teodor Sigaev wrote:
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.
All new features are described in PGConf.EU talk
http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf
(since PGCon
Jeffrey Walton writes:
> On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
> wrote:
>> We have marked a large number of memory leak reports by Coverity in
>> initdb and other short-lived programs as false positive, on the grounds
>> that there's no point in freeing memory in a program that's about
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar wrote:
> This patch implementing the following TODO item
>
> Allow parallel cores to be used by vacuumdb
> http://www.postgresql.org/message-id/4f10a728.7090...@agliodbs.com
>
>
>
> Like Parallel pg_dump, vacuumdb is provided with the option to run the
>
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar wrote:
> This patch implementing the following TODO item
>
> Allow parallel cores to be used by vacuumdb
> http://www.postgresql.org/message-id/4f10a728.7090...@agliodbs.com
Cool. Could you add this patch to the next commit fest for 9.4? It
begins offici
On 11/13/2013 06:36 AM, Rohit Goyal wrote:
> Hi,
> Thanks for document. It was really helpful.
> Now, as index folder contains basically interface for all index type, do
> I need to change it, if I want to modify only b tree index algorithm?
>
> Do I need to change only btree index files or Do i
On Sun, 2013-11-10 at 18:12 -0500, Tom Lane wrote:
> Perhaps, if we're worried about people keeping perl somewhere other
> than /usr/bin. However, the most likely reason for having a
> /usr/local/bin/perl or whatever is that it's a newer and shinier one
> than what's in /usr/bin. Since we're only
On Tue, 2013-11-12 at 10:02 -0500, Robert Haas wrote:
> IMV, the role of the #! line is just to cater to
> the less-likely scenario where someone wants to run one of those
> scripts outside the build process;
Let's remember that we are talking about unused_oids here.
--
Sent via pgsql-hackers
On 11/12/2013 09:01 PM, Peter Eisentraut wrote:
On Sun, 2013-11-10 at 18:12 -0500, Tom Lane wrote:
Perhaps, if we're worried about people keeping perl somewhere other
than /usr/bin. However, the most likely reason for having a
/usr/local/bin/perl or whatever is that it's a newer and shinier on
On Tue, 2013-11-12 at 21:30 -0500, Andrew Dunstan wrote:
> As Robert pointed out, The build process should be, and now is,
> invoking it via $(PERL), so how is this still an issue?
unused_oids is not part of the build process.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Mon, 2013-11-11 at 14:38 -0500, Andrew Dunstan wrote:
> Can we please agree on a minimum version of git and just support its
> features? Relying on versions close to the bleeding
We're not relying on it. With an older version, you just can't take
advantage of the newer features, so everything
Similar to recent pg_upgrade changes
(https://commitfest.postgresql.org/action/patch_view?id=1216), here is a
patch to separate the terminating and nonterminating variants of
mmerror() in ecpg.
>From 2c8cc7ea1135c9ceddb5b60c30e4363d3784cb29 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue
1 - 100 of 111 matches
Mail list logo
