On Friday 29 May 2009 06:31:23 Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On Tuesday 05 May 2009 03:01:05 Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
> > > >> I think we can handle that and the cases Tom presents by error
Hi,
Quoting "Robert Haas" :
That's not the best news I've had today...
Sorry :-(
To me they sound complex and inconvenient. I guess I'm kind of
mystified by why we can't make this work reliably. Other than the
"broken tags" issue we've discussed, it seems like the only real issue
should be
Hi,
Quoting "Robert Haas" :
That might work, but then we better be pretty darn confident that that
"fresh conversion" is actually correct. I'd rather have them going
side-by-side so that we can verify everything before shutting the old
system off.
I agree, as long as you take non-incremental
On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote:
> On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira
> > Don't you think is too strange having, for example, 6.67 rows?
>
> No stranger than having it say 7 when it's really not. Actually mine
> mostly come out 1 when the real
Peter Eisentraut wrote:
> On Tuesday 05 May 2009 03:01:05 Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
> > >> I think we can handle that and the cases Tom presents by erroring out
> > >> when the U& syntax is used with stdstr off.
> >
On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira
wrote:
> Robert Haas escreveu:
>> I have always assumed that there is some very good reason why EXPLAIN
>> ANALYZE reports the number of rows as an integer rather than a
>> floating point value, but in reading explain.c it seems that the
Robert Haas escreveu:
> I have always assumed that there is some very good reason why EXPLAIN
> ANALYZE reports the number of rows as an integer rather than a
> floating point value, but in reading explain.c it seems that the
> reason is just that we decided to round to zero decimal places. Any
>
Andy Colson wrote:
Josh Berkus wrote:
Andy,
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may not
be out of the ordinary). I think my kill-a-
On Thu, 28 May 2009, Alvaro Herrera wrote:
There are so many caveats on pg_migrator (and things that need to be
done after the migration is complete) that one starts to wonder if
people is not better off just using parallel pg_restore.
If you've got something close to a 24x7 shop, where planne
I have always assumed that there is some very good reason why EXPLAIN
ANALYZE reports the number of rows as an integer rather than a
floating point value, but in reading explain.c it seems that the
reason is just that we decided to round to zero decimal places. Any
chance we could reconsider this
Added to TODO:
|Improve bytea COPY format
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00192.php
---
Merlin Moncure wrote:
> On Sat, May 16, 2009 at 11:23 AM, Stefan Kaltenbrunner
> wrote:
> >
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Why not? Right now it's single-threaded. Would it be faster if it ran
several copies in parallel?
Sure, but that assumes you have parallel I/O channels; I assume right
now it is I/O limited.
But so
No. Still no sandbox.
-Caleb
On 5/28/09 6:06 PM, "Andrew Dunstan" wrote:
Does Python 3 have some sort of usable sandbox that would mean we could
have a trusted plpython?
Otherwise, I'm not too keen simply to throw Python 2.x overboard until
it's no longer common on platforms people are likely
On Thu, May 28, 2009 at 1:33 AM, Heikki Linnakangas
wrote:
> Now let's discuss implementation. It may well be that there is no solution
> that totally satisfies all those requirements, so there's plenty of room for
> various tradeoffs to discuss. I think fully spec-compliant behavior is a
> hard r
Alvaro Herrera wrote:
Bruce Momjian escribió:
Peter Eisentraut wrote:
On Monday 06 April 2009 02:10:59 James Pye wrote:
Any thoughts on the acceptability of a complete rewrite for Python 3?
http://www.joelonsoftware.com/articles/fog69.html
You usually
Bruce,
Sure, but that assumes you have parallel I/O channels; I assume right
now it is I/O limited.
Even a simple cp will be speeded up between 50% and 150% (depending on
your storage) by doing several files in parallel. However, I'm not sure
that's what you should be spending your time on
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Why not? Right now it's single-threaded. Would it be faster if it ran
> > several copies in parallel?
>
> Sure, but that assumes you have parallel I/O channels; I assume right
> now it is I/O limited.
But so does parallel pg_restore, no?
--
A
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > There are so many caveats on pg_migrator (and things that need to be
> > > done after the migration is complete) that one starts to wonder if
> > > people is not better off just using parallel pg_restore. From Stefan's
Bruce Momjian escribió:
> Peter Eisentraut wrote:
> > On Monday 06 April 2009 02:10:59 James Pye wrote:
> > > Any thoughts on the acceptability of a complete rewrite for Python 3?
> >
> > http://www.joelonsoftware.com/articles/fog69.html
>
> You usually have to rewrite when you have not d
On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> It also seems to me that we're getting seriously sidetracked from the
>>> dependency-tracking part of this project which seems to me to be a
>>> much deeper and more fundamental issue.
>> I thought
On Thu, May 28, 2009 at 3:56 PM, Aidan Van Dyk wrote:
> Ok, so seeing the interest in having a "good conversion", I took a stab at
Awesome!
> Much better!!!
>
> The REL8_0_0 branch seem funny yet:
> src/backend/po/ru.po | 8416 ++--
> src/backend/parse
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > There are so many caveats on pg_migrator (and things that need to be
> > done after the migration is complete) that one starts to wonder if
> > people is not better off just using parallel pg_restore. From Stefan's
> > reported timings I'm not sure
"Kevin Grittner" wrote:
> so as you haven't read other
> data, you would be safe in the particular case you cite.
Sorry, that's not true. If you run your bulk data load at
serializable isolation level, you could still get rolled back in this
scenario, even if you're just writing:
(1) A co
On Fri, May 29, 2009 at 12:53 AM, Bruce Momjian wrote:
> That is accurate. I doubt copy mode speed can be improved. I think
> doing a backup, then using --link mode will be the most common usage
> pattern.
Well doing a backup will take more or less the same time as copy mode, no?
Actually ther
Greg Stark wrote:
> On Fri, May 29, 2009 at 12:53 AM, Bruce Momjian wrote:
> > That is accurate. ?I doubt copy mode speed can be improved. ?I think
> > doing a backup, then using --link mode will be the most common usage
> > pattern.
>
> Well doing a backup will take more or less the same time as
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > People who want decent performance on partial match queries (or maybe
> > even *any* TS queries) are going to have to convert to the new format
> > anyway, though, so maybe this isn't something worth putting a whole lot
> > of work into. It might be s
Peter Eisentraut wrote:
> On Monday 06 April 2009 02:10:59 James Pye wrote:
> > Any thoughts on the acceptability of a complete rewrite for Python 3?
>
> http://www.joelonsoftware.com/articles/fog69.html
You usually have to rewrite when you have not done refactoring as part
of development
Tom Lane wrote:
> People who want decent performance on partial match queries (or maybe
> even *any* TS queries) are going to have to convert to the new format
> anyway, though, so maybe this isn't something worth putting a whole lot
> of work into. It might be sufficient if the database conversi
Greg Stark wrote:
> how much would it suck to find your big data load abort after 10
> hours loading data? And how much if it didn't wasn't even selecting
> data which your data load conflicted with.
That's certainly a fair question. The prototype implementation of the
technique gave preferen
On Thu, May 28, 2009 at 06:28:14PM -0400, Tom Lane wrote:
> Joshua Tolley writes:
> > The dtrace probes documentation [1] spells each probe name with dashes
> > ("transaction-start", "transaction-commit", etc.). Yet as far as I can see,
> > dtrace only works if you spell the probe names with doubl
On Thu, May 28, 2009 at 11:49 PM, Kevin Grittner
wrote:
> The problem
> is that the cost of a "perfect" predicate locking system is much
> higher than the cost of letting some transaction block or roll back
> for retry.
Surely that depends on how expensive it is to retry the transaction?
Like, ho
Greg Stark writes:
> On Thu, May 28, 2009 at 11:26 PM, Bruce Momjian wrote:
>> Kind of --- I am stuck because we don't auto-cast for index usage like
>> we do for function calls and operators, so I will just keep going and
>> disable tsvector.
> I was pretty stumped by what you meant by "auto-ca
Tom Lane wrote:
> The fundamental problem with all the "practical" approaches I've
> heard of is that they only work for a subset of possible predicates
> (possible WHERE clauses). The idea that you get true
> serializability only if your queries are phrased just so is ...
> icky. So icky that
On Thu, May 28, 2009 at 11:26 PM, Bruce Momjian wrote:
> Kind of --- I am stuck because we don't auto-cast for index usage like
> we do for function calls and operators, so I will just keep going and
> disable tsvector.
I was pretty stumped by what you meant by "auto-cast" but now I'm
beginning t
Joshua Tolley writes:
> The dtrace probes documentation [1] spells each probe name with dashes
> ("transaction-start", "transaction-commit", etc.). Yet as far as I can see,
> dtrace only works if you spell the probe names with double underscores
> ("transaction__start", "transaction__commit", etc.
Tom Lane wrote:
> Bruce Momjian writes:
> > Josh Berkus wrote:
> >> Given that it's going to prevent users of Tsearch from
> >> upgrading-in-place, the format change ought to be giving us some serious
> >> gains. Otherwise we should put it off until we need to make other
> >> datatype changes.
Tom,
It was changed to support partial-match tsvector queries. Without it,
a partial match query would have to scan entire tsvectors instead
of applying binary search. I don't know if Oleg and Teodor did any
actual performance tests on the size of the hit, but it seems like
it could be pretty
Bruce Momjian writes:
> Josh Berkus wrote:
>> Given that it's going to prevent users of Tsearch from
>> upgrading-in-place, the format change ought to be giving us some serious
>> gains. Otherwise we should put it off until we need to make other
>> datatype changes.
> No idea but now that we
Josh Berkus writes:
> Bruce,
>> The ordering of the lexems was changed:
> What does that get us in terms of performance etc.?
It was changed to support partial-match tsvector queries. Without it,
a partial match query would have to scan entire tsvectors instead
of applying binary search. I don
Simon Riggs writes:
> Thus there is no guarantee that this is sufficient to have archived all
> the files you would like to archive. The patch does not provide a clean
> shutdown in all cases and since you don't know what state its in, you
> are still forced to take external action to be safe, exa
The dtrace probes documentation [1] spells each probe name with dashes
("transaction-start", "transaction-commit", etc.). Yet as far as I can see,
dtrace only works if you spell the probe names with double underscores
("transaction__start", "transaction__commit", etc.). Why the discrepancy?
Obvious
Josh Berkus wrote:
> Bruce,
>
> > The ordering of the lexems was changed:
> >
> > /*
> > * Convert 8.3 tsvector to 8.4
> > *
> > * 8.3 sorts lexemes by its length and if lengths are the same then it
> > uses
> > * alphabetic order; 8.4 sorts lexemes in lexicographical ord
Bruce,
The ordering of the lexems was changed:
/*
* Convert 8.3 tsvector to 8.4
*
* 8.3 sorts lexemes by its length and if lengths are the same then it
uses
* alphabetic order; 8.4 sorts lexemes in lexicographical order, e.g.
*
* =
On Thu, 2009-05-28 at 19:58 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
> >
> >> postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
> >
> > Then we have a regression, since we changed the code to mak
Josh Berkus wrote:
> On 5/28/09 2:30 PM, Bruce Momjian wrote:
> > Because no one has responded, I am going to prevent pg_migrator from
> > working with a cluster that uses tsvector. I realize this limits
> > pg_migrator's usefulness, but I have to move on.
>
> I don't know how to fix the issue, c
On 5/28/09 2:30 PM, Bruce Momjian wrote:
Because no one has responded, I am going to prevent pg_migrator from
working with a cluster that uses tsvector. I realize this limits
pg_migrator's usefulness, but I have to move on.
I don't know how to fix the issue, certainly.
Why was there a format
Because no one has responded, I am going to prevent pg_migrator from
working with a cluster that uses tsvector. I realize this limits
pg_migrator's usefulness, but I have to move on.
---
Bruce Momjian wrote:
> I found out a
Josh Berkus wrote:
Andy,
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may not
be out of the ordinary). I think my kill-a-watt said, at idle,
On May 28, 2009, at 12:33 PM, Tom Lane wrote:
Greg Stark writes:
Is that really a complete answer? How do we deal with upgrading an
extension to a more recent version? What happens to objects in the
database which depend on objects from the extension?
Well, if it's only a code change then yo
Because no one has responed
---
Bruce Momjian wrote:
> I found out at PGCon that the internal format of tsvector changed
> slightly from 8.3 to 8.4. Teodor gave me a conversion function and I
> have adjusted pg_migrator to
On May 28, 2009, at 12:10 PM, Robert Haas wrote:
It feels like a Java CLASSPATH,
or installing every application into /usr/local/ so
that your path has 50 bin directories in it.
+1 Yeah, that was my trouble with it.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On May 28, 2009, at 11:38 AM, Tom Lane wrote:
I suppose there might be some use-case involving concurrent
installation
of multiple versions of the *same* extension, but I'm not sure we
should
be designing around that as a key case.
Agreed. One thing at a time.
Best,
David
--
Sent via pg
Bruce Momjian wrote:
> > Another advantage of atfork handler is that you can close all open
> > connection and clean resource (similar to what pkcs11 library does). But
> > at this moment libpq does not keep list of open connections and atfork
> > handler works only with pthreads.
> >
> > > I thin
On May 28, 2009, at 11:27 AM, Greg Stark wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler > wrote:
Yes, just as long as your extensions schema doesn't turn into a
bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end up
with a
giant collection of functions and
On May 28, 2009, at 12:53 PM, Kevin Field wrote:
Can pgTap check for a regex instead if just a string?
That's the other option, if the pgTAP author is willing...if the
SQLSTATE thing doesn't work out I guess we'll have to go down that
road.
Patches welcome. ;-)
http://github.com/theory/pg
On May 28, 2009, at 12:22 PM, Tom Lane wrote:
What you need is a test that looks at the SQLSTATE code, and little
if anything else.
Yes, and throws_ok() supports that:
SELECT throws_ok( 'SELECT 1 / 0', '22012' );
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Kevin Field writes:
> I wanted to use the SQLSTATE code, but it's always XX000. If there
> were some way to set it when calling elog()
ereport?
http://developer.postgresql.org/pgdocs/postgres/error-message-reporting.html
At the plpgsql level, since 8.4 you can specify a SQLSTATE in RAISE.
AFAI
* Aidan Van Dyk [090528 15:56]:
> Ok, so seeing the interest in having a "good conversion", I took a stab at
> parsecvs this afternoon, probably what I consider the leading "static"
> conversion tool.
> It takes about 10 minutes to run my old xeon.
>
> And a comparison between it's conversion
* Andres Freund [090528 16:07]:
>> BTW, can anyone comment on whether and how we can maintain the current
>> split between master repository (that's not even accessible to
>> non-committers) and a public mirror? If only from a standpoint of
>> security paranoia, I'd rather like to preserve that
On May 28, 3:28 pm, and...@dunslane.net (Andrew Dunstan) wrote:
> Kevin Field wrote:
> > I use pgTAP to make sure my functions produce the correct errors using
> > throws_ok(). So when I get an error from a plpgsql function, it looks
> > like this:
>
> > ERROR: upper bound of FOR loop cannot be n
On May 28, 3:22 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field writes:
> > I use pgTAP to make sure my functions produce the correct errors using
> > throws_ok(). So when I get an error from a plpgsql function, it looks
> > like this:
> > ERROR: upper bound of FOR loop cannot be null
> >
Hi,
On 05/28/2009 06:19 PM, Tom Lane wrote:
I am hoping that git's cvs server emulation is complete enough that you
can commit through it --- anybody know? But that will be just a
stopgap.
Comitting is no problem - you can't tag, branch or merge through it
though (Not really surprisingly I thi
Zdenek Kotala wrote:
>
> Tom Lane p??e v ne 03. 05. 2009 v 16:39 -0400:
> > Zdenek Kotala writes:
> > > When postgreSQL is compiled with --thread-safe that libpq should be
> > > thread safe. But it is not true when somebody call fork(). The problem
> > > is that fork() forks only active threads a
* Aidan Van Dyk [090527 17:22]:
> And actually looking at the history of the gpo repo, the branches are all
> messed up with "merges" and stuff that I'm not sure where they are coming
> from... 8.2, 8.3, and master(HEAD) are all the same as my gpo repo, but the
> back branchs are very bad...
O
Greg Stark writes:
> Is that really a complete answer? How do we deal with upgrading an
> extension to a more recent version? What happens to objects in the
> database which depend on objects from the extension?
Well, if it's only a code change then you install a newer version of the
.so and you'
Tom Lane wrote:
Robert Haas writes:
It also seems to me that we're getting seriously sidetracked from the
dependency-tracking part of this project which seems to me to be a
much deeper and more fundamental issue.
I thought that part was a pretty simple problem, actually. Have an
ob
Kevin Field wrote:
I use pgTAP to make sure my functions produce the correct errors using
throws_ok(). So when I get an error from a plpgsql function, it looks
like this:
ERROR: upper bound of FOR loop cannot be null
CONTEXT: PL/pgSQL function "foo" line 35 at FOR with integer loop
variable
Kevin Field writes:
> I use pgTAP to make sure my functions produce the correct errors using
> throws_ok(). So when I get an error from a plpgsql function, it looks
> like this:
> ERROR: upper bound of FOR loop cannot be null
> CONTEXT: PL/pgSQL function "foo" line 35 at FOR with integer loop
On Thu, May 28, 2009 at 8:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> It also seems to me that we're getting seriously sidetracked from the
>> dependency-tracking part of this project which seems to me to be a
>> much deeper and more fundamental issue.
>
> I thought that part was a pretty sim
Robert Haas writes:
> It also seems to me that we're getting seriously sidetracked from the
> dependency-tracking part of this project which seems to me to be a
> much deeper and more fundamental issue.
I thought that part was a pretty simple problem, actually. Have an
object representing the mo
2009/5/28 Tom Lane :
> Pavel Stehule writes:
>> for typmod others then -1 we should to use IO cast - but we should to
>> check, if it's one from known casts.
>
> I still think it's fundamentally wrong to be treating typmod -1 so
> differently from other typmods. If this behavior is sane at all th
On Thu, 28 May 2009, Tom Lane wrote:
Each released minor version tag must check out the same as from CVS, at
least back to some specified point (perhaps 7.4.0). I'd really prefer
to insist on that all the way back.
We'd all like to hope that conversion process that works for everything
back
On Thu, May 28, 2009 at 2:27 PM, Greg Stark wrote:
> On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler
> wrote:
>> Yes, just as long as your extensions schema doesn't turn into a bricolage of
>> stuff. I mean, if I use a lot of extensions, it means that I end up with a
>> giant collection of fun
I use pgTAP to make sure my functions produce the correct errors using
throws_ok(). So when I get an error from a plpgsql function, it looks
like this:
ERROR: upper bound of FOR loop cannot be null
CONTEXT: PL/pgSQL function "foo" line 35 at FOR with integer loop
variable
...which I can then t
Pavel Stehule writes:
> for typmod others then -1 we should to use IO cast - but we should to
> check, if it's one from known casts.
I still think it's fundamentally wrong to be treating typmod -1 so
differently from other typmods. If this behavior is sane at all then
it should work in both case
2009/5/28 Tom Lane :
> Pavel Stehule writes:
>> I propose for types with typmod -1 early casting - etc casting to
>> target type on planner level. We cannot use this method for defined
>> typmod, because we would to raise exception for following situation:
>
> What existing coding habits will this
Andy,
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may not
be out of the ordinary). I think my kill-a-watt said, at idle, it was
near 300W. (T
Josh Berkus writes:
> On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
>> That really seems exactly to be what we're proposing with pre_ and post_
>> search_path components: don't change current meaning of search_path,
>> just give DBAs better ways to manage it. And now that you're leaning
>> towards
Greg Stark writes:
> I don't understand what storing them in different namespaces and then
> putting them all in your search_path accomplishes. You end up with the
> same mishmash of things in your namespace.
+1 ... naming conflicts between different extensions are going to be a
problem for peopl
On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
towards a search_path suffix, don't you w
Dimitri Fontaine wrote:
"we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time".
I don't think we all agree on that at all. ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler wrote:
> Yes, just as long as your extensions schema doesn't turn into a bricolage of
> stuff. I mean, if I use a lot of extensions, it means that I end up with a
> giant collection of functions and types and whatnot in this one namespace.
> PHP pr
Pavel Stehule writes:
> I propose for types with typmod -1 early casting - etc casting to
> target type on planner level. We cannot use this method for defined
> typmod, because we would to raise exception for following situation:
What existing coding habits will this break? People have long bee
Alvaro Herrera writes:
> Tom Lane escribió:
>> What was in the back of my mind was that we'd go around and mass-remove
>> $PostgreSQL$ (and any other lurking tags), but only from HEAD and only
>> after the repo conversion. Although just before it would be okay too.
> You mean we would remove the
Hello
current plpgsql cannot detect early some errors based on unknown
casting. Other problem is IO casting.
The reason is an late casting:
current_code is some like:
val = eval_expr(query, &result_type);
if (result_type != expected_type)
{
str = convert_to_string(val, result_type);
val =
Tom Lane escribió:
> Alvaro Herrera writes:
> > There's another issue which is that of the $Id$ and similar tags. We
> > have to decide what we want to do with them. If we're not going to have
> > them in the Git repository, then they are only causing trouble right now
> > and it would be better
On Thu, May 28, 2009 at 12:51 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> There's another issue which is that of the $Id$ and similar tags. We
>> have to decide what we want to do with them. If we're not going to have
>> them in the Git repository, then they are only causing trouble right n
Simon Riggs wrote:
On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
Then we have a regression, since we changed the code to make sure the
archiver did shutdown even if there was a backlog.
The commit messag
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Right. Shall we try to spec out exactly what our conversion
> requirements are? Here's a shot:
[...]
> Comments? Other considerations?
Certainly sounds reasonable to me. I'd be really suprised if that's
really all that hard to accomplish. I'd be happy
On Thu, May 28, 2009 at 12:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> What's hard about that? INSERTs are the hard case, because the rows
>> you care about don't exist yet. SELECT, UPDATE, and DELETE are easy
>> by comparison; you can lock the actual rows at issue. Unless I'm
>> confused?
Alvaro Herrera writes:
> There's another issue which is that of the $Id$ and similar tags. We
> have to decide what we want to do with them. If we're not going to have
> them in the Git repository, then they are only causing trouble right now
> and it would be better to get rid of them completel
Greg Smith writes:
> The best way to control the scope creep here is to avoid doing that, and
> instead focus on what you really need from the repo conversion. [...]
> If the goalposts are moved to "every ancient tag/release ever must build
> perfectly and have sane history no matter how nasty
Robert Haas escribió:
> To me they sound complex and inconvenient. I guess I'm kind of
> mystified by why we can't make this work reliably. Other than the
> "broken tags" issue we've discussed, it seems like the only real issue
> should be how to group changes to different files into a single
>
On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
> postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
Then we have a regression, since we changed the code to make sure the
archiver did shutdown even if there was a backlog. The reason is that if
there is a long b
Greg Smith wrote:
On Thu, 28 May 2009, Andy Colson wrote:
Yeah, when it shipped I think it was about 75 pounds. It is a tower,
yes, and an impressively large box (my experience with servers is
limited, this is the first I've ever gotten to play with, so it may
not be out of the ordinary).
Robert Haas writes:
> On Thu, May 28, 2009 at 12:19 PM, Tom Lane wrote:
>> I think
>> we will have to make a clean cutover from "CVS is authoritative" to
>> "CVS is dead and git is authoritative", and do a fresh repository
>> conversion at that instant. What we should be doing to get prepared fo
On Thu, 28 May 2009, Robert Haas wrote:
My understanding is that the histories of some of the branches we have
now are flat-out wrong. I don't have a problem keeping those
alongside the corrected history for ease of rebasing and porting
commits, but I don't want to punt the problem of figuring
Jignesh K. Shah wrote:
On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote:
Having all extensions live in pg_extension schema also solves the
problem in a much easier way, except for people who care about not
messing it all within a single schema (fourre-tout is the french for a
place where you put anything and everyt
Greg Stark wrote:
> On Thu, May 28, 2009 at 4:33 PM, Kevin Grittner wrote:
>>
>> Can you cite anywhere that such techniques have been successfully
>> used in a production environment
>
> Well there's a reason our docs say: "Such a locking system is
> complex to implement and extremely expensive i
1 - 100 of 169 matches
Mail list logo
