On Fri, May 25, 2012 at 12:34:54PM -0400, Tom Lane wrote:
> Sandro Santilli writes:
> > I ended up providing an explicit mechanism to request interruption of
> > whatever the library is doing, and experimented (successfully so far)
> > requesting the interruption from a SIGINT handler.
>
> > Do y
Sorry, the OS is WindRiver Linux.
Yes , I am taking of the fast path locking patch discussed in the link
below.
http://postgresql.1045698.n5.nabble.com/bug-in-fast-path-locking-td5626629.html
Regards,
Harshitha
On Fri, May 25, 2012 at 7:09 PM, Tom Lane wrote:
> Harshitha S writes:
> > We are
On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
> On May24, 2012, at 18:42 , Kohei KaiGai wrote:
> > As we discussed, it causes a problem with approach to append
> > additional qualifiers to where clause implicitly, because it does
> > not solve the matter corresponding to the order
On May 27, 2012, at 12:53 PM, Tom Lane wrote:
> Another thing that can be deduced from those stack traces is that sinval
> resets were happening. For example, in the third message linked above,
> the heapscan is being done to load up a relcache entry for relation 2601
> (pg_am). This would be un
On lör, 2012-05-26 at 15:53 -0400, Tom Lane wrote:
> 2. Seeing that this is the first complaint since 9.0, should we decide
> that --disable-shared is no longer worth supporting? Seems like we
> should either make this case work or remove this switch.
I think the last remaining use was the QNX po
Noah Misch writes:
> On Sat, May 26, 2012 at 03:14:18PM -0400, Tom Lane wrote:
>> It seems clear to me that we should just disable syncscans for the
>> relcache reload heapscans. There is lots of downside due to breaking
>> the early-exit optimization in RelationBuildTupleDesc, and basically no
>
On Sat, May 26, 2012 at 03:14:18PM -0400, Tom Lane wrote:
> It seems clear to me that we should just disable syncscans for the
> relcache reload heapscans. There is lots of downside due to breaking
> the early-exit optimization in RelationBuildTupleDesc, and basically no
> upside. I'm inclined to
On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> I think we should rewrite the way we track the parents completely. Rather
> than keep a path stack attached to every node buffer, let's just maintain a
> second hash table that contains the parent
On 27-05-2012 10:45, Fujii Masao wrote:
> OK, let me propose another approach: add pg_size_pretty(int).
> If we do this, all usability and performance problems will be solved.
>
I wouldn't like to add another function but if it solves both problems... +1.
--
Euler Taveira de Oliveira - Timbir
I've been continuing to poke at this business of relcache-related
startup stalls, and have come to some new conclusions. One is that
it no longer seems at all likely that the pg_attribute rows for system
catalogs aren't at the front of pg_attribute, because the commands that
might be used to updat
Excerpts from Kohei KaiGai wrote on Fri, May 25,
2012 at 11:08 PM:
> If we assume RLS is applied when user has
> no privileges on tables, the current ExecCheckRTEPerms()
> always raises an error towards unprivileged users, prior to
> execution of queries.
> Isn't it preferable behavior to allow un
On tis, 2012-05-22 at 10:19 -0400, Robert Haas wrote:
> I think we should have made roles and tablespaces database
> objects rather than shared objects,
User names are global objects in the SQL standard, which is part of the
reason that the current setup was never seriously challenged.
--
Sent
On 05/27/2012 02:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
AIUI, for Tom's scheme to work pg_upgrade would need not to check
libraries that belonged to extension functions. Currently it simply
assumes that what is present in the old cluster is exactly what will be
needed in the new cluste
Hi,
I did another test using the same data and the same code, which I've
provided before and the performance of the single thread seems to be
degrading quadratically with the number of threads.
Here are the results:
Nthreads Time_to_execute_one_thread
1 8.1
2 7.8
3 8.1
4 9.0
5 10.2
6 11.4
7 1
Bruce Momjian writes:
> On Sun, May 27, 2012 at 11:31:12AM -0400, Tom Lane wrote:
>> I don't recall exactly what problems drove us to make pg_upgrade do
>> what it does with extensions, but we need a different fix for them.
> Uh, pg_upgrade doesn't do anything special with extensions, so it must
Andrew Dunstan writes:
> AIUI, for Tom's scheme to work pg_upgrade would need not to check
> libraries that belonged to extension functions. Currently it simply
> assumes that what is present in the old cluster is exactly what will be
> needed in the new cluster. Tom's proposed scheme would com
On 05/27/2012 12:50 PM, Bruce Momjian wrote:
On Sun, May 27, 2012 at 12:31:09PM -0400, Andrew Dunstan wrote:
On 05/27/2012 11:31 AM, Tom Lane wrote:
Having said that, I've got to also say that I think we've fundamentally
blown it with the current approach to upgrading extensions. Because w
On Sun, May 27, 2012 at 12:31:09PM -0400, Andrew Dunstan wrote:
>
>
> On 05/27/2012 11:31 AM, Tom Lane wrote:
> >
> >
> >Having said that, I've got to also say that I think we've fundamentally
> >blown it with the current approach to upgrading extensions. Because we
> >dump all the extension mem
On 05/27/2012 11:31 AM, Tom Lane wrote:
Having said that, I've got to also say that I think we've fundamentally
blown it with the current approach to upgrading extensions. Because we
dump all the extension member objects, the extension contents have got
to be restorable into a new database v
On Sun, May 27, 2012 at 12:08:14PM -0400, Bruce Momjian wrote:
> > > We are not writing a one-off pg_upgrade for JSON-backpatchers here.
> >
> > I tend to agree with that position, and particularly think that we
> > should not allow the not-community-approved design of the existing
> > JSON backpo
On Sun, May 27, 2012 at 11:31:12AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sun, May 27, 2012 at 08:48:54AM -0400, Andrew Dunstan wrote:
> >> "things like CREATE LANGUAGE plperl" is a rather vague phrase. The
> >> PL case could be easily handled by adding this to the query:
> >> OR EX
Bruce Momjian writes:
> On Sun, May 27, 2012 at 08:48:54AM -0400, Andrew Dunstan wrote:
>> "things like CREATE LANGUAGE plperl" is a rather vague phrase. The
>> PL case could be easily handled by adding this to the query:
>> OR EXISTS (SELECT 1 FROM pg_catalog.pg_language WHERE lanplcallfoid
>> =
On Sun, May 27, 2012 at 08:48:54AM -0400, Andrew Dunstan wrote:
>
> >I just realized the problem as part of debugging the report of a problem
> >with plpython_call_handler():
> >
> > http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php
> > http://archives.postgresql.org/pgsql-
On Sun, May 27, 2012 at 1:33 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Sat, May 26, 2012 at 9:30 AM, Tom Lane wrote:
>>> The argument for adding pg_size_pretty(numeric) was pretty darn thin in
>>> the first place, IMHO; it does not seem to me that it justified this
>>> loss of usability.
>
Hello
2012/5/27 hubert depesz lubaczewski :
> On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
>> I proposed new psql's format "shell". This format is optimized for
>> processing returned result in shell:
>
> While I generally like the idea, please note that safe reading output
> fro
On 05/27/2012 06:40 AM, Bruce Momjian wrote:
On Fri, May 25, 2012 at 11:08:10PM -0400, Bruce Momjian wrote:
On Fri, May 25, 2012 at 10:20:29AM -0400, Andrew Dunstan wrote:
pg_upgrade is a little over-keen about checking for shared libraries
that back functions. In particular, it checks for li
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
> I proposed new psql's format "shell". This format is optimized for
> processing returned result in shell:
While I generally like the idea, please note that safe reading output
from queries is possible, with COPY, and proper IFS, like
On Fri, May 25, 2012 at 11:08:10PM -0400, Bruce Momjian wrote:
> On Fri, May 25, 2012 at 10:20:29AM -0400, Andrew Dunstan wrote:
> > pg_upgrade is a little over-keen about checking for shared libraries
> > that back functions. In particular, it checks for libraries that
> > support functions create
On Thursday, May 24, 2012, Thom Brown wrote:
> On 24 May 2012 13:37, Magnus Hagander >
> wrote:
> > On Thu, May 24, 2012 at 2:34 PM, Thom Brown >
> wrote:
> >> On 24 May 2012 13:05, Magnus Hagander >
> wrote:
> >>> On Thu, Apr 19, 2012 at 1:00 PM, Thom Brown >
> wrote:
> On 10 April 2012 21:0
On Friday, May 25, 2012, Tom Lane wrote:
> Andres Freund > writes:
> > On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
> >> Where do you suggest the file be written to?
>
> > One could argue stats_temp_directory would be the correct place.
>
> No, that would be exactly the *wrong* place
On Friday, May 25, 2012, Peter Geoghegan wrote:
> On 25 May 2012 14:13, Magnus Hagander >
> wrote:
> > Here's a patch that does the two easy fixes:
> > 1) writes the file to a temp file and rename()s it over the main file
> > as it writes down. This removes the (small) risk of corruption because
>
31 matches
Mail list logo
