Is everything ok with postgres mail server? I have problem to send mail
to hackers list and pgadmin-hacker as well. If somebody is on cc, he
receives mail correctly, but it does not appear in the list. Any suggestion?
Zdenek
---(end of
On Tue, Aug 22, 2006 at 11:56:17AM -0700, Mark Dilger wrote:
I proposed something like this quite a bit up-thread. I was hoping we
could have a mode in which the system would run the second, third, fourth,
... best plans rather than just the best looking one, and then determine
from actual
On Thu, Aug 17, 2006 at 08:02:32PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
If there was a mechanism to obtain
field widths from the catalog there would be no need to store the
field width in each tuple. This would be
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Treat
Sent: 23 August 2006 04:16
To: pgsql-hackers@postgresql.org
Cc: Peter Eisentraut; Tom Lane
Subject: Re: pgsql-patches reply-to (was Re: [HACKERS]
[PATCHES] selecting large result
Is everything ok with postgres mail server? I have problem to send mail
to hackers list and pgadmin-hacker as well. If somebody is on cc, he
receives mail correctly, but it does not appear in the list. Any
suggestion? This problem first occurred when I sign into pgadmin-hacker
list.
Hi,
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to commit to doing it
On Fri, Aug 18, 2006 at 09:15:59AM +0900, Satoshi Nagayasu wrote:
ITAGAKI Takahiro wrote:
But the method has the above problem. So I suggest to use whether
the right link points to the next adjacent page or not.
if (opaque-btpo_next != P_NONE opaque-btpo_next != blkno + 1)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Zdenek Kotala
Sent: 23 August 2006 08:07
To: Josh Berkus; Bruce Momjian; pgsql-hackers@postgresql.org;
[EMAIL PROTECTED]
Subject: [HACKERS] Problem with mailing list?
Is everything ok with
On Tue, Aug 22, 2006 at 11:08:49AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
If there's a bunch of activity on a table but stats are reset before a
vacuum is run on it and then a vacuum is run, the user will still be
left thinking that the table needs to be vacuumed.
On Wed, Aug 23, 2006 at 01:45:43PM +0900, ITAGAKI Takahiro wrote:
Jim C. Nasby [EMAIL PROTECTED] wrote:
And +1 on Rod's suggestion to make it more aggressive. I always drop the
scale factor to at least 0.2 and 0.1 (though 0.1 and 0.05 don't seem
unreasonable), and typically drop the
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Zdenek Kotala
Sent: 23 August 2006 08:07
To: Josh Berkus; Bruce Momjian; pgsql-hackers@postgresql.org;
[EMAIL PROTECTED]
Subject: [HACKERS] Problem with mailing list?
Is everything
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 23 August 2006 08:56
To: Dave Page
Cc: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Problem with mailing list?
I had similar problem with pgsql-hackers list yesterday. I
Christopher Browne wrote:
Yeah, and you can't complain when you're cut off...
:-) yeah, known problem... I used gmane to track the list, but...
Regards
Markus
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Ühel kenal päeval, T, 2006-08-22 kell 16:48, kirjutas Tom Lane:
Joshua D. Drake [EMAIL PROTECTED] writes:
It's fairly clear that we could support concurrent builds of nonunique
indexes, but is that enough of a use-case to justify it?
I believe there would be. Most PostgreSQL users I run
--On Dienstag, August 22, 2006 23:12:21 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of
Ühel kenal päeval, K, 2006-08-23 kell 11:05, kirjutas Hannu Krosing:
Ühel kenal päeval, T, 2006-08-22 kell 16:48, kirjutas Tom Lane:
Joshua D. Drake [EMAIL PROTECTED] writes:
It's fairly clear that we could support concurrent builds of nonunique
indexes, but is that enough of a use-case
It may be a good idea to put a elog(LOG) with the error code in
the
failure path of AllocateFile.
That seems like a plan to me. I had been thinking of making
win32error.c itself log the conversions, but that would not
provide
any context information. AllocateFile could log the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Magnus Hagander
Sent: 23 August 2006 09:25
To: Andrew Dunstan; Tom Lane
Cc: Alvaro Herrera; Stefan Kaltenbrunner; PostgreSQL-development
Subject: Re: [HACKERS] seahorse again failing
I'm working on pg_upgrade concept. I try to determine what is changed
from 8.1 to 8.2. There is list of important areas for upgrade and
suggested action.
1) BKI - catalog.
There are a lot of changes. See attached file.
a) There is new table pg_shdescription
action: create
b)
Is it not possible to brute force this adding an AM method to insert
without the uniqueness check?
Hm. Actually there already is a feature of aminsert to allow
suppressing the unique check, but I'm not sure whether using
it for RECENTLY_DEAD tuples helps. Seems like we have to
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
snip
1) BKI - catalog.
c) Some records are changed
action: ???
They just need to be changed. In principle the datalog needs to be
updated so it looks like a database initdb'd with the new version.
5) Tuples
On Tue, Aug 22, 2006 at 01:11:22PM -0400, Andrew Dunstan wrote:
There's nothing hidden (unless it's also hidden from me ;-) )
I take it that when you talk about we did this you are referring to
the patch from Karel Zak.
Hans has been original author of COPY VIEW idea and I've wrote it for
Hi all,
seriously... I don't have time to work on PostgreSQL. It's time to
say that I'm leaving this project. So, if you found some my broken
code or whatever in PostgreSQL you should go and fix it. It's
community-driven project. It's about collaboration -- don't ask why
should I help --
Tom Lane [EMAIL PROTECTED] writes:
What I think we can do about this is to include DELETE_IN_PROGRESS
tuples in the set of candidate tuples to insert in the second pass.
During the merge step that verifies whether the tuple is already
in the index, if we find that it's not, then we must wait
Ühel kenal päeval, E, 2006-08-21 kell 21:46, kirjutas Fujii Masao:
Stefan Kaltenbrunner wrote:
It is however async replication so you can loose data commited on the
master but not yet replicated to the slaves in case you loose the master
completely.
Yes, here is an insufficient point of
Jim C. Nasby [EMAIL PROTECTED] writes:
I think it would be good to have something, so that people are
occasionally reminded about these things. That's a good way to help
shake ideas out.
I think the only reason there aren't more outrageous dreamworld ideas in the
TODO is that people came
AFAIR the authors have never proposed it for inclusion.
We'll be glad if hstore will be in main tarball. As I remember, when we suggest
(may be, in private exchange of letters) to include it, somebody says that
hstore breaks relational in db.
Lastest version is located at
Ühel kenal päeval, E, 2006-08-21 kell 15:00, kirjutas D'Arcy J.M. Cain:
On Mon, 21 Aug 2006 14:46:05 -0400
Gregory Maxwell [EMAIL PROTECTED] wrote:
On 8/21/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
But the confirmation that needs to come is that the WAL changes have
been applied
Ühel kenal päeval, K, 2006-08-23 kell 05:23, kirjutas Gregory Stark:
With all this code to handle ignoring vacuum transactions in calculating the
global xmin it just occurred to me to wonder: Does lazy vacuum need a
transaction at all? It doesn't do the tuple moving tricks with xvac that
Hannu Krosing wrote:
But any sync _replication_ system will have severe impact on
performance. My guess is that for a full sync replication, going from 1
server to 2 will actually lower performance andsome small gains would be
possible only starting from 3rd server.
Only testing will show
Ühel kenal päeval, K, 2006-08-23 kell 13:09, kirjutas Markus
Schiltknecht:
Hannu Krosing wrote:
But any sync _replication_ system will have severe impact on
performance. My guess is that for a full sync replication, going from 1
server to 2 will actually lower performance andsome small
Hannu Krosing wrote:
But if you have very few writes, then there seems no reason to do sync
anyway.
I think there is one: high-availability. A standby-server which can
continue if your primary fails. Of course sync is only needed if you
absolutely cannot effort loosing any committed
Tom Lane [EMAIL PROTECTED] writes:
In the past, the only way we could see HEAPTUPLE_INSERT_IN_PROGRESS
or HEAPTUPLE_DELETE_IN_PROGRESS was for tuples created/deleted by our
own transaction, and so the actions taken by IndexBuildHeapScan are
to include in the index in both cases, but exclude
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Aug 23, 2006 at 01:39:34PM +0400, Teodor Sigaev wrote:
AFAIR the authors have never proposed it for inclusion.
We'll be glad if hstore will be in main tarball.
FWIW, I'd be glad too.
As I
[Sorry for the duplicate -- I accidentally sent the previous before I was
finished editing it]
Tom Lane [EMAIL PROTECTED] writes:
I think we can solve this by having IndexBuildHeapScan not index
DELETE_IN_PROGRESS tuples if it's doing a concurrent build. The problem
of old transactions
Martijn van Oosterhout wrote:
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
snip
1) BKI - catalog.
c) Some records are changed
action: ???
They just need to be changed. In principle the datalog needs to be
updated so it looks like a database initdb'd with the new
Patch isn't full, simple test (values are took from regression.diffs):
and try dump table and restore:
ERROR: syntax error
CONTEXT: COPY tt, line 5, column tq: '1 ''2'
Attached cumulative patch fixes problem, but I have some doubts, is it really
needed?
--
Teodor Sigaev
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what I should be spending my time on in the
Hannu Krosing [EMAIL PROTECTED] writes:
When I asked the same question, I was told that a lot of core
functionality vacuum uses needs to be in transaction. I guess bad things
can happen, if some other backend ends a transaction you claim to be in.
And it is not so much about what ends up
Bernd Helmle [EMAIL PROTECTED] writes:
What are these open issues for the updatable views patch you are seeing
exactly?
Didn't Alvaro list a bunch of issues when he put the patch back up for
comment? I have not looked at it myself yet.
i see the INSERT...RETURNING stuff as the only big hurd
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2006-08-23 kell 11:05, kirjutas Hannu Krosing:
Maybe we could find a way to build a non-unique index first and then
convert it to a unique one later, in yet another pass ?
Or even add ALTER INDEX myindex ADD/DROP UNIQUE;
Greg Stark [EMAIL PROTECTED] writes:
But then wouldn't we have deadlock risks? If we come across these records in a
different order from someone else (possibly even the deleter) who also wants
to lock them? Or would it be safe to lock and release them one by one so we
only every hold one lock
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
I'm confused too. Would it be possible for you to send me a dump of
your database?
Attached is a cleaned out database, the full schema is included, but
only the relevant tables contain any data.
Thanks. After digging through it a
Greg Stark [EMAIL PROTECTED] writes:
It seems like it would be simpler to leave the core in charge the whole time.
It would call an AM method to initialize state, then call an AM method for
each tuple that should be indexed, and lastly call a finalize method.
[ shrug... ] I'm uninterested in
Alban Hertroys [EMAIL PROTECTED] writes:
Mm_object is always larger than any other table in the database, as
every table joins with (different) records in it to determine it's otype
and owner. So I don't understand how a fraction of any of those tables
could be larger than mm_object as a
--On Mittwoch, August 23, 2006 08:24:55 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
What are these open issues for the updatable views patch you are seeing
exactly?
Didn't Alvaro list a bunch of issues when he put the patch back up for
comment? I have not looked at it myself yet.
Indeed he
Greg Stark [EMAIL PROTECTED] writes:
Hmmm. Or is that true. The problem may be somewhat easier since at least you
can be sure every tuple in the heap is in the index. So if you see a
DELETE_IN_PROGRESS either it *was* a constraint violation prior to the delete
and failing is reasonable or it's
Ühel kenal päeval, K, 2006-08-23 kell 08:11, kirjutas Greg Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
BTW, I think that CONCURRENT CREATE INDEX should be modified to use long
transactions which actually build the index and are ignored by vacuum
and short ones which write data to system
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what I should be spending my time on
Böszörményi Zoltán wrote:
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what
Böszörményi Zoltán wrote:
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of
those
others. But is that what I
Böszörményi Zoltán wrote:
It seems I was able to get it working for both the VIEW and SELECT
cases. I still have one issue, the reference to the select is left open
and it complains on closing the transaction. But basically works.
Cool, thanks. Send the patch and we can look it over to see
Böszörményi Zoltán wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Tom Lane wrote:
It would be interesting to know the actual underlying Windows
error
code
--- I see that win32error.c maps several different codes to
EACCES.
It may be a good idea to put a elog(LOG) with the error code in
the
failure path of AllocateFile.
That seems like a plan
Ühel kenal päeval, K, 2006-08-23 kell 09:01, kirjutas Tom Lane:
Greg Stark [EMAIL PROTECTED] writes:
Hmmm. Or is that true. The problem may be somewhat easier since at least you
can be sure every tuple in the heap is in the index. So if you see a
DELETE_IN_PROGRESS either it *was* a
Zdenek Kotala wrote:
Martijn van Oosterhout wrote:
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
snip
1) BKI - catalog.
c) Some records are changed
action: ???
They just need to be changed. In principle the datalog needs to be
updated so it looks like a
Gregory Stark wrote:
With all this code to handle ignoring vacuum transactions in calculating the
global xmin it just occurred to me to wonder: Does lazy vacuum need a
transaction at all? It doesn't do the tuple moving tricks with xvac that
vacuum full does so does lazy vacuum's xid ever
On Wed, 23 Aug 2006 12:42:11 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
OK, that solves your problem. How about my problem where replication
has to happen on servers in three countries on two continents and
thousands of updates a second have to happen in less that 10ms?
For this
Böszörményi Zoltán wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
Best regards,
Zoltán Böszörményi
B?sz?rm?nyi Zolt?n wrote:
B?sz?rm?nyi Zolt?n wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
I think
Am Dienstag, 22. August 2006 02:52 schrieb Bruce Momjian:
This seems like a nice /contrib module.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
Böszörményi Zoltán wrote:
B?sz?rm?nyi Zolt?n wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
I think
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't think we need it immediately,
especially if he is still working on it. We are at least 1-2 weeks away
from
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
* The schema now uses foreign keys to more accurately reflect a finacial DDL
Addition of foreign key checking will certainly impact performance
significantly.
That is kind of the point. Without foreign keys it is a flawed test
stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
[ thinks for a bit... ] At least, it seems hopeless if we use
SnapshotNow. Does it help if we use a real snapshot? I'm thinking
pass 1 inserts exactly those tuples that are good according to a
snap taken at its beginning,
Ühel kenal päeval, K, 2006-08-23 kell 13:36, kirjutas Markus
Schiltknecht:
Hannu Krosing wrote:
But if you have very few writes, then there seems no reason to do sync
anyway.
I think there is one: high-availability. A standby-server which can
continue if your primary fails. Of course
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
Addition of foreign key checking will certainly impact performance
significantly.
That is kind of the point. Without foreign keys it is a flawed test
because you wouldn't be running in production without them and thus you
can't
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
Addition of foreign key checking will certainly impact performance
significantly.
That is kind of the point. Without foreign keys it is a flawed test
because you wouldn't be running in production without them and thus
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2006-08-23 kell 05:23, kirjutas Gregory Stark:
global xmin it just occurred to me to wonder: Does lazy vacuum need a
transaction at all?
When I asked the same question, I was told that a lot of core
functionality vacuum uses
Tom Lane [EMAIL PROTECTED] writes:
Or do you mean we use SatisfiesVacuum to determine what to insert but
SatisfiesSnapshot to determine whether to check uniqueness?
Right. The problems seem to all stem from the risk of trying to
unique-check more than one version of a tuple, and using a
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't think we need it immediately,
especially if he is still working on it. We are at least
Jim C. Nasby wrote:
On Tue, Aug 22, 2006 at 11:56:17AM -0700, Mark Dilger wrote:
I proposed something like this quite a bit up-thread. I was hoping we
could have a mode in which the system would run the second, third, fourth,
... best plans rather than just the best looking one, and then
stark [EMAIL PROTECTED] writes:
What happens if someone inserts a record that we miss, but it gets deleted by
the same phase 2 starts. So it's not visible to phase 2 but conflicts with
some other record we find. I suppose that's ok since the delete would have to
have comitted for that to
Hi,
Hannu Krosing wrote:
but it still needs to do at least one network roundtrip + any needed
testing on all nodes + WAL sync on all nodes before it can COMMIT, no?
No. It only needs the 'roundtrip' in the sense that a transaction sends
out its writeset and has to wait for the GCS to have it
Tom Lane [EMAIL PROTECTED] writes:
I think that's OK, but the whole idea of using an MVCC snap in phase 2
doesn't work on closer inspection. The problem is still the same one
that you need to take (at least) share lock on each tuple you insert
into the index. Telling aminsert to check
On Wed, 2006-08-23 at 13:36 +0200, Markus Schiltknecht wrote:
Hannu Krosing wrote:
But if you have very few writes, then there seems no reason to do sync
anyway.
I think there is one: high-availability. A standby-server which can
continue if your primary fails. Of course sync is only
To cut the Gordon knot I'm going to suggest we use:
\set CURSOR_FETCH fetch_count
and \g and ; are modified such that when they see
this variable set to fetch_count 0 and the buffer
is a select they would use the modified fetch/output code.
Does this sound reasonable to everyone?
OK
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I think that's OK, but the whole idea of using an MVCC snap in phase 2
doesn't work on closer inspection. The problem is still the same one
that you need to take (at least) share lock on each tuple you insert
into the
[ cc list trimmed to something reasonable ]
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output.
Zoltan Boszormenyi wrote:
The exact same code was there,
e.g. parse and rewrite SELECT * FROM view
just not in analyze.c. I will try without it, though.
And it was wrong as well. (The code was there on the COPY-view patch,
not on the official code).
--
Alvaro Herrera
Tom Lane wrote:
frankly I see no reason for this patch to be messing with the
relation case at all.
Quite apart from anything else, if it's done that way nothing that
currently works gets broken.
cheers
andrew
---(end of broadcast)---
TIP
Tom Lane írta:
[ cc list trimmed to something reasonable ]
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the
On 8/18/06, Magnus Hagander [EMAIL PROTECTED] wrote:
i doubled all my heap settings and was able to roughly double the -
c
on pgbench from ~158 (stock) to ~330 (modified). so this is
definately the problem.
If you try decreasing max_files_per_process to a significantly lower
value (say,
Zoltan Boszormenyi wrote:
1. to minimize the already huge code impact on the relation case.
2. the checks done for the SELECT case is not exactly the
same as for the realation case.
So put them in CopyToRelation. But the ones that apply to both, leave
in CopyTo.
3. the relation case is
Alvaro Herrera [EMAIL PROTECTED] writes:
Which is why you should leave the relation case alone and only add the
different case. The relation case is already known to be good.
Well, a certain amount of refactoring of the code is inevitable unless
we want a lot of code duplication. But I don't
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
How about the callback solution for the SELECT case
that was copied from the original? Should I consider
open-coding in copy.c what ExecutorRun() does
to avoid the callback?
Adding a DestReceiver type is a good solution ... although that static
On Tue, Aug 22, 2006 at 23:15:59 -0400,
Robert Treat [EMAIL PROTECTED] wrote:
On Thursday 17 August 2006 11:55, Peter Eisentraut wrote:
I'm curious, do you combine any other lists like that? I've played around
with that idea (for example, I used to combine webmaster emails, pgsql-www,
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't think we need it immediately,
especially if he is still
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't
Zoltan Boszormenyi írta:
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said
Zoltan Boszormenyi wrote:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output. Please, suggest a solution.
I'm not sure I agree with the approach
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output. Please, suggest a solution.
I'm not
Bruno Wolff III wrote:
On Tue, Aug 22, 2006 at 23:15:59 -0400,
Robert Treat [EMAIL PROTECTED] wrote:
On Thursday 17 August 2006 11:55, Peter Eisentraut wrote:
I'm curious, do you combine any other lists like that? I've played around
with that idea (for example, I used to combine
On Wed, Aug 23, 2006 at 15:03:24 -0400,
Alvaro Herrera [EMAIL PROTECTED] wrote:
Bruno Wolff III wrote:
I do, but it is a lot of email and if I miss a few days it takes a while to
catch up again. At some point I will probably do some smarter filtering, but
I don't want to spend the
[EMAIL PROTECTED] wrote:
To cut the Gordon knot I'm going to suggest we use:
ITYM Gordian - see http://en.wikipedia.org/wiki/Gordian_Knot
cheers
andrew ;-)
---(end of broadcast)---
TIP 5: don't forget to increase your free space map
Alvaro Herrera wrote:
I have on my TODO to have procmail
throw away an email that it already delivered (e.g. by comparing
Message-Id's), so if someone has a solution to that I'd like to know.
:0 Wh: msgid.lock
| formail -D 65536 $HOME/.msgid.cache
I don't use the eliminatecc feature either,
Michael wrote: Idohopethatyouralgorithmforgenerating13digitsfrom10hasbeen validatedwithisbn.org,sinceallthecheckdigitswillchange.I believeitiscrucialforpostgresqltogenerateisbncodesinboth10 and13digits
Indeed now that see the module it's finally close to be accepted as an official module, I'm
On Wed, Aug 23, 2006 at 08:47:03 +0200,
Zdenek Kotala [EMAIL PROTECTED] wrote:
Is everything ok with postgres mail server? I have problem to send mail
to hackers list and pgadmin-hacker as well. If somebody is on cc, he
receives mail correctly, but it does not appear in the list. Any
Jeremy Kronuz wrote:
Michael wrote:
I do hope that your algorithm for generating 13 digits from 10 has been
validated with isbn.org, since all the check digits will change. I
believe it is crucial for postgresql to generate isbn codes in both 10
and 13 digits
Indeed now that see the
1 - 100 of 108 matches
Mail list logo
