On Jan21, 2011, at 10:16 , Simon Riggs wrote:
> On Fri, 2011-01-21 at 13:49 +0900, Tatsuo Ishii wrote:
>>
>>> I'm pretty well convinced that we should NOT be issuing
>>> ERRCODE_ADMIN_SHUTDOWN for a recovery conflict, but that could be
>>> fixed by a trivial simplification of the code posted above
On 01/21/2011 03:25 AM, Florian Pflug wrote:
The COMMIT order in the actual, concurrent, schedule doesn't not necessarily
represent the order of the transaction in an equivalent serial schedule. Here's
an example
T1: BEGIN SERIALIZABLE; -- (Assume snapshot is set here)
T1: UPDATE D1 ... ;
T2: BE
On Tue, Jan 18, 2011 at 09:33, Kevin Grittner
wrote:
> Review for CF:
Thank your for the review!
> Since it doesn't appear to be intended to change any user-visible
> behavior, I don't see any need for docs or changes to the regression
> tests.
There might be some user-visible behaviors in erro
On Fri, Jan 21, 2011 at 04:06, Andrew Dunstan wrote:
>
>
> On 01/20/2011 09:52 PM, Robert Haas wrote:
>>
>> On Thu, Jan 20, 2011 at 10:17 AM, XiaoboGu wrote:
>>>
>>> Hi,
>>> We are using R to work with 64bit PostgreSQL client libraries, and
>>> to avoid compiler compatibility issues the R
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii wrote:
>> Here is the patch to implement the feature.
>>
>> 1) pg_terminate_backend() sends SIGUSR1 signal rather than SIGTERM to
>> the target backend.
>> 2) The infrastructure used for message passing is
>> storage/ipc/procsignal.c The new messag
On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
> On 21.01.2011 11:10, Simon Riggs wrote:
> > So any xid that commits in a different sequence to the order in which
> > the xid was assigned creates a potential for unserialization? Or?
>
> It's not the order in which the xid was assigne
On 20.01.2011 17:22, Heikki Linnakangas wrote:
(I'm working on this, no need to submit a new patch)
Ok, here's a heavily refactored version of this (also available at
git://git.postgresql.org/git/users/heikki/postgres.git, branch
pg_dump_directory). The directory format is now identical to th
On 21.01.2011 11:10, Simon Riggs wrote:
So any xid that commits in a different sequence to the order in which
the xid was assigned creates a potential for unserialization? Or?
It's not the order in which the xid was assigned that matters, but the
order the transactions started and got their sn
On Fri, 2011-01-21 at 13:49 +0900, Tatsuo Ishii wrote:
> >
> > I'm pretty well convinced that we should NOT be issuing
> > ERRCODE_ADMIN_SHUTDOWN for a recovery conflict, but that could be
> > fixed by a trivial simplification of the code posted above, without
> > introducing any new error code.
>
On Fri, 2011-01-21 at 02:32 -0500, Dan Ports wrote:
> On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
> > We have enough information in the standby to reconstruct all writes done
> > in the master. I gather that's not enough, in order to roll back
> > read-only transaction T3
On Thu, Jan 20, 2011 at 8:13 PM, Itagaki Takahiro
wrote:
> On Fri, Jan 21, 2011 at 09:11, Bruce Momjian wrote:
>> What happened to our work to add a JSON data type for PG 9.1?
>
> Nothing will happen in 9.1.
> I assume we are in "competition" status:
>
> http://archives.postgresql.org/pgsql-hacke
On Wed, Jan 19, 2011 at 1:12 PM, Fujii Masao wrote:
>>> + r = PQgetCopyData(conn, ©buf, 0);
>>> + if (r == -1)
>>>
>>> Since -1 of PQgetCopyData might indicate an error, in this case,
>>> we would need to call PQgetResult?.
>>
>> Uh, -1 means end of data, no? -2 means e
101 - 112 of 112 matches
Mail list logo
