Hi,
It might be relevant for the whole discussion about inclusion of some form of
row level permissions, whatever based on, that there exist heaps of (in my
eyes conflicting) patents about row level permissions for relational
databases. I don't have any real clue about patent issues, but I
On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote:
Hello community,
Second time after migration 8.3.7 -- 8.4.1 I was caught by this
problem. Migration was 8 days ago.
(note, I never seen such situation on 8.3)
Is 8.4 configured similarly to 8.3?
Andres
--
Sent via
On Saturday 14 November 2009 15:33:00 Kevin Grittner wrote:
Andres Freund wrote:
On Saturday 14 November 2009 01:03:33 Kevin Grittner wrote:
It is in context format, applies cleanly, and passes make check.
Unfortunately the latter is not saying much - I had a bug
Hi,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
Updated patch attached. Per discussion, this:
- Changes the envvar name to PGAPPNAME
- Removes support for setting application_name in the startup packet,
and instead sends an explicit SET command as part of the connection
setup in
On Wednesday 25 November 2009 14:28:14 Dave Page wrote:
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund and...@anarazel.de wrote:
Hi,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
Updated patch attached. Per discussion, this:
- Changes the envvar name to PGAPPNAME
- Removes
On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund and...@anarazel.de wrote:
One more question: Per my reading of the discussion (which very well
might be flawed), wasnt the plan to limit the availale
On Sunday 29 November 2009 00:47:49 Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Applied with assorted editorialization. There were a couple of
Hi,
On Monday 30 November 2009 01:16:43 Florian G. Pflug wrote:
Tom Lane wrote:
: One possibility would be to make it possible to issue SETs that
behave : as if set in a startup packet - imho its an implementation
detail that : SET currently is used.
I think there's a good deal of
On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote:
Boszormenyi Zoltan z...@cybertec.at wrote:
we tried to discuss on a lower level what should be needed
for a partial replication based on streaming replication.
We need to discuss a partial recovery before the partial replication.
If
On Monday 30 November 2009 10:32:50 Stefan Kaltenbrunner wrote:
Andres Freund wrote:
On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote:
Boszormenyi Zoltan z...@cybertec.at wrote:
we tried to discuss on a lower level what should be needed
for a partial replication based
On Monday 30 November 2009 17:46:45 Hans-Jürgen Schönig wrote:
On Nov 30, 2009, at 10:32 AM, Stefan Kaltenbrunner wrote:
the question is if filtering on the sending side is actually the
right thing to do.
It increases the overhead and the complexity on the master,
especially if you think
On Tuesday 01 December 2009 01:11:13 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Le 30 nov. 2009 à 22:38, Robert Haas a écrit :
I still don't really understand why we wouldn't want RESET ALL to
On Tuesday 01 December 2009 09:59:17 Dave Page wrote:
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund and...@anarazel.de wrote:
Actually I think the poolers make a good case for a SET variant which
emulates connection set variables...
RESET ALL in a connection pooler does different things
On Tuesday 01 December 2009 10:16:45 Heikki Linnakangas wrote:
Dave Page wrote:
Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
could be used to set the default GUC value that RESET would revert to.
This seems to me to be the ideal solution, and I'd somewhat hesitantly
On Tuesday 01 December 2009 14:38:26 marcin mank wrote:
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a CRC check. When a dirty
block is written to disk we
On Tuesday 01 December 2009 15:26:21 Aidan Van Dyk wrote:
* Andres Freund and...@anarazel.de [091201 08:42]:
On Tuesday 01 December 2009 14:38:26 marcin mank wrote:
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote
Hi,
On Friday 04 December 2009 17:36:00 Dave Page wrote:
Version EOL Date
PostgreSQL 7.4July 2010 (extended)
PostgreSQL 8.0July 2010 (extended)
PostgreSQL 8.1November 2010
PostgreSQL 8.2December 2011
PostgreSQL 8.3February 2013
On Monday 07 December 2009 02:12:43 Greg Smith wrote:
After getting off to a good start, it looks like this patch is now stuck
waiting for a second review pass from Kevin right now, with no open
items for Andres to correct. Since the only issues on the table seem to
be that of code aesthetics
On Monday 07 December 2009 21:44:37 Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
In particular I wonder why we bother with the page headers.
Since we re-use the file for a new segment, without overwriting
On Tuesday 08 December 2009 16:23:11 Kevin Grittner wrote:
I wrote:
Frankly, I'd be amazed if there was a performance regression,
OK, I'm amazed. While it apparently helps some cases dramatically
(Andres had a case where run time was reduced by 93.2%), I found a
pretty routine case where
On Tuesday 08 December 2009 17:15:36 Kevin Grittner wrote:
Andres Freund and...@anarazel.de wrote:
Could you show your testcase?
Will hopefully look into this later.
I dont see why it could get slower?
I don't either. The best I can tell, following the pointer from
orig to any of its
Hi,
On Tuesday 08 December 2009 20:09:22 Greg Smith wrote:
Andres, are using any optimization flags when you're testing?
I was testing with and without debug/cassert - and did not get adverse results
in both...
Unfortunately it looks like I wont get to test today, but only tomorrow
morning
On Tuesday 08 December 2009 17:15:36 Kevin Grittner wrote:
Andres Freund and...@anarazel.de wrote:
Could you show your testcase?
OK. I was going to try to check other platforms first, and package
up the information better, but here goes.
I created 1 lines with random IP-based URLs
reviewing!
Actually I dont mind very much if it gets delayed or not. Its trivial enough
that it shouldnt cause much work/conflicts/whatever next round and I am running
patched versions anyway, so ...
Andres
From e01bac641f318b378c4353aa6ccebc76b3071166 Mon Sep 17 00:00:00 2001
From: Andres Freund
Hi,
On Thursday 10 December 2009 23:08:17 Tom Lane wrote:
My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal to, and very possibly a good deal more
than, what it took to make a native Windows port. If SEPostgres could
bring us even 10% as
On Tuesday 15 December 2009 20:44:36 Greg Smith wrote:
As for the tsearch improvements, not to trivialize the patch, but I
think this one will survive being committed between alpha3 CF 2010-01
if it doesn't make it in this week. Teodor can work on getting that
committed when he has time, I
Moin,
On Wednesday 16 December 2009 16:24:42 Robert Haas wrote:
Inserts and deletes follow the same protocol, obtaining an exclusive
lock on the row after the one being inserted or deleted. The result
of this locking protocol is that a range scan prevents concurrent
inserts or
On Wednesday 16 December 2009 20:07:07 Gurjeet Singh wrote:
2009/12/15 Greg Smith g...@2ndquadrant.com
Jaime Casanova wrote:
So in this extreme case avg tps is just 6 transactions better
Great job trying to find the spot where the code worked better. I'm not
so sure I trust pgbench
Hi,
On Monday 21 December 2009 02:23:39 Robert Haas wrote:
A more important point is whether we really need to make this
dependent on Perl 5.6 or later. What features are we using here that
actually require Perl 5.6? I suspect the answer is none, but we
don't like writing the code in a way
Hi Simon, Hi all,
HS currently does the following in GetConflictingVirtualXIDs
TransactionId pxmin = proc-xmin;
/*
* We ignore an invalid pxmin because this means that backend
* has no snapshot and cannot get another one while we hold exclusive lock.
*/
if (TransactionIdIsValid(pxmin)
On Monday 21 December 2009 04:23:57 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Monday 21 December 2009 02:23:39 Robert Haas wrote:
A more important point is whether we really need to make this
dependent on Perl 5.6 or later.
I dont see a platform without perl 5.6 where
On Monday 21 December 2009 16:38:07 Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Andres Freund wrote:
The logic behind this seems fine except in the case of dropping a
database. There you very well might have a open connection without an
open snapshot.
Perhaps
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 that would not effect the
case of normal running.
Actually its less simply than I had thought at first - I don't think the
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
On Wednesday 23 December 2009 02:23:55 Jan Urbański wrote:
Hi,
I've been playing with using a Simulated Annealing-type algorithm for
determinig join ordering for relations.
Very cool.
Lastly, I'm lacking good testcases or even a testing approach: I'm
generating silly queries and looking at
On Wednesday 25 November 2009 17:25:43 Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
An idle-in-transaction transaction can also hold a temporary file. Think
of an open cursor, for example. Therefore, remove the distinction
between CONFLICT_MODE_ERROR and
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 and...@anarazel.de
Date: Sun, 27 Dec 2009 17:28:39 +0100
Subject: [PATCH 1/2] Use correct
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
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 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 than
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:
On Monday 28 December 2009 22:39:06 Dimitri Fontaine wrote:
Hi,
Le 28 déc. 2009 à 21:33, Kevin Grittner a écrit :
We often see posts from people who have more active connections than
is efficient.
How would your proposal better solve the problem than using pgbouncer?
mad proposal
On Saturday 12 December 2009 21:38:41 Andres Freund wrote:
On Saturday 12 December 2009 21:36:27 Michael Clemmons wrote:
If ppl think its worth it I'll create a ticket
Thanks, no need. I will post a patch tomorrow or so.
Well. It was a long day...
Anyway.
In this patch I delay the fsync done
On Monday 28 December 2009 23:54:51 Andres Freund wrote:
On Saturday 12 December 2009 21:38:41 Andres Freund wrote:
On Saturday 12 December 2009 21:36:27 Michael Clemmons wrote:
If ppl think its worth it I'll create a ticket
Thanks, no need. I will post a patch tomorrow or so.
Well
On Tuesday 29 December 2009 00:06:28 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
This speeds up CREATE DATABASE from ~9 seconds to something around 0.8s
on my laptop. Still slower than with fsync off (~0.25) but quite a
worthy improvement.
I can't help wondering whether
On Tuesday 29 December 2009 00:06:28 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
This speeds up CREATE DATABASE from ~9 seconds to something around 0.8s
on my laptop. Still slower than with fsync off (~0.25) but quite a
worthy improvement.
I can't help wondering whether
On Tuesday 29 December 2009 01:27:29 Greg Stark wrote:
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund and...@anarazel.de wrote:
fsync everything in that pass.
Including the directory - which was not done before and actually might be
necessary in some cases.
Er. Yes. At least on ext4
On Monday 28 December 2009 22:30:44 matt wrote:
Is there some way to export the postgresql query parse tree in XML format?
I can not locate the API/Tool etc to do that...
Thats more of a -general question.
There is no such possibility in 8.4 - the not yet released 8.5 contains such a
On Tuesday 29 December 2009 01:35:25 Robert Haas wrote:
On Mon, Dec 28, 2009 at 7:32 PM, Andres Freund and...@anarazel.de wrote:
On Monday 28 December 2009 22:30:44 matt wrote:
Is there some way to export the postgresql query parse tree in XML
format? I can not locate the API/Tool etc to do
On Tuesday 29 December 2009 01:30:17 da...@lang.hm wrote:
On Tue, 29 Dec 2009, Greg Stark wrote:
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund and...@anarazel.de
wrote:
fsync everything in that pass.
Including the directory - which was not done before and actually might
be necessary
On Tuesday 29 December 2009 01:46:21 Greg Smith wrote:
Andres Freund wrote:
As I said the real benefit only occurred after adding posix_fadvise(..,
FADV_DONTNEED) which is somewhat plausible, because i.e. the directory
entries don't need to get scheduled for every file and because
On Tuesday 29 December 2009 03:53:12 Michael Clemmons wrote:
Andres,
Great job. Looking through the emails and thinking about why this works I
think this patch should significantly speedup 8.4 on most any file
system(obviously some more than others) unless the system has significantly
On Tuesday 29 December 2009 04:04:06 Michael Clemmons wrote:
Maybe not crash out but in this situation.
N=0
while(N=0):
CREATE DATABASE new_db_N;
Since the fsync is the part which takes the memory and time but is
happening in the background want the fsyncs pile up in the background
On Tuesday 29 December 2009 11:48:10 Greg Stark wrote:
On Tue, Dec 29, 2009 at 2:05 AM, Andres Freund and...@anarazel.de wrote:
Reads Completed:2,8KiB Writes Completed: 2362,
29672KiB New:
Reads Completed:0,0KiB Writes Completed: 550
On Tuesday 29 December 2009 15:30:00 matt wrote:
--- On Mon, 12/28/09, Andres Freund and...@anarazel.de wrote:
From: Andres Freund and...@anarazel.de
Subject: Re: [HACKERS] parse tree to XML format
To: pgsql-hackers@postgresql.org
Cc: Robert Haas robertmh...@gmail.com, matt nuc
On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
If we use the same signal for both cases, the receiving backend cannot
tell what the intention of the sending backend was. That's why I
proposed to make SIGINT similar to SIGUSR1 where we write a
On Monday 28 December 2009 23:59:43 Andres Freund wrote:
On Monday 28 December 2009 23:54:51 Andres Freund wrote:
On Saturday 12 December 2009 21:38:41 Andres Freund wrote:
On Saturday 12 December 2009 21:36:27 Michael Clemmons wrote:
If ppl think its worth it I'll create a ticket
On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
This seems like a fairly bad idea. One of the intended use-cases is
to be able
- Ursprüngliche Mitteilung -
On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund and...@anarazel.de wrote:
On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Tuesday 29 December
On Thursday 31 December 2009 01:09:57 Robert Haas wrote:
On Wed, Dec 30, 2009 at 6:43 PM, Andres Freund and...@anarazel.de wrote:
On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund and...@anarazel.de
wrote:
On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote:
On Tue, 2009-12-29 at 11
On Thursday 31 December 2009 12:25:19 Simon Riggs wrote:
On Wed, 2009-12-30 at 20:06 +0100, Andres Freund wrote:
Hm. I just read a bit of that multiplexing facility (out of a different
reason) and I have some doubt about it being used unmodified for
canceling backends:
procsignal.c
On Tuesday 05 January 2010 09:37:57 black light wrote:
Hi,
Why PG uses a flat file (global\pg_auth) for md5 authentication!? Is it
forced to do it instead of accessing relevant table is system catalog?
It does not anymore:
backend. Does this sufficiently cover the concerns of Andres
Freund discussed upthread?
I think it solves the major concern (which I btw could easily reproduce using
software that is in production) but unfortunately not completely.
The avoided situation is:
C(Client): BEGIN; SELECT WHATEVER;
S
On Thursday 07 January 2010 18:10:43 Magnus Hagander wrote:
Not having our release schedule driven by marketing is a *strength* of
our project!
Yes.
We made the mistake last time to delay the release significantly for a
single feature. It turned out said feature didn't make it *anyway*.
On Thursday 07 January 2010 19:12:31 Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
While we're discussing this: the current coding with
AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe.
I realize that's
On Thursday 07 January 2010 19:49:59 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Stupid question:
Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything
calling recv (especially in the EINTR) case?
We pretty much have CHECK_FOR_INTERRUPTS everywhere
On Thursday 07 January 2010 20:58:10 Heikki Linnakangas wrote:
Robert Haas wrote:
Are there
really no other open issues for 8.5? That would be great, but I am
concerned that there may be other things that people just haven't
gotten around to mentioning yet.
Well, there's still a
On Thursday 07 January 2010 21:47:47 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code
path was that it should allow a relatively natural handling of
canceling IDLE IN TRANSACTION queries without doing anything
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as revert to old code and add two step killing (thats
likely around 10 lines or so).
two step killing
On Thursday 07 January 2010 23:32:27 Peter Eisentraut wrote:
On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
I've a .git/info/exclude file I pulled from a link on the dev wiki.
Some of the changes I'm making create new files that ought to be added
to the excluded files. I can easily
On Friday 08 January 2010 17:38:15 Alex Hunsaker wrote:
On Fri, Jan 8, 2010 at 02:03, Magnus Hagander mag...@hagander.net wrote:
You can always create your own branch with just the .gitignore files
and merge that into whatever you're working on :)
The only thing annoying about that is if
On Friday 08 January 2010 19:07:16 Bruce Momjian wrote:
I think so, too, but I'm actually afraid that if we don't start making
some tough decisions soon it's going to be even later than that. I'm
dismayed by the number of people who seem to think that the current
schedule is not already
On 01/07/10 22:37, Andres Freund wrote:
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as revert to old code and add two step killing (thats
likely around
On 01/07/10 22:37, Andres Freund wrote:
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as revert to old code and add two step killing (thats
likely around
On 01/12/10 09:40, Simon Riggs wrote:
On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote:
On 01/07/10 22:37, Andres Freund wrote:
On Thursday 07 January 2010 22:28:46 Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
I did not want to suggest using Simons code there. Sorry
On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote:
On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote:
Currently the patch does not yet do anything to avoid letting the
protocol out of sync. What do you think about adding a flag for error
codes not to communicate with the client
Hi,
The thought was that it might be helpful to be able to raise NOTICE or DEBUG*
as well - but admitedly there is not a big need for it...
Andres
--
Sent from a mobile phone - please excuse brevity and formatting.
- Ursprüngliche Mitteilung -
Andres Freund and...@anarazel.de writes
Hi Simon,
On Wednesday 13 January 2010 19:24:22 Simon Riggs wrote:
We've been chewing around query cancel on Hot Standby and I think things
have got fairly confusing, hence a new thread.
Good idea.
I enclose a patch that includes all the things that we all agree on so
far, in my
On Thursday 14 January 2010 13:21:07 Simon Riggs wrote:
On Wed, 2010-01-13 at 19:23 +, Simon Riggs wrote:
On Wed, 2010-01-13 at 19:58 +0100, Andres Freund wrote:
I am still testing patch, so should be confident to commit tomorrow
barring issues.
I have only looked at briefly
On Wednesday 13 January 2010 00:07:53 Simon Riggs wrote:
On Tue, 2010-01-12 at 19:43 +0100, Andres Freund wrote:
On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote:
On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote:
Currently the patch does not yet do anything to avoid letting
On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark gsst...@mit.edu wrote:
Looking at this patch for the commitfest I have a few questions.
So I've touched this patch up a bit:
1) moved the posix_fadvise call to a new fd.c function
On Saturday 16 January 2010 12:32:35 Simon Riggs wrote:
On Thu, 2010-01-07 at 13:16 -0500, Robert Haas wrote:
On Sun, Dec 27, 2009 at 2:12 PM, Andres Freund and...@anarazel.de wrote:
While unlikely to cause issues two new LWLockAcquire calls use the
wrong locking mode.
Patch attached
Hi Greg,
On Monday 18 January 2010 17:35:59 Greg Stark wrote:
2) Why does the second pass to do the fsyncs read through fromdir to
find all the filenames. I find that odd and counterintuitive. It would
be much more natural to just loop through the files in the new
directory. But I suppose it
Hi Greg,
On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark gsst...@mit.edu wrote:
Looking at this patch for the commitfest I have a few questions.
So I've touched this patch up a bit:
1) moved the posix_fadvise call to a new fd.c function
On Tuesday 19 January 2010 15:57:14 Greg Stark wrote:
On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark gsst...@mit.edu wrote:
Barring any objections shall I commit it like this?
Actually before we get there could someone who demonstrated the
speedup verify that this patch still gets that same
On Tuesday 19 January 2010 11:46:24 Simon Riggs wrote:
On Tue, 2009-12-15 at 20:11 +0900, Hiroyuki Yamada wrote:
Hot Standby node can freeze when startup process calls
LockBufferForCleanup(). This bug can be reproduced by the following
procedure.
0. start Hot Standby, with one active
On Wednesday 20 January 2010 06:30:28 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Is there any supported platform with sizeof(sig_atomic_t) 4 - I would
doubt so?
Er ... what? I believe there are live platforms with sig_atomic_t = char.
If we're assuming more that's a must
On Wednesday 20 January 2010 06:30:28 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Is there any supported platform with sizeof(sig_atomic_t) 4 - I would
doubt so?
Er ... what? I believe there are live platforms with sig_atomic_t = char.
If we're assuming more that's a must
On Wednesday 20 January 2010 10:40:10 Simon Riggs wrote:
On Wed, 2010-01-20 at 06:14 +0100, Andres Freund wrote:
Full resolution patch attached for Startup process waits on buffer
pins.
Startup process sets SIGALRM when waiting on a buffer pin. If woken by
alarm we send SIGUSR1
On Wednesday 20 January 2010 10:52:24 Simon Riggs wrote:
On Wed, 2010-01-20 at 10:45 +0100, Andres Freund wrote:
LWLockAcquire
I'm using spinlocks, not lwlocks.
CancelDBBackends which is used in SendRecoveryConflictWithBufferPin which in
turn used by CheckStandbyTimeout triggered by SIGALRM
On Wednesday 20 January 2010 11:33:05 Simon Riggs wrote:
On Wed, 2010-01-20 at 11:04 +0100, Andres Freund wrote:
On Wednesday 20 January 2010 10:52:24 Simon Riggs wrote:
On Wed, 2010-01-20 at 10:45 +0100, Andres Freund wrote:
LWLockAcquire
I'm using spinlocks, not lwlocks
On Wednesday 20 January 2010 12:59:40 Simon Riggs wrote:
On Wed, 2010-01-20 at 04:47 +0100, Andres Freund wrote:
On Saturday 16 January 2010 12:32:35 Simon Riggs wrote:
No. As mentioned upthread, this is not a bug.
Could you also mention in a little bit more detail why not?
When
On Wednesday 20 January 2010 17:30:04 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Wednesday 20 January 2010 06:30:28 Tom Lane wrote:
Er ... what? I believe there are live platforms with sig_atomic_t =
char. If we're assuming more that's a must-fix.
The reason I have
Hi Tom, Hi Simon,
On Wednesday 20 January 2010 17:59:36 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I realize its way too late in the cycle for that, but why dont we start
using some library for easy cross platform atomic ops?
(1) there probably isn't one that does exactly
On Wednesday 20 January 2010 17:59:36 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I realize its way too late in the cycle for that, but why dont we start
using some library for easy cross platform atomic ops?
(1) there probably isn't one that does exactly what we want, works
On Saturday 23 January 2010 22:24:41 Dimitri Fontaine wrote:
I was under the illusion than we had some RRR people not talented enough
to be full-speed contributors to release management that we could have
this team run one or two ReviewFest while the serious guys were
working.
I find not
On Friday 29 January 2010 23:34:09 Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I stand by the position that it's way too late in the cycle for
insufficiently-thought-out proposals for major behavioral changes.
I don't see how announcing this earlier in the dev cycle would help,
On Friday 29 January 2010 23:54:15 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
What about anouncing in the 9.0 releasenotes that it will be removed in
9.1?
That seems quite useless.
I note that we've made such statements before and not followed through
on them; one
On Friday 29 January 2010 23:47:22 Bruce Momjian wrote:
Andres Freund wrote:
On Friday 29 January 2010 23:34:09 Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I stand by the position that it's way too late in the cycle for
insufficiently-thought-out proposals for major
On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
On Fri, Jan 29, 2010 at 1:56 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That function *seriously* needs documentation, in particular the fact
that it's a no-op on machines
1 - 100 of 8944 matches
Mail list logo