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)--
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
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
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
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)---
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
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
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:
>
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
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, 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
"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 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
> -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
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
"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?
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
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
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
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
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
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'
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 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 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
[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 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
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
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.
>
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,
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
"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
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
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
[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 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
-
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
"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 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:
> 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
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
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
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
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
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
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
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 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
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
> 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 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
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
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
[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
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/
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
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:
=
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
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
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
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
[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
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
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
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
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
Table with one million rows:
wow=# \d _document83
Table "public._document83"
Column |Type | Modifiers
+-+---
_idrref| bytea | not null
_marked| boolean |
> > 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
> >>> 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
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
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
71 matches
Mail list logo
