On Sun, Sep 26, 2010 at 12:56 AM, Esteban Zimanyi
wrote:
> When I run the examples there is a server crash. I used both Visual
> C++ 2008 and 2005 for building the dll. I also used both PostgreSQL
> versions 8.4 and 9.0. All versions produce the same problem.
>
> Do you know how can I solve the pr
Greg Stark wrote:
> Just to be clear I wasn't saying it was or wasn't a problem, I was
> just trying to see if I understand the problem and if I do maybe
> help bring others up to speed.
Thanks for that, and my apologies for misunderstanding you. It does
sound like you have a firm grasp on my
On Sat, Sep 25, 2010 at 10:45 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Sep 23, 2010 at 4:08 PM, Kevin Grittner
>> wrote:
>>> One place I'm particularly interested in using such a feature is in
>>> pg_dump. Without it we have the choice of using a SERIALIZABLE
>>> transaction, which mi
Hello
I have problems defining user-defined types and functions in
PostgreSQL using a Visual C++ development environment.
In order to look for the solution I took the complex.c and
complex.source files coming with the PostgreSQL distribution
(src/tutorial).
When I run the examples there is a ser
On Sat, Sep 25, 2010 at 10:34 AM, Tom Lane wrote:
> This is all pretty much a dead end, because it offers no confidence
> whatsoever. Suppose that COPY calls type X's input function, which
> calls function Y, which calls function Z. Z doesn't like what it sees
> so it throws an error, which it m
Hi all.
My name is Jose Arthur and I use PostgreSQL for a while, but never
contributed to the main project, until now.
Since nobody else take this patch to review in this commitfest, I'm going to
try :-). The main problem can be found here:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg
Just to be clear I wasn't saying it was or wasn't a problem, I was just
trying to see if I understand the problem and if I do maybe help bring
others up to speed.
On 25 Sep 2010 23:28, "Kevin Grittner" wrote:
> Greg Stark wrote:
>
>> So T1 must have happened before TN because it wrote something ba
Greg Stark wrote:
> So T1 must have happened before TN because it wrote something based
> on data as it was before TN modified it. But T0 can see TN but not
> T1 so there's no complete ordering between the three transactions
> that makes them all make sense.
Correct.
> The thing is that the
On Sat, Sep 18, 2010 at 4:21 AM, Robert Haas wrote:
>> (It's exactly what apache pre-fork does, no? Is anybody concerned about the
>> idle processes there? Or do they consume much less resources?)
>
> I don't know whether an idle Apache worker consumes more or less
> memory than an idle Postg
I'm not subscribed to pgsql-committers, but apparently under the new
git-enabled setup, I'm getting a "Stalled post to pgsql-committers"
message for every commit. Fix that please.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Sat, Sep 25, 2010 at 4:24 PM, Kevin Grittner
wrote:
> OK, to get back to the question -- pg_dump's transaction (T0) could
> see an inconsistent version of the database if one transaction (TN)
> writes to a table, another transaction (T1) overlaps TN and can't
> read something written by TN beca
Nicolas Barbier wrote:
> IOW, one could say that the backup is consistent only if it were
> never compared against the system as it continued running after the
> dump took place.
Precisely. I considered making that point in the email I just sent,
but figured I had rambled enough. I suppose I
Greg Stark wrote:
> Kevin Grittner wrote:
>> One place I'm particularly interested in using such a feature is
>> in pg_dump. Without it we have the choice of using a SERIALIZABLE
>> transaction, which might fail or cause failures (which doesn't
>> seem good for a backup program) or using REPEAT
Greg Stark writes:
> On Thu, Sep 23, 2010 at 4:08 PM, Kevin Grittner
> wrote:
>> One place I'm particularly interested in using such a feature is in
>> pg_dump. Without it we have the choice of using a SERIALIZABLE
>> transaction, which might fail or cause failures (which doesn't seem
>> good for
Gurjeet Singh writes:
> On Fri, Sep 24, 2010 at 11:15 PM, Robert Haas wrote:
>> Hmm. So the problem is that we don't want to accidentally catch an
>> error that isn't actually safe to catch. We could probably mitigate
>> this problem to a considerable degree by throwing data validation
>> error
[ Forgot the list, resending. ]
2010/9/25 Greg Stark :
> On Thu, Sep 23, 2010 at 4:08 PM, Kevin Grittner
> wrote:
>
>> One place I'm particularly interested in using such a feature is in
>> pg_dump. Without it we have the choice of using a SERIALIZABLE
>> transaction, which might fail or cause f
On Sat, Sep 25, 2010 at 8:28 AM, Michael Haggerty wrote:
> It looks like your transition to git has been a success. Your very
> careful conversion from CVS to git and your exacting scrutiny of the
> results are a great check that cvs2git is not doing anything completely
> crazy. I will soon rele
Hi,
It looks like your transition to git has been a success. Your very
careful conversion from CVS to git and your exacting scrutiny of the
results are a great check that cvs2git is not doing anything completely
crazy. I will soon release a version 2.4 of cvs2svn that includes the
many improveme
On Thu, Sep 23, 2010 at 4:08 PM, Kevin Grittner
wrote:
> One place I'm particularly interested in using such a feature is in
> pg_dump. Without it we have the choice of using a SERIALIZABLE
> transaction, which might fail or cause failures (which doesn't seem
> good for a backup program) or using
On Thu, Sep 23, 2010 at 02:33:06PM -0400, Robert Haas wrote:
> I'm worried about how we're going to manage that. First, as
> pg_upgrade becomes more mature, the penalty for breaking on-disk
> compatibility gets a LOT bigger. I'd like to think that "the next
> time we break on-disk compatibility"
On Fri, Sep 24, 2010 at 11:15 PM, Robert Haas wrote:
> On Fri, Sep 24, 2010 at 3:41 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Sep 21, 2010 at 7:05 PM, Tom Lane wrote:
> >>> There are many rules that you could possibly make for type input
> >>> functions. But "you cannot throw a
Craig Ringer wrote:
On 25/09/2010 11:51 AM, Darren Duncan wrote:
There should just be a single syntax that works for all types, in the
general case, for testing whether a value is a member of that type, or
alternately whether a value can be cast to a particular type.
Pg already gets it right
On 25/09/2010 11:51 AM, Darren Duncan wrote:
Colin 't Hart wrote:
The fact that this wraps would seem to me to make the implementation
of is_date() difficult.
Having separate is_foo() syntax per type is a bad design idea, same as
having a different equality test like eq_int() or assignment syn
23 matches
Mail list logo
