Teodor Sigaev wrote:
5 of 120 tests failed.
This is on a Fedora-9 x86 box, and:
-bash-3.2$ rpm -qv glibc
glibc-2.8-8.i686
Interesting. On my notebook all is ok.
% uname -a
FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2
Is any possibility
On Monday 19 January 2009 22:39:30 Zdenek Kotala wrote:
> Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200:
> > The remaining 80 failures are more-or-less linguistic issues that belong
> > to the following 26 language/country combinations:
> >
> >
> > cs_CZ sorts ch separately; sorts st
On Mon, 2009-01-19 at 21:41 +0300, Teodor Sigaev wrote:
> > gin_numeric_cmp() can be called from regular SQL. I missed this before,
> > but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in
> > v0.7 at least).
>
> Fixed, gin_numeric_cmp is marked as strict.
>
> > And how does G
On Monday 19 January 2009 23:22:21 Todd A. Cook wrote:
> The docs at
> http://developer.postgresql.org/pgdocs/postgres/functions-aggregate.html
> don't prohibit using array values with array_arg(), so I assumed that it
> would work.
> test=> select array_agg(v.a) from (values (array[1,2]), (array[
> Here is what I hope is a consensus patch. It adds 'A' to show all
> objects, including system ones. It turns out that this is how 'S' works
> now in CVS, but 'S' is unclear because it suggests just system objects;
> 'A' for show 'all' objects seems clearer.
I think it's probably fine for "S" t
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Do you want to send an updated patch for it, or do you want me to look
at it?
I would send a new patch to which I added a simple ISO style check for
locale names.
Attached is a new patch.
I added a simpl
Bruce Momjian wrote:
> I know we don't like the current behavior, but I think we need to make
> them consistent first for easy testing and so when we change it, it will
> remain consistent.
>
> I will work on a consensus patch soon for the new behavior.
Here is what I hope is a consensus patch.
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
[COMMITTERS] pgsql: Use the new text domain names
A
Gregory Stark wrote:
> The behaviour of \dt in the face of tables which shadow system tables is
> actually even stranger:
>
> postgres=# create table pg_proc (t text);
> CREATE TABLE
> postgres=# commit;
> COMMIT
> postgres=# \dt pg_proc
> No matching relations found.
>
>
Tom Lane wrote:
> Peter Eisentraut writes:
> > On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote:
> >> Added to TODO:
> >> Have statement-level triggers fire for all tables in an
> >> inheritance hierarchy
>
> > I don't think that was really the conclusion from the thread.
>
> > As far as
On Sat, Sep 27, 2008 at 4:25 AM, Brendan Jurd wrote:
> One way to tidy this up would be to re-implement the meridiem markers
> using the seq_search functions, i.e., make it work like the day and
> month names. This would make it easy to accept any flavour of marker,
> and the error messages throw
Hi,
The docs at
http://developer.postgresql.org/pgdocs/postgres/functions-aggregate.html
don't prohibit using array values with array_arg(), so I assumed that it would
work.
However, with CVS HEAD from Friday afternoon, I get
test=> select version() ;
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
wrote:
Here is my updated patch based on yours.
Outstanding issues, as far as I can see, are:
Critical:
* Updatability check must reject views where the select list references
the same column more than once.
checkTree() will r
Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200:
> The remaining 80 failures are more-or-less linguistic issues that belong to
> the following 26 language/country combinations:
>
> cs_CZ sorts ch separately; sorts st = s
s < st
Zdenek
--
Sent via pgsql-hackers mailing list (
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
>
> Guillaume Smet wrote:
> > On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane wrote:
> >
> >> However, the
> >> de facto policy is that we try to keep them passing in locales that
> >> are used by any of the regular developers. I think it would b
Andrew Chernow wrote:
> Bruce Momjian wrote:
> >
> > We could have gone with a more elegant init/uninit solution but there is
> > a history of slow upstream adoption of libpq API changes.
> >
> >
>
> If that's the case, adding a connectdb option seems like a good
> alternative. Orignally sugg
Bruce Momjian wrote:
We could have gone with a more elegant init/uninit solution but there is
a history of slow upstream adoption of libpq API changes.
If that's the case, adding a connectdb option seems like a good
alternative. Orignally suggested here:
http://archives.postgresql.org/pg
James Mansion wrote:
> Magnus Hagander wrote:
> > The use-case of rapidly creating and dropping connections isn't
> > particularly common, I think. And there is a perfectly functioning
> > workaround - something that we should perhaps document in the FAQ or
> > somewhere in the documentation?
> >
>
On Mon, 2009-01-19 at 21:41 +0300, Teodor Sigaev wrote:
> > And how does GIN handle SQL NULL values in the column? Does it index
> > them at all, or just ignore them?
> SQL NULL: GIN doesn't support it (amindexnulls/amsearchnulls == false)
> C NULL: NULL-numeric could be returned only by gin_extrac
5 of 120 tests failed.
This is on a Fedora-9 x86 box, and:
-bash-3.2$ rpm -qv glibc
glibc-2.8-8.i686
Interesting. On my notebook all is ok.
% uname -a
FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2
Is any possibility of broken locale?
--
gin_numeric_cmp() can be called from regular SQL. I missed this before,
but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in
v0.7 at least).
Fixed, gin_numeric_cmp is marked as strict.
And how does GIN handle SQL NULL values in the column? Does it index
them at all, or just
On Mon, 2009-01-19 at 20:45 +0300, Teodor Sigaev wrote:
> How to reproduce that?
-bash-3.2$ psql -l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access
Privileges
+--+--+--
I suggest you take StdRdOptions out of the GinOptions struct, and leave
fillfactor out of ginoptions. I don't think there's much point in
supporting options that don't actually do anything. If the user tries
to set fillfactor for a gin index, he will get an error. Which is a
good thing IMHO.
On Mon, 2009-01-19 at 20:15 +0300, Teodor Sigaev wrote:
> Changes:
> - use NULL as left-most value. It's safe because NULL numeric value
>cannot be an argument for any function except gin_numeric_cmp and it
>cannot be returned in regular SQL query.
gin_numeric_cmp() can be called from regu
Alvaro Herrera writes:
> Teodor Sigaev wrote:
>> I didn't change a recognition of fillfactor value, although GIN doesn't
>> use it for now.
> I suggest you take StdRdOptions out of the GinOptions struct, and leave
> fillfactor out of ginoptions. I don't think there's much point in
> supporting
I think the test show that there is a bug in the tsearch support for
Turkish. Here is the test diff:
How to reproduce that?
% psql -l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access privileges
++--
Teodor Sigaev wrote:
>> I notice you added a fillfactor reloption in ginoptions, but does it
>> really make sense? I recall removing it because the original code
>> contained a comment that says "this is here because default_reloptions
>> wants it, but it has no effect".
>
> I didn't change a reco
Alvaro Herrera writes:
> Magnus Hagander escribió:
>> For a change like
>> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480&r2=1.481
>>
>> Will it work to stick _(hintmsg) around it there?
> Assuming that there is a gettext_noop() call in the literal that's
>
I notice you added a fillfactor reloption in ginoptions, but does it
really make sense? I recall removing it because the original code
contained a comment that says "this is here because default_reloptions
wants it, but it has no effect".
I didn't change a recognition of fillfactor value, altho
I'm pretty certain I recall Greg Stark recommending that we adopt
something like that as the standard numeric representation of zero.
It didn't get done yet, but it might happen someday.
Changes:
- use NULL as left-most value. It's safe because NULL numeric value
cannot be an argument for any
Teodor Sigaev wrote:
> New version. Changes:
> - synced with current CVS
I notice you added a fillfactor reloption in ginoptions, but does it
really make sense? I recall removing it because the original code
contained a comment that says "this is here because default_reloptions
wants it, but it
On Mon, 2009-01-19 at 11:35 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > I like the fact that this patch does not modify the numeric ADT. It
> > still relies on the fact that the numeric type will never make use of
> > the minimal varlena struct, however. I bring this up in case someone
> > see
On Tue, Jan 20, 2009 at 2:44 AM, Rubén F. wrote:
> I have a doubt. I am designing a program for manage CV's. This program
> connect with a PostgresDB. This program will be used for 5,000 persons
> becaus it will be used in a University. Then, ¿how many actives connection
> could be postgres? ¿does
Changes:
Results of pernding list's scan now are placed directly in resulting
tidbitmap. This saves cycles for filtering results and reduce memory usage.
Also, it allows to not check losiness of tbm.
Is this a 100% bulletproof solution, or is it still possible for a query
to fail due to the
Magnus Hagander escribió:
> For a change like
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480&r2=1.481
>
> Will it work to stick _(hintmsg) around it there?
Assuming that there is a gettext_noop() call in the literal that's
assigned to hintmsg, yes, it shou
Jeff Davis writes:
> I like the fact that this patch does not modify the numeric ADT. It
> still relies on the fact that the numeric type will never make use of
> the minimal varlena struct, however. I bring this up in case someone
> sees it as a problem.
I'm pretty certain I recall Greg Stark re
Magnus Hagander wrote:
Andrew Chernow wrote:
James Mansion wrote:
Is there a need for a new API to control this - can't you just
interpret another parameter keyword
in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)?
That's an interesting idea. I don't know if its the correct
still relies on the fact that the numeric type will never make use of
the minimal varlena struct, however. I bring this up in case someone
sees it as a problem.
Greg Stark was working on a patch to make certain values use the short
representation.
Fake value contains only VARHDRSZ bytes.
--
T
Andrew Chernow wrote:
> James Mansion wrote:
>> Is there a need for a new API to control this - can't you just
>> interpret another parameter keyword
>> in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)?
>
> That's an interesting idea. I don't know if its the correct place to
> c
Hi!
First of all, excuse my english...
I have a doubt. I am designing a program for manage CV's. This program
connect with a PostgresDB. This program will be used for 5,000 persons
becaus it will be used in a University. Then, ¿how many actives connection
could be postgres? ¿does it support a ver
On Mon, 2009-01-19 at 16:50 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I prefer the last one, but if you think otherwise, please shout.
>
> We're now emitting WAL records for relcache invalidations, IIRC. I
> wonder if those are useful for this?
Tom already objected to putting st
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> I've extracted this patch from Hiroshi Inoues patch about bug #4186. Per
>> his comment, "It also includes the changes to mbutils.c and elog.c which
>> fix recently introduced bug by the domain name change from "postgres" to
>> "postgres-8.4"."
>>
Magnus Hagander wrote:
I've extracted this patch from Hiroshi Inoues patch about bug #4186. Per
his comment, "It also includes the changes to mbutils.c and elog.c which
fix recently introduced bug by the domain name change from "postgres" to
"postgres-8.4"."
Can somebody who actually knows how
Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
>> Bruce Momjian wrote:
>>> Hiroshi, is this patch still needed?
>>
>> Yes though it should be slightly changed now.
In what way should it be changed?
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Devrim GÜNDÜZ wrote:
Yep, I ran them already, and as you wrote, I'm getting 3 errors (tsearch
tests + foreign_data test).
And then use your language skills to determine what the correct
behavior is. ;-)
SKIES would be skıes (dotless i).
Here is the conversion table:
I (capital) <-> ı
İ
I've extracted this patch from Hiroshi Inoues patch about bug #4186. Per
his comment, "It also includes the changes to mbutils.c and elog.c which
fix recently introduced bug by the domain name change from "postgres" to
"postgres-8.4"."
Can somebody who actually knows how that works comment on it,
Simon Riggs wrote:
I prefer the last one, but if you think otherwise, please shout.
We're now emitting WAL records for relcache invalidations, IIRC. I
wonder if those are useful for this?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing
Jeff Davis escribió:
> I like the fact that this patch does not modify the numeric ADT. It
> still relies on the fact that the numeric type will never make use of
> the minimal varlena struct, however. I bring this up in case someone
> sees it as a problem.
Greg Stark was working on a patch to ma
Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
>> Magnus Hagander wrote:
>>>
>>> Do you want to send an updated patch for it, or do you want me to look
>>> at it?
>>
>> I would send a new patch to which I added a simple ISO style check for
>> locale names.
>
> Attached is a new patch.
> I added a si
On Mon, 2009-01-19 at 12:54 +, Simon Riggs wrote:
> Some refactoring in this area is also required
> because we need to handle two other types of conflict to correctly
> support drop database and drop user, which is now underway.
I've hung the drop database conflict code in dbase_redo().
For
On Mon, 2009-01-19 at 15:47 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I suggest we handle this on the recovery side, not on the master, by
> > deriving the xmin at the point the WAL record arrives. We would
> > calculate it by looking at recovery procs only. That will likely give u
Simon Riggs wrote:
I suggest we handle this on the recovery side, not on the master, by
deriving the xmin at the point the WAL record arrives. We would
calculate it by looking at recovery procs only. That will likely give us
a later value than we would get from the master, but that can't be
helpe
James Mansion wrote:
Is there a need for a new API to control this - can't you just interpret
another parameter keyword
in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)?
That's an interesting idea. I don't know if its the correct place to control
this, but it does allow turn
On Mon, 2009-01-19 at 14:00 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > GetSnapshotData() sets
> > RecentGlobalXmin to the result of the snapshot's xmin.
>
> No. RecentGlobalXmin is set to the oldest *xmin* observed, across all
> running transactions. TransactionXmin is the xid of
Tom Lane wrote:
> Magnus, you wanna clean up the mess? And what patch does the "few more"
> comment refer back to?
>
> A workable solution that both silences the warning and preserves
> localizability is to follow a coding pattern like this:
>
> const char *mymsg = gettext_noop("Some text
Simon Riggs wrote:
GetSnapshotData() sets
RecentGlobalXmin to the result of the snapshot's xmin.
No. RecentGlobalXmin is set to the oldest *xmin* observed, across all
running transactions. TransactionXmin is the xid of the oldest running
transaction. IOW, RecentGlobalXmin is the xid of transa
On Mon, 2009-01-19 at 12:50 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > One of us needs a coffee.
>
> Clearly, I put the kettle on...
I had one too, just in case.
> > How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at
> > step (9) the value of RecentGlobalXmin
Simon Riggs wrote:
One of us needs a coffee.
Clearly, I put the kettle on...
How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at
step (9) the value of RecentGlobalXmin has gone backwards?
Looks like I mixed up the xids of the two transactions in steps 8 and 9.
Let's see
On Mon, 2009-01-19 at 12:22 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Well, steps 7 and 8 don't make sense.
> >
> > Your earlier comment was that it was possible for a WAL record to be
> > written with a RecentGlobalXmin that was lower than other backends
> > values. In step 9 the
Simon Riggs wrote:
Well, steps 7 and 8 don't make sense.
Your earlier comment was that it was possible for a WAL record to be
written with a RecentGlobalXmin that was lower than other backends
values. In step 9 the RecentGlobalXmin is *not* lower than any other
backend, it is the same.
So if t
On Fri, 2009-01-16 at 19:12 +0100, Gianni Ciolli wrote:
> On Fri, Jan 16, 2009 at 06:39:11PM +0100, Gianni Ciolli wrote:
> (...)
> > During a Warm Standby session using current HEAD I obtained the
> > following error on the standby node:
I think I understand the cause of these bugs in CVS HEAD no
On Mon, 2009-01-19 at 09:16 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-01-16 at 22:09 +0200, Heikki Linnakangas wrote:
> >
> RecentGlobalXmin is just a hint, it lags behind the real oldest xmin
> that GetOldestXmin() would return. If another backend has a m
Bernd Helmle wrote:
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
wrote:
* It is not clear how automatic rules and manual DO ALSO rules should
interact. A manual DO ALSO rule will currently clear out an automatic
INSTEAD rule, which I find to be illogical.
My intentional fe
James Mansion wrote:
> Andrew Chernow wrote:
>> m$ docs indicate that wsastartup can't be called from dllmain :(
>>
> OK, fair cop. Says it in the MSDN online version but not in the SDK 6.1
> version. :-( Some helper(s)
> must start threads I guess.
That, and it loads other DLLs as well.
> Re
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
wrote:
* It is not clear how automatic rules and manual DO ALSO rules should
interact. A manual DO ALSO rule will currently clear out an automatic
INSTEAD rule, which I find to be illogical.
My intentional feeling was that it wou
65 matches
Mail list logo
