On Thu, 8 Feb 2007, Joshua D. Drake wrote:
>
> Well how deep are we talking here? My understanding of what Jan wants to
> do is simple.
>
> Be able to declare which triggers are fired depending on the state of
> the cluster.
>
> In Jan's terms, the Origin or Subscriber. In Replicator terms the Mas
Full_page_compress is not intended to use with PITR slave, but for the
case to keep both online backup and archive log for archive recovery,
which is very popular PostgreSQL operation now.
I've just posted my evaluation for the patch as a reply for another
thread of the same proposal (sorry, I cre
From: "Magnus Hagander" <[EMAIL PROTECTED]>
> hnetcfg.dll is a part of Windows. "Home Networking Configuration
> Manager". LPK.DLL is also a part of Windows - it's the language
pack.
Thank you for information.
> On Thu, Feb 08, 2007 at 09:50:26PM +0900, Takayuki Tsunakawa wrote:
>> When I try to
Sorry for the late responce;
Gzip can reduce the archive log size about one fourth. My point is
that it can still be large enough.Removing physical log record (by
replacing them with logical log record) from archive log will achieve
will shrink the size of the archive log to one twentiet
Uh, I thought the approach was to create type-specific in/out functions,
and add casting so every time there were referenced, they would expand
to a varlena structure in memory.
---
Gregory Stark wrote:
>
> I've been lookin
On Thu, 2007-02-08 at 22:15 -0500, Tom Lane wrote:
> I'm testing the patch currently. I was a bit surprised to find the
> without_oid test failing, but it makes sense because I'm using a
> MAXALIGN=8 machine. I suppose Heikki tested on MAXALIGN=4.
That's definitely strange. The patch has been p
I just want an outline of what each option is supposed to control. If
that information is in a documentation patch, then fine, he can just
post that and tell people to read the patch documentation.
---
Joshua D. Drake wrote
Jan Wieck wrote:
> On 2/8/2007 3:32 PM, Bruce Momjian wrote:
>> Alvaro Herrera wrote:
>>> > > Is this a new policy that after discussion, all patches must be >
>>> > resubmitted with a summary and conclusions of the discussion? I can
>>> > > certainly do that for you, but just tell me if you are go
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Combo is OK, because it's a *combination* of two CommandIds.
>>
>> That means they are ComboCommandIds or CCIs.
> CCI is CommandCounterIncrement to me, so let's not use that
> abbreviation.
Agreed. I looked for a bit at adding
On Fri, 2007-02-09 at 00:08 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Thu, 2007-02-08 at 15:32 -0500, Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > Tom Lane wrote:
> > > >> Packed doesn't seem to have quite the right connotation either --- it
> > > >> sound
Simon Riggs wrote:
> On Thu, 2007-02-08 at 15:32 -0500, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Packed doesn't seem to have quite the right connotation either --- it
> > >> sounds like it means there are two separable fields in the CID value.
> >
On Thu, 2007-02-08 at 15:32 -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Packed doesn't seem to have quite the right connotation either --- it
> >> sounds like it means there are two separable fields in the CID value.
> >>
> >> Maybe "composite cid"?
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > That is part of the original open() code that Claudio did back for 8.0,
> > so it has definitly been working since then.
>
> Hm, maybe best not to touch it, but still...
>
> > I haven't really read into
> > the code, though... Bu
Who is working on this item?
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Mon, Sep 04, 2006 at 05:15:57PM +0100, Mark Cave-Ayland wrote:
> > 3) Add planner support so that WITH clauses are mapped to
Jan Wieck wrote:
> On 2/8/2007 3:32 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> > > Is this a new policy that after discussion, all patches must be
> >> > > resubmitted with a summary and conclusions of the discussion? I can
> >> > > certainly do that for you, but just tell me if you
On 2/8/2007 3:32 PM, Bruce Momjian wrote:
Alvaro Herrera wrote:
> > Is this a new policy that after discussion, all patches must be
> > resubmitted with a summary and conclusions of the discussion? I can
> > certainly do that for you, but just tell me if you are going to ask the
> > same from
On Wed, 2007-02-07 at 14:17 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > The basic idea is that when a tuple is UPDATEd we can, in certain
> > circumstances, avoid inserting index tuples for a tuple. Such tuples are
> > marked HEAP_ONLY_TUPLE, but their storage is otherwis
OK, where are we on this patch?
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > >> This patch doesn't seem to cope with cases where the supplied tuple has
> > >> the wrong number of colu
Here is the more recent email I have on this feature work.
---
Bernd Helmle wrote:
> --On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
> <[EMAIL PROTECTED]> wrote:
>
> >
> > So in other words, views on serial column
Where are we on this feature?
---
Bernd Helmle wrote:
> --On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>
> > Bernd Helmle <[EMAIL PROTECTED]> writes:
> >> [ latest views patch ]
> >
> >
IF I run the following with the a < 2900 condition first, the more
expensive EXISTS only gets executed when needed, but if I change the
order of the OR's, the EXISTS is always executed. It would be good if
the optimizer could re-order the OR conditions based on estimated
cost (granted, this
Can someone add this to the TODO?
patch
Description: Binary data
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---(end of broadcast)---
TIP 7: You
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The way combo cid is supposed to work is that you are deleting a row
> > created in your same transaction by a previous command id, so you look
> > in the combo cid array to see if a match for that pair exists --- if
> > not, you creat
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The way combo cid is supposed to work is that you are deleting a row
> created in your same transaction by a previous command id, so you look
> in the combo cid array to see if a match for that pair exists --- if
> not, you create a new entry and put the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Humm, sorry, obviously this makes no sense at all because I mentally
> mixed the Xid locker and the Cids.
After thinking a bit, I have a sketch of a solution.
Assume that we extend the MultiXact infrastructure so that it can track
whether each member o
Tom Lane wrote:
> > At one point I was thinking "combo". but "composite" sounds good.
>
> I like "combo" --- nice and short.
>
> >> Another issue that we need to think about before we go too far with this
> >> is the problem that we punted on before 8.2 release: how to deal with
> >> rolling back
Alvaro Herrera wrote:
> This starts to look awfully similar to MultiXactIds. And probably using
> such a mechanism would allow you to "rollback" any number of row locks:
> take the current membersoof the "multicid", substract the one that
> rolled back and use that as new multicid. The main diff
Bruce Momjian wrote:
> Tom Lane wrote:
> >
> > Another issue that we need to think about before we go too far with this
> > is the problem that we punted on before 8.2 release: how to deal with
> > rolling back an upgrade of a row-level lock from shared to exclusive
> > within a subtransaction. I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Packed doesn't seem to have quite the right connotation either --- it
>> sounds like it means there are two separable fields in the CID value.
>>
>> Maybe "composite cid"?
> At one point I was thinking "combo". but "composite" sounds
Alvaro Herrera wrote:
> > > Is this a new policy that after discussion, all patches must be
> > > resubmitted with a summary and conclusions of the discussion? I can
> > > certainly do that for you, but just tell me if you are going to ask the
> > > same from everyone.
> >
> > No, I am asking o
On Thu, 2007-08-02 at 12:24 -0800, Stephan Szabo wrote:
> On Thu, 8 Feb 2007, Marc Munro wrote:
>
> > I don't think this does stop the second from continuing before the
> > first. What will stop it, is the eventual lock that is taken on the
> > child (triggering) record.
>
> But at that point, y
Tom Lane wrote:
> [ time to move this thread to -hackers ]
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>> Heikki Linnakangas wrote:
> Tom Lane wrote:
> > BTW, I don't care much for the terminology "phantom cid" ... t
On Thu, 8 Feb 2007, Marc Munro wrote:
> On Thu, 2007-08-02 at 10:06 -0800, Stephan Szabo wrote:
> > On Thu, 8 Feb 2007, Marc Munro wrote:
> . . .
> > >
> > > That other transaction, T1, would have run the same RI triggers and so
> > > would have the same parent records locked.
> >
> > That's not t
Bruce Momjian wrote:
> Jan Wieck wrote:
> > On 2/7/2007 11:12 PM, Bruce Momjian wrote:
> > > Jan Wieck wrote:
> > >> On 2/7/2007 10:35 PM, Bruce Momjian wrote:
> > >>
> > >> > Also, I saw the trigger patch with no explaination of why it was
> > >> > important or who would use it --- that also isn't
[ time to move this thread to -hackers ]
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Heikki Linnakangas wrote:
Tom Lane wrote:
> BTW, I don't care much for the terminology "phantom cid" ... there's
> nothing particularl
On Thu, 2007-08-02 at 14:33 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > Yes in this case, T1 must abort because the record it was going to
> > update has disappeared from underneath it. I don't see how this is
> > significantly different from the same race for the record if
Jan Wieck wrote:
> On 2/7/2007 11:12 PM, Bruce Momjian wrote:
> > Jan Wieck wrote:
> >> On 2/7/2007 10:35 PM, Bruce Momjian wrote:
> >> > I find the term "logical proof of it's correctness" too restrictive. It
> >> > sounds like some formal academic process that really doesn't work well
> >> > for
On Feb 8, 11:28 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
> Tom Lane wrote:
> > I thought it might be coming from your --with-libs switch somehow,
> > but when I add that to my configure command it does not change this
> > output at all. Is it possible you've got environment variables
> > (lik
Marc Munro <[EMAIL PROTECTED]> writes:
> Yes in this case, T1 must abort because the record it was going to
> update has disappeared from underneath it. I don't see how this is
> significantly different from the same race for the record if the table
> had no RI constraints. The only difference th
Tom Lane wrote:
> I thought it might be coming from your --with-libs switch somehow,
> but when I add that to my configure command it does not change this
> output at all. Is it possible you've got environment variables
> (like CFLAGS) that configure might be picking up?
A stout I'll bet it's $L
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
> I'm trying to build PostgreSQL 8.2.2 outside the ports system on a
> FreeBSD 6.2 amd64 box.
Note you *definitely* want 8.2.3 not 8.2.2.
> configure:2209: checking for C compiler default output file name
> configure:2212: gcc -O3 -funroll-loops -m64
Andrew Hammond wrote:
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by PostgreSQL configure 8.2.2, which was
> generated by GNU Autoconf 2.59. Invocation command line was
>
> $ ./configure --
On 2/7/2007 11:12 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 2/7/2007 10:35 PM, Bruce Momjian wrote:
> I find the term "logical proof of it's correctness" too restrictive. It
> sounds like some formal academic process that really doesn't work well
> for us.
Thank you.
> Also, I saw the trig
--enable-thread-saftey is surely misspelled.
not sure about the rest.
cheers
andrew
Andrew Hammond wrote:
I'm trying to build PostgreSQL 8.2.2 outside the ports system on a
FreeBSD 6.2 amd64 box. The databases/postgresql81-server port builds
8.1.7 just fine on the same box. My configure fa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm honestly looking for some practical use of this. We have debated
> other NOTICE messages over the years, but they at least tell you
> something you can use after the command.
The objection I had to the original patch (which didn't return a noti
On Thu, 2007-08-02 at 10:06 -0800, Stephan Szabo wrote:
> On Thu, 8 Feb 2007, Marc Munro wrote:
. . .
> >
> > That other transaction, T1, would have run the same RI triggers and so
> > would have the same parent records locked.
>
> That's not true in the case of delete, since the referencing table
I can set up build farm on it if yall need it. Its running 6.2/amd64
--- Original Message ---
From: "Andrew Hammond" <[EMAIL PROTECTED]>
To: " Larry Rosenman "
Sent: 2/8/07, 12:19:07 PM
Subject: Re: BuildFarm: Do we need another FreeBSD/amd64 member?
On Jan 19 2006, 9:36 pm, [EMAIL PROT
I'm trying to build PostgreSQL 8.2.2 outside the ports system on a
FreeBSD 6.2 amd64 box. The databases/postgresql81-server port builds
8.1.7 just fine on the same box. My configure fails. I'm new to
FreeBSD so I expect I'm missing something pretty obvious. config.log
follows. Line 2212 is very od
On Jan 19 2006, 9:36 pm, [EMAIL PROTECTED] ("Larry Rosenman") wrote:
> Tom Lane wrote:
> > "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> >> I've got a fastFreeBSD/amd64 server available to run Buildfarm
> >> on.
>
> >> However, I see we already have a couple of others running it.
>
> >>
On Thu, 8 Feb 2007, Marc Munro wrote:
> Oops, forgot to include pgsql-hackers when I responded to this the first
> time.
>
> On Tue, 2007-06-02 at 20:53 -0500, Tom Lane wrote:
> > Marc Munro <[EMAIL PROTECTED]> writes:
> > > The RI triggers currently fire when a record is updated. Under my
> > >
Peter Eisentraut wrote:
The downside is that while I wanted to use the IF EXISTS form to reduce
the chatter at the beginning of schema loading scripts, this just gives
me a different spelling of that same chatter.
There is possibly a good case for dropping the message level.
cheers
andr
Andrew Dunstan wrote:
> Peter Eisentraut wrote:
> > What is the practical purpose of the notices emitted by DROP
> > SOMETHING IF EXISTS when the object in fact does not exist?
>
> It was asked for ...
The argument was that MySQL does the same. Which is valid but not
overriding.
I'm honestly lo
On Thu, 2007-08-02 at 18:06 +0100, Csaba Nagy wrote:
> The problem is that eliminating the deadlock is still not the complete
> cake... the interlocking still remains, possibly leading to degraded
> performance on high contention on very common parent rows. The real
> solution would be when an upd
On Thu, 2007-02-08 at 17:47, Marc Munro wrote:
> [snip] One of the causes of deadlocks in Postgres is that its referential
> integrity triggers can take locks in inconsistent orders. Generally a
> child record will be locked before its parent, but not in all cases.
[snip]
The problem is that elim
I am going to restate my earlier proposal, to clarify it and in the hope
of stimulating more discussion.
One of the causes of deadlocks in Postgres is that its referential
integrity triggers can take locks in inconsistent orders. Generally a
child record will be locked before its parent, but not
Oops, forgot to include pgsql-hackers when I responded to this the first
time.
On Tue, 2007-06-02 at 20:53 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > The RI triggers currently fire when a record is updated. Under my
> > proposal they would fire in the same way but before
On Thu, 8 Feb 2007, Heikki Linnakangas wrote:
> Gavin Sherry wrote:
> > I will update the code tomorrow. The focus will be cleaning up the
> > executor modifications. Please look else where for now.
>
> I'm getting a segfault with this test script:
>
>
> CREATE TABLE bmtest (i int);
>
> I
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Log Message:
---
Reduce WAL activity for page splits:
Currently, an index split writes all the data on the split page to
WAL. That's a lot of WAL traffic. The tuples that are copied to th
Gavin Sherry wrote:
I will update the code tomorrow. The focus will be cleaning up the
executor modifications. Please look else where for now.
I'm getting a segfault with this test script:
CREATE TABLE bmtest (i int);
INSERT INTO bmtest SELECT 1 FROM generate_series(1,10) a;
INSE
Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
The basic idea is that when a tuple is UPDATEd we can, in certain
circumstances, avoid inserting index tuples for a tuple. Such tuples are
marked HEAP_ONLY_TUPLE, but their storage is otherwise identical to
other tuples.
What is VACUUM
Heikki Linnakangas wrote:
> Stefan Kaltenbrunner wrote:
> >Bruce Momjian wrote:
> >>Log Message:
> >>---
> >>Reduce WAL activity for page splits:
> >>
> >>>Currently, an index split writes all the data on the split page to
> >>>WAL. That's a lot of WAL traffic. The tuples that are copied to
Markus Schiltknecht wrote:
> since str(n?)cat got replaced with strlcat, I fail to build
Since the buildfarm thinks it's OK, I'd first of all check whether you
have a complete and consistent checkout. Note that the default cvs
options will probably not get you one.
--
Peter Eisentraut
http://
Markus Schiltknecht wrote:
Hi,
since str(n?)cat got replaced with strlcat, I fail to build PostgreSQL
(current CVS HEAD). HAVING_DECL_STRLCAT is not set, so AFAIK, the
strlcat() function from src/port should be used. However, I've read the
README there, but still don't quite know what's wrong
Hi,
since str(n?)cat got replaced with strlcat, I fail to build PostgreSQL
(current CVS HEAD). HAVING_DECL_STRLCAT is not set, so AFAIK, the
strlcat() function from src/port should be used. However, I've read the
README there, but still don't quite know what's wrong.
The linker throws:
gcc
Heikki Linnakangas wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Log Message:
---
Reduce WAL activity for page splits:
Currently, an index split writes all the data on the split page to
WAL. That's a lot of WAL traffic. The tuples that are copied to the
right page need to be
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Log Message:
---
Reduce WAL activity for page splits:
Currently, an index split writes all the data on the split page to
WAL. That's a lot of WAL traffic. The tuples that are copied to the
right page need to be WAL logged, but the tuples
> Yes, yes, and yes ... but aside from the problem that you use the very
> ambiguous word "timestamp" (which somehow suggests using a "clock" of
> some sort), isn't the "begin" timestamp of a long running transaction
imho a begin timestamp is near useless
> worse than the "commit" timestamp,
On Tue, Feb 06, 2007 at 02:16:05PM -0500, Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > On Feb 6, 2007, at 12:40 PM, Tom Lane wrote:
> >> ... massive expansion of the tests doesn't seem justified
>
> > What about the idea that's been floated in the past about a --
> > extensive mode
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Log Message:
---
Reduce WAL activity for page splits:
Currently, an index split writes all the data on the split page to
WAL. That's a lot of WAL traffic. The tuples that are copied to the
right page need to be WAL logged, but the tuples
Bruce Momjian wrote:
Log Message:
---
Reduce WAL activity for page splits:
Currently, an index split writes all the data on the split page to
WAL. That's a lot of WAL traffic. The tuples that are copied to the
right page need to be WAL logged, but the tuples that stay on the
original pa
70 matches
Mail list logo
