Alvaro Herrera wrote:
I think getting rid of the FAQ completely is not necessarily a good
idea; it seems useful as a collection of interesting questions. Moving
the contents to new pages is probably OK. Also, as the answers mature
on the Wiki, perhaps it'd be possible to move them to the SGML
On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
The importance of the WAL will only increase as more people start to
use it for PITR, replication etc.
Agreed.
The 2nd use case, however, I find pretty unconvincing. I can't think of
a good example of that. Anything that needs
On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:
The main idea was to invert the meaning of the xid array in the snapshot
struct - instead of storing all the xid's between xmin and xmax that are
to be considering in-progress, the array contained all the xid's
xmin that are to be
Disabling autovacuum can have catastrophic effects, since it disables
the ANALYZing of tables.
Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
ANALYZE times are fairly bounded because of the way we do sampling.
VACUUM times are not bounded at all, and typically O(n). So
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
The 2nd use case, however, I find pretty unconvincing. I can't think of
a good example of that. Anything that needs to define its own resource
manager is very low-level stuff, and probably
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
The standard specifies that non-recursive WITH should be evaluated
Hi,
On Fri, Sep 12, 2008 at 12:41 AM, Tom Lane [EMAIL PROTECTED] wrote:
Markus Wanner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Sooner or later we shall have to bite the bullet and set up a
multiplexing system to transmit multiple event types to backends with
just one signal. We already did
Tom Lane [EMAIL PROTECTED] writes:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes:
I'm getting these on Fedora-9:
tqual.c:115: warning: inlining failed in call to ‘SetHintBits’: call is
They're just cosmetic. We don't generally worry about fixing cosmetic
warnings in back
On Mon, 2008-09-15 at 10:47 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
The 2nd use case, however, I find pretty unconvincing. I can't think of
a good example of that. Anything that needs to define its
Hi,
I just released new RPM sets, which is based on Sep 15 10:00 AM EEST CVS
snapshot.
These packages *do* require a dump/reload, even from previous 8.4
packages, because of a catversion update.
Over the last week, we have 70 more testers (now 220!) .
As usual, please find detailed info from:
Tom Lane wrote:
But I think Alvaro is worried about something
at a higher level: the regression test process as a whole has some
directory layout assumptions built into it, particularly in regards
to where to find .so's.
The only information about the location of the .so's is in the test
On Thu, 2008-09-11 at 15:25 -0400, Andrew Dunstan wrote:
Great, thanks (and also to Guillaume).
It looks to me like the simple way around this issue would be to provide
an option to have pg_restore emit:
begin; truncate foo; copy foo ... commit;
The truncate will be trivial as
On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:
The current read-only snapshot (which current meaning the
corresponding state on the master at the time the last replayed wal
record was generated) was maintained in shared memory. It' xmin field
was continually updated with the
Markus Wanner wrote:
Dmitry Koterov wrote:
But, what about intarray patch? Does somebody plan to review it? I'd
prefer to include it too. If you approve, I'll correct the code style
in intarray contrib patch too.
I've already volunteered for reviewing it as well. I just felt like
splitting
Simon Riggs wrote:
On Thu, 2008-09-11 at 15:25 -0400, Andrew Dunstan wrote:
Great, thanks (and also to Guillaume).
It looks to me like the simple way around this issue would be to provide
an option to have pg_restore emit:
begin; truncate foo; copy foo ... commit;
The truncate
Simon Riggs [EMAIL PROTECTED] writes:
So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to the master, not the
other way around so that WAL records for tuple removal are not
generated.
I think most people were pretty
Hi,
sorry for not having completed this review, yet. As you are obviously
looking at the patch as well, I'll try to quickly write down my points
so far.
Trying to compile the intarray module, I now receive an error:
error: ‘INT4OID’ undeclared (first use in this function)
That can be
On Mon, 2008-09-15 at 13:13 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to the master, not the
other way around so that WAL records for tuple
On Fri, Sep 12, 2008 at 7:41 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-09-11 at 18:17 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
I think that this case would often happen. So, we should establish a
certain
solution or procedure to the case where TLI of the master
Gregory Stark [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
Indexes have always been able to be added dynamically. Now they can be
recovered correctly as well.
Hm, so currently if you want to add a new indexam you can't just insert into
pg_am and make them recoverable. You
D'Arcy J.M. Cain wrote:
On Fri, 12 Sep 2008 06:53:55 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
Josh has assigned your patch to me for an initial review.
And me.
Thanks for the reviews, guys. I've adjusted the patch per your comments
(I think), and applied it.
//Magnus
--
Sent via
On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
I think that this case would often happen. So, we should establish a
certain
solution or procedure to the case where TLI of the master doesn't match
TLI of the slave. If we only allow the case
On Mon, Sep 15, 2008 at 8:40 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-09-15 at 13:13 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to
Simon Riggs escribió:
On Fri, 2008-09-12 at 17:08 +0300, Heikki Linnakangas wrote:
It should be clear that to make this work you must run with a base
backup that was derived correctly on the current master. You can do that
by re-copying everything, or you can do that by just shipping
On Mon, Sep 15, 2008 at 10:53 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Thanks for the reviews, guys. I've adjusted the patch per your comments
(I think), and applied it.
Cool. I had a look at the commitdiff and I think you missed one of
the error messages (it's still all on one line).
Alvaro Herrera wrote:
Simon Riggs escribió:
On Fri, 2008-09-12 at 17:08 +0300, Heikki Linnakangas wrote:
It should be clear that to make this work you must run with a base
backup that was derived correctly on the current master. You can do that
by re-copying everything, or you can do that by
Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to the master, not the
other way around so that WAL records for tuple removal are not
generated.
I think most
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
Indexes have always been able to be added dynamically. Now they can be
recovered correctly as well.
Hm, so currently if you want to add a new indexam you can't just insert into
Brendan Jurd [EMAIL PROTECTED] writes:
Cool. I had a look at the commitdiff and I think you missed one of
the error messages (it's still all on one line). It's at
src/backend/libpq/hba.c line 841. I've included a patch to split it
up below.
Hm, that doesn't seem like a great improvement
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Cool. I had a look at the commitdiff and I think you missed one of
the error messages (it's still all on one line). It's at
src/backend/libpq/hba.c line 841. I've included a patch to split it
up below.
Hm, that doesn't seem like a
On Mon, 2008-09-15 at 16:26 +0300, Heikki Linnakangas wrote:
In any case, we'll need the capability in the slave to notice when
it's about to remove a tuple that's still visible to a snapshot in the
slave.
Agreed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services
On Mon, 2008-09-15 at 08:52 -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
Indexes have always been able to be added dynamically. Now they can be
recovered correctly as well.
Hm, so currently if you want to add a new indexam you
On Mon, 2008-09-15 at 09:07 -0400, Merlin Moncure wrote:
Well, my impression from all inputs is there is no single preferred
route. Any one of the approaches seems to have a possible objection,
depending upon the needs of the user. So I'm going to give options.
In any case it's not just
Simon Riggs [EMAIL PROTECTED] writes:
The version mismatch idea presumes that a code author would structure
their code in two pieces: one to generate the WAL and one to read it.
Seems much more likely to me that authors would have one module
containing both as a way of avoiding the problem
Simon Riggs wrote:
On Mon, 2008-09-15 at 08:52 -0400, Tom Lane wrote:
I've never heard of anyone building a non-core index AM at all; much
less trying to use it in a production context. Given the obvious
potential for version-mismatch-type problems, it's hard to believe
that anyone ever would
Simon Riggs [EMAIL PROTECTED] writes:
We have plugin APIs with possible version mismatches in other contexts,
but I don't see us doing anything about that. In the context of WAL, the
basic WAL format has not changed in about 6 releases, so its been one of
the most stable file formats.
Er,
On Mon, Sep 15, 2008 at 11:46 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Hm, that doesn't seem like a great improvement --- in particular, it
violates the style guideline that detail messages should be complete
sentences.
I think the error text is all right as-is, really.
Brendan Jurd [EMAIL PROTECTED] writes:
Or perhaps the DETAIL portion would be more appropriate as a CONTEXT?
+1
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Fujii Masao wrote:
On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Hmm. There's more problems than the TLI with that. For the original master
to catch up by replaying WAL from the new slave, without restoring from a
full backup, the original master must not write
A few days ago I complained that the lossy-hash-indexes patch needed a
better solution for letting catalog/index.c know that hash indexes will
really store only hashcodes and not the underlying column type. The
current version of the patch puts some hard-wired knowledge into
index.c:
/*
On Mon, 2008-09-15 at 16:26 +0300, Heikki Linnakangas wrote:
In any case,
we'll need the capability in the slave to notice when it's about to
remove a tuple that's still visible to a snapshot in the slave.
Looks like what I'll do is this:
Alter functions in pruneheap.c so that we bubble up
Simon Riggs [EMAIL PROTECTED] writes:
Bottom line is that any backup of Postgres needs to include plugin
directories, otherwise parts of the application could stop working
following restore. This patch doesn't change that.
No, backups of executables are normally not the same backups as the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually this is wrong -- since the library is going to run with
postgres text domain, we need to add the files to the backend's
nls.mk:
Can't we give it its own text domain? It seems fundamentally wrong
for a plug-in language to
On Mon, 2008-09-15 at 16:43 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Bottom line is that any backup of Postgres needs to include plugin
directories, otherwise parts of the application could stop working
following restore. This patch doesn't change that.
No,
On Friday 12 September 2008 07:44:36 Csaba Nagy wrote:
And then
the actually interesting question: what will the slave do with views,
rules, triggers ? I guess triggers are out of the question to be
executed, what about rules ? Probably must be also ignored... user
functions will probably get
On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The version mismatch idea presumes that a code author would structure
their code in two pieces: one to generate the WAL and one to read it.
No, the version mismatch problem is that you might try to
I'm trying to optimize postgres performance on a headless solid state
hardware platform (no fans or disks). I have the database stored on a
USB 2.0 flash drive (hdparm benchmarks reads at 10 MB/s). Performance is
limited by the 533Mhz CPU.
Hardware:
IXP425 XScale (big endian) 533Mhz 64MB RAM
USB
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Or perhaps the DETAIL portion would be more appropriate as a CONTEXT?
+1
Is this the proper syntax for errcontext() messags?
//Magnus
Index: hba.c
===
RCS file:
Magnus Hagander [EMAIL PROTECTED] writes:
Or perhaps the DETAIL portion would be more appropriate as a CONTEXT?
+1
Is this the proper syntax for errcontext() messags?
Hmm, I think I'd suggest following the wording already in use in
ts_locale.c:
errcontext(line %d of
Simon Riggs wrote:
On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:
The main idea was to invert the meaning of the xid array in the snapshot
struct - instead of storing all the xid's between xmin and xmax that are
to be considering in-progress, the array contained all the xid's
xmin
Simon Riggs wrote:
On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:
The current read-only snapshot (which current meaning the
corresponding state on the master at the time the last replayed wal
record was generated) was maintained in shared memory. It' xmin field
was continually
On Mon, 2008-09-15 at 19:20 +0100, Florian G. Pflug wrote:
Simon Riggs wrote:
On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:
The main idea was to invert the meaning of the xid array in the snapshot
struct - instead of storing all the xid's between xmin and xmax that are
to
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Or perhaps the DETAIL portion would be more appropriate as a CONTEXT?
+1
Is this the proper syntax for errcontext() messags?
Hmm, I think I'd suggest following the wording already in use in
ts_locale.c:
Unless I'm compiling stuff wrong, it seems HEAD is giving me
slightly different output on Intervals than 8.3 in the roundoff
of seconds. 8.3 was rounding to the nearest fraction of a second,
HEAD seems to be truncating.
In the psql output below it shows 8.3.1 outputting 6.70 secs
while the
Ron Mayer [EMAIL PROTECTED] writes:
Unless I'm compiling stuff wrong, it seems HEAD is giving me
slightly different output on Intervals than 8.3 in the roundoff
of seconds. 8.3 was rounding to the nearest fraction of a second,
HEAD seems to be truncating.
Yeah, that's surely because of the
On Mon, Sep 15, 2008 at 4:58 PM, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Unless I'm compiling stuff wrong, it seems HEAD is giving me
slightly different output on Intervals than 8.3 in the roundoff
of seconds. 8.3 was rounding to
Kevin Grittner [EMAIL PROTECTED] wrote:
I find the results on 8.3.3 with integer timestamps surprising:
Even more surprising is the behavior for interval(1) here:
ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval;
interval
-
Kevin Grittner wrote:
...not the only place where the float-timestamps code has
rounding behavior that doesn't appear in the integer-timestamps
code. ...
I find the results on 8.3.3 with integer timestamps surprising:
Agreed it's surprising and agreed there are more places.
Sounds like I
Ron Mayer [EMAIL PROTECTED] writes:
Sounds like I should keep that separate and perhaps later
submit a separate patch to identify and/or remove surprising
rounding behavior.
Agreed. It's easier to review and get consensus on patches if you
keep separate issues separate.
Unless I'm compiling stuff wrong, it seems HEAD is giving me
slightly different output on Intervals than 8.3 in the roundoff
of seconds. 8.3 was rounding to the nearest fraction of a second,
HEAD seems to be truncating.
In the psql output below it shows 8.3.1 outputting 6.70 secs
while the
Tom Lane wrote:
This is not the only place where the float-timestamps code has rounding
behavior that doesn't appear in the integer-timestamps code.
Yeah... For that matter, I find this surprising as well:
regression=# select '0.7 secs'::interval, ('7 secs'::interval/10);
interval |
We have recently seen one definite and one probable report of overflow
of the nLocks field of a backend's local lock table:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00021.php
While it's still unclear exactly why 8.3 seems more prone to this than
earlier releases, the general shape of
Tom Lane wrote:
support for SQL-spec interval literals. I decided to go look at exactly
how unfinished it was, and it turns out that it's actually pretty close.
Hence the attached proposed patch ;-)
Is this code handling negative interval literals right?
I think I quote the relevant spec part
Ron Mayer [EMAIL PROTECTED] writes:
Is this code handling negative interval literals right?
I think I quote the relevant spec part at the bottom.
We support independent signs for the different components of the
interval. I'm not sure how well the spec copes with that.
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Is this code handling negative interval literals right?
I think I quote the relevant spec part at the bottom.
We support independent signs for the different components of the
Even so it surprises me that:
'-1-1'::interval gives me a
Peter, Abhijit,
Could you tell me the current status of reviewing process in the CommitFest:Sep?
I can understand the patches contain several new concept and a bit large,
and it is a tough work to review them comprehensively.
I'm not unconcern anything even if reviwing comments are partial one.
Here is a revised patch to renewal NDirectFileRead/Write.
Tom Lane [EMAIL PROTECTED] wrote:
* Let's rename them BufFileReadCount and BufFileWriteCount to reflect
their actual purpose.
* In any case I agree that the current arrangement
with execdebug.h declaring variables defined in
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Can't we give it its own text domain? It seems fundamentally wrong
for a plug-in language to require core support for its messages.
Another idea would be to redefine errmsg() and friends within the
plpgsql sources, but that seems
Attached is an updated and separate version of my patch exposing the
internal GUC boot_val as default_val, which failed to attach itself to the
already committed changes to the pg_settings view.
Brief reminder of what it does:
postgres=# select name,setting,default_val from pg_settings where
69 matches
Mail list logo
