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
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
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
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
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
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.
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
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:
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
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:
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 |
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
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.
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
>>> "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
>>> 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
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
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
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:
>
>
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
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
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
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
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
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
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 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.
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
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
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
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 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
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
"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
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
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
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:
> 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
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
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 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
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
"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 <[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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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.
> > * 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
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
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
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
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
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
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
71 matches
Mail list logo
