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 d
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 need
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 t
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 i
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 pr
> > * 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 WIT
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.
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
> warnin
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 t
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
files
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 a
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 t
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 will
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 prett
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 solved
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
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
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 recover
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
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
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 passe
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 s
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 ju
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 p
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 j
"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 improve
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
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, Service
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
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
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 probl
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 t
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 a
"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:
http://www.postgresql.org/m
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:
/* H
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
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 th
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-i
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.
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
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
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 2
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: /c
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
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 >
xm
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 upd
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 tha
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 s
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
>>> 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
>>> "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 sh
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 si
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 t
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 day-h
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 define
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 se
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
On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
> > > * Single Evaluation:
> > >
> > > with
> > > foo(i) as (select random() as i)
> > > select * from foo union all select * from foo;
> > >i
> > > ---
> > >0.233165248762816
> > > 0.621266
Any status updates on the following patches?
1. Fragments in tsearch2 headlines:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00043.php
2. Bug in hlCover:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00089.php
-Sushant.
--
Sent via pgsql-hackers mailing list (pgsql-hacke
71 matches
Mail list logo
