http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguardt=2010-01-05%2004:00:03
(and the same a couple times before this...)
Core was generated by `postgres: autovacuum worker process regression
'.
Program terminated with signal 6, Aborted.
[New process 9209]
Robert,
On Mon, 4 Jan 2010, Robert Haas wrote:
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey pram...@cleverelephant.ca wrote:
I'm sure whatever conclusion -hackers comes to in the end will be the
best for pgsql, and I'll be supportive. But until then, let me note
from the PostGIS point-of-view:
Hi all!
There will be planned downtime on tribble.postgresql.org Jan 6(tomorrow)
from 10:00-12:30 GMT(estimated) affecting the following services:
cvs.postgresql.org
wwwmaster.postgresql.org
www.pgadmin.org
doxygen.postgresql.org
Downtime is necessary to implement some OS level updates (both
Hi,
Why PG uses a flat file (global\pg_auth) for md5 authentication!? Is it
forced to do it instead of accessing relevant table is system catalog?
Thanks - B. L.
Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 1, 2010 at 20:45, Magnus Hagander mag...@hagander.net wrote:
On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada tsut...@sraoss.co.jp wrote:
2) use appropriate macro and datatypes for Windows API.
enables more than 32bits shared
On Tuesday 05 January 2010 09:37:57 black light wrote:
Hi,
Why PG uses a flat file (global\pg_auth) for md5 authentication!? Is it
forced to do it instead of accessing relevant table is system catalog?
It does not anymore:
You might want to search the archives (or the wiki history, or the CVS
history if it's been there since before we moved the TODO list to the
wiki) for discussion of why that item was added to the TODO in the
first place.
I read the thread:
As part of a research project I would like to change the source code of
Postgres. There, I want to do the following: I want to stop the optimizer at
some place, issue a query from the optimizer and use the result of the query
to continue the optimization process.
Is there a good and clean way how
There is likely to be a long period where many Windows packages for
PostgreSQL are 32 bit only. Due to the way Windows searches for DLLs,
Windows installations of PostgreSQL tend to install libpq.dll into the
bin/ directory of the installation. This will cause obvious problems
with 32 bit packages
On Tue, Jan 5, 2010 at 09:14, Tsutomu Yamada tsut...@sraoss.co.jp wrote:
Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 1, 2010 at 20:45, Magnus Hagander mag...@hagander.net wrote:
On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada tsut...@sraoss.co.jp
wrote:
2) use appropriate
Magnus Hagander mag...@hagander.net wrote:
2009/12/4 Tsutomu Yamada tsut...@sraoss.co.jp:
Thanks to suggestion.
I send pathces again by another mailer for the archive.
Sorry to waste resources, below is same content that I send before.
I have a couple of comments about the
Hi,
Kevin Grittner wrote:
It's very soon going to be critical that I be able to test particular
interleavings of statements in particular concurrent transaction sets
to be able to make meaningful progress on the serializable
transaction work.
I've something in place for Postgres-R, as I also
Hi,
My suggestion is to keep two sets of histograms. One which is generated by
running ANALYZE and
the other which is dynamically generated histograms using the entries from
logging (that is done
in insert/update/delete operations).
I am not sure how difficult is it to read such record details
2010/1/5 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I don't have a problem to write second and safe fmtId
function (with technique used in dumputils don't need to modify
libpq), although
On Sun, Jan 3, 2010 at 05:13, Andrew Dunstan and...@dunslane.net wrote:
Peter Eisentraut wrote:
On fre, 2010-01-01 at 16:32 +0100, Magnus Hagander wrote:
I therefor propose that we rename this file to config.pl.default,
and change the scripts to first load config.pl.default, and then load
On Tue, Jan 5, 2010 at 12:58, Tsutomu Yamada tsut...@sraoss.co.jp wrote:
Magnus Hagander mag...@hagander.net wrote:
2009/12/4 Tsutomu Yamada tsut...@sraoss.co.jp:
Thanks to suggestion.
I send pathces again by another mailer for the archive.
Sorry to waste resources, below is
Robert Wittauer wrote:
As part of a research project I would like to change the source code of
Postgres. There, I want to do the following: I want to stop the optimizer at
some place, issue a query from the optimizer and use the result of the query
to continue the optimization process.
Is
On 5/01/2010 6:52 PM, Dave Page wrote:
There is likely to be a long period where many Windows packages for
PostgreSQL are 32 bit only. Due to the way Windows searches for DLLs,
Windows installations of PostgreSQL tend to install libpq.dll into the
bin/ directory of the installation. This will
Looking at the latest streaming replication patch, I don't much like the
signaling between WAL sender and postmaster. It seems complicated, and
as a rule of thumb postmaster shouldn't be accessing shared memory. The
current signaling is:
1. A new connection arrives. A new backend process is
2010/1/5 Craig Ringer cr...@postnewspapers.com.au:
It would also be a nice touch to have the 64 bit MSVC build system
create both the 64 and 32 bit libraries. That would make it much
easier for those of us that need to combine 32 and 64 bit packages
together, saving the pain of building 32 and
On Tue, Jan 5, 2010 at 12:56 AM, black light blacklight1...@gmail.com wrote:
Hi,
I want to add some hard-wired extra authentication codes in my PG. The only
problem is how to access tables to get/change information from core
(auth.c)?
I have changed the SPI functions to use them but it was
Heikki Linnakangas escribió:
Looking at the latest streaming replication patch, I don't much like the
signaling between WAL sender and postmaster. It seems complicated, and
as a rule of thumb postmaster shouldn't be accessing shared memory. The
current signaling is:
1. A new connection
On Tue, Jan 5, 2010 at 7:49 AM, Chetan Suttraway
chetan.suttra...@enterprisedb.com wrote:
if we can treat this case as similar to that of merging of histograms in
case of joins involving 2 tables and generating the histograms for the
cartesian (result) node,
...which you can't, because it's
On Tue, Jan 5, 2010 at 3:58 AM, Leonardo F m_li...@yahoo.it wrote:
You might want to search the archives (or the wiki history, or the CVS
history if it's been there since before we moved the TODO list to the
wiki) for discussion of why that item was added to the TODO in the
first place.
I
Dave Page dp...@pgadmin.org writes:
After chatting with Magnus, we feel that a good solution would be to
rename libpq on Win64 to libpq64.dll to distinguish it from the 32 bit
equivalent.
Isn't that going to break applications? Where by break I mean
have to explicitly link with 'libpq64',
On Mon, Jan 4, 2010 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
My only objection to that is that if we're going to add attoptions
also, I'd like to get this committed first before I start working on
that, and we're running short on time. If you
On mån, 2010-01-04 at 21:58 -0500, Tom Lane wrote:
The old Gen_fmgrtab.sh script used temporary file names that included
its process PID. It had this comment about that:
# We use the temporary files to avoid problems with concurrent runs
# (which can happen during parallel make).
The new
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Alvaro Herrera wrote:
I thought it was impossible to use bare mountpoints as tablespaces due
to ownership problems ... Is that not the case? -1 for special hacks
that work around bogus setups, if that means intrusive changes to the
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 5, 2010 at 12:56 AM, black light blacklight1...@gmail.com wrote:
In fact, i want to add a table to system catalog and SELECT/UPDATE it from
auth.c.
If you are considering proposing your patch for inclusion in the
PostgreSQL upstream
On mån, 2010-01-04 at 22:54 -0500, Robert Haas wrote:
I think you're dismissing the idea too cavalierly. If A generates B,
A is inevitably changed frequently, but the changes to A affect B only
rarely, this is a good trick.
If that is the case, you might want to consider splitting up A or
Peter Eisentraut pete...@gmx.net writes:
On mån, 2010-01-04 at 21:58 -0500, Tom Lane wrote:
The new implementation uses temp files that just have .tmp appended to
the target file name. If there is a risk that make -j will run the
same action twice in parallel, this isn't good enough. While
As you say, there's really no point in changing the internal
representation, and if you don't find replace() useful either, then
why are you even working on this at all?
I would like a get_bit / set_bit for bit strings, as I find them useful.
get_bit could be a simple call to substring, but
As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest
of the system to support such compilers, it's a bit annoying to
have this little
Bruce Momjian br...@momjian.us writes:
I liked the idea, but I listed it as item #2 and no one else said they
liked it. The only complexity I can see with the idea is that doing an
upgrade from one alpha to another would have the same major version
number and would therefore not be possible,
Tom Lane wrote:
As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest
of the system to support such compilers, it's a bit
On Tue, Jan 5, 2010 at 10:45 AM, Leonardo F m_li...@yahoo.it wrote:
As you say, there's really no point in changing the internal
representation, and if you don't find replace() useful either, then
why are you even working on this at all?
I would like a get_bit / set_bit for bit strings, as I
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I liked the idea, but I listed it as item #2 and no one else said they
liked it. The only complexity I can see with the idea is that doing an
upgrade from one alpha to another would have the same major version
number and would
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I liked the idea, but I listed it as item #2 and no one else said they
liked it. The only complexity I can see with the idea is that doing an
upgrade
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Good point. Using catversion for the purpose seems a bit ugly but
I have no better ideas.
I thought we had rejected the idea of being able to migrate
On Tue, Jan 05, 2010 at 10:47:33AM -0500, Tom Lane wrote:
As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest of
the system to
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Good point. ?Using catversion for the purpose seems a bit ugly but
I have no better ideas.
I thought we had rejected the idea
Magnus Hagander wrote:
On Thu, Dec 31, 2009 at 00:57, Magnus Hagander mag...@hagander.net wrote:
2009/12/31 Hiroshi Inoue in...@tpf.co.jp:
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue in...@tpf.co.jp:
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on
Markus Wanner mar...@bluegap.ch wrote:
Kevin Grittner wrote:
It's very soon going to be critical that I be able to test
particular interleavings of statements in particular concurrent
transaction sets to be able to make meaningful progress on the
serializable transaction work.
I've
On Mon, Jan 04, 2010 at 07:39:14PM +0100, Boszormenyi Zoltan wrote:
new patch attached.
...
Great job Zoltan, committed.
The sqlda.h header switches between the two different
structures depending on a new #define introduced in
and added to the generated C source by the preprocessor
I
On Mon, Jan 04, 2010 at 02:32:56PM -0500, Tom Lane wrote:
I think checking SIZEOF_LONG would be preferred, since that's what
we use elsewhere. Although actually I wonder why this code exists
at all --- wouldn't it be easier to make these depend on int64?
It does use int64. However, ecpg uses
On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
After chatting with Magnus, we feel that a good solution would be to
rename libpq on Win64 to libpq64.dll to distinguish it from the 32 bit
equivalent.
Isn't that going to break
On Tue, Jan 5, 2010 at 4:42 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
= with t as (delete from foo returning *)
- insert into bar
- select * from t;
INSERT 0 2
It correctly reports 2 affected rows (one deleted and one inserted), but is
this the answer we want? It doesn't seem
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
catalog header files. This greatly simplifies modification of the
bootstrapped catalogs.
This patch finally
On Tue, Jan 05, 2010 at 05:21:12PM +, Greg Stark wrote:
On Tue, Jan 5, 2010 at 4:42 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
= with t as (delete from foo returning *)
- insert into bar
- select * from t;
INSERT 0 2
It correctly reports 2 affected rows (one deleted
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
this broke the build on spoonbill:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbilldt=2010-01-05%2015:05:08
manually executing the command shows that the perl process eats more
than 250MB of RAM at closely afterwards fails
On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
catalog header files.
On 2010-01-05 19:21 +0200, Greg Stark wrote:
with t as (delete from foo returning *)
select * from t where x=?
applications will almost certainly expect the number to match the
actual number of rows returned and may well misbehave if they don't.
I probably wasn't clear about the actual
Robert Haas wrote:
On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Tom Lane wrote:
Log Message:
---
Get rid of the need for manual maintenance of the initial contents of
pg_attribute, by having genbki.pl derive the information from the various
Robert Haas robertmh...@gmail.com writes:
Is there by any chance some other, conflicting Catalog.pm on that machine?
Even if there is, shouldn't the use of perl -I ensure our version gets
loaded?
Also, Stefan's log shows that it got through genbki.pl, so whatever the
problem is, I don't think
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yep. It would also lower the barrier to future innovations of that
type, which would be a good thing, IMO. Unfortunately we'd likely
need to continue to support the existing syntax
Robert Haas robertmh...@gmail.com writes:
Another option would be to call it inherits_ndistinct, or something
like that, which seems a little more readable, but not great: I don't
think there's going to be any getting around the need to RTFM before
setting these parameters.
Well, the
On Tue, Jan 5, 2010 at 12:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Is there by any chance some other, conflicting Catalog.pm on that machine?
Even if there is, shouldn't the use of perl -I ensure our version gets
loaded?
I would certainly think so.
On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another option would be to call it inherits_ndistinct, or something
like that, which seems a little more readable, but not great: I don't
think there's going to be any getting around
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array
of XML. So for example, to extract a numeric value you need to:
1) use xpath to get the node
2) get the first element of the XML array
3) cast that
Robert Haas robertmh...@gmail.com writes:
Beats me. I don't have any other ideas at the moment.
Stefan, could you try adding some debugging printouts to the
Gen_fmgrtab.pl script to see how far it gets before blowing up?
regards, tom lane
--
Sent via pgsql-hackers
On Tue, Jan 5, 2010 at 1:09 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 5, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another option would be to call it inherits_ndistinct, or something
like that, which seems a little more
Robert Haas robertmh...@gmail.com writes:
It's probably also worth noting that the reason I used DISTINCT
originally is because it's already a keyword.
True.
It occurs to me that the pg_stats view already exposes n_distinct
as a column name. I wouldn't object to using n_distinct and
On Tue, Jan 5, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's probably also worth noting that the reason I used DISTINCT
originally is because it's already a keyword.
True.
It occurs to me that the pg_stats view already exposes n_distinct
On Tue, Jan 5, 2010 at 1:14 PM, Scott Bailey arta...@comcast.net wrote:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array of
XML. So for example, to extract a numeric value you need to:
1) use xpath
2010/1/5 Scott Bailey arta...@comcast.net:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array of
XML. So for example, to extract a numeric value you need to:
1) use xpath to get the node
2) get the
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
= with t as (delete from foo returning *)
- insert into bar
- select * from t;
INSERT 0 2
It correctly reports 2 affected rows (one deleted and one inserted), but
is this the answer we want?
No. The returned tag should consider only
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Beats me. I don't have any other ideas at the moment.
Stefan, could you try adding some debugging printouts to the
Gen_fmgrtab.pl script to see how far it gets before blowing up?
did that and it seems the problem is in the loop that
On Tue, 2010-01-05 at 03:09 -0500, Tom Lane wrote:
I think this can likely be blamed on the HS changes in transaction
abort, since I'm not aware of any other recent changes near here.
I'll take a look.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list
On Mon, 2010-01-04 at 08:04 +, Simon Riggs wrote:
I would prefer this slightly modified version
1. Commit your patch, as-is (you/me)
I assume this is OK with you now?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on whitespace
Huh. It's
Stefan Kaltenbrunner escribió:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on whitespace
# won't work, because some quoted fields might contain internal
# whitespace. We
Hi,
Kevin Grittner wrote:
Where would I find this (and any related documentation)?
Sorry, if that didn't get clear. I'm trying to put together something I
can release real soon now (tm). I'll keep you informed.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list
Merlin Moncure wrote:
On Tue, Jan 5, 2010 at 1:14 PM, Scott Bailey arta...@comcast.net wrote:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array of
XML. So for example, to extract a numeric value you
I have a question regarding true serializability and predicate locking.
There's some context on the wiki page:
http://wiki.postgresql.org/wiki/Serializable
under the heading Predicate Locking.
If you have the following DDL:
create table mytable(mycircle circle);
create index
On tis, 2010-01-05 at 10:14 -0800, Scott Bailey wrote:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array
of XML. So for example, to extract a numeric value you need to:
1) use xpath to get the
On tis, 2010-01-05 at 16:48 +, Dave Page wrote:
On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would have thought Microsoft would have a better solution than this
for managing 64-bit libraries. Or am I too optimistic about Redmond's
competence?
They have two
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the individual data fields. Just splitting on
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
yeah it is probably some strange platform specific issue - however with
some help from the IRC channel I came up with the following patch that
considerable reduces the memory bloat (but still needs ~55MB max) and
allows the build to
On Tuesday, January 5, 2010, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-01-05 at 16:48 +, Dave Page wrote:
On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would have thought Microsoft would have a better solution than this
for managing 64-bit libraries. Or
Pavel Stehule wrote:
2010/1/5 Scott Bailey arta...@comcast.net:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array of
XML. So for example, to extract a numeric value you need to:
1) use xpath to get
Garick Hamlin gham...@isc.upenn.edu writes:
On Tue, Jan 05, 2010 at 02:02:51PM -0500, Tom Lane wrote:
I'm not nearly good enough in Perl to be sure about the semantics
of this loop. Is it possible that it's changing the global contents
of the @$data structure, rather than just hacking a local
On Tue, Jan 05, 2010 at 02:02:51PM -0500, Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
did that and it seems the problem is in the loop that does:
foreach my $row (@$data)
{
# To construct fmgroids.h and fmgrtab.c, we need to inspect some
# of the
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
yeah it is probably some strange platform specific issue - however with
some help from the IRC channel I came up with the following patch that
considerable reduces the memory bloat (but still needs ~55MB max) and
allows the
On Tue, Jan 5, 2010 at 2:14 PM, Jeff Davis pg...@j-davis.com wrote:
I have a question regarding true serializability and predicate locking.
There's some context on the wiki page:
http://wiki.postgresql.org/wiki/Serializable
under the heading Predicate Locking.
If you have the following
Jeff Davis pg...@j-davis.com wrote:
Clearly one of those transactions should abort, because that will
happen in either serialized order. But I don't see where any lock
is stored, nor how the conflict is detected.
That depends on where in the development cycle of this feature you
are. I'm
Peter Eisentraut wrote:
On tis, 2010-01-05 at 10:14 -0800, Scott Bailey wrote:
One of the problem with shredding XML is that it is very kludgy to get a
scalar value back from xpath. The xpath function always returns an array
of XML. So for example, to extract a numeric value you need to:
1)
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
What about Alvaro's idea of adding
$row = undef;
at the bottom of the loop? That seems marginally less ugly...
not sure I want to argue about the ugliness of perl but that has the
same effect as my patch so either way would do to get
Tom Lane wrote:
I'm not nearly good enough in Perl to be sure about the semantics
of this loop. Is it possible that it's changing the global contents
of the @$data structure, rather than just hacking a local copy of
each row before pushing some values into @fmgr?
That's exactly what it
Andrew Dunstan and...@dunslane.net writes:
Something like:
(my $bkival = $row-{bki_values}) =~ s/[^]*/xxx/g;
my $atts = {};
@{$att...@attnames} = split /\s+/, $bkival;
might work better.
I committed Alvaro's suggestion (undef at the bottom), but feel
free to clean it up if you
David Fetter da...@fetter.org writes:
On Tue, Jan 05, 2010 at 10:47:33AM -0500, Tom Lane wrote:
As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to
On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
On Dec 30, 2009, at 2:54 PM, Tim Bunce wrote:
That much works currently. Behind the scenes, when a stored procedure is
loaded into plperl the code ref for the perl sub is stored in a cache.
Effectively just
Alvaro Herrera wrote:
Bruce Momjian wrote:
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves
On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
of spi_* calls. Umm. I thought performance was a major driving factor.
Sounds like you're more keen on syntactic sugar.
I'm saying do both. Make the cached version the one that
On Tue, 2010-01-05 at 13:47 -0600, Kevin Grittner wrote:
I will not
spend any significant amount of time looking at the specifics of any
particular optimizations yet, because such premature optimization is
certain to kill the whole project.
I'm certainly not trying to derail the project, I'm
On tis, 2010-01-05 at 11:50 -0800, Scott Bailey wrote:
There has been talk about adding something like xpath_string,
xpath_number, xpath_boolean for fetching xpath expressions that
don't
return nodesets. I think that would fit your use case.
The first two sound very much like what I'm
On 1/5/10 9:45 AM, Marko Tiikkaja wrote:
On 2010-01-05 19:21 +0200, Greg Stark wrote:
with t as (delete from foo returning *)
select * from t where x=?
applications will almost certainly expect the number to match the
actual number of rows returned and may well misbehave if they don't.
I
Jeff Davis pg...@j-davis.com wrote:
Is a full table lock acceptable in the end? If so, then predicate
locking is just optimization, and we should leave it until later.
I think that the predicate locking will need to be RAM-based to
provide acceptable performance, and that we will need a
On Tue, Jan 05, 2010 at 01:05:40PM -0800, David E. Wheeler wrote:
On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
of spi_* calls. Umm. I thought performance was a major driving factor.
Sounds like you're more keen on
On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yep. It would also lower the barrier to future innovations of that
type, which would be a good thing, IMO. Unfortunately we'd likely
need to continue to support the existing syntax
On Tue, Jan 5, 2010 at 4:20 PM, Josh Berkus j...@agliodbs.com wrote:
On 1/5/10 9:45 AM, Marko Tiikkaja wrote:
On 2010-01-05 19:21 +0200, Greg Stark wrote:
with t as (delete from foo returning *)
select * from t where x=?
applications will almost certainly expect the number to match the
1 - 100 of 124 matches
Mail list logo
