On Fri, Feb 10, 2012 at 01:59:18PM -0500, Robert Haas wrote:
> On Fri, Feb 10, 2012 at 6:42 AM, Noah Misch 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 bother to free) addi
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 mail
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 seri
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
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 m
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, any
On Thu, Feb 9, 2012 at 03:21, Christoph Berg 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, utf_e2u does
On Fri, Feb 10, 2012 at 2:23 PM, Jim Nasby 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 itself.
>
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 w
On Fri, Feb 10, 2012 at 7:01 PM, Ants Aasma wrote:
>
> On Feb 9, 2012 1:27 AM, "Robert Haas"
>
>> 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
On Feb 9, 2012 1:27 AM, "Robert Haas"
> 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 LWLock contention did
On Fri, Feb 10, 2012 at 6:42 AM, Noah Misch 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; that's a com
Robert Haas 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:
http://www.postgresql.org/mai
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:
[
-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
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 s
On Fri, Feb 10, 2012 at 11:22 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane 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 th
Robert Haas writes:
> On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane 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 contextual information that's l
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 M
On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane 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 accompl
Robert Haas writes:
> On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane 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 it's short doesn't make it
>> good.
On Fri, Feb 10, 2012 at 10:52 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane 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, ma
Robert Haas writes:
> On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane 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 leave it unfixed in existing
>> b
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane 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
On Thu, Feb 9, 2012 at 6:21 PM, Tom Lane 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 an entirely un
On 9 February 2012 14:51, Robert Haas 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, as there is an impe
Robert Haas writes:
> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane 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 certainly be nice to type:
> SELECT pg_si
On 10/02/12 08:50, Robert Haas wrote:
> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane wrote:
> > Peter Eisentraut 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
>
2012/2/10 Robert Haas :
> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane wrote:
>> Peter Eisentraut 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 th
On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane wrote:
> Peter Eisentraut 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 right after SELECT is a f
(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 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.
>
> Tha
On Fri, Feb 10, 2012 at 7:00 AM, Euler Taveira de Oliveira
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 to pg_xlog_
34 matches
Mail list logo
