I tried running 'make installcheck' in contrib just now, and didn't
get past btree_gist :-(
The interval test fails with the attached diffs. text, varchar, char,
bytea, bit, varbit and numeric either dump core or go into infinite
loops during CREATE INDEX. (It's probably significant that these a
On Tue, 2004-06-01 at 01:33, Tom Lane wrote:
> First you might want to check which flavor of strerror_r() your platform
> has --- does it return int or char* ? The Linux man page for
> strerror_r() says
>From the definition in /usr/include/string.h, glibc 2.3.2 still has the
version that returns
Alvaro Herrera wrote:
Hackers,
Is there a way to add the current transaction nesting level in the be/fe
protocol without breaking compatibility? AFAICS the ReadyForQuery
message is not expansible (sp?) :-(
Perhaps you could treat the nesting level as a runtime parameter and
generate a ParameterSt
I was playing with PL/pgSQL functions that would start and commit
transactions and got very weird behavior. First I just take the check
for TransactionStmt off, so I could execute them. With this change I
can write a function that opens a subtransaction, and it works, sort of;
I can open a subtra
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > So I disagree with the premise. Measuring these things in KB is not an
> > improvement.
>
> I agree, although I think changing effective_cache_size to be measured in KB/MB
> is worth doing.
I have to say as a user the parameters that
Hackers,
Is there a way to add the current transaction nesting level in the be/fe
protocol without breaking compatibility? AFAICS the ReadyForQuery
message is not expansible (sp?) :-(
--
Alvaro Herrera ()
"The problem with the future is that it keeps turning into the present"
(Hobbes)
---
Oliver Jowett <[EMAIL PROTECTED]> writes:
> I have a patch for delayed planning of unnamed statements when using the
> extended query protocol that's in need of review:
Right, I have it on my to-do list.
regards, tom lane
---(end of broadcast)
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> A completely different idea would be to log a "logical index creation",
> so that during normal recovery those entries are saved somewhere; after
> the rest of WAL recovery is done, the system is taken into a more normal
> post-recovery pre-usable state,
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> So AFAICS, we've got to dump the index contents into WAL to support
>> PITR. This is a tad annoying.
> Is it possible in this case to dump the index block by block into the log
> after it has been generated?
That's what we do now, and it more or less d
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> what is wrong with just going:
> wal_sync_method = fsync
> fsync = false
fsync = false causes wal_sync_method to be ignored. You get no syncing.
regards, tom lane
---(end of broadcast)
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume if someone turns on archiving in postgresql.conf, sighups the
> > postmaster, then does a tar backup, they should be able to do archiving,
> > no?
>
> I would have zero problem with labeling the archive parameter as
> changea
On Tue, Jun 01, 2004 at 11:34:15AM +1000, Gavin Sherry wrote:
> On Mon, 31 May 2004, Tom Lane wrote:
>
> > I thought for a little bit about a magic "reconstruct the index" WAL
> > entry that would invoke the index build procedure in toto, but that
> > doesn't look like it will fly either. (Two pr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume if someone turns on archiving in postgresql.conf, sighups the
> postmaster, then does a tar backup, they should be able to do archiving,
> no?
I would have zero problem with labeling the archive parameter as
changeable only at postmaster start.
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The code we have appears to assume that the result will always be placed
>> in the user-supplied buffer, which is apparently NOT what the glibc
>> version does.
> What does "may, but need not, use the user-supplied buffer" supposed to
> mean in practica
Tom Lane writes:
> Hm, is this a Windows box? We already suspected that we'd
> have to fudge on matching the timezone abbreviations on Windows ..,
In my case, yes, Win XP.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these
Tom Lane wrote:
So I disagree with the premise. Measuring these things in KB is not an
improvement.
I agree, although I think changing effective_cache_size to be
measured in KB/MB is worth doing.
-Neil
---(end of broadcast)---
TIP 9: the planner wi
Christopher Kings-Lynne wrote:
> > What I'm thinking about right now is tweaking the index-build code to
> > write to WAL only if it sees that PITR is actually in use. It would
> > have to look at the GUC variables to determine whether WAL archiving
> > is enabled. If archiving isn't turned on, t
Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> >> I can't duplicate that here. It looks to me like the probable
> >> explanation is a broken or incompatible version of strerror_r() on your
> >> machine. Does the failure go away if y
What I'm thinking about right now is tweaking the index-build code to
write to WAL only if it sees that PITR is actually in use. It would
have to look at the GUC variables to determine whether WAL archiving
is enabled. If archiving isn't turned on, then we could assume that
rollforward from a pas
Christopher Kings-Lynne wrote:
> Hi,
>
> I had this question posed to me on IRC and I didn't know the answer.
>
> If all that is needed to ensure integrity is that the WAL is fsynced,
> what is wrong with just going:
>
> wal_sync_method = fsync
> fsync = false
wal_sync_method is only used if f
Claudio Natoli <[EMAIL PROTECTED]> writes:
> In my case, one of these should be right:
> DEBUG: Reject TZ "Australia/NSW": at 1086048000 "EST" versus "AUS Eastern
> Standard Time"
> DEBUG: Reject TZ "Australia/Sydney": at 1086048000 "EST" versus "AUS
> Eastern Standard Time"
Hm, is this a Win
Marc G. Fournier wrote:
If anyone is working on other features that they feel can be polished
off before the July 1st deadline, we would be most happy to incorporate
those as well, but do recommend submitting patches for review *sooner*,
rather then later, so that any recommended corrections can
On Mon, 31 May 2004, Tom Lane wrote:
[snip]
> I thought for a little bit about a magic "reconstruct the index" WAL
> entry that would invoke the index build procedure in toto, but that
> doesn't look like it will fly either. (Two problems: during crash
> recovery, you couldn't be sure that what'
Hi,
I had this question posed to me on IRC and I didn't know the answer.
If all that is needed to ensure integrity is that the WAL is fsynced,
what is wrong with just going:
wal_sync_method = fsync
fsync = false
??
Chris
---(end of broadcast)---
TIP
> So what *is* your zone, exactly? I don't see how you expect us to
> figure out why it's not matching when we don't know what it's not
> matching.
In my case, one of these should be right:
DEBUG: Reject TZ "Australia/NSW": at 1086048000 "EST" versus "AUS Eastern
Standard Time"
DEBUG: Rejec
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
>> I can't duplicate that here. It looks to me like the probable
>> explanation is a broken or incompatible version of strerror_r() on your
>> machine. Does the failure go away if you build without thread-sa
I was just about to commit a patch that revises the btree index build
procedure as discussed here:
http://archives.postgresql.org/pgsql-general/2004-05/msg00480.php
specifically, not using shared buffers during index build and bypassing
WAL-logging in favor of just fsyncing the index file before co
Harald Fuchs wrote:
Why don't you just do
( echo "-- This is my comment"
pg_dump whatever
) > dumpfile
?
How could I dump using the custom format, and then use "dumpfile" with
pg_restore to restore the dump? If I just prepend the comment to the
file, then pg_restore will choke, since the
The world rejoiced as [EMAIL PROTECTED] (Greg Stark) wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
>> Greg Stark <[EMAIL PROTECTED]> writes:
>> > This is the only place where I see hardly any movement on major
>> > items the whole development cycle, then a rush of radical changes
>> > just before
Hello Experts,
Trying to run sample Postgrel's ECPG(Embedded
SQL)programs on RHL 9.0.
Im unable to connect to PostgreSQL database (sirishadb) when I run
the program
# su postgres (enter)
# /usr/bin/ecpg -t -I/usr/include/pgsql/sample1.pgc (enter)
# gcc -g -o sample1 -I /us
On Saturday 29 May 2004 18:10, [EMAIL PROTECTED] wrote:
> Having internal PostgreSQL variables that are not present on disk, or
> maybe, variables that are mirrored on disk may be good.
Yes. I agree. I can see why you proposed no transactions few posts ago. Take
an example of a count variable. It
On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > 1. There are regression failures on timestamptz and horology which seem
> > to have come about either on input or output of timestamps with
> > fractional seconds.
>
> I believe I've fixed this.
All reg
On Mon, 2004-05-31 at 19:09, Marc G. Fournier wrote:
> Although we feel that there are enough improvements and features already
> in place for 7.5, Tom's felt that if we gave it that extra month, we could
> also have PITR in place for 7.5 ...
>
You have my full support and commitment for 1 July
> Hello I have my data base postgresql installed in linux, but when I want
> to
> make consultations by means of php does not respond to me and it generates
> following mensage to me.
>
> Call to undefined function: pg_connect()
>
>
This really isn't the right group for this, but, you need to make
> [EMAIL PROTECTED] wrote:
>
>>
>>What you are missing is that the RAID is dealing with the multiple drives
>>as one drive. Two operations have to happen serially,
>>
>
> You're kidding or vastly underestimating raid controllers. The average
> db access is well served with a single block of data, s
> Dear anonymous,
>
> This is really making me tired, and still OT. May anybody interested
> read the document you're citing abusively, or believe you that storage
> controllers are only capable of one command at a time or not.
I would say this is totally off topic except that it does present opin
Dear anonymous,
This is really making me tired, and still OT. May anybody interested
read the document you're citing abusively, or believe you that storage
controllers are only capable of one command at a time or not.
Regards,
Andreas
---(end of broadcast)---
> [EMAIL PROTECTED] wrote:
>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
>>>
What you are missing is that the RAID is dealing with the multiple
drives
as one drive. Two operations have to happen serially,
>>>You're kidding or vastly underestimating raid controllers. The average
[EMAIL PROTECTED] (Bruce Momjian) wrote:
> Win32 has 98% of its code in CVS, so it will make it
> Tablespaces - Christopher says it is ready, and has run tests
> PITR - some functionality might be in 7.5, but we aren't sure
> Nested transactions - Alvaro thinks it is close,
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
What you are missing is that the RAID is dealing with the multiple drives
as one drive. Two operations have to happen serially,
You're kidding or vastly underestimating raid controllers. The average
db access is well served with a single
[EMAIL PROTECTED] wrote:
What you are missing is that the RAID is dealing with the multiple drives
as one drive. Two operations have to happen serially,
You're kidding or vastly underestimating raid controllers. The average
db access is well served with a single block of data, stored on a single
> [EMAIL PROTECTED] wrote:
>
>>
>>As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
>>expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
>>rocks.
>>
>>
>
> Obviously, you're caught by those marketing geeks. You're taking
> bandwidth (MB/s)as performance index
[EMAIL PROTECTED] wrote:
As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
rocks.
Obviously, you're caught by those marketing geeks. You're taking
bandwidth (MB/s)as performance index, which is irrelevant
Hello I have my data base postgresql installed in linux, but when I want to
make consultations by means of php does not respond to me and it generates
following mensage to me.
Call to undefined function: pg_connect()
---(end of broadcast)---
TIP 1
On Fri, 2004-05-28 at 08:15, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>You are absolutely wrong on all accounts here. A RAID5 system is slower
> >>than a single spindle as it is only as fast as the slowest disk in the
> >>stripe and the overhead of the RAID.
> >>
> > Huh, what k
Quoth [EMAIL PROTECTED] (Christopher Kings-Lynne):
>> Ingres is to be released as open source:
>>
>> http://developers.slashdot.org/article.pl?sid=04/05/25/0043219&mode=nested&tid=126&tid=137&tid=163&tid=185&tid=198
>
> Like the article says, I wonder if these is any synergy between the
> products.
Oliver Elphick <[EMAIL PROTECTED]> writes:
> 1. There are regression failures on timestamptz and horology which seem
> to have come about either on input or output of timestamps with
> fractional seconds.
I believe I've fixed this.
> 2. If the postmaster is not running, there is garbage in psql
Just so that everyone is aware, we are going to push the freeze date for
7.5 to July 1st.
Although we feel that there are enough improvements and features already
in place for 7.5, Tom's felt that if we gave it that extra month, we could
also have PITR in place for 7.5 ...
If anyone is working
7.4, on not finding a postmaster:
[EMAIL PROTECTED] pgsql]$ pg_ctl stop
/home/tgl/version74/bin/pg_ctl: line 274: kill: (15273) - No such process
waiting for postmaster to shut
down failed
pg_ctl: postmaster does not shut down
CVS t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Any reason why postgres can't detect time zone on my machine
> automatically?
>> I'm guessing the TZ code isn't identifying Aussie timezones.
So what *is* your zone, exactly? I don't see how you expect us to
figure out why it's not matching
Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > Right now following are measured in pages
> > wal_buffers
> > shared_buffers
> > effective_cachesize
> > while rest of the memory parameters are in kb. I thought being uniform would
> > be good. Besides it will make it indepen
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Right now following are measured in pages
> wal_buffers
> shared_buffers
> effective_cachesize
> while rest of the memory parameters are in kb. I thought being uniform would
> be good. Besides it will make it independent of page size as well.
It
Shridhar Daithankar wrote:
> On Sunday 30 May 2004 19:37, Bruce Momjian wrote:
> > > The relevant configure messages read
> > > -
> > > checking whether pthreads work without any flags... no
> > > checking whether pthreads work with -Kthread... no
> > > checking whether pthreads work wi
On Sunday 30 May 2004 19:37, Bruce Momjian wrote:
> > The relevant configure messages read
> > -
> > checking whether pthreads work without any flags... no
> > checking whether pthreads work with -Kthread... no
> > checking whether pthreads work with -kthread... no
> > checking for the
Looking forward to see it work on WIN32 !
Regards !
On Monday 31 May 2004 15:32, Teodor Sigaev wrote:
> Commited, thank you.
> I don't apply Makefile changes, becouse symbol links to pg_reg* functions
> will be resolved at runtime. And I did some small chenges in spell.c (add
> pg_wchar convers
On Monday 31 May 2004 18:41, Bruce Momjian wrote:
> Shridhar Daithankar wrote:
> > On Sunday 30 May 2004 21:33, Tom Lane wrote:
> > > Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > > > I was toying around with idea of converting all the memory related
> > > > parameters in postgresql.conf to k
Jan Wieck wrote:
> This can be accomplished with 10-20 lines of shell scripting. I don't
> think it's worth the trouble bloating pg_dump with it at all.
Considering how much bloat -v adds, adding a datestamp to it is trivial.
-v outputs things like:
--
-- TOC entry 1449
Commited, thank you.
I don't apply Makefile changes, becouse symbol links to pg_reg* functions will
be resolved at runtime. And I did some small chenges in spell.c (add pg_wchar
conversion to regcomp call).
Darko Prenosil wrote:
Here:
http://archives.postgresql.org/pgsql-hackers-win32/2004-05/m
On 5/28/2004 2:52 PM, Alvaro Herrera wrote:
On Fri, May 28, 2004 at 01:43:16PM -0400, Bruce Momjian wrote:
In this case, I want to try all of the inserts, but any of them can
fail, then I want the bottom part done.
I wonder where everyone eas when I asked this question a lot of time
ago. I said I
Shridhar Daithankar wrote:
> On Sunday 30 May 2004 21:33, Tom Lane wrote:
> > Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > > I was toying around with idea of converting all the memory related
> > > parameters in postgresql.conf to kilobytes for simplicity and
> > > uniformity.
> >
> > Why is
This can be accomplished with 10-20 lines of shell scripting. I don't
think it's worth the trouble bloating pg_dump with it at all.
Jan
On 5/27/2004 10:10 PM, Chris Campbell wrote:
I've encountered a situation where I'd like to store some information
about the database when I do a pg_dump. For i
Any reason why postgres can't detect time zone on my machine
automatically?
I'm guessing the TZ code isn't identifying Aussie timezones. I'm getting the
same message, albeit Etc/GMT-10. If anyone who hacked on the TZ code
(Magnus, Bruce, ...) wants me to add a few printfs to trace this down, ple
On Sunday 30 May 2004 21:33, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > I was toying around with idea of converting all the memory related
> > parameters in postgresql.conf to kilobytes for simplicity and
> > uniformity.
>
> Why is that a good idea?
Right now following a
Here:
http://archives.postgresql.org/pgsql-hackers-win32/2004-05/msg00125.php
I', not shure about Makefile changes, because I think Makefiles for contrib
were changed since then.
Regards !
On Monday 31 May 2004 04:48, Oleg Bartunov wrote:
> On Sun, 30 May 2004, Darko Prenosil wrote:
> > Oleg ca
Christopher Kings-Lynne writes:
> Any reason why postgres can't detect time zone on my machine
> automatically?
>
> LOG: could not recognize system timezone, defaulting to "Etc/GMT-8"
> HINT: You can specify the correct timezone in postgresql.conf.
> postmaster starting
> -bash-2.05b$ LOG: d
Any reason why postgres can't detect time zone on my machine automatically?
LOG: could not recognize system timezone, defaulting to "Etc/GMT-8"
HINT: You can specify the correct timezone in postgresql.conf.
postmaster starting
-bash-2.05b$ LOG: database system was shut down at 2004-05-31 15:19:0
66 matches
Mail list logo
