Itagaki Takahiro wrote:
>
> Alvaro Herrera wrote:
>
> > > We should remember whether a field was specified or not independntly.
> > I'm not sure what you are suggesting ...?
>
> Please imagine that:
>
> =# SET autovacuum_vacuum_scale_factor = 0.05;
> =# ALTER TABLE tbl SET (autovacuum_vacuum_t
Alvaro Herrera wrote:
> > We should remember whether a field was specified or not independntly.
> I'm not sure what you are suggesting ...?
Please imagine that:
=# SET autovacuum_vacuum_scale_factor = 0.05;
=# ALTER TABLE tbl SET (autovacuum_vacuum_threshold = 10);
AutoVacOpts.vacuum_threshol
Itagaki Takahiro wrote:
>
> Alvaro Herrera wrote:
>
> > we could use that to set a boolean
> > in StdRdOptions that indicated whether they are set in reloptions or are
> > default values.
>
> Do you mean we will have a boolean field *for each* field in StdRdOptions?
No, I was thinking in a sin
Here is a patch to fix a bug in handling default values in reloptions.
This fix should be applied to HEAD and 8.4.0.
I used 'magic number -1' to propagate "not-specified" information to
autovacuum process. It might look strange because the default value is
out of range of the reloption, but I thi
Alvaro Herrera wrote:
> we could use that to set a boolean
> in StdRdOptions that indicated whether they are set in reloptions or are
> default values.
Do you mean we will have a boolean field *for each* field in StdRdOptions?
We should remember whether a field was specified or not independntly
Itagaki Takahiro wrote:
> To fix the bug, each field in StdRdOptions should have "not-specified" flag.
> If not specified, autovacuum should use current GUC settings instead of
> reloptions. Is it possible to change the default values of reloptions
> to some magic number (-1 or so) ?
Ah. After c
On Wed, Aug 19, 2009 at 11:45, Heikki
Linnakangas wrote:
> Magnus Hagander wrote:
>> This would amount to fairly major surgery for pg_standby on Win32. Is
>> that something we'd want to backpatch, or do we want to backpatch just
>> the removal of the signal() calls which would amount to not support
The following bug has been logged online:
Bug reference: 4996
Logged by: Shivesh Wangrungvichaisri
Email address: s...@appsig.com
PostgreSQL version: 8.3.7
Operating system: Windows XP x64 / Windows 7 x64
Description:postgres.exe memory consumption keeps going up
Deta
Morus Walter writes:
> Is there a place where I should have read about solved issues before
> sending the report? (Besides reading the bugs/committers mailing list)
You could try scanning the pgsql-bugs archives, but there's no formal
tracking mechanism.
regards, tom lane
HI,
I have a normal user 'abcd' and grant all previliges to this user on the
database 'pqr'.
now i am unable to use dblink(text,text).
while via super user 'postgre' which is the owner of database 'postgre' I
am able to use dblink(text,text).
Can you please let me know how to get use of dblink(
Hallo Tom,
> > when trying to use the array_agg aggregate I ran into a `out of memory'
> > issue.
>
> This looks like a known issue, fixed here:
>
> http://archives.postgresql.org/pgsql-committers/2009-07/msg00210.php
>
> It will be in 8.4.1.
>
Thanks a lot.
I tried the modifications mentioned
Magnus Hagander wrote:
> This would amount to fairly major surgery for pg_standby on Win32. Is
> that something we'd want to backpatch, or do we want to backpatch just
> the removal of the signal() calls which would amount to not supporting
> signals in pg_standby on win32?
I think we should just
On Wed, Aug 19, 2009 at 10:31 AM, Magnus Hagander wrote:
> On Tue, Aug 18, 2009 at 19:38, Ali Al-Aswad wrote:
>> msiexec /i postgresql-8.2-int.msi /qn INTERNALLAUNCH=1 DOSERVICE=1
>
>
> ^ This says 8.2.
>
>> The PostgreSQL Database Server 8.0 service on Local Computer started and
>> then stopped. S
On Tue, Aug 18, 2009 at 19:38, Ali Al-Aswad wrote:
> msiexec /i postgresql-8.2-int.msi /qn INTERNALLAUNCH=1 DOSERVICE=1
^ This says 8.2.
> The PostgreSQL Database Server 8.0 service on Local Computer started and
> then stopped. Some services stop automatically if they have no work to do,
> for e
On Wed, Aug 19, 2009 at 08:38, Fujii Masao wrote:
> On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagander wrote:
>> Not sure. Potentially pure luck. SIGINT has never *worked*, though, it
>> just hasn't crashed.
>
> OK.
>
>> We could implement the same type of check in pg_standby, but it
>> requires some
15 matches
Mail list logo
