On Sun, Dec 21, 2008 at 9:35 PM, Bruce Momjian wrote:
> Jonah H. Harris wrote:
>> On Sun, Dec 21, 2008 at 11:02 PM, Scott Marlowe
>> wrote:
>> > The difference is HE put forth an opinion about the pg developers
>> > being smarter, but you put forth what seems like a statement of fact
>> > with n
Jonah H. Harris wrote:
> On Sun, Dec 21, 2008 at 11:02 PM, Scott Marlowe
> wrote:
> > The difference is HE put forth an opinion about the pg developers
> > being smarter, but you put forth what seems like a statement of fact
> > with no evidence to back it up. One is quite subjective and open fo
On Sun, Dec 21, 2008 at 11:02 PM, Scott Marlowe wrote:
> The difference is HE put forth an opinion about the pg developers
> being smarter, but you put forth what seems like a statement of fact
> with no evidence to back it up. One is quite subjective and open for
> debate on both sides, and ofte
On Sun, Dec 21, 2008 at 11:04 PM, Scott Marlowe wrote:
>> Having dealt with cust service for a few commercial dbs, I can safely
>> say I get way better service from way smarter people when I have a
>> problem. And I don't have a lot of problems.
>
> Clarificiation: That's saying I get better ser
> Having dealt with cust service for a few commercial dbs, I can safely
> say I get way better service from way smarter people when I have a
> problem. And I don't have a lot of problems.
Clarificiation: That's saying I get better service and such from pg
users / developers than anywhere else.
On Sun, Dec 21, 2008 at 8:48 PM, Jonah H. Harris wrote:
> On Sun, Dec 21, 2008 at 9:42 PM, David Fetter wrote:
>> On Sun, Dec 21, 2008 at 08:46:15PM -0500, Jonah H. Harris wrote:
>>> On Fri, Dec 19, 2008 at 7:49 AM, Alvaro Herrera
>>> wrote:
>>> >> Oracle on the other hand stores the lock inform
On Sun, Dec 21, 2008 at 9:42 PM, David Fetter wrote:
> On Sun, Dec 21, 2008 at 08:46:15PM -0500, Jonah H. Harris wrote:
>> On Fri, Dec 19, 2008 at 7:49 AM, Alvaro Herrera
>> wrote:
>> >> Oracle on the other hand stores the lock information directly in
>> >> the data block that is locked, thus the
On Sun, Dec 21, 2008 at 08:46:15PM -0500, Jonah H. Harris wrote:
> On Fri, Dec 19, 2008 at 7:49 AM, Alvaro Herrera
> wrote:
> >> Oracle on the other hand stores the lock information directly in
> >> the data block that is locked, thus the number of locks does not
> >> affect system performance (in
On Fri, Dec 19, 2008 at 7:49 AM, Alvaro Herrera
wrote:
>> Oracle on the other hand stores the lock information directly in the data
>> block that is locked, thus the number of locks does not affect system
>> performance (in terms of managing them).
>>
>> I couldn't find any description on which st
Howdy, all.
I have a log-shipping replication environment (based on PostgreSQL
8.3.4) using pg_lesslog+LZOP for compression of archived segments (kept
around long-term for possible use doing PITR). The slave came out of
synchronization recently, restoring a series of segments and then
failing
On Sunday 21 December 2008 1:49:18 am Herouth Maoz wrote:
> Adrian Klaver wrote:
> >
> >
> > Are you sure the problem is not in "$datefield" = "*" . That the script
> > that formats the data file is not correctly adding "*" to the right file.
> > Seems almost like sometimes the second CMD is being
(Sorry for the forward, I forgot to CC the list)
On Wed, Dec 17, 2008 at 9:38 AM, Herouth Maoz wrote:
> and for non-transaction tables (ones that have records that might
> change but don't accumulate based on time) it's DELETE without WHERE.
In that case, you are better off using TRUNCATE instea
Adrian Klaver wrote:
>
>
> Are you sure the problem is not in "$datefield" = "*" . That the script that
> formats the data file is not correctly adding "*" to the right file. Seems
> almost like sometimes the second CMD is being run against the table that the
> first CMD should be run on. In ot
13 matches
Mail list logo
