On Fri, Dec 25, 2009 at 3:10 PM, Robert Haas wrote:
> On Fri, Dec 25, 2009 at 2:30 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Works for me. One small problem discussed upthread is that there
>>> currently doesn't appear to be a libpq function that does
>>> ident-quoting. I'm thinking that
On Sun, Dec 27, 2009 at 2:16 PM, Robert Haas wrote:
> On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
>> Bruce Momjian wrote:
>>> There are several pg_migrator limitations that appeared late in the 8.4
>>> development cycle and were impossible to fix at that point. I would
>>> like to fix
On Dec 20, 2009, at 12:03 AM, Tom Lane wrote:
> This looks like it's most likely redundant with the stuff I added
> recently for the plpgsql parser rewrite. Please see if you can use that
> instead.
The parser param hooks will definitely work. As for getting the result
TupleDesc prior to executi
We can define variables with any names in pgbench,
but only can refer them with names that consist of [A-Za-z0-9_]+ .
It could cause confusion discussed here:
http://archives.postgresql.org/message-id/4b272833.8080...@2ndquadrant.com
The attached patch verifies variable names at definition.
$
Hi Simon,
Btw, dont understand my questions as criticism or such. I am really impressed
by the quality of the HS patch - many thanks to you, heikki and all the
others.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Sunday 27 December 2009 23:10:09 Simon Riggs wrote:
> On Sun, 2009-12-27 at 20:12 +0100, Andres Freund wrote:
> > While unlikely to cause issues two new LWLockAcquire calls use the wrong
> > locking mode.
> > Patch attached.
> It's important to explain why you think something is a bug, rather th
On Sunday 27 December 2009 21:04:43 Simon Riggs wrote:
> On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
> > On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
> > > On Tue, 2009-12-22 at 03:19 +0100, Andres Freund wrote:
> > > > On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
>
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
> On Tue, 2009-12-22 at 03:19 +0100, Andres Freund wrote:
> > On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
> > > Giving the drop database a snapshot is not the answer. I expect Andres
> > > to be able to fix this with a simple patch
Le 13/11/2009 12:11, Dave Page a écrit :
> [...]
>> What about pg_dump/psql setting fallback_application_name?
>
> Per Tom, I'm waiting on the possible new array-based libpq connect API
> which will make a conversion of those utilities from PQsetdbLogin a
> lot cleaner than moving to PQconnectdb (
On Sun, Dec 27, 2009 at 5:15 PM, Bruce Momjian wrote:
>> Is that something we're comfortable adding in the final commitfest?
>
> Uh, no idea. It would be nice, of course.
Do we know if there's active development in progress on page CRCs? If
so, when can we expect to see a working patch?
With r
Greg Stark wrote:
> On Sun, Dec 27, 2009 at 8:13 PM, Bruce Momjian wrote:
> > Well, I think the checksums are going in the item pointers, so there
> > isn't any new storage space --- my guess is that the page version number
> > will control how the backend stores the checksum. ?Basically the backe
On Sun, 2009-12-27 at 20:12 +0100, Andres Freund wrote:
> While unlikely to cause issues two new LWLockAcquire calls use the wrong
> locking mode.
> Patch attached.
It's important to explain why you think something is a bug, rather than
make that claim on its own.
The locking mode was intention
On Sat, 2009-12-26 at 20:15 -0500, Kris Jurka wrote:
> The JDBC driver's regression test suite has revealed a change in behavior
> introduced by the hot standy patch. Previously when a client sent a
> cancel request on an idle connection, nothing happened. Now it sends an
> error message "ERR
On Sun, Dec 27, 2009 at 3:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> If we're really doing it, sure. But putting half of it in
>> TopMemoryContext and the other half in CacheMemoryContext is not
>> obviously of any value.
>
> There isn't any of that stuff that's *in* TopMemoryContext. Whet
On Sun, Dec 27, 2009 at 8:13 PM, Bruce Momjian wrote:
> Well, I think the checksums are going in the item pointers, so there
> isn't any new storage space --- my guess is that the page version number
> will control how the backend stores the checksum. Basically the backend
> will need to read old
Greg Stark wrote:
> I'm kind of curious about the heap page conversion plan. I think
> we have a plan for how to do page checksums now if someone
> submits it now will we have time to do the page wok to handle
> page conversions? Or if not, are we better off waiting till 8.6
> to get checksums?
We
On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
> On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
> > On Tue, 2009-12-22 at 03:19 +0100, Andres Freund wrote:
> > > On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
> > > > Giving the drop database a snapshot is not the answer. I
Robert Haas writes:
> If we're really doing it, sure. But putting half of it in
> TopMemoryContext and the other half in CacheMemoryContext is not
> obviously of any value.
There isn't any of that stuff that's *in* TopMemoryContext. Whether the
hash table contexts are children of TopMemoryConte
On Sun, Dec 27, 2009 at 2:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> it does make me wonder whether there's any point in retaining
>> CacheMemoryContext at all.
>
> Well, as per backend/utils/mmgr/README:
>
> CacheMemoryContext --- permanent storage for relcache, catcache, and
> related mo
Robert Haas writes:
> it does make me wonder whether there's any point in retaining
> CacheMemoryContext at all.
Well, as per backend/utils/mmgr/README:
CacheMemoryContext --- permanent storage for relcache, catcache, and
related modules. This will never be reset or deleted, either, so it's
On Sun, Dec 27, 2009 at 12:59 PM, Tom Lane wrote:
> My inclination is to leave the actual memory allocation behavior alone
> and just get rid of the CreateCacheMemoryContext calls in these places.
I don't have a strong feeling on it. It is only one extra line of
code to make the hash table conte
On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> There are several pg_migrator limitations that appeared late in the 8.4
>> development cycle and were impossible to fix at that point. I would
>> like to fix them for Postgres 8.5:
>>
>> o a user-defined comp
Hi,
While unlikely to cause issues two new LWLockAcquire calls use the wrong
locking mode.
Patch attached.
Andres
From e70524baa7399972e51345d81b50377d7f15196d Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Sun, 27 Dec 2009 17:28:39 +0100
Subject: [PATCH 1/2] Use correct locking at two func
Robert Haas writes:
> I was just taking a look at find_oper_cache_entry() and noticed
> something odd. When we discover that OprCacheHash == NULL, we make
> sure that CacheMemoryContext is initialized before calling
> hash_create(). But since we don't pass HASH_CONTEXT to hash_create(),
> ISTM i
I'm kind of curious about the heap page conversion plan. I think we have a plan
for how to do page checksums now if someone submits it now will we have time to
do the page wok to handle page conversions? Or if not, are we better off
waiting till 8.6 to get checksums?
"Bruce Momjian" wrote:
>B
Bruce Momjian wrote:
> There are several pg_migrator limitations that appeared late in the 8.4
> development cycle and were impossible to fix at that point. I would
> like to fix them for Postgres 8.5:
>
> o a user-defined composite data type
> o a user-defined array data type
>
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian writes:
> > > > > Tom Lane wrote:
> > > > >> The reason I don't want to do it that way is that then you need two
> > > > >> ugly kluges in the backend, not just one. With the zero-and-
27 matches
Mail list logo
