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 nearing xid wrap-around, right? It even does so when
autovacuum is disabled in the
Hi All,
So i think we are clear now, that it is possible to have an index
with snapshot info. Let me try to enumerate the uses of having the Index
with snapshot info, in comparison to the Dead Space Map.
a) Dead Space, if it is successfull in its implementation of what it claims,
will
Hi All,
Last mail was sent by mistake without completion. I apologize for
that. i am continuing on that.
So i think we are clear now, that it is possible to have an index with
snapshot info. Let me try to enumerate the uses of having the Index with
snapshot info, in comparison to the
Hi All,
Last two mails were sent by mistake without completion. I couldn't
curse my system any further
I apologize for that.
If we comeback to the topic of discussion
So i think we are clear now, that it is possible to have an index with
snapshot info. Let me try to
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 nearing xid wrap-around, right? It even
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.
No, that was not the intent. The indent was to say we got a lot done in
one
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
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.
No, that
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 are
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
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 - because a
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
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 case we
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
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_global
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 there ever
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():
/*
* Only
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 workers
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 you expect the
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 implementation
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 tell the
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 with the
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, because a
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
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
collations?
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
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
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
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 the
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 code page is
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_size()
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
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 fix the
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.
What
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
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
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 you
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 inserted
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 number of
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
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 version of run_build.pl in
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
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 PROTECTED]
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
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 in
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
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 be
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, what I think
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
wanted
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
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
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 do
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
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.
Remember
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 after
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
cancelled.
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 objections to
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 a
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 both cases?
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
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 says
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
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
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 perhaps
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
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
to
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
76 matches
Mail list logo
