Hello
I am looking on ToDo topic - Allow handling of %TYPE arrays, e.g.
tab.col%TYPE[]
Some the most simple solution can be enhancing regtype to support this
syntax - this can be relative simple, and it can be useful for other
PL and for dynamic SQL too. It can be simple test - if some table has
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie sep 03 19:36:06 -0400 2010:
>> On the whole I'm still afraid that changing the initial typing of
>> integer constants is going to break a lot of code while buying not much.
>> Do you have a specific reason for reopening the issue? O
Robert Haas writes:
> Maybe the lexer isn't the right place to fix this. The problem here
> (or so I gather) is that if I say foo(1), then 1 is an integer and
> we'll do an "implicit" cast to bigint, real, double precision,
> numeric, oid, or reg*, but the cast to smallint is assignment-only.
> B
On Fri, Sep 3, 2010 at 9:19 PM, Alvaro Herrera
wrote:
> The problem I'm facing is functions declared to take type smallint not
> working unless the integer literal has an explicit cast. Currently the
> best answer is simply to avoid using smallint in functions, but this
> isn't completely satisfy
Excerpts from Tom Lane's message of vie sep 03 19:36:06 -0400 2010:
> > Does anyone know where to find the discussion refered to here?
> > http://archives.postgresql.org/pgsql-hackers/2008-10/msg01485.php
>
> I think this was the last time I tried it:
> http://archives.postgresql.org/pgsql-hacker
On Fri, Sep 3, 2010 at 6:24 PM, Tom Lane wrote:
> Now the HS case likewise appears to be set up so that the signal can
> only directly interrupt ProcWaitForSignal, so I think the core issue is
> whether any deadlock situations are possible. Given that this gets
> called from a low-level place lik
On Fri, Sep 3, 2010 at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane wrote:
>>> On reflection I think that for parameterized paths the problem won't be
>>> too bad, because (a) we'll ignore parameterized paths except when
>>> considering a join to the
On Fri, Sep 3, 2010 at 7:09 PM, Tom Lane wrote:
> I wrote:
>> Alexey Klyukin writes:
>>> I always wondered why ps ax|grep postgres shows several extra blank lines
>>> after the process name, i.e.
>
>> AFAIR it's always done that on OSX. I thought we'd tried the '\0'
>> padding way back when and
> Tatsuo Ishii writes:
> > Is there any way to use regclass without having ERROR?
>
> > pgpool-II needs to find the oid from table name and for the purpose it
> > issues something like "SELECT 'table_name'::regproc::oid". Problem is,
> > if the table does not exist, an error occured and the trans
Alvaro Herrera writes:
> I'm researching if smallint can be made a higher-class citizen of our type
> system than currently.
> Does anyone know where to find the discussion refered to here?
> http://archives.postgresql.org/pgsql-hackers/2008-10/msg01485.php
I think this was the last time I tried
I wrote:
> Alexey Klyukin writes:
>> I always wondered why ps ax|grep postgres shows several extra blank lines
>> after the process name, i.e.
> AFAIR it's always done that on OSX. I thought we'd tried the '\0'
> padding way back when and it didn't work nicely, but maybe Apple fixed
> that.
I t
Tom Lane wrote:
> +1 for adding parens; we might want to make a function of it
> someday.
> How about IsolationUsesXactSnapshot
Patch attached.
Joe said that he'll review this weekend and probably commit in a day
or two if there are no objections.
-Kevin
*** a/src/backend/catalog/index.c
Hi,
I'm researching if smallint can be made a higher-class citizen of our type
system than currently.
Does anyone know where to find the discussion refered to here?
http://archives.postgresql.org/pgsql-hackers/2008-10/msg01485.php
I did some searches on the archives but no keywords I search for
Hi David
I seem to recall the last time that I built Postgres on windows using
VC++, there was a whole load of compiler warnings, because MS have
taken it upon themselves to deprecate various C std lib functions (in
particular, string.h functions). You're supposed to use their
non-standard variant
Robert Haas writes:
> Color me confused; I may need to backpedal rapidly here. I had
> thought that what Tom was complaining about was the fact that the
> signal handler was taking LWLocks, which I would have thought to be
> totally unsafe.
Well, it's unsafe if the signal could interrupt mainlin
Robert Haas writes:
> On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane wrote:
>> On reflection I think that for parameterized paths the problem won't be
>> too bad, because (a) we'll ignore parameterized paths except when
>> considering a join to the right outer rel, so their presence in the
>> rel's pat
Heikki Linnakangas writes:
> A safer approach would be to just PGSemaphoreUnlock() in the signal
> handler, and do all the other processing outside it.
I don't see any particularly good reason to assume that
PGSemaphoreUnlock is safe either: you're still talking about nested
semop operations.
T
On Fri, Sep 3, 2010 at 4:20 PM, Heikki Linnakangas
wrote:
> Maybe that's ok, if I'm reading the deadlock checker code correctly, it also
> calls semop() to increment the another process' semaphore, and the deadlock
> checker can be invoked from a signal handler while in semop() to wait on our
> pr
On 9/3/10 2:20 PM, Josh Berkus wrote:
> However, if you look at any mature, large open
> source project you will find that at least 1/4 of its code contributors
> are paid to work on the project by *someone*, and that those paid
> developers account for 70% to 95% of the code.
Relevant link for th
John,
> I honestly do not mean any offence, just out of curiosity.
>
> If you guys care about money and time why would you spend the best years
> of your life basically copying commercial products for free?
We don't do it to copy commercial products. We do it to build something
better than them
On Fri, Sep 3, 2010 at 12:23 PM, Heikki Linnakangas
wrote:
> On 03/09/10 18:53, David Blewett wrote:
>>
>> On Fri, Sep 3, 2010 at 11:47 AM, Tom Lane wrote:
>>>
>>> IOW, what I'd like to see is protocol extensions that allow an external
>>> copy of rsync to be invoked; not build in rsync, or tar,
On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane wrote:
> On reflection I think that for parameterized paths the problem won't be
> too bad, because (a) we'll ignore parameterized paths except when
> considering a join to the right outer rel, so their presence in the
> rel's pathlist won't cost much other
On 03/09/10 19:38, Robert Haas wrote:
On Fri, Sep 3, 2010 at 12:10 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
[ shrug... ] I stated before that the Hot Standby patch is doing
utterly unsafe things in signal handlers. Simon rejected that.
I am
Josh Berkus writes:
>> I noticed in postgres you cannot return multiple result sets from a
>> stored procedure (surprisingly as it looks like a very good dbms).
> That feature has been on the TODO list for years. However, nobody has
> stepped forward to either write it, or to fund working on it.
On Fri, Sep 3, 2010 at 3:11 PM, Ron Mayer wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
[ shrug... ] I stated before that the Hot Standby patch is doing
utterly unsafe things in signal handlers. Simon rejected that.
I am wai
> I noticed in postgres you cannot return multiple result sets from a
> stored procedure (surprisingly as it looks like a very good dbms).
That feature has been on the TODO list for years. However, nobody has
stepped forward to either write it, or to fund working on it. If your
company has prog
All,
As far as I'm concerned, the other big "missing feature" for HS is the
ability to promote standbys to become the new master. If we had that
feature, then HS can be the backbone of a large-scale PostgreSQL
"cloud"; if we don't have it, then HS does not contribute very much to
scalability bey
On Fri, Sep 03, 2010 at 09:56:12AM -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > The rsync code itself is not modular, I believe. I think the author
> > thereof kind of took the approach of placing efficiency before all.
>
> Yeah, I looked into this when discussin
On Thu, Sep 2, 2010 at 7:17 PM, Alvaro Herrera
wrote:
> Excerpts from John Adams's message of jue sep 02 18:25:45 -0400 2010:
>> I noticed in postgres you cannot return multiple result sets from a stored
>> procedure (surprisingly as it looks like a very good dbms).
>
> If you're really intent abo
Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
>>> [ shrug... ] I stated before that the Hot Standby patch is doing
>>> utterly unsafe things in signal handlers. Simon rejected that.
>>> I am waiting for irrefutable evidence to emerge from the field
>>
Alexey Klyukin writes:
> I always wondered why ps ax|grep postgres shows several extra blank lines
> after the process name, i.e.
AFAIR it's always done that on OSX. I thought we'd tried the '\0'
padding way back when and it didn't work nicely, but maybe Apple fixed
that.
Heikki Linnakangas writes:
> On 03/09/10 21:16, Tom Lane wrote:
>> It's probably not too unreasonable to assume that pid_t assignment is
>> atomic. But I'm still thinking that we have bigger problems than that
>> if there are really cases where SetLatch can execute at approximately
>> the same ti
On 03/09/10 21:16, Tom Lane wrote:
Heikki Linnakangas writes:
WaitLatch had to set the pid on the Latch struct to allow other
processes to send the signal. Another process could call SetLatch and
read the pid field, while WaitLatch is just setting it. I think we'll
have to put a spinlock there,
On Fri, Sep 03, 2010 at 06:24:06PM +0200, Magnus Hagander wrote:
> On Fri, Sep 3, 2010 at 17:18, Dave Page wrote:
> > On Fri, Sep 3, 2010 at 4:11 PM, David Fetter wrote:
> >> Hello,
> >>
> >> At work, I've been tasked with providing some Windows connection
> >> libraries, etc. Are people still u
Hi,
I always wondered why ps ax|grep postgres shows several extra blank lines
after the process name, i.e.
972 ?? Ss 0:00.69 postgres: writer process
973 ?? Ss 0:00.51 postgres: wal writer process
(I put newlines instead of spaces there). By looking into the code I've found
Heikki Linnakangas writes:
> On 03/09/10 17:51, Tom Lane wrote:
>> If there is *any* possibility of that happening then you have far worse
>> problems than whether the field is atomically readable or not: the
>> behavior will be unpredictable at just slightly larger timescales.
> Each Walsender n
Robert Haas writes:
> On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane wrote:
>> The best idea I can come up with at the moment is to compute "best case"
>> and "worst case" costs for a parameterized path,
> Interestingly, I previously proposed almost exactly this approach to
> handle a couple of other
On 03/09/10 17:51, Tom Lane wrote:
Heikki Linnakangas writes:
On 02/09/10 23:13, Tom Lane wrote:
Also, using sig_atomic_t for owner_pid is entirely not sane.
Hmm, true, it doesn't need to be set from signal handler, but is there
an atomicity problem if one process calls ReleaseLatch while a
Excerpts from David Fetter's message of vie sep 03 13:31:00 -0400 2010:
> We have no mechanism to do this, or any other check, during a bulk
> load. It'd be a great feature to have :)
I'm not sure what kind of bulk load you are talking about, nor what does
it have to do with pgpool-II.
--
Álva
On Fri, Sep 03, 2010 at 01:28:15PM -0400, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of vie sep 03 10:21:00 -0400 2010:
>
> > > How about using a SAVEPOINT before the cast? Wouldn't fail your
> > > transaction..
> >
> > For unattended operation, there are some issues:
> >
> >
Excerpts from David Fetter's message of vie sep 03 10:21:00 -0400 2010:
> > How about using a SAVEPOINT before the cast? Wouldn't fail your
> > transaction..
>
> For unattended operation, there are some issues:
>
> * Generating appropriate SAVEPOINT names
> * Keeping track of same
> * Detecting
On Fri, Sep 3, 2010 at 12:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
>>> [ shrug... ] I stated before that the Hot Standby patch is doing
>>> utterly unsafe things in signal handlers. Simon rejected that.
>>> I am waiting for irrefutable ev
On Fri, Sep 3, 2010 at 17:18, Dave Page wrote:
> On Fri, Sep 3, 2010 at 4:11 PM, David Fetter wrote:
>> Hello,
>>
>> At work, I've been tasked with providing some Windows connection
>> libraries, etc. Are people still using MinGW, or should I just
>> recommend using a proprietary toolkit to do t
On 03/09/10 18:53, David Blewett wrote:
On Fri, Sep 3, 2010 at 11:47 AM, Tom Lane wrote:
IOW, what I'd like to see is protocol extensions that allow an external
copy of rsync to be invoked; not build in rsync, or tar, or anything
else that we could get off-the-shelf.
Personally, I would love
On 03/09/10 19:09, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
IOW, what I'd like to see is protocol extensions that allow an external
copy of rsync to be invoked; not build in rsync, or tar, or anything
else that we could get off-the-shelf.
I'd much rather use an existing libr
Tom Lane wrote:
> what I'd like to see is protocol extensions that allow an external
> copy of rsync to be invoked; not build in rsync, or tar, or
> anything else that we could get off-the-shelf.
The complexities of dealing with properly invoking rsync externally
could well require more code a
Robert Haas writes:
> On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
>> [ shrug... ] I stated before that the Hot Standby patch is doing
>> utterly unsafe things in signal handlers. Simon rejected that.
>> I am waiting for irrefutable evidence to emerge from the field
>> (and am very confiden
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> IOW, what I'd like to see is protocol extensions that allow an external
> copy of rsync to be invoked; not build in rsync, or tar, or anything
> else that we could get off-the-shelf.
I'd much rather use an existing library to implement it than call out to
s
On Sep 3, 2010, at 7:31 AM, Tom Lane wrote:
> I don't think the cast should act that way, but I could see providing a
> separate conversion function that returns 0 ... or perhaps better NULL
> ... if no match.
+1 I could use this in pgTAP.
David
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Fri, Sep 3, 2010 at 11:47 AM, Tom Lane wrote:
> IOW, what I'd like to see is protocol extensions that allow an external
> copy of rsync to be invoked; not build in rsync, or tar, or anything
> else that we could get off-the-shelf.
Personally, I would love to see protocol-level compression adde
On Fri, Sep 3, 2010 at 11:47 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>>> Stephen Frost wrote:
>>> In any case, it's certainly not something required for an initial
>>> implementation..
>
>> No disagreement there; but sometimes it pays to know where you might
>> want to go, so you don't do
"Kevin Grittner" writes:
>> Stephen Frost wrote:
>> In any case, it's certainly not something required for an initial
>> implementation..
> No disagreement there; but sometimes it pays to know where you might
> want to go, so you don't do something to make further development in
> that directio
On Fri, Sep 3, 2010 at 10:07 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Fri, Sep 3, 2010 at 11:08 AM, Tom Lane wrote:
>>> elog(FATAL) is *certainly* not a better idea. I think there's really
>>> nothing that can be done, you just have to silently ignore the error.
>
>> Hmm.. some functions
On Fri, Sep 3, 2010 at 11:20 AM, Stephen Frost wrote:
> Kevin,
>
> * Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
>> While 1GB granularity would be OK, I doubt it's optimal; I think CRC
>> checks for smaller chunks might be worthwhile. My gut feel is that
>> somewhere in the 64kB to 1MB ra
On 03/09/10 18:01, Tom Lane wrote:
Heikki Linnakangas writes:
On 03/09/10 15:16, Greg Stark wrote:
On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
wrote:
* We need a smarter way to do pg_start/stop_backup() with this. At the
moment, you can only have one backup running at a time, but w
>Stephen Frost wrote:
> We have something much better, called WAL. If people want to keep
> their backup current, they should use that after getting the base
> backup up and working.
Unless you want to provide support for Point In Time Recovery
without excessive recovery times.
> We don't n
On 3 September 2010 16:01, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 03/09/10 15:16, Greg Stark wrote:
>>> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
>>> wrote:
* We need a smarter way to do pg_start/stop_backup() with this. At the
moment, you can only have one backu
Kevin,
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> While 1GB granularity would be OK, I doubt it's optimal; I think CRC
> checks for smaller chunks might be worthwhile. My gut feel is that
> somewhere in the 64kB to 1MB range would probably be optimal for us,
> although the "sweet spo
On Fri, Sep 3, 2010 at 4:11 PM, David Fetter wrote:
> Hello,
>
> At work, I've been tasked with providing some Windows connection
> libraries, etc. Are people still using MinGW, or should I just
> recommend using a proprietary toolkit to do the builds? If so, which
> one(s)?
Visual C++ 2005 for
Hello,
At work, I've been tasked with providing some Windows connection
libraries, etc. Are people still using MinGW, or should I just
recommend using a proprietary toolkit to do the builds? If so, which
one(s)?
Cheers,
David (Windows n00b)
--
David Fetter http://fetter.org/
Phone: +1 415 235
Stephen Frost wrote:
> there's a heck of alot of complexity there that we *don't* need.
> rsync is a great tool, don't get me wrong, but let's not try to go
> over our heads here.
Right -- among other things, it checks for portions of a new file
which match the old file at a different location
Heikki Linnakangas writes:
> On 03/09/10 15:16, Greg Stark wrote:
>> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
>> wrote:
>>> * We need a smarter way to do pg_start/stop_backup() with this. At the
>>> moment, you can only have one backup running at a time, but we shouldn't
>>> have that
Heikki Linnakangas writes:
> On 02/09/10 23:13, Tom Lane wrote:
>>> (Yeah, I realize the caller
>>> could look into the latch to find that out, but callers really ought to
>>> treat latches as opaque structs.)
> Hmm, maybe we need a TestLatch function to check if a latch is set.
+1. It could be
On Sep 3, 2010, at 4:40 PM, Tom Lane wrote:
> =?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?=
> writes:
>> imagine a system with, say, 1000 partitions (heavily indexed) or so. the
>> time taken by the planner is already fairly heavy in this case.
>
> As the fine manual points out, the c
=?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?=
writes:
> imagine a system with, say, 1000 partitions (heavily indexed) or so. the time
> taken by the planner is already fairly heavy in this case.
As the fine manual points out, the current scheme for managing
partitioned tables isn't inte
Hello, guys.
You wrote:
TI> Hi,
TI> Is there any way to use regclass without having ERROR?
TI> pgpool-II needs to find the oid from table name and for the purpose it
TI> issues something like "SELECT 'table_name'::regproc::oid". Problem is,
TI> if the table does not exist, an error occured and
Tatsuo Ishii writes:
> Is there any way to use regclass without having ERROR?
> pgpool-II needs to find the oid from table name and for the purpose it
> issues something like "SELECT 'table_name'::regproc::oid". Problem is,
> if the table does not exist, an error occured and the transaction
> abo
On Fri, Sep 03, 2010 at 05:10:44PM +0300, Marko Tiikkaja wrote:
> On 2010-09-03 4:46 PM, Tatsuo Ishii wrote:
> >>You can write a query against the system catalog tables.
> >
> >That was pretty hard than I though(schema search path etc.).
> >
> >>Or you could
> >>install a function that wraps the re
On 2010-09-03 4:46 PM, Tatsuo Ishii wrote:
You can write a query against the system catalog tables.
That was pretty hard than I though(schema search path etc.).
Or you could
install a function that wraps the regclass cast in an exception
handler.
That requires users to install the function.
Fujii Masao writes:
> On Fri, Sep 3, 2010 at 11:08 AM, Tom Lane wrote:
>> elog(FATAL) is *certainly* not a better idea. I think there's really
>> nothing that can be done, you just have to silently ignore the error.
> Hmm.. some functions called by a signal handler use elog(FATAL), e.g.,
> Reco
* Robert Haas (robertmh...@gmail.com) wrote:
> The rsync code itself is not modular, I believe. I think the author
> thereof kind of took the approach of placing efficiency before all.
Yeah, I looked into this when discussing this same concept at PGCon with
folks. There doesn't appear to be a go
> You can write a query against the system catalog tables.
That was pretty hard than I though(schema search path etc.).
> Or you could
> install a function that wraps the regclass cast in an exception
> handler.
That requires users to install the function. Annoying for users.
--
Tatsuo Ishii
SRA
On Wed, Sep 1, 2010 at 2:42 AM, Sushant Sinha wrote:
> I have attached a patch that emits parts of a host token, a url token,
> an email token and a file token. Further, it makes sure that a
> host/url/email/file token and the first part-token are at the same
> position in tsvector.
You should pr
On Fri, Sep 3, 2010 at 9:32 AM, Dave Page wrote:
> No, I agree we don't want an external dependency (I was just bleating
> about needing tar on Windows). I was assuming/hoping there's a
> librsync somewhere...
The rsync code itself is not modular, I believe. I think the author
thereof kind of to
On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
> On Sep 1, 2010, at 10:21 AM, Greg Stark wrote:
>> For what it's worth I disagree with Tom. I think this is a situation
>> where we need *both* types of solution. Ideally we will be able to use
>> a plain Append node for cases where we know the rel
On Fri, Sep 3, 2010 at 4:28 AM, Tatsuo Ishii wrote:
> Is there any way to use regclass without having ERROR?
>
> pgpool-II needs to find the oid from table name and for the purpose it
> issues something like "SELECT 'table_name'::regproc::oid". Problem is,
> if the table does not exist, an error o
On Fri, Sep 3, 2010 at 2:29 PM, Robert Haas wrote:
> On Fri, Sep 3, 2010 at 9:26 AM, Dave Page wrote:
>> rsync? Might be easier to use that from day 1 (well, day 2) than to
>> retrofit later.
>
> I'm not sure we want to depend on an external utility like that,
> particularly one that users may no
On Fri, Sep 3, 2010 at 9:26 AM, Dave Page wrote:
> rsync? Might be easier to use that from day 1 (well, day 2) than to
> retrofit later.
I'm not sure we want to depend on an external utility like that,
particularly one that users may not have installed. And I'm not sure
if that can be made to wo
2010/9/3 PostgreSQL - Hans-Jürgen Schönig :
> i tried this one with 5000 unindexed tables (just one col):
>
> test=# \timing
> Timing is on.
> test=# prepare x(int4) AS select * from t_data order by id desc;
> PREPARE
> Time: 361.552 ms
>
> you will see similar or higher runtimes in case of 500 par
On Fri, Sep 3, 2010 at 2:24 PM, Robert Haas wrote:
> On Fri, Sep 3, 2010 at 7:28 AM, Dave Page wrote:
>> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
>> wrote:
>>> Here's a WIP patch. It adds a new "TAKE_BACKUP" command to the replication
>>> command set. Upon receiving that command, the
On Fri, Sep 3, 2010 at 15:24, Robert Haas wrote:
> On Fri, Sep 3, 2010 at 7:28 AM, Dave Page wrote:
>> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
>> wrote:
>>> Here's a WIP patch. It adds a new "TAKE_BACKUP" command to the replication
>>> command set. Upon receiving that command, the ma
On Fri, Sep 3, 2010 at 7:28 AM, Dave Page wrote:
> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
> wrote:
>> Here's a WIP patch. It adds a new "TAKE_BACKUP" command to the replication
>> command set. Upon receiving that command, the master starts a COPY, and
>> streams a tarred copy of the
Fujii Masao írta:
> On Fri, Sep 3, 2010 at 6:43 PM, Boszormenyi Zoltan wrote:
>
>> In my patch, when the transactions were waiting for ack from
>> the standby, they have already released all their locks, the wait
>> happened at the latest possible point in CommitTransaction().
>>
>> In Fujii's
2010/9/3 Heikki Linnakangas :
> On 03/09/10 11:16, Pavel Stehule wrote:
>>
>> 2010/8/31 Tom Lane:
>>>
>>> Pavel Stehule writes:
there is a dump from 8KB files
>>>
>>> Well, those certainly look like tables/indexes not temp files.
>>> So we can rule out one theory.
>>>
>>> You're *certain
On 03/09/10 15:16, Greg Stark wrote:
On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
wrote:
* We need a smarter way to do pg_start/stop_backup() with this. At the
moment, you can only have one backup running at a time, but we shouldn't
have that limitation with this built-in mechanism.
W
* PostgreSQL - Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
> this seems like more a developer question to me than a pre performance one.
> it is not related to the table structure at all - it is basically an issue
> with incredibly large inheritance lists.
> it applies to postgres 9 and most
On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
wrote:
> * We need a smarter way to do pg_start/stop_backup() with this. At the
> moment, you can only have one backup running at a time, but we shouldn't
> have that limitation with this built-in mechanism.
Well there's no particular reason we
On Sep 3, 2010, at 2:04 PM, Stephen Frost wrote:
> * PostgreSQL - Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
>> did anybody think of a solution to this problem.
>> or more precisely: can there be a solution to this problem?
>
> Please post to the correct list (-performance) and provide in
* PostgreSQL - Hans-Jürgen Schönig (postg...@cybertec.at) wrote:
> did anybody think of a solution to this problem.
> or more precisely: can there be a solution to this problem?
Please post to the correct list (-performance) and provide information
like PG version, postgresql.conf, the actual tabl
On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane wrote:
> Awhile back I ranted about replacing the planner's concept of inner
> indexscans with a more generalized notion of "parameterized paths":
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00994.php
>
> The executor fixes for that are done,
On Fri, Sep 3, 2010 at 13:48, Heikki Linnakangas
wrote:
> On 03/09/10 14:28, Dave Page wrote:
>>
>> On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
>> wrote:
>>>
>>> Here's a WIP patch. It adds a new "TAKE_BACKUP" command to the
>>> replication
>>> command set. Upon receiving that command, t
On 03/09/10 14:28, Dave Page wrote:
On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
wrote:
Here's a WIP patch. It adds a new "TAKE_BACKUP" command to the replication
command set. Upon receiving that command, the master starts a COPY, and
streams a tarred copy of the data directory to the c
On 03/09/10 14:25, Thom Brown wrote:
On 3 September 2010 12:19, Heikki Linnakangas
wrote:
TODO:
* We need a smarter way to do pg_start/stop_backup() with this. At the
moment, you can only have one backup running at a time, but we shouldn't
have that limitation with this built-in mechanism.
On 3 September 2010 12:30, Magnus Hagander wrote:
> On Fri, Sep 3, 2010 at 13:25, Thom Brown wrote:
>> On 3 September 2010 12:19, Heikki Linnakangas
>> wrote:
>>> TODO:
>>>
>>> * We need a smarter way to do pg_start/stop_backup() with this. At the
>>> moment, you can only have one backup running
On Fri, Sep 3, 2010 at 13:25, Thom Brown wrote:
> On 3 September 2010 12:19, Heikki Linnakangas
> wrote:
>> TODO:
>>
>> * We need a smarter way to do pg_start/stop_backup() with this. At the
>> moment, you can only have one backup running at a time, but we shouldn't
>> have that limitation with t
On Fri, Sep 3, 2010 at 6:43 PM, Boszormenyi Zoltan wrote:
> In my patch, when the transactions were waiting for ack from
> the standby, they have already released all their locks, the wait
> happened at the latest possible point in CommitTransaction().
>
> In Fujii's patch (I am looking at synch_r
On Fri, Sep 3, 2010 at 13:19, Heikki Linnakangas
wrote:
> It's been discussed before that it would be cool if you could stream a new
> base backup from the master server, via libpq. That way you would not need
> low-level filesystem access to initialize a new standby.
>
> Magnus mentioned today th
On Fri, Sep 3, 2010 at 12:19 PM, Heikki Linnakangas
wrote:
> Here's a WIP patch. It adds a new "TAKE_BACKUP" command to the replication
> command set. Upon receiving that command, the master starts a COPY, and
> streams a tarred copy of the data directory to the client. The patch
> includes a simp
On 3 September 2010 12:19, Heikki Linnakangas
wrote:
> TODO:
>
> * We need a smarter way to do pg_start/stop_backup() with this. At the
> moment, you can only have one backup running at a time, but we shouldn't
> have that limitation with this built-in mechanism.
Would it be possible to not requi
It's been discussed before that it would be cool if you could stream a
new base backup from the master server, via libpq. That way you would
not need low-level filesystem access to initialize a new standby.
Magnus mentioned today that he started hacking on that, and
coincidentally I just start
1 - 100 of 111 matches
Mail list logo
