Simon Riggs schreef:
On Fri, 2007-10-12 at 07:17 +0100, Simon Riggs wrote:
On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
Michael Paesold escribió:
Simon Riggs wrote:
Hmm, I am not sure we are there, yet. Autovacuum does take extra care to
vacuum tables neari
On Fri, Oct 12, 2007 at 07:51:13AM +0100, Simon Riggs wrote:
> On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Kevin Grittner wrote:
> > >> If the goal is to provide fair warning of a high-than-usual-risk
> > >> release, you've got it covered.
Hannu Krosing wrote:
> > We have hooks in executor calling our own collecting functions, so we
> > don't need the trigger machinery to launch replication.
>
> But where do you store the collected info - in your own replication_log
> table, or do reuse data in WAL you extract it on master befor
>
Gokulakannan Somasundaram wrote:
> Last two mails were sent by mistake without completion. I couldn't
> curse my system any further
:-)
> a) Dead Space, if it is successfull in its implementation of what it claims,
> will have the means to point out that all the tuples of certain chunks
Simon Riggs wrote:
I think the best way to handle this is to have two limits.
First limit attempts to autovacuum, but can be cancelled.
When we hit second limit, sometime later, then autovacuum cannot be
cancelled.
That would give us a breathing space if we need it.
Sounds quite reasonable.
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
--
Andreas Joseph Krogh <[EMAIL PROTECTED]>
Senior Software Developer / Manager
+-+
OfficeNet AS| The most difficult thing in t
Mario Weilguni wrote:
> I cannot use "-1" for performance, because some gist stuff has changed
> and the restore fails. But there seems to be no option for pg_restore to
> use transactions for data restore, so it's very very slow (one million
> records, each obviously in it's own transaction - beca
On Fri, Oct 12, 2007 at 02:03:47PM +0100, Gregory Stark wrote:
> This approach doesn't address that but I don't think it makes the problems
> there any worse either. That is, I think already have these problems around
> shared tables.
Or we could just setup encodings/locales per column and the pr
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
>> . when creating a new database from a template the new locale and encoding
>> must be identical to the template database's encoding and locale. Unless
>> the template is template0 in which cas
Heikki Linnakangas wrote:
Mario Weilguni wrote:
I cannot use "-1" for performance, because some gist stuff has changed
and the restore fails. But there seems to be no option for pg_restore to
use transactions for data restore, so it's very very slow (one million
records, each obviously in it's o
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> * Just remove the above-quoted lines. Superusers should be allowed to
>>> shoot themselves in the foot. (I'm not actually sure that there would
>>> be any bad consequences from putting an ordinary table into pg_g
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Just remove the above-quoted lines. Superusers should be allowed to
>> shoot themselves in the foot. (I'm not actually sure that there would
>> be any bad consequences from putting an ordinary table into pg_global
>> anyway.
> Is
Tom Lane wrote:
> I wrote:
>> [ squint... ] There is something wrong here, because a superuser should
>> certainly pass the aclcheck test. I don't know where the bug is but
>> this is not the correct fix.
>
> OK, after looking, the issue is this wart in pg_tablespace_aclmask():
>
> /*
>
On Fri, 2007-10-12 at 13:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Can you explain further what you meant by "don't disable manual
> > cancels".
>
> I meant that pg_cancel_backend() should still work on autovac workers,
> contrary to Alvaro's suggestion that autovac w
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> With respect to you Kevin, your managers should wait. You don't
>> install .0 releases of "any" software into production without "months"
>> of testing. At which point, normally a .1 release has come out anyway.
>
> How exactly do
Simon Riggs <[EMAIL PROTECTED]> writes:
> Can you explain further what you meant by "don't disable manual
> cancels".
I meant that pg_cancel_backend() should still work on autovac workers,
contrary to Alvaro's suggestion that autovac workers should sometimes
ignore SIGINT.
Basically the implement
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
It would make Postgres inconsistent and less integrated with the rest of
the OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't
On Fri, 2007-10-12 at 11:26 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > That seemed more complex when I thought about that, but if we just use
> > SIGUSR2 for automatic cancels then this would be very simple.
>
> Why not SIGINT?
I must be missing something. How would I te
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
>> It would make Postgres inconsistent and less integrated with the rest of
>> the OS. How do you explain that Postgres doesn't follow the system's
>> configurations and the collations don't agree wit
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Attached is a patch I want to apply for this. Toms message at
>> http://archives.postgresql.org/pgsql-hackers/2007-10/msg00448.php makes me
>> bring it up here before I apply it.
>
> [ squint... ] There is something wrong here, beca
On Fri, Oct 12, 2007 at 03:28:26PM +0100, Gregory Stark wrote:
> Fix the problem by making ICU a smaller less complex dependency?
How? It's 95% data, you can't reduce that. glibc also has 10MB of locale
data. That actual code is much smaller than postgres and doesn't depend
on any other non-syste
Michael Glaesemann wrote:
>
> On Oct 12, 2007, at 10:19 , Gregory Stark wrote:
>
>> It would make Postgres inconsistent and less integrated with the rest
>> of the
>> OS. How do you explain that Postgres doesn't follow the system's
>> configurations and the collations don't agree with the system
>>
Simon Riggs <[EMAIL PROTECTED]> writes:
> That seemed more complex when I thought about that, but if we just use
> SIGUSR2 for automatic cancels then this would be very simple.
Why not SIGINT?
regards, tom lane
---(end of broadcast)
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > select pg_tablespace_size('pg_global');
> > ERROR: permission denied for tablespace pg_global
>
> > Can this be fixed please?
>
> What's to be fixed? That's exactly the result I'd expect given the
> previously-agreed-to behavior for pg
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Attached is a patch I want to apply for this. Toms message at
> http://archives.postgresql.org/pgsql-hackers/2007-10/msg00448.php makes me
> bring it up here before I apply it.
[ squint... ] There is something wrong here, because a superuser should
ce
Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> Will $SUBJECT make it possible for count(*) to use index? This is a much
> wanted feature.
If you mean "count(*) will become instantaneous", no it won't. It would
get faster, but probably not by more than a factor of 10 or so,
corresponding to th
On Fri, Oct 12, 2007 at 06:03:52AM -0700, Trevor Talbot wrote:
> On 10/12/07, Dave Page <[EMAIL PROTECTED]> wrote:
> > Tom Lane wrote
> > > That still leaves us with the problem of how to tell whether a locale
> > > spec is bad on Windows. Judging by your example, Windows checks whether
> > > the
On Fri, Oct 12, 2007 at 12:20:08PM +0100, Dave Page wrote:
> Following on from Hiroshi's earlier post:
> http://archives.postgresql.org/pgsql-hackers/2007-10/msg00324.php
>
> Per http://archives.postgresql.org/pgsql-hackers/2007-08/msg01018.php,
> superusers should be able to use pg_tablespace_siz
Am Freitag, 12. Oktober 2007 schrieb Martijn van Oosterhout:
> Where we're stuck is that we can't agree on a
> source of locale data. People don't want the ICU or glibc data and
> there's no other source as readily available.
What were the objections to ICU?
--
Peter Eisentraut
http://developer.
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> People don't want the ICU or glibc data and there's no other source as
> readily available.
>
> Perhaps we should fix that problem, rather than making more
> workarounds.
Fix the problem by making ICU a smaller less complex dependency?
Or fi
On 10/12/07, Dave Page <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote
> > That still leaves us with the problem of how to tell whether a locale
> > spec is bad on Windows. Judging by your example, Windows checks whether
> > the code page is present but not whether it is sane for the base locale.
> >
Simon Riggs schreef:
On Fri, 2007-10-12 at 11:44 +0200, Michael Paesold wrote:
Simon Riggs wrote:
On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
Yes, I think it is easy to mark the "is for xid wraparound" bit in the
WorkerInfo struct and have the cancel work only if it
There's a IMO a problem with pg_restore, it should be easy to fix (I
hope - and I could try to fix it and send a patch).
* I've a dump taken from a 8.1 database
* I'm using gist and ltree
* I'm restoring to a 8.2 database
Problem:
I cannot use "-1" for performance, because some gist stuff has ch
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
> . when creating a new database from a template the new locale and encoding
> must be identical to the template database's encoding and locale. Unless
> the template is template0 in which case we rebuild all indexes after
> copying.
Why would
On 10/12/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> If records have just been inserted to a block, it is in cache. Therefore
> hitting that block to check visibility isn't going to cost much. There
> might be some middle-ground where a tuple has been in
Hannu Krosing wrote:
> > We don't use either a log table in database or WAL. The data to
> > replicate is stored in disk files, one per transaction.
>
> Clever :)
>
> How well does it scale ? That is, at what transaction rate can your
> replication keep up with database ?
This depend on a numbe
It seems like the root of the problems we're butting our heads against with
encoding and locale is all the same issue: it's nonsensical to take the locale
at initdb time per-cluster and then allow user-specified encoding
per-database. If anything it would make more sense to go the other way around
Following on from Hiroshi's earlier post:
http://archives.postgresql.org/pgsql-hackers/2007-10/msg00324.php
Per http://archives.postgresql.org/pgsql-hackers/2007-08/msg01018.php,
superusers should be able to use pg_tablespace_size() on any tablespace,
however when logged in as postgres on a beta1
Ühel kenal päeval, R, 2007-10-12 kell 12:39, kirjutas Alexey Klyukin:
> Hannu Krosing wrote:
>
> > > We have hooks in executor calling our own collecting functions, so we
> > > don't need the trigger machinery to launch replication.
> >
> > But where do you store the collected info - in your own
On Tue, Oct 09, 2007 at 05:44:22PM -0400, Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
> >
> >
> >Magnus Hagander wrote:
> >>>(Hint: if you don't put the PlatformSDK directories first in the
> >>>INCLUDE and LIB lists bad and inexplicable things can happen.)
> >>>
> >>>Pick up the latest ve
Andreas Joseph Krogh wrote:
> Will $SUBJECT make it possible for count(*) to use index? This is a much
> wanted feature.
Yes, both the DSM approach and the approach proposed by Gokul.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadc
On Friday 12 October 2007 11:49:17 Heikki Linnakangas wrote:
> Andreas Joseph Krogh wrote:
> > Will $SUBJECT make it possible for count(*) to use index? This is a much
> > wanted feature.
>
> Yes, both the DSM approach and the approach proposed by Gokul.
Good.
--
Andreas Joseph Krogh <[EMAIL PRO
Simon Riggs wrote:
On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
Yes, I think it is easy to mark the "is for xid wraparound" bit in the
WorkerInfo struct and have the cancel work only if it's off.
However, what I think should happen is that the signal handler for
SIGINT in a worker f
Am Donnerstag, 11. Oktober 2007 schrieb Gregory Stark:
> Thinking of it as UTC is the wrong way to think about it. A birth occurred
> at a specific moment in time. You want to record that precise moment, not
> what it happened to show on the clock at the time. If the clock turns out
> to have been
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2007-10-12 at 11:26 -0400, Tom Lane wrote:
>> Why not SIGINT?
> I must be missing something. How would I tell the difference between
> manual and automatic cancels if we use SIGINT for both cases?
Why do you need to? I thought the plan was that D
I wrote:
> [ squint... ] There is something wrong here, because a superuser should
> certainly pass the aclcheck test. I don't know where the bug is but
> this is not the correct fix.
OK, after looking, the issue is this wart in pg_tablespace_aclmask():
/*
* Only shared relations can b
On Fri, 2007-10-12 at 11:44 +0200, Michael Paesold wrote:
> Simon Riggs wrote:
> > On Fri, 2007-10-12 at 01:24 -0400, Alvaro Herrera wrote:
> >> Yes, I think it is easy to mark the "is for xid wraparound" bit in the
> >> WorkerInfo struct and have the cancel work only if it's off.
> >>
> >> However
I agree with that. I will go ahead and do a test implementation and share
the results with everyone.
Thanks,
Gokul.
On 10/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> > Will $SUBJECT make it possible for count(*) to use index? This is a much
>
On Oct 12, 2007, at 10:19 , Gregory Stark wrote:
It would make Postgres inconsistent and less integrated with the
rest of the
OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't agree with the system
collations?
How is this fundamentall
Dave Page <[EMAIL PROTECTED]> writes:
> In the message I quoted at the end of the long discussion on the topic
> you assured me it would work for superusers.
> Is there any reason the superuser shouldn't see the size of pg_global?
Oh, you were superuser? Then something's broken, agreed.
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> select pg_tablespace_size('pg_global');
>> ERROR: permission denied for tablespace pg_global
>
>> Can this be fixed please?
>
> What's to be fixed? That's exactly the result I'd expect given the
> previously-agreed-to behavior for pg_ta
Tom Lane wrote
> That still leaves us with the problem of how to tell whether a locale
> spec is bad on Windows. Judging by your example, Windows checks whether
> the code page is present but not whether it is sane for the base locale.
> What happens when there's a mismatch --- eg, what encoding d
Heikki Linnakangas schrieb:
Mario Weilguni wrote:
I cannot use "-1" for performance, because some gist stuff has changed
and the restore fails. But there seems to be no option for pg_restore to
use transactions for data restore, so it's very very slow (one million
records, each obviously in i
Simon Riggs <[EMAIL PROTECTED]> writes:
> I think the best way to handle this is to have two limits.
> First limit attempts to autovacuum, but can be cancelled.
> When we hit second limit, sometime later, then autovacuum cannot be
> cancelled.
This seems like uselessly complex overdesign.
Remembe
Trevor Talbot wrote:
> The encoding output is the one you specified.
OK.
> Keep in mind,
> underneath Windows is mostly working with Unicode, so all characters
> exist and the locale rules specify their behavior there. The encoding
> is just the byte stream it needs to force them all into afte
Dave Page <[EMAIL PROTECTED]> writes:
> select pg_tablespace_size('pg_global');
> ERROR: permission denied for tablespace pg_global
> Can this be fixed please?
What's to be fixed? That's exactly the result I'd expect given the
previously-agreed-to behavior for pg_tablespace_size.
On Fri, 2007-10-12 at 10:19 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I think the best way to handle this is to have two limits.
> > First limit attempts to autovacuum, but can be cancelled.
> > When we hit second limit, sometime later, then autovacuum cannot be
> > cance
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Am Freitag, 12. Oktober 2007 schrieb Martijn van Oosterhout:
>> Where we're stuck is that we can't agree on a
>> source of locale data. People don't want the ICU or glibc data and
>> there's no other source as readily available.
>
> What were the ob
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
> It would make Postgres inconsistent and less integrated with the rest of
> the OS. How do you explain that Postgres doesn't follow the system's
> configurations and the collations don't agree with the system collations?
We already have our own
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Fri, Oct 12, 2007 at 03:28:26PM +0100, Gregory Stark wrote:
>> I think realistically we're basically waiting for strcoll_l to become
>> standardized by POSIX so we can depend on it.
> I think we could be waiting forever then.
strcoll is only
On Fri, 2007-10-12 at 12:42 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-10-12 at 11:26 -0400, Tom Lane wrote:
> >> Why not SIGINT?
>
> > I must be missing something. How would I tell the difference between
> > manual and automatic cancels if we use SIGINT for
Hi, I'm calling an arbitrary user-defined function from the backend.
Although I can do it via FunctionCallInvoke, I have a weird problem when
calling fmgr_info. The call results in a argument variable (eventType)
being cleared. A gdb hardware watch says that the variable is modified by
fmgr_inf
Luis Vargas <[EMAIL PROTECTED]> writes:
> Hi, I'm calling an arbitrary user-defined function from the backend.
> Although I can do it via FunctionCallInvoke, I have a weird problem when
> calling fmgr_info. The call results in a argument variable (eventType)
> being cleared. A gdb hardware watch
As Martin Pitt pointed out in this pgsql-bugs thread
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00089.php
we have managed to create an ABI break between 8.2 and 8.3 libpq
by renumbering encoding IDs in pg_wchar.h. Although perhaps this
does not hurt any third-party clients, it does break
Tom Lane wrote:
I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
influenced by my Red Hat packaging responsibilities --- I'll personally
have to spend time on a compatibility package if we go with #1.
Other opinions out there?
Also, if we do #2 it means that we have the opti
On Friday 12 October 2007 15:41:58 Tom Lane wrote:
> As Martin Pitt pointed out in this pgsql-bugs thread
> http://archives.postgresql.org/pgsql-bugs/2007-10/msg00089.php
> we have managed to create an ABI break between 8.2 and 8.3 libpq
> by renumbering encoding IDs in pg_wchar.h. Although perhap
On Oct 12, 2007, at 17:41 , Tom Lane wrote:
Also, if we do #2 it means that we have the option to resolve the
contrib/txid mess by pushing txid into the core backend before beta2.
Any votes pro or con on that?
+1
Michael Glaesemann
grzm seespotcode net
---(end of b
Hi,
On Fri, 2007-10-12 at 18:41 -0400, Tom Lane wrote:
>
> I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
> influenced by my Red Hat packaging responsibilities --- I'll
> personally
> have to spend time on a compatibility package if we go with #1.
> Other opinions out there?
On Wed, Sep 05, 2007 at 03:07:03PM -0500, Kenneth Marshall wrote:
> On Sun, Sep 02, 2007 at 01:04:04PM -0500, Kenneth Marshall wrote:
> > Dear PostgreSQL Hackers:
> >
> > After following the hackers mailing list for quite a while,
> > I am going to start investigating what will need to be done
> >
Hi Simon/Hannu,
a) I accept with storing ctid in place of oid. That would definitely improve
the performance. I guess it would also remove the restriction of the size on
TOASTABLE ATTRIBUTES. I guess different chunks have to be linked together,
without the index.
b) But i don't understand how sto
On 10/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> > Will $SUBJECT make it possible for count(*) to use index? This is a much
> > wanted feature.
>
> If you mean "count(*) will become instantaneous", no it won't. It would
> get faster, but proba
On Sat, 2007-10-13 at 11:12 +0530, Gokulakannan Somasundaram wrote:
> b) But i don't understand how storing the visibility info in TOAST
> table would help you. In that case you may need to update it for every
> delete/ update happening in the main table. Only thing, it would help
> is if someone
72 matches
Mail list logo
