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 wid
> >>> 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 th
> > 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 /servi
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 l
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 i
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
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
shouldn
[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 lo
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 PostgreS
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
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 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
pass-by-value datatypes to
Hi Magnus,
After trying to unlock the nul device using:
Subinacl /service NULL /grant="authenticated users"=QSEILU
It doesn't solve the problem (even after restating the machine)
Here is the new output from running "Subinacl /service NULL" 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=, orig_to=,
relay=mai
a.hub.org[200.46.208.251], delay=1, status=sent (250 2.7.1 Ok,
disca
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, backend/
[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 co
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
> > sequen
> 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 prod
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
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
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 evidenc
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 point
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 w
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 Po
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
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 ap
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
"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 m
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 gener
"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 guarantee
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 f
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 wheth
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 applicat
[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 answe
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 bit
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 wa
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 n
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'
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 replicati
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 histor
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
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 perfor
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
> >>>be
"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 c
> -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 PROTE
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
PostgreSQL
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 perf
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 num
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 broadcast)---
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 rec
"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 att
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 cod
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
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
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 broadcast)--
71 matches
Mail list logo