2009/5/13 Joshua Tolley :
> On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
>> this patch has some bugs but it is good prototype (it's more stable
>> than old patch):
>
> I'm not sure if you're at the point that you're interested in bug reports, but
> here's something that didn't beh
On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:
Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather
than
just focus on one method.
I have to distinct problems with idle in transaction. One is
reporting users / the to
On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
> this patch has some bugs but it is good prototype (it's more stable
> than old patch):
I'm not sure if you're at the point that you're interested in bug reports, but
here's something that didn't behave as expected:
5432 j...@josh*#
Robert Haas wrote:
> On Thu, Apr 30, 2009 at 8:36 AM, Peter Eisentraut wrote:
> > The archives for this thread
> >
> > http://archives.postgresql.org//pgsql-hackers/2009-04/threads.php#01329
> >
> > show a bunch of missing messages. ?Were they being stored in a temporary
> > table?
> >
> > Anywher
On Tue, May 12, 2009 at 12:10, Alex Hunsaker wrote:
> On Mon, May 11, 2009 at 21:18, Tom Lane wrote:
>
>> However, he can do that anyway via ALTER TABLE, which
>> will happily take out AccessExclusiveLock before it checks any
>> permissions. So I'm not seeing the point of risking unsafe behavior
I've been poking at the problems described here:
http://archives.postgresql.org/message-id/20090306191404.gk3...@alvh.no-ip.org
http://archives.postgresql.org/message-id/5265.1240417...@sss.pgh.pa.us
I've about come to the conclusion that the only real fix is to abandon
our attempt to manage libxm
Erik Rijkers wrote:
> One complication: I hadn't noticed
> that there were 2 tables with a not yet
> installed datatype. These tables were
> simply not created by the pg_migrator-run.
>
> I don't know how this influenced the results,
> but I'll repeat it in the coming days.
I have modified pg_mi
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Erik Rijkers" writes:
> > > On Sun, May 10, 2009 02:05, Alvaro Herrera wrote:
> > >> I'm wondering that it could have forgotten to migrate the later table
> > >> segments ...
> >
> > > It seems al 'truncated' tables give
> > > pg_relation_size(oid) = 10
Hello all!
If no one objecte (all agree, in other say) i continue work on patch -
particulary, i want support second strategy (tuple store instead of
hash-table) for save order of source (more cheap solution in case with
grouping sets + order by), investigate and brainstorm another
optimisation, wr
On Tue, 2009-05-12 at 17:10 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > If we're going to require cascaded permissions like this, would it make
> > sense to make GRANT cascade down the inheritance tree also?
>
> That's been discussed before. I forget whether we decided it was a good
> ide
Simon Riggs writes:
> If we're going to require cascaded permissions like this, would it make
> sense to make GRANT cascade down the inheritance tree also?
That's been discussed before. I forget whether we decided it was a good
idea or not, but in any case it looks like a new feature not a bug
On Tue, 2009-05-12 at 16:43 +, Tom Lane wrote:
> Fix LOCK TABLE to eliminate the race condition that could make it give weird
> errors when tables are concurrently dropped. To do this we must take lock
> on each relation before we check its privileges. The old code was trying
> to do that t
Khee Chin writes:
> My sincere apologies for flooding your mailboxes once again, as the
> patch attached in the previous post was incorrect. Also, I had failed
> to show test-cases of \d in both 8.4 and 8.3 servers.
This is still modifying the behavior of \di, which I thought was not
wanted.
On Tue, 2009-05-12 at 14:38 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
> >
> >> Here's another idea: Let's modify xlog.c so that when the server asks
> >> for WAL file X, and restore_command returns "not found", the serv
On Mon, May 11, 2009 at 11:18 PM, Tom Lane wrote:
> So I'm not seeing the point of risking unsafe behavior
> in LOCK TABLE.
Me neither.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
--On Mittwoch, Mai 06, 2009 19:04:21 -0400 Tom Lane
wrote:
So I'm now persuaded that a better textual representation for bytea
should indeed make things noticeably better here. It would be
useful though to cross-check this thought by profiling a case that
dumps a comparable volume of text dat
Simon Riggs wrote:
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns "not found", the server
will not ask for any WAL files >= X again (in that recovery session).
Presum
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
> Here's another idea: Let's modify xlog.c so that when the server asks
> for WAL file X, and restore_command returns "not found", the server
> will not ask for any WAL files >= X again (in that recovery session).
> Presumably if X do
Fujii Masao wrote:
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
wrote:
This is getting complicated, though. I guess it would be enough to document
that you mustn't copy any extra files into pg_xlog if you use a fast
trigger.
Agreed. I added this note into document.
Attached is the upd
19 matches
Mail list logo
