Jonathan Guthrie wrote:
> The thing is, the C++ code does this
>
> BEGIN transaction 1
> INSERT project
> COMMIT
>
> BEGIN transaction 2
> SET permissions
> COMMIT
>
> or, at least, it's supposed to.
OK, and we know that if it is doing what it is supposed to, transaction
2 /must/ see the chang
Jonathan Guthrie <[EMAIL PROTECTED]> writes:
> ... or, at least, it's supposed to. Those two operations are not supposed
> to overlap at all even if they're on two different connections. I
> thought I had verified this by looking at the log file. I mean, I can
> look at the log file and see thin
On Wed, 2008-11-05 at 04:40 +0900, Craig Ringer wrote:
> The point is that if your initial create and the setting of the initial
> permissions must succeed or fail together, they MUST be done within a
> single transaction. That is, in fact, the fundamental point of database
> transactions.
I under
Jonathan Guthrie wrote:
> It's possible, likely even. We use a connection pool to manage
> connections to the database and they're doled out as the system sees
> fit. However, at some point every update has to finish such that any
> view of the database will see that update as finished, right?
Jonathan Guthrie wrote:
> On Tue, 2008-11-04 at 07:49 +, Richard Huxton wrote:
>> Jonathan Guthrie wrote:
>>> When I create a project, entries in the project table and the resource
>>> table are created in a single function. Then, separate functions are
>>> called to set the owner's access to
On Tue, Nov 4, 2008 at 11:18 AM, Jonathan Guthrie
<[EMAIL PROTECTED]> wrote:
> On Tue, 2008-11-04 at 07:49 +, Richard Huxton wrote:
>> Jonathan Guthrie wrote:
>> > When I create a project, entries in the project table and the resource
>> > table are created in a single function. Then, separate
On Tue, 2008-11-04 at 07:49 +, Richard Huxton wrote:
> Jonathan Guthrie wrote:
> > When I create a project, entries in the project table and the resource
> > table are created in a single function. Then, separate functions are
> > called to set the owner's access to the new project. These oth
Jonathan Guthrie wrote:
> When I create a project, entries in the project table and the resource
> table are created in a single function. Then, separate functions are
> called to set the owner's access to the new project. These other
> functions are failing because of the resourceid foreign key
Jonathan Guthrie wrote:
> The stored procedures (250 or so of them) have
> been converted into Postgres functions using a tool called SQLWays. I'm
> using named prepared procedures for each of the Postgres functions that
> are called, plus three, "BEGIN", "COMMIT", and "ROLLBACK", which consist
I've been tearing my hair out over this one issue and I'm hoping that
someone on this list will have an insight on the matter that will shed
some light on why the system is doing what it's doing.
I have a database with a number of tables, two of which are projects and
resources. We also have a us
10 matches
Mail list logo
