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 needed
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 surprised.
Stephen Frost sfr...@snowman.net 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
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
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
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
On Tue, Nov 12, 2013 at 12:19 PM, Colin 't Hart co...@sharpheart.orgwrote:
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
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 t...@sss.pgh.pa.us 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
Kevin Grittner kgri...@ymail.com 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
On 5 November 2013 14:28, Leonardo Francalanci m_li...@yahoo.it 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
* 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
On Sat, Nov 9, 2013 at 10:01 AM, Craig Ringer cr...@2ndquadrant.com 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
On Sat, Nov 9, 2013 at 5:52 AM, lucamarletta i...@beopen.it 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
Kevin Grittner kgri...@ymail.com 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
On Fri, Nov 8, 2013 at 10:33 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
* 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 back
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
On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch n...@leadboat.com 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
Kohei KaiGai kai...@kaigai.gr.jp 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
On Sun, Nov 10, 2013 at 6:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
On Sun, Nov 10, 2013 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Nov 11, 2013 at 3:03 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Tue, Nov 12, 2013 at 9:45 AM, Kohei KaiGai kai...@kaigai.gr.jp 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.
-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
2013/11/12 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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
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
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 pavel.steh...@gmail.com
2013/11/11 Tom Lane
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, it seems like a
On Wed, Oct 23, 2013 at 10:31:39AM +0530, Amit Kapila wrote:
On Tue, Oct 22, 2013 at 3:04 AM, Piotr Marcinczyk pmarc...@gmail.com 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
2013/11/12 Robert Haas robertmh...@gmail.com:
On Tue, Nov 12, 2013 at 9:45 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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
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
* 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 kai...@kaigai.gr.jp writes:
2013/11/12 Tom Lane t...@sss.pgh.pa.us:
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
On Tue, Nov 12, 2013 at 7:05 AM, Andres Freund and...@2ndquadrant.com 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
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 was this
On Tue, Nov 12, 2013 at 11:25 AM, Stephen Frost sfr...@snowman.net 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..
Kevin Grittner kgri...@ymail.com 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;
On Tue, Nov 12, 2013 at 11:45 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
G'day Andres.
On Tue, Nov 12, 2013 at 11:13 AM, Andres Freund and...@2ndquadrant.com 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
* 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
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.
* 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 knows.
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 kgri...@ymail.com writes:
Kevin Grittner kgri...@ymail.com 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,
2013/11/12 Claudio Freire klaussfre...@gmail.com:
On Tue, Nov 12, 2013 at 11:45 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Nov 11, 2013 at 12:00 PM, Andres Freund and...@2ndquadrant.com 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
On Tue, Nov 12, 2013 at 11:54 AM, Stephen Frost sfr...@snowman.net 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',
2013/11/12 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
2013/11/12 Tom Lane t...@sss.pgh.pa.us:
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
Yeb Havinga yebhavi...@gmail.com writes:
On 2013-09-13 18:32, Robert Haas wrote:
On Thu, Sep 12, 2013 at 5:29 AM, Yeb Havinga yebhavi...@gmail.com 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
Kohei KaiGai kai...@kaigai.gr.jp 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
Hi,
On 2013-11-12 12:13:54 -0500, Robert Haas wrote:
On Mon, Nov 11, 2013 at 12:00 PM, Andres Freund and...@2ndquadrant.com
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
On Tue, Nov 12, 2013 at 12:50 PM, Andres Freund and...@2ndquadrant.com 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
On Mon, Nov 11, 2013 at 1:57 PM, Andres Freund and...@2ndquadrant.com 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().
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 pretty
On 2013-11-12 13:18:19 -0500, Robert Haas wrote:
On Tue, Nov 12, 2013 at 12:50 PM, Andres Freund and...@2ndquadrant.com
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
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
On Tue, Nov 12, 2013 at 11:55 AM, Andres Freund and...@2ndquadrant.com 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=#
2013/11/12 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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,
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 +
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us 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
On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Nov 12, 2013 at 3:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
...
One thought for the Clang people is that most of the reports such as null
pointer
On 2013-11-12 15:33:13 -0500, Jeffrey Walton wrote:
On Tue, Nov 12, 2013 at 3:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
...
One thought for the Clang people
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com 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?
On Tue, Nov 12, 2013 at 3:35 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-12 15:33:13 -0500, Jeffrey Walton wrote:
On Tue, Nov 12, 2013 at 3:25 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
...
It might not recognize our
On Tue, Nov 12, 2013 at 11:47 AM, Devrim GÜNDÜZ dev...@gunduz.org 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
On 11/12/2013 03:54 PM, Nigel Heron wrote:
On Tue, Nov 12, 2013 at 11:47 AM, Devrim GÜNDÜZ dev...@gunduz.org 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?
On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us 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
2013/11/2 Simon Riggs si...@2ndquadrant.com:
On 29 October 2013 16:10, Peter Geoghegan p...@heroku.com 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
2013/11/12 Nicolas Barbier nicolas.barb...@gmail.com:
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
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 nicolas.barb...@gmail.com 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
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?
I
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
nicolas.barb...@gmail.com 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%
Peter Eisentraut pete...@gmx.net 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
On Tue, Nov 12, 2013 at 6:04 PM, Kevin Grittner kgri...@ymail.com wrote:
Peter Eisentraut pete...@gmx.net 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
On 8.11.2013 16:13, Albe Laurenz wrote:
Tom Lane wrote:
Albe Laurenz laurenz.a...@wien.gv.at 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?
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
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
On Tue, Nov 12, 2013 at 5:19 PM, Peter Eisentraut pete...@gmx.net 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
On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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
Jeffrey Walton noloa...@gmail.com writes:
On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar dilip.ku...@huawei.com 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
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar dilip.ku...@huawei.com 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
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 have
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 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
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
1 - 100 of 111 matches
Mail list logo
