--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net 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
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 the
Bernd Helmle wrote:
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net 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.
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 more recent
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:
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
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 has
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 now.
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
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
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 to be
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 the
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
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
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 us
a
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
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 simple ISO style
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 make
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
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,
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) - ı
İ
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 your
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 that
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.
Can somebody
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 strange
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
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
control
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.
--
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
Jeff Davis pg...@j-davis.com 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
Magnus Hagander escribió:
For a change like
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480r2=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 should
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
On Tue, Jan 20, 2009 at 2:44 AM, Rubén F. rfs1...@gmail.com 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
On Mon, 2009-01-19 at 11:35 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com 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
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
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
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,
Alvaro Herrera alvhe...@commandprompt.com writes:
Magnus Hagander escribió:
For a change like
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480r2=1.481
Will it work to stick _(hintmsg) around it there?
Assuming that there is a gettext_noop() call in the
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 recognition of
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
Alvaro Herrera alvhe...@commandprompt.com 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
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 regular
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:45 +0300, Teodor Sigaev wrote:
How to reproduce that?
-bash-3.2$ psql -l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access
Privileges
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
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?
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
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?
Would it
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:
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 suggested here:
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 t...@sss.pgh.pa.us 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
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
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net 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.
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 Sat, Sep 27, 2008 at 4:25 AM, Brendan Jurd dire...@gmail.com 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
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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 I
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.
And I
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
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. It
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
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 to
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]),
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 GIN handle
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 = s
s
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
65 matches
Mail list logo
