Scott Marlowe writes:
> It was a few posts back, but our discussion point was minor point
> upgrades and the fact that OP was running 8.3.1 and not sure there
> were updates to 8.3.9 (or latest) out there for debian. I'm quite
> sure debian has 8.3.9 out by now.
Yes:
http://packages.debian.o
On Sun, Mar 21, 2010 at 5:33 AM, Craig Ringer
wrote:
> On 21/03/2010 7:12 AM, Scott Marlowe wrote:
>>
>> On Sat, Mar 20, 2010 at 3:57 PM, Herouth Maoz
>> wrote:
>>>
>>>
>>> The problem is not so much danger in upgrading, but the fact that doing
>>> so
>>> without using the system's usual security
On 21/03/2010 7:12 AM, Scott Marlowe wrote:
On Sat, Mar 20, 2010 at 3:57 PM, Herouth Maoz wrote:
The problem is not so much danger in upgrading, but the fact that doing so
without using the system's usual security/bugfix update path means
non-standard work for the sysadmin, meaning he has to
On Sat, Mar 20, 2010 at 3:57 PM, Herouth Maoz wrote:
>
>
> The problem is not so much danger in upgrading, but the fact that doing so
> without using the system's usual security/bugfix update path means
> non-standard work for the sysadmin, meaning he has to upgrade every package
> on the system u
? Scott Marlowe:
On Sat, Mar 20, 2010 at 11:44 AM, Herouth Maoz wrote:
The server version is 8.3.1. Migration to a higher version might be
difficult as far as policies go, if there isn't a supported debian package
for it, but if you can point out a version where this has been fixed I mig
On Sat, Mar 20, 2010 at 11:44 AM, Herouth Maoz wrote:
> The server version is 8.3.1. Migration to a higher version might be
> difficult as far as policies go, if there isn't a supported debian package
> for it, but if you can point out a version where this has been fixed I might
> be able to persu
quoth Greg Smith:
Herouth Maoz wrote:
Aren't socket writes supposed to have time outs of some sort? Stupid
policies notwithstanding, processes on the client side can disappear
for any number of reasons - bugs, power failures, whatever - and this
is not something that is supposed to cause a ba
Herouth Maoz wrote:
Aren't socket writes supposed to have time outs of some sort? Stupid policies
notwithstanding, processes on the client side can disappear for any number of
reasons - bugs, power failures, whatever - and this is not something that is
supposed to cause a backend to hang, I wo
Craig Ringer writes:
> On 17/03/2010 8:43 PM, Herouth Maoz wrote:
>> (gdb) backtrace
>> #0 0x8dfcb410 in ?? ()
>> #1 0xbff10a28 in ?? ()
>> #2 0x083b1bf4 in ?? ()
>> #3 0xbff10a00 in ?? ()
>> #4 0x8db98361 in send () from /lib/tls/i686/cmov/libc.so.6
>> #5 0x08195d54 in secure_write ()
>> #6
On Mar 17, 2010, at 14:56 , Craig Ringer wrote:
> On 17/03/2010 8:43 PM, Herouth Maoz wrote:
>>
>> On Mar 17, 2010, at 13:34 , Craig Ringer wrote:
>>
>>> On 17/03/2010 6:32 PM, Herouth Maoz wrote:
On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
> Though next time you see
On 17/03/2010 8:43 PM, Herouth Maoz wrote:
On Mar 17, 2010, at 13:34 , Craig Ringer wrote:
On 17/03/2010 6:32 PM, Herouth Maoz wrote:
On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
Though next time you see a query which doesn't respond to
pg_cancel_backend(), try gathering information
On Mar 17, 2010, at 13:34 , Craig Ringer wrote:
> On 17/03/2010 6:32 PM, Herouth Maoz wrote:
>>
>> On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
>>
>>> Though next time you see a query which doesn't respond to
>>> pg_cancel_backend(), try gathering information about the query and
>>> what
On 17/03/2010 6:32 PM, Herouth Maoz wrote:
On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
Though next time you see a query which doesn't respond to
pg_cancel_backend(), try gathering information about the query and
what the backend is doing; either you're doing something unusual (e.g.
an a
On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
> Though next time you see a query which doesn't respond to
> pg_cancel_backend(), try gathering information about the query and what the
> backend is doing; either you're doing something unusual (e.g. an app is
> restarting the query automati
>
>
>> Second, and the more complicated one - what do I do about rogue queries
>> that are running when my process starts? Today we had a query that ran since
>> yesterday. I called pg_cancel_backend() on it several times and waited for
>> almost two hours - to no avail. Eventually I had to ask our
On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
>
> On Wed, Mar 3, 2010 at 8:31 AM, Herouth Maoz wrote:
>
> First, the easy part - regarding allowing/disallowing queries. Is it possible
> to GRANT or REVOKE access to tables based on the originating IP?
>
> I'd suggest separating out acces
On Wed, Mar 3, 2010 at 8:31 AM, Herouth Maoz wrote:
>
>
> First, the easy part - regarding allowing/disallowing queries. Is it
> possible to GRANT or REVOKE access to tables based on the originating IP?
>
I'd suggest separating out access to your tables by roles, and then
restricting those roles
Hi.
I'm continuing on with the problems I have in our reports/data warehouse
system. Basically, the system brings in tables from our various production
systems (sybase, postgresql, mssql, different servers) every night. Some tables
are brought in whole, and some are brought in based on a date f
18 matches
Mail list logo
