On Fri, Feb 10, 2012 at 7:00 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 08-02-2012 09:35, Fujii Masao wrote:
Fujii, new patch attached. Thanks for your tests.
Thanks for the new patch!
But another problem happened. When I changed pg_proc.h so that the unused
OID was assigned
On Thu, Feb 09, 2012 at 11:11:16PM +0200, Marti Raudsepp wrote:
I've always been a little wary of using the TRUNCATE command due to
the warning in the documentation about it not being MVCC-safe:
queries may silently give wrong results and it's hard to tell when
they are affected.
That got
(2011/12/15 11:30), Etsuro Fujita wrote:
(2011/12/14 15:34), Shigeru Hanada wrote:
I think this patch could be marked as Ready for committer with some
minor fixes. Please find attached a revised patch (v6.1).
I've tried to make pgsql_fdw work with this feature, and found that few
static
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word
2012/2/10 Robert Haas robertmh...@gmail.com:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus.
On 10/02/12 08:50, Robert Haas wrote:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
That seems pretty useful, and it's more or less a one-line change, as in
the attached patch.
That seems pretty nearly entirely bogus. What
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a function name?
It isn't necessarily, but it might be. It'd
On 9 February 2012 14:51, Robert Haas robertmh...@gmail.com wrote:
I'm not sure I entirely follow all this, but I'll look at the code
once you have it.
I have attached a revision of the patch, with the adjustments already
described. Note that I have not made this support btree tuplesorting
yet,
On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Attached is a proposed patch to deal with the issue described here:
http://archives.postgresql.org/pgsql-bugs/2012-02/msg0.php
Even though we'd previously realized that comparing the text of
inherited CHECK expressions is
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Although this is a bug fix, it's a nontrivial change in the logic and
so I'm hesitant to back-patch into stable branches. Given the lack of
prior complaints, maybe it would be best to
On Fri, Feb 10, 2012 at 10:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Although this is a bug fix, it's a nontrivial change in the logic and
so I'm hesitant to back-patch into stable
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not against tab-completing functions, if people think that's
useful. I am against tab-completing them in 1% of use-cases, which is
what this patch accomplishes. The fact that
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not against tab-completing functions, if people think that's
useful. I am against tab-completing them in 1%
In view of the recently fixed data-corruption issues in hot standby
operation (bugs 6200, 6425), the core team feels we should push out back
branch update releases soon. Due to unavailability of some key people,
the earliest feasible schedule turns out to be wrap Thursday 2/23 for
public release
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you want a patch with low standards, what about tab-completing
function names anywhere that we do not see context suggesting something
else?
I think that without a bit more
On Fri, Feb 10, 2012 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you want a patch with low standards, what about tab-completing
function names anywhere that we do not see
Dear hackers,
Thanks for the work on PLPython result metadata, it is very useful! I
just came across a crash when trying to access this metadata on the
result of an UPDATE, which obviously cannot return any tuple (unless
you specify a RETURNING clause maybe?).
Please find attached a patch that
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Haas wrote:
One thing that's been bugging me for a while is that the tab
completion code all works by looking backward up to n words. What we
really want to know is what kind of statement we're in and where we
are in it. Absent
The auto_explain module appears to create invalid JSON (in all versions
since 9.0). For example, with the settings
auto_explain.log_format = 'json'
auto_explain.log_min_duration = 0
the query
select * from pg_type;
produces this in the log:
LOG: duration: 529.808 ms plan:
[
Robert Haas robertmh...@gmail.com writes:
... I'd lean toward back-patching.
Not hearing any contrary opinions, that's what I've done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, Feb 10, 2012 at 6:42 AM, Noah Misch n...@leadboat.com wrote:
I like the design you have chosen. It would find applications beyond
TRUNCATE, so your use of non-specific naming is sound. For example, older
snapshots will see an empty table t after CREATE TABLE t AS SELECT 1
commits;
On Feb 9, 2012 1:27 AM, Robert Haas robertmh...@gmail.com
However, there is a potential fly in the ointment: in other cases in
which we've reduced contention at the LWLock layer, we've ended up
with very nasty contention at the spinlock layer that can sometimes
eat more CPU time than the
On Fri, Feb 10, 2012 at 7:01 PM, Ants Aasma ants.aa...@eesti.ee wrote:
On Feb 9, 2012 1:27 AM, Robert Haas robertmh...@gmail.com
However, there is a potential fly in the ointment: in other cases in
which we've reduced contention at the LWLock layer, we've ended up
with very nasty contention
On 2/8/12 6:17 AM, Christian Nicolaisen wrote:
Hi
We have some tables with documents and their metadata (filename, filetype, etc).
Most of the time we just want to get the metadata (filename, filetype, etc) and
not the document itself.
In this case it would be nice to have the metadata (which
On Fri, Feb 10, 2012 at 2:23 PM, Jim Nasby j...@nasby.net wrote:
On 2/8/12 6:17 AM, Christian Nicolaisen wrote:
We have some tables with documents and their metadata (filename, filetype,
etc).
Most of the time we just want to get the metadata (filename, filetype,
etc) and not the document
On Thu, Feb 9, 2012 at 03:21, Christoph Berg c...@df7cb.de wrote:
Hi,
we have a database that is storing strings in various encodings (and
non-encodings, namely the arbitrary byte soup [ ... ]
For this reason, the database uses
sql_ascii encoding
...snip...
In sql_ascii databases,
I wrote:
Now, back to the original subject of this thread: both HEAD and 9.1 are
now operating as designed, in that they will dump the (user-provided
portion of the) contents of an extension config table whenever that
extension is dumped, even if --schema is specified.
Or so I thought,
All,
Andrew ran crake on these modules, and they do not add any links not
added by core postgres already.
As such, can we proceed with this patch? Greg, do you have an updated
version to run against HEAD?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
On sön, 2012-02-05 at 10:53 -0800, Jeff Davis wrote:
initdb should do these syncs by default and offer an option to
disable them.
For test frameworks that run initdb often, that makes sense.
But for developers, it doesn't make sense to spend 0.5s typing an
option
that saves you 0.3s.
On 2/7/12 8:14 AM, Alvaro Herrera wrote:
Having one sequence for each toast table could be wasteful though. I
mean, sequences are not the best use of shared buffer cache currently.
If we could have more than one sequence data in a shared buffer page,
things would be different. Not sure how
I wonder if somewhere in Postgres source we are relying on the GCC
correct behaviour regarding the read-modify-write of bitfield in
structures.
Take a read at this https://lwn.net/Articles/478657/
sorry if this was already mentioned.
Regards
Gaetano Mendola
--
Sent via pgsql-hackers mailing
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
While chasing a PL/Python memory leak, I did a few tests with PL/pgSQL
and I think there are places where memory is not freed sufficiently early.
I think the basic issue here is that the type output function might
generate (and not
On Fri, Feb 10, 2012 at 01:59:18PM -0500, Robert Haas wrote:
On Fri, Feb 10, 2012 at 6:42 AM, Noah Misch n...@leadboat.com wrote:
I like the design you have chosen. ?It would find applications beyond
TRUNCATE, so your use of non-specific naming is sound. ?For example, older
snapshots will
34 matches
Mail list logo
