Matt Miller írta:
The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ...
However, the patch will not apply to cvs branch REL8_2_0.
I've been told that the pgcluster patch patches some generated files
(parse.h and other apparently).
Yes, I could not at first apply to
On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Oh, you mean MB vs Mb. Man, it had to be that simple :)
>
> ISTM we had discussed whether guc.c should accept units strings in
> a case-insensitive manner, and the forces of pedantry won the first
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round. Shall we reopen that argument?
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2006-12-15 at 09:56 -0500, Tom Lane wrote:
>> The fundamental problem with it was the assumption that different
>> executions of a plan node will have the same timing. That's not true,
>> in fact not even approximately true.
> It doesn't make s
Magnus Hagander wrote:
> > I'll try to take a look at this sometime the next couple of days (out of
> > time for today) unless beaten to it.
> >
>
> Actually, there's another option that Hiroshi mentioned off-list, that I
> forgot.
>
> We can implement the Microsoft functions _fseeki64() and _ft
From: "Takayuki Tsunakawa" <[EMAIL PROTECTED]>
How about mimicing postgres with a script that starts gdb to run
> postgres? That is, rename the original postgres module to
> postgres.org and create a shell script named postgres like this:
>
> #!/bin/bash
> gdb postgres $*
Sorry, this should be p
Hello, Mr. Stark
> Are there any tricks people have for debugging bootstrapping
processing? I
> just need to know what index it's trying to build here and that
should be
> enough to point me in the right direction:
As Mr. Lane says, it would be best to be able to make postgres sleep
for an arbitr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...VACUUM FULL WAIT
> Sounds like a deadlock waiting to happen :-(
Yeah, this sounds more and more like a job for a client application.
> AFAIK the general practice is to just accept the fact that vacuum can't
> remove recently-dead tuples. You sh
On Sun, 2006-12-17 at 10:56 +0100, Lukas Kahwe Smith wrote:
> PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more
> detailed todo list have not come into reality yet to assist in for the
> next 8.3 release. A couple people have replied to my earlier request to
> form a little
On Thu, 2006-12-14 at 07:35 +0900, Tatsuo Ishii wrote:
> Could you please submit to -pacthes?
Patch submitted to -patches as requested last Thursday.
Any feedback would be gratefully received.
Thanks,
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---
On Fri, 2006-12-15 at 10:57 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs:
> >> Until we work out a better solution we can fix this in two ways:
> >>
> >> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] .
another windows admin running all his service
under the administrator context.
I needed the PostgreSQL setup to prove to a customer
that a working setup could be made using PGSQL. It lived
on my system for a couple of days in total, so cooking
up a perfectly secure system was hardly worth it, i
Magnus Hagander wrote:
>>> Hmm. This was even worse than I thought :-(
>>>
>>> I got it building most of the way by following Andrews suggestion and
>>> greating a pgoff_t, just to check it out. That done, it seems that mingw
>>> doesn't include these 64-bit functions in their import library *at al
>> Hmm. This was even worse than I thought :-(
>>
>> I got it building most of the way by following Andrews suggestion and
>> greating a pgoff_t, just to check it out. That done, it seems that mingw
>> doesn't include these 64-bit functions in their import library *at all*.
>> That gives us basical
Magnus Hagander wrote:
I suspect we might need to create a pg_off_t type or some such gadget.
Bleah.
But it does need to be fixed.
Bummer. That might be what's needed, but I'm going to at least try to
find some neater way first. I wonder why it didn't happen on MSVC...
Hmm. This
On Mon, 2006-12-18 at 11:13 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I think what you are saying is: VACUUM places blocks so that they are
> > immediately reused. This stops shared_buffers from being polluted by
> > vacuumed-blocks, but it also means that almost every
>> I suspect we might need to create a pg_off_t type or some such gadget.
>>
>> Bleah.
>>
>> But it does need to be fixed.
>
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...
Hmm. This was even worse than
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Is there any special reason why I can't use "Mb" and "Gb" and such
>> for effective_cache_size, the way I can for say shared_buffers?
>
> You can't use "Mb" or "Gb" for shared_buffers either, because those are
> not accepted units.
>
Oh, you m
On Mon, 2006-12-18 at 22:08 +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is there any special reason why I can't use "Mb" and "Gb" and such
> > for effective_cache_size, the way I can for say shared_buffers?
>
> You can't use "Mb" or "Gb" for shared_buffers either, because those are
"Matt Miller" <[EMAIL PROTECTED]> writes:
> Yes, I could not at first apply to REL8_2_0 because the patch file
> wanted to patch src/backend/parser/gram.c. At that point I started over
> with a fresh REL8_2_0, ran "./configure; make", and tried the patch
> again. That's when I got a bunch of fail
Magnus Hagander wrote:
> Is there any special reason why I can't use "Mb" and "Gb" and such
> for effective_cache_size, the way I can for say shared_buffers?
You can't use "Mb" or "Gb" for shared_buffers either, because those are
not accepted units.
--
Peter Eisentraut
http://developer.postgres
"Mike G" <[EMAIL PROTECTED]> writes:
> In the online documentation for 8.2, pg_dump page, --table=table section, in
> the second
> "Note:" paragraph, "rather than the old locution of -n sch -t tab" probably
> should be
> "rather than the old location of -n sch -t tab"
No, locution is a real word
> > The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ...
> > However, the patch will not apply to cvs branch REL8_2_0.
>
> I've been told that the pgcluster patch patches some generated files
> (parse.h and other apparently).
Yes, I could not at first apply to REL8_2_0 because the
Is there any special reason why I can't use "Mb" and "Gb" and such for
effective_cache_size, the way I can for say shared_buffers?
//Magnus
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
h
In the online documentation for 8.2, pg_dump page, --table=table section, in
the second
"Note:" paragraph, "rather than the old locution of -n sch -t tab" probably
should be
"rather than the old location of -n sch -t tab"
Also maybe this section on pg_dump in the release notes page for 8.2 shou
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I just wondered idly if we could piggyback on the existing
> WAKEN_CHILDREN/SIGUSR1 mechanism?
I'd be inclined to keep it separate. There isn't currently any benefit
to merging them, and I think it would convolute the code. In particular
I'm not conv
Tom Lane wrote:
Are we keeping use of SIGUSR2 in this scheme?
What for? Just protect the write pointer with a lwlock and have
listeners check whether somebody has written something.
You do want something comparable to SIGUSR2 to prod active backends to
consume messages, in ca
Matt Miller wrote:
difference between REL8_2_STABLE, REL8_2_0
STABLE doesn't mean static. It's the branch for what will be the
8.1.x series.
Okay, and this is all different from HEAD, which will presumably become
8.3, correct?
Yes. Of course, I should have said 8.2.x above.
c
> > difference between REL8_2_STABLE, REL8_2_0
>
> STABLE doesn't mean static. It's the branch for what will be the
> 8.1.x series.
Okay, and this is all different from HEAD, which will presumably become
8.3, correct?
---(end of broadcast)---
TIP 9:
Matt Miller wrote:
> However, the patch will not apply to cvs branch REL8_2_0. This all
> raises the question: what's the difference between REL8_2_STABLE,
> REL8_2_0, and the 8.2.0 tarball?
REL8_2_0 is the tag from with the 8.2.0 tarball was built.
REL8_2_STABLE is the branch that, having star
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Matt Miller wrote:
>> However, the patch will not apply to cvs branch REL8_2_0. This all
>> raises the question: what's the difference between REL8_2_STABLE,
>> REL8_2_0, and the 8.2.0 tarball?
> STABLE doesn't mean static. It's the branch for what wil
Andrew Dunstan wrote:
> Matt Miller wrote:
> >>When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get
> >>a handful of rejects.
> >
> >The patch applies to the 8.2.0 tarball without rejects and without
> >fuzz. That's good. Now on to some fun with pgcluster...
> >
> >However, the p
Matt Miller wrote:
When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get
a handful of rejects.
The patch applies to the 8.2.0 tarball without rejects and without
fuzz. That's good. Now on to some fun with pgcluster...
However, the patch will not apply to cvs branch REL8_
> When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get
> a handful of rejects.
The patch applies to the 8.2.0 tarball without rejects and without
fuzz. That's good. Now on to some fun with pgcluster...
However, the patch will not apply to cvs branch REL8_2_0. This all
raises t
Tom Lane wrote:
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
I'd like to see something like VACUUM FULL WAIT. :)
Sounds like a deadlock waiting to happen :-(
AFAIK the general practice is to just accept the fact that vacuum can't
remove recently-dead tuples. You should look into whether
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> I'd like to see something like VACUUM FULL WAIT. :)
Sounds like a deadlock waiting to happen :-(
AFAIK the general practice is to just accept the fact that vacuum can't
remove recently-dead tuples. You should look into whether you can't
shorten
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a general strategy out there for removing dead rows on
busy databases? I've learned that both a vacuum and a vacuum full
will not remove dead rows if there is an open transaction anywhere
on the entire cluster. Closing open transactions is n
"Brusser, Michael" <[EMAIL PROTECTED]> writes:
> Can I assume that oid for any new record will be larger than oid on any
> other existing rows?
No; that will fail once the installation has consumed 4G OIDs. The
counter just wraps around.
However, if you pay attention to the OID value returned in
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> I suspect we might need to create a pg_off_t type or some such gadget.
>>> Bleah.
>
>> Bummer. That might be what's needed, but I'm going to at least try to
>> find some neater way first. I wonder why it did
Brusser, Michael wrote:
I ran into a situation with the query that needs to fetch the last
record from the table.
The table schema wasn't really designed to support this, (no serial id,
or anything else I could use)
so SQL makes use of max(create_date) which has a resolution of 1 second
and thus
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I suspect we might need to create a pg_off_t type or some such gadget.
>> Bleah.
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...
Se
I ran into a situation with the query that needs to fetch the last
record from the table.
The table schema wasn't really designed to support this, (no serial id,
or anything else I could use)
so SQL makes use of max(create_date) which has a resolution of 1 second
and thus allows for duplicate value
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> Index: src/bin/pg_dump/pg_dump.h
>> ===
>> RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v
>> retrieving revision 1.130
>> diff -c -r1.130 pg_dump.h
>> *** src/bin/pg_dump
Magnus Hagander wrote:
Index: src/bin/pg_dump/pg_dump.h
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v
retrieving revision 1.130
diff -c -r1.130 pg_dump.h
*** src/bin/pg_dump/pg_dump.h 9 Oct 2006 23:36:59 -
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Not so: consider a backend COPY reading or writing a multi-gig table.
>
> > Good point --- but do we do any seeks in COPY files? I don't think so,
>
> True, so if the problem is limited to whether we can seek or
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not so: consider a backend COPY reading or writing a multi-gig table.
> Good point --- but do we do any seeks in COPY files? I don't think so,
True, so if the problem is limited to whether we can seek or not, then
we don't need to fi
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>> But "opfamid" is a really unfortunate name, because it looks way too
>> much like it's supposed to be the ID of the family itself, rather than
>> of the index AM it's associated with.
> I think by convention it is clear that we are talkin
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> A question though - is there any *gain* from using 64-bit offsets in the
> >> actual backend? The change could of course be done in port.h, but that
>
> > No, not really. All files are kept < 1gig for the
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I think what you are saying is: VACUUM places blocks so that they are
> immediately reused. This stops shared_buffers from being polluted by
> vacuumed-blocks, but it also means that almost every write becomes a
> backend dirty write when VACUUM is workin
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, I suppose. Though starting a second gdb is a pain. What I've done in the
> past is introduce a usleep(3000) in strategic points in the backend to
> give me a chance to attach.
There is already an option to sleep early in backend startup for the
n
On Mon, 2006-12-18 at 11:55 +0900, ITAGAKI Takahiro wrote:
> I'm testing the recently changes of WAL entries for freezing-tuples.
> VACUUM FREEZE took more time. The cause seems to be flushing WAL buffers.
Great thinking.
> Vacuuming processes free buffers into freelist. The buffers in freelist
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> A question though - is there any *gain* from using 64-bit offsets in the
>> actual backend? The change could of course be done in port.h, but that
> No, not really. All files are kept < 1gig for the backend.
Not so: consider a
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I propose that we should set pg_am.amstrategies to zero when the index
>> AM doesn't have a fixed interpretation of strategy numbers. This would
>> make it clearer that there's no intended upper bound. It would also
> Agreed. BTW, that also plays arou
>>> I have tried --with-thread-safety and configure fails on ldap check
>>> because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing
>>> on compile command, although present before that. I can't find why
>>
>> You mean PTHREAD_FLAGS, right?
>>
> Nope,I mean PTHREAD_CFLAGS witch is define
On Mon, Dec 18, 2006 at 09:50:12AM -0500, Bruce Momjian wrote:
> > > Yes, Magnus-san suggested the problem. It is present TODO. The entire
> > > adjustment was still difficult though I had tried it. SetFilePointer
> > > might
> > > be able to be saved. However, I think it might be an attempt o
Hi.
Oh, your great trust confidence.:-)
I have the fix made for just bin/pg_dump for now (in pg_dump.h), and I'm
testing that. (So far only on MSVC builds)
However, MinGW+gcc be able to be saved?
I was wishing it
Regards,
Hiroshi Saito
---(end of broadcast)-
Magnus Hagander wrote:
> On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote:
> >
> > >Win32 does not implement fseeko() and ftello(). So I think it limit to
> > >handle a 2GB file. Is this a specification?
> >
> > Yes, Magnus-san suggested the problem. It is present TODO. The entire
Alvaro Herrera wrote:
Gregory Stark wrote:
I've been fooling with catalog entries here and I've obviously done something
wrong. But I'm a bit frustrated trying to debug initdb. Because of the way it
starts up the database in a separate process I'm finding it really hard to
connect to the data
Hi Albe,
On Mon, 18 Dec 2006, Albe Laurenz wrote:
> Date: Mon, 18 Dec 2006 09:31:35 +0100
> From: Albe Laurenz <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]>
> Cc: pgsql-hackers list
> Subject: RE: [HACKERS] unixware and --with-ldap
>
> >>> If libldap_r.so does require the
On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote:
>
> >Win32 does not implement fseeko() and ftello(). So I think it limit to
> >handle a 2GB file. Is this a specification?
>
> Yes, Magnus-san suggested the problem. It is present TODO. The entire
> adjustment was still difficult th
Gregory Stark wrote:
"Martijn van Oosterhout" writes:
Here's what I did: you can step over functions in initdb until it fails
(although I alredy know which part it's failing I guess). Restart. Then
you go into that function and step until the new backend has been
started. At this point you att
Gregory Stark wrote:
>
> I've been fooling with catalog entries here and I've obviously done something
> wrong. But I'm a bit frustrated trying to debug initdb. Because of the way it
> starts up the database in a separate process I'm finding it really hard to
> connect to the database and get a ba
On Mon, 18 Dec 2006, Gregory Stark wrote:
>
> I've been fooling with catalog entries here and I've obviously done something
> wrong. But I'm a bit frustrated trying to debug initdb. Because of the way it
> starts up the database in a separate process I'm finding it really hard to
> connect to the
On Mon, Dec 18, 2006 at 12:59:28PM +0100, Zeugswetter Andreas ADI SD wrote:
> How do you attach fast enough, so not all is over before you are able to
> attach ?
> I'd like to debug initdb failure on Windows (postgres executable not
> found) when
> running make check with disabled is_admin check a
On 12/18/06, Martijn van Oosterhout wrote:
If you get an error, you put a breakpoint on errfinish(). Note, that
gets called even on messages you don't normally see, so you may have to
skip a couple to get the real message.
You wouldn't need to skip anything if you put the breakpoint inside t
"Martijn van Oosterhout" writes:
> Here's what I did: you can step over functions in initdb until it fails
> (although I alredy know which part it's failing I guess). Restart. Then
> you go into that function and step until the new backend has been
> started. At this point you attach another gdb
> > Are there any tricks people have for debugging bootstrapping
processing? I
> > just need to know what index it's trying to build here and that
should be
> > enough to point me in the right direction:
>
> Here's what I did: you can step over functions in initdb until it
fails
> (although I alr
On Mon, Dec 18, 2006 at 11:35:44AM +, Gregory Stark wrote:
> Are there any tricks people have for debugging bootstrapping processing? I
> just need to know what index it's trying to build here and that should be
> enough to point me in the right direction:
Here's what I did: you can step over
I've been fooling with catalog entries here and I've obviously done something
wrong. But I'm a bit frustrated trying to debug initdb. Because of the way it
starts up the database in a separate process I'm finding it really hard to
connect to the database and get a backtrace. And the debugging log
On Mon, 18 Dec 2006, Martijn van Oosterhout wrote:
On Mon, Dec 18, 2006 at 02:11:42PM +0300, Oleg Bartunov wrote:
Hi there,
I'm a bit confused with the quoting, see below:
contrib_regression=# ALTER OPERATOR CLASS pg_catalog.int4_ops USING btree
OWNER TO megera;
contrib_regression=# ALTER OPE
On Mon, Dec 18, 2006 at 02:11:42PM +0300, Oleg Bartunov wrote:
> Hi there,
>
> I'm a bit confused with the quoting, see below:
>
> contrib_regression=# ALTER OPERATOR CLASS pg_catalog.int4_ops USING btree
> OWNER TO megera;
> contrib_regression=# ALTER OPERATOR CLASS "pg_catalog.int4_ops" USING
Hi there,
I'm a bit confused with the quoting, see below:
contrib_regression=# ALTER OPERATOR CLASS pg_catalog.int4_ops USING btree OWNER
TO megera;
contrib_regression=# ALTER OPERATOR CLASS "pg_catalog.int4_ops" USING btree
OWNER TO megera;
ERROR: operator class "pg_catalog.int4_ops" does no
> pg_opfamily
>
> OID
> opfamid access method OID
> opfname family name
> opfnamespacefamily namespace
> opfownerowner's OID
>
> But "opfamid" is a really unfortunate name, because it looks way too
> much l
I propose that we should set pg_am.amstrategies to zero when the index
AM doesn't have a fixed interpretation of strategy numbers. This would
make it clearer that there's no intended upper bound. It would also
Agreed. BTW, that also plays around possibility of grouping operator classes -
sinc
>>> If libldap_r.so does require the same libs, please add
$EXTRA_LDAP_LIBS
>>> to the 'LDAP_LIBS_FE="-lldap_r"' line as well.
>>
>> Actually, I did that in the patch-as-committed. It seems to me that
>> it's probably harmless even if not needed.
>
> I have tried --with-thread-safety and configure
75 matches
Mail list logo
