Joshua D. Drake wrote:
Modern systems *must* scale beyond a single computer, and the PostgreSQL
support shipped in modern Linux distros is completely incapable of this.
Slony-I is quite capable as a production class FOSS replication system
and is in use widely.
Slony-I is not enough because
Fujii Masao wrote:
Joshua D. Drake wrote:
Modern systems *must* scale beyond a single computer, and the
PostgreSQL support shipped in modern Linux distros is completely
incapable of this.
Slony-I is quite capable as a production class FOSS replication system
and is in use widely.
Slony-I
The procedure entry point ldap_start_tls_sA could not be
located in
the
dynamic link library wldap32.dll.
I'd counsel just leaving --with-ldap off until Magnus gets back
from
vacation. We can always revert the patch later if he can't fix
it.
Looking at the MSDN documentation it
I'd be interested in seeing the output from the command:
Subinacl /service NULL
On a system where this does not work.
Here is the output for Subinacl /service NULL
Both, for the Administrator user and for the Postgres user:
Thanks.
Postgres user:
Subinacl /service NULL
Table with one million rows:
wow=# \d _document83
Table public._document83
Column |Type | Modifiers
+-+---
_idrref| bytea | not null
_marked| boolean |
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 Slony-I, i think.
Most systems will not permit the committed data to be
On Mon, Aug 21, 2006 at 02:56:10PM +1200, Andrej Ricnik-Bay wrote:
On 8/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is there an interest, or any active project to examine PostgreSQL in
the area of 64-bit processors? Has it already been done? I don't recall
seeing a reference to it in my
On Sun, Aug 20, 2006 at 11:00:26PM -0400, Douglas McNaught wrote:
[EMAIL PROTECTED] writes:
Is there an interest, or any active project to examine PostgreSQL in
the area of 64-bit processors? Has it already been done? I don't recall
seeing a reference to it in my travels. I'm also not sure
Yes the needs are simple. I was also thinking about using DBI. The most
important thing to me is that everything is kept in a transaction so that
users can still read the data while I'm snapshotting it at the same time.
If my transaction is isolated from all the reads happening, then it
[EMAIL PROTECTED] wrote:
This is what I mean by after thought. PostgreSQL is designed for
32-bit processors. Which is fine. I'm not complaining. The question
was whether there is an interest in pursuing 64-bit specific
optimizations. In the PostgreSQL code, a quick check points me only to
has
On Mon, Aug 21, 2006 at 09:16:46AM -0400, [EMAIL PROTECTED] wrote:
This is what I mean by after thought. PostgreSQL is designed for
32-bit processors. Which is fine. I'm not complaining. The question
was whether there is an interest in pursuing 64-bit specific
optimizations. In the PostgreSQL
On Mon, Aug 21, 2006 at 06:40:22AM -0700, Paul Silveira wrote:
Yes the needs are simple. I was also thinking about using DBI. The most
important thing to me is that everything is kept in a transaction so that
users can still read the data while I'm snapshotting it at the same time.
If my
One more attempt to send this, now without the attachment. It's getting
eaten somewhere. I assume it's not the moderation queue, because someone
would hopefully have gotten to it during the four weeks I was gone..
Anyawy. Third take on the message itself, if it goes through, could
someone who has
Martijn van Oosterhout kleptog@svana.org writes:
Can you think of any places at all where 64-bit would make a difference
to processing? 64-bit gives you more memory, and on some x86 chips, more
registers, but that's it.
It would be interesting to look into making int8 and float8 be
Hi Magnus,
After trying to unlock the nul device using:
Subinacl/serviceNULL/grant="authenticatedusers"=QSEILU
It doesn't solve the problem (even after restating the machine)
Here is the new output from running "Subinacl/serviceNULL" after the change
For Administrator:
Another take on this. Dave convinced me that I had access to svr1, which
it turns out I did, so I managed to check the logs myself. And I find:
Aug 21 10:51:24 postgresql postfix/smtp[52021]: 3F45C9FB2BB:
to=pgsql-patches-p
[EMAIL PROTECTED], orig_to=pgsql-patches@postgresql.org,
relay=mai
Teodor Sigaev [EMAIL PROTECTED] writes:
Can I tweak something in 8.1 or it's a bug?
It's not a bug, it's an intentional change:
2005-04-24 21:30 tgl
* src/: backend/commands/explain.c,
backend/executor/nodeBitmapIndexscan.c,
backend/executor/nodeIndexscan.c,
[EMAIL PROTECTED] writes:
I believe the answer is no. No or few 64-bit optimization possibilities
have been chased down, probably because some or many of these would:
1) require significant re-architecture
2) reduce the performance in a 32-bit world
Honestly, I think the main
Fujii Masao wrote:
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 Slony-I, i think.
Most systems will not permit the
On Sat, 2006-08-19 at 16:01 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The only complaint I can see is that someone
who wants pg_dump to dump out SERIAL so it appears just as he created
the table, doesn't get that. Could we have pg_dump do that if the
sequences all
WRT 64-bit and Postgres, it depends on the CPU as to whether you
see a simple performance benefit. On the Opteron you will see a
benefit when doing CPU bound work. When doing the CPU portion, the
additional registers of the Opteron running in 64-bit mode are used
by the compiler to produce
On Mon, Aug 21, 2006 at 10:23:16AM -0400, Douglas McNaught wrote:
[EMAIL PROTECTED] writes:
I believe the answer is no. No or few 64-bit optimization possibilities
have been chased down, probably because some or many of these would:
1) require significant re-architecture
2) reduce
On Mon, Aug 21, 2006 at 12:00:58PM +0300, Alexander Kirpa wrote:
WRT 64-bit and Postgres, it depends on the CPU as to whether you
see a simple performance benefit. On the Opteron you will see a
benefit when doing CPU bound work. When doing the CPU portion, the
additional registers of the
Can you do that if you have functions tied to the table? Also would that be
in a transaction? I need to allow seamless usability to the data while I'm
doing this snapshot. Not sure the -c option (Clean Drop schema) would work
here. I want to only drop a table and not the entire db so that I'm
On Mon, Aug 21, 2006 at 10:46:56AM -0400, [EMAIL PROTECTED] wrote:
Compilers are getting smarter, but having code profiled, and hand tuned
for 32-bits does not automatically get compiled with a 64-bit compiler,
to code that has been profile, and hand tuned for 64-bit.
I don't see any evidence
On Aug 21, 2006, at 10:30 , Joshua D. Drake wrote:
Fujii Masao wrote:
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
It is very, very common to have asynchronous replication. I would say
the need for synchronous is far more limited (although greater desired).
I would imagine that multi-master synchronous replication would be
fairly trivial to implement with 2PC and wal-shipping available, no?
Trivial? I
Hi,
AgentM wrote:
I would imagine that multi-master synchronous replication would be
fairly trivial to implement with 2PC and wal-shipping available, no?
Yes, that could be done. And AFAIK eigter pgpool or PgCluster (1) try to
do sync, multi-master replication that way.
The problem is that
On Mon, Aug 21, 2006 at 05:13:58PM +0200, Martijn van Oosterhout wrote:
On the whole, PostgreSQL is still in the phase where we're trying to
find the best algorithms. When that's done (if ever), we can start
worrying about processor optimisations...
I don't disagree. :-)
You claimed that
Fujii Masao wrote:
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 Slony-I, i think.
Most systems will not permit
I have realized that my modifications in configure.in and
src/interfaces/libpq/Makefile to link libpq against
OpenLDAP are buggy.
Here is a proposed patch to fix it.
I write this to pgsql-hackers too because I want to share
the difficulty I'm facing - maybe somebody has a better
idea.
To handle
Marko Kreen [EMAIL PROTECTED] writes:
Following patch exports 8 byte txid and snapshot to user level
allowing its use in regular SQL. It is based on Slony-I xxid
module. It provides special 'snapshot' type for snapshot but
uses regular int8 for transaction ID's.
Per discussion, I've applied
On 8/21/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
(I wouldn't do it like this though --- TransactionIdAdvance itself is
the place to bump the secondary counter.)
Agreed.
I reconsidered after trying to do it that way --- although fixing
Marko Kreen [EMAIL PROTECTED] writes:
Dropping the pg_sync_txid() would be loss, because that means that
user cannot just dump and restore the data and just continue where
it left off. Maybe its not a problem for replication but for generic
queueing it would need delicate juggling when
On Mon, 2006-08-21 at 11:33 -0400, AgentM wrote:
I would imagine that multi-master synchronous replication would be
fairly trivial to implement with 2PC and wal-shipping available, no?
How does WAL shipping help synchronous replication?
Regards,
Jeff Davis
[EMAIL PROTECTED] writes:
What re-architecting would be needed?
I'm asking that it be admitted that it has not been looked at. Not
seriously. Nor is this unique to PostgreSQL. I expect the performance
for Linux applications in general to slowly improve on 64-bit
processors as more and more
On 8/21/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
Dropping the pg_sync_txid() would be loss, because that means that
user cannot just dump and restore the data and just continue where
it left off. Maybe its not a problem for replication but for generic
Marko Kreen [EMAIL PROTECTED] writes:
On 8/21/06, Tom Lane [EMAIL PROTECTED] wrote:
I'm not following the point here. Dump and restore has never intended
to preserve the transaction counter, so why should it preserve
high-order bits of the transaction counter?
Thus it guarantees that any
Jeff Davis wrote:
How does WAL shipping help synchronous replication?
The WAL is written _before_ commit, logging all the changes the
transaction wants to write to the disk. This makes it look very similar
to what is needed for synchronous replication.
Instead of waiting for confirmation
Do we want to replace our /contrib/isbn with this, or have it pgfoundry?
---
Jeremy Kronuz wrote:
I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year
ago, and I was wondering if it could be made official,
Markus Schiltknecht wrote:
Jeff Davis wrote:
How does WAL shipping help synchronous replication?
The WAL is written _before_ commit, logging all the changes the
transaction wants to write to the disk. This makes it look very similar
to what is needed for synchronous replication.
Reminding folks this bug is still open.
---
Tom Lane wrote:
... because nowhere does it update the checkAsUser fields in the
view's query to be the OID of the new owner. This means that
permission checks about whether
On Mon, Aug 21, 2006 at 01:05:13PM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
What re-architecting would be needed?
I'm asking that it be admitted that it has not been looked at. Not
seriously. Nor is this unique to PostgreSQL. I expect the performance
for Linux applications in
[EMAIL PROTECTED] writes:
On Mon, Aug 21, 2006 at 01:05:13PM -0400, Tom Lane wrote:
What you seem to be asking for is that we engage in a lot of
machine-specific tuning for some particular processor or other.
The question was whether PostgreSQL was optimized for 64-bit Linux.
The answer is
On 8/21/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 8/21/06, Tom Lane [EMAIL PROTECTED] wrote:
I'm not following the point here. Dump and restore has never intended
to preserve the transaction counter, so why should it preserve
high-order bits of the
On 8/21/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
But the confirmation that needs to come is that the WAL changes have
been applied (fsync'ed), so the performance will be terrible. So bad,
that I don't think anyone will want to use such a replication system ...
Okay. I give up... Why is
On Mon, 2006-08-21 at 19:42 +0200, Markus Schiltknecht wrote:
Jeff Davis wrote:
How does WAL shipping help synchronous replication?
The WAL is written _before_ commit, logging all the changes the
transaction wants to write to the disk. This makes it look very similar
to what is needed
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 (fsync'ed), so the performance will be terrible. So bad,
that I don't think
Alvaro Herrera wrote:
But the confirmation that needs to come is that the WAL changes have
been applied (fsync'ed), so the performance will be terrible. So bad,
that I don't think anyone will want to use such a replication system ...
Yeah, that's the big problem of sync, multi-master
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2006-08-21 at 19:27 +0300, Martin Atukunda wrote:
If readline is used by psql, a history file is automatically used.
This patch adds the special file name 'none', which if set as the
HISTFILE parameter, will cause psql not to use the history file.
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2006-08-21 at 19:27 +0300, Martin Atukunda wrote:
If readline is used by psql, a history file is automatically used.
This patch adds the special file name 'none', which if set as the
HISTFILE parameter, will cause psql not to
Gregory Maxwell wrote:
infiniband is cheap..
Can I get one? I'd love to run some tests with Postgres-R ;-)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Aug 21, 2006, at 15:00 , D'Arcy J.M. Cain wrote:
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 (fsync'ed), so the performance
Jeff Davis wrote:
Synchronous replication (to me) means that the data has been written to
permanent storage on all masters and all slaves before any master or
slave reports a successful COMMIT. Are you suggesting that you ship the
WAL over the network, wait for it to be written to the slave, and
AgentM wrote:
On Aug 21, 2006, at 15:00 , D'Arcy J.M. Cain wrote:
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 (fsync'ed),
Magnus Hagander [EMAIL PROTECTED] writes:
Attached is a patch that fixes this issue at least in my test machine
(yes, I found one 2000 machine that was broken as well)
Applied. Dave, would you re-enable the LDAP option on bandicoot so
we can verify this fixes it?
On Mon, 21 Aug 2006 15:14:10 -0400
AgentM [EMAIL PROTECTED] wrote:
My experience is that any replication needs to be based on your
business
rules which will vary widely.
Sure- and more specifically, replication rules may differ on every
table according to those rules. The current
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 21 August 2006 20:24
To: pgsql-hackers@postgresql.org; Magnus Hagander
Cc: Dave Page; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] [HACKERS] BF Failure on Bandicoot
Magnus Hagander [EMAIL PROTECTED]
Bruce Momjian wrote:
Do we want to replace our /contrib/isbn with this, or have it pgfoundry?
---
Jeremy Kronuz wrote:
I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year
ago, and I was wondering if it
Tom, all,
BTW, the reason that the CVS code for the old contrib projects isn't up on
pgFoundry yet is that we're having an issue with permissions for which I
don't have a solution yet. I am still planning to fix this as soon as I
can figure out a workaround.
--
--Josh
Josh Berkus
I suppose having it to replace the current contrib/isbn would be a good option, this 13 digits ISBN will be the standard by 2007, and some publishers are already issuing 13 digit ISBN numbers since last year.
The module I created uses int64 instead of strings, for the numbers, and thus the
So we don't want COPY FROM VIEW in 8.2? Even if we later support COPY
(SELECT ...), aren't we still going to want to copy from a view? I
guess not because you would just do COPY (SELECT * FROM view)?
---
Tom Lane wrote:
Jeremy Kronuz wrote:
I suppose having it to replace the current contrib/isbn would be a
good option, this 13 digits ISBN will be the standard by 2007, and
some publishers are already issuing 13 digit ISBN numbers since last year.
The module I created uses int64 instead of strings, for the
I will try to generate a list of open 8.2 items in 7-10 days so we can
start focusing on beta.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of
On Aug 22, 2006, at 2:52 , Bruce Momjian wrote:
Do we want to replace our /contrib/isbn with this, or have it
pgfoundry?
If contrib/isbn is made obsolete by the pgfoundry ISBN/ISSN/ISMN/
EAN13 code, unless there's a compelling reason that the pgfoundry be
part of the distribution, I
Magnus Hagander [EMAIL PROTECTED] writes:
a.hub.org[200.46.208.251], delay=1, status=sent (250 2.7.1 Ok,
discarded, id=258
35-09 - BANNED: P=p003,L=1,M=multipart/mixed |
P=p002,L=1/2,M=application/x-gzip
,T=gz,N=vcbuild.tar.gz | P=p...)
Seems -patches is rejecting any mail with attached
Bruce Momjian [EMAIL PROTECTED] writes:
As part of the move to support standard-conforming strings and treat
backslash literally, I reviewed the tsearch2 code and found two place
that seemed to use \' rather than '', and generated the attached patch.
I thought we had decided that that code
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
As part of the move to support standard-conforming strings and treat
backslash literally, I reviewed the tsearch2 code and found two place
that seemed to use \' rather than '', and generated the attached patch.
I thought we had
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Trying to get back on point. What is the scope of work for the TODO
item? Forget everything else I brought up. What is the goal of the
existing TODO?
I'm not sure that the TODO item has a reason to
Bruce Momjian wrote:
I will try to generate a list of open 8.2 items in 7-10 days so we can
start focusing on beta.
FYI, you have three emails about updatable views in the queue, but you
are missing the one I sent today which contains an updated patch that is
substantially better than those in
Bruce Momjian [EMAIL PROTECTED] writes:
OK, based on this feedback, I am adding COPY VIEW to the patches queue.
I think we have other things that demand our attention more than a
half-baked feature.
regards, tom lane
---(end of
71 matches
Mail list logo
