On Tuesday 01 March 2005 12:46, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This has to be coming from exec_simple_query():
> >
> > I wonder if some statistics were turned on at postmaster start and even
> > though it was turned off and 'pg_ctl reload' was done the
> > checkpo
On Tuesday 01 March 2005 18:16, Gavin Sherry wrote:
> On Tue, 1 Mar 2005, Joshua D. Drake wrote:
> > Hello,
> >
> > I am looking at having one of our guys write up the code to allow
> > logging as insert statements. I have a couple of questions.
> >
> > What would we like the postgresql.conf option
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Does it help if you flip the order of the snprintf and vsnprintf
> > >> functions in snprintf.c?
> >
> > > Yes, it fixes the problem and I have applied the reordering with a
> > > comment.
> >
> > Fasci
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Does it help if you flip the order of the snprintf and vsnprintf
> >> functions in snprintf.c?
>
> > Yes, it fixes the problem and I have applied the reordering with a
> > comment.
>
> Fascinating.
>
> > I will start working on fi
Bruce Momjian writes:
> Tom Lane wrote:
>> Does it help if you flip the order of the snprintf and vsnprintf
>> functions in snprintf.c?
> Yes, it fixes the problem and I have applied the reordering with a
> comment.
Fascinating.
> I will start working on fixing the large fmtpar allocations now.
Tom Lane wrote:
> Bruce Momjian writes:
> > I think this means it is finding our /port/snprintf(), but when it calls
> > vsnprintf, it must be using some other version, probably the operating
> > system version that doesn't support %lld.
>
> Ya know, I was wondering about that but dismissed it be
Tom Lane wrote:
> Bruce Momjian writes:
> > I think this means it is finding our /port/snprintf(), but when it calls
> > vsnprintf, it must be using some other version, probably the operating
> > system version that doesn't support %lld.
I can confirm that using "%I64d" for the printf format allo
Bruce Momjian writes:
> I think this means it is finding our /port/snprintf(), but when it calls
> vsnprintf, it must be using some other version, probably the operating
> system version that doesn't support %lld.
Ya know, I was wondering about that but dismissed it because the
routines were all
I have some new information. If I add the attached patch to snprintf.c,
I should see see snprintf() being called printing "0", vsnprintf()
printing "1" and dopr(), "2". However, I only see "0" printing in the
server logs.
I think this means it is finding our /port/snprintf(), but when it calls
v
Nicolai Tufar wrote:
> On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Nicolai Tufar <[EMAIL PROTECTED]> writes:
> > Just out of curiosity, do either HAVE_INT64 or HAVE_UINT64 get set
> > in pg_config.h? The observed symptoms would be explained if typedef
> > int64 were
I have a feeling Bruce was referring to item 1.4:
http://developer.postgresql.org/readtext.php?src/FAQ/
FAQ_DEV.html+Developers-FAQ#1.4
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-
Bruce Momjian wrote:
Have you read the developer's FAQ. It is a requirement to get involved.
How does the developer's FAQ address this concern?
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Tue, 1 Mar 2005, Joshua D. Drake wrote:
> Hello,
>
> I am looking at having one of our guys write up the code to allow
> logging as insert statements. I have a couple of questions.
>
> What would we like the postgresql.conf option to be? I was thinking
> log_statements_as_inserts = (t/f)
>
> Ho
On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane > Just out of curiosity,
do either HAVE_INT64 or HAVE_UINT64 get set
> in pg_config.h?
pg_config.h is attached. What drew my attention is the
following declaration:
/* Define to 1 if `long long int' works and is 64 bits. */
#define HAVE_LONG_LONG_INT
Nicolai Tufar <[EMAIL PROTECTED]> writes:
> Amazingly enough HAVE_LONG_LONG_INT_64 is
> defined when compilation comes to src/port/snprintf.c
> but the result is still wrong. I looked into configure.in
> but the check for HAVE_LONG_LONG_INT_64 is too
> complicated for me to understand. Bruce, could
On Tue, 1 Mar 2005 16:20:50 -0500 (EST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Well, here is a stupid question, do we even know which snprintf we are
> using on Win32? May it be possible that we are using the MingW version
> which may be broken?
Defenitely not. I checked it by placing
Hello,
I am looking at having one of our guys write up the code to allow
logging as insert statements. I have a couple of questions.
What would we like the postgresql.conf option to be? I was thinking
log_statements_as_inserts = (t/f)
However I thought that was getting a little silly. Also do we
Mark Wong <[EMAIL PROTECTED]> writes:
> On Tue, Mar 01, 2005 at 04:57:11PM -0500, Tom Lane wrote:
>> Curious. The immediate question is "does it ever flatten out, and
>> if so at what TPM rate compared to 8.0.1?" Could you run the same
>> test for a longer duration?
> The comparison was against
On Tue, Mar 01, 2005 at 04:57:11PM -0500, Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > About a 6% increase, but if you look at the performance over time,
> > it's degrading steadily. The latter throughput peaks near 5000.
>
> Curious. The immediate question is "does it ever flatte
On Thu, Feb 03, 2005 at 07:25:55PM +0900, ITAGAKI Takahiro wrote:
> Hello everyone.
>
> I fixed two bugs in the patch that I sent before.
> Check and test new one, please.
Ok, finally got back into the office and was able to run 1 set of
tests.
So the new baseline result with 8.0.1:
http
Mark Wong <[EMAIL PROTECTED]> writes:
> About a 6% increase, but if you look at the performance over time,
> it's degrading steadily. The latter throughput peaks near 5000.
Curious. The immediate question is "does it ever flatten out, and
if so at what TPM rate compared to 8.0.1?" Could you run
On Sat, Feb 19, 2005 at 12:57:52AM -0500, Tom Lane wrote:
> So far I've not been able to measure any consistent difference, but you
> know how much I trust pgbench ;-). I hope that Mark Wong can give us
> some results on the OSDL setup soon.
Sorry for the delay, broken laptop, vacation, etc.
Her
[EMAIL PROTECTED] writes:
> Well, here is a stupid question, do we even know which snprintf we are
> using on Win32? May it be possible that we are using the MingW version
> which may be broken?
The regression tests were not failing until we started using the port/
version ...
> On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Is there a reason why we don't use the snprintf that comes with the
>> various C compilers?
>
> snprintf() is usually buried in OS libraries. We implement
> our own snprintf to make things like this:
> snpr
On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Is there a reason why we don't use the snprintf that comes with the
> various C compilers?
snprintf() is usually buried in OS libraries. We implement
our own snprintf to make things like this:
snprintf(buf,"%2$
>> I spent all day debugging it. Still have absolutely
>> no idea what could possibly go wrong. Does
>> anyone have a slightest clue what can it be and
>> why it manifests itself only on win32?
>
>It may be that the CLIB has badly broken support for 64bit
>integers on 32
>bit platforms. Does anyo
> I spent all day debugging it. Still have absolutely
> no idea what could possibly go wrong. Does
> anyone have a slightest clue what can it be and
> why it manifests itself only on win32?
It may be that the CLIB has badly broken support for 64bit integers on 32
bit platforms. Does anyone know o
[EMAIL PROTECTED] writes:
> Just a question, and don't mind me if I am being rude, isn't this the
> WRONG PLACE for a "printf" function? Wouldn't an "itoa" function be more
> efficient and be less problematic?
This particular call could be so replaced, but it wouldn't solve the
general problem. s
> Nicolai Tufar wrote:
>> On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
>> > My next guess
>> > is that Win32 isn't handling va_arg(..., long long int) properly.
>> >
>>
>> I am trying various combination of number and types
>> of parameters in my test program and everything prints fine.
>
I spent all day debugging it. Still have absolutely
no idea what could possibly go wrong. Does
anyone have a slightest clue what can it be and
why it manifests itself only on win32?
On Tue, 1 Mar 2005 09:29:07 -0500 (EST), Bruce Momjian
wrote:
> Nicolai Tufar wrote:
> > On Tue, 1 Mar 2005 00:55:
OK, lets step back a bit and see if there is a solution that fits what we
think we need and PostgreSQL.
Lets talk about FTSS, its something I can discuss easily. It is a two
stage system with an indexer and a server. Only the data to be indexed is
in the database, all the FTSS data structures are
* Tom Lane <[EMAIL PROTECTED]> [01.03.2005 21:07]:
> Hmm, you seem to be envisioning that these are actually lists, not
> arrays --- that is, to find the N'th page in a list requires traversing
> list links starting at the first page. That doesn't sound workable.
> If you can't access all the entr
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> All lists (list of ctids, bitmaps) will only grow, no data will be
> deleted, as deletes will require relocation and possibly exclusive
> lock on the index.
> Extending lists will need only a short-term exclusive locks on the pages in
> the tails of
[EMAIL PROTECTED] writes:
> A "persistent reference" index would be like almost any other index except
> that as new items are added to a table a new entry is added to the end of
> the index. When a row is updated, its CTID is updated in the table.
This *does not work* under MVCC: it can't cope wi
Have you read the developer's FAQ. It is a requirement to get involved.
---
Matthias Schmidt wrote:
> Hi *,
>
> I have submitted a patch which does exactly this. Somebody edited it
> and Bruce put it on
> the queue for 8.
--- Oliver Jowett <[EMAIL PROTECTED]> escreveu:
> Francisco Figueiredo Jr. wrote:
>
> > After some testing, I could send an Execute message with 2 as the manx
> > number of rows. After the second execute I get the following:
> >
> > portal "" does not exist
> > Severity: ERROR
> > Code: 34000
>
> [EMAIL PROTECTED] writes:
>> Tom, I posted a message about a week ago (I forget the name) about a
>> persistent reference index, sort of like CTID, but basically a table
>> lookup. The idea is to simulate a structure that ISAM sort of techniques
>> can work in PostgreSQL.
>
>> Eliminating the bit
[EMAIL PROTECTED] writes:
> Tom, I posted a message about a week ago (I forget the name) about a
> persistent reference index, sort of like CTID, but basically a table
> lookup. The idea is to simulate a structure that ISAM sort of techniques
> can work in PostgreSQL.
> Eliminating the bitmap inde
Hi *,
I have submitted a patch which does exactly this. Somebody edited it
and Bruce put it on
the queue for 8.1.
Now we both did the same work twice. This is a good example how a
public accessible
Bugtracker and TODO-List where one can claim things (or get assigned to
some workitem)
can save v
* Tom Lane <[EMAIL PROTECTED]> [01.03.2005 09:37]:
> The other stuff you mentioned implies that an insertion therefore
> requires exclusive lock on the index (because you may have to relocate
> everything in sight to add one more CTID slot).
No, exclusive lock on index is worst thing to do.
All l
Bruce Momjian writes:
> Tom Lane wrote:
>> This has to be coming from exec_simple_query():
> I wonder if some statistics were turned on at postmaster start and even
> though it was turned off and 'pg_ctl reload' was done the
> checkpoint/bgwriter process isn't reloading for some reason.
The chec
I have a server running 7.4 that has an index file that's kind of
floating in limbo, not attached to anything. When I try to drop it, I
get the following:
ERROR: could not open relation with OID 2293160133
The OID of the table that it should be attached to is 2300667425, so it
might still thi
Nicolai Tufar wrote:
> On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
> > My next guess
> > is that Win32 isn't handling va_arg(..., long long int) properly.
> >
>
> I am trying various combination of number and types
> of parameters in my test program and everything prints fine.
> When
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I keep seeing the following log output around every 5 minutes:
> > 2005-02-28 23:25:05 [8646] LOG: 0: QUERY STATISTICS
>
> This has to be coming from exec_simple_query():
>
> if (save_log_statement_stats)
> Sh
On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
> My next guess
> is that Win32 isn't handling va_arg(..., long long int) properly.
>
I am trying various combination of number and types
of parameters in my test program and everything prints fine.
When it comes to pg, it fails :(
> >
> I don't think we really need any more fundamentally nonconcurrent index
> types :-(
>
Tom, I posted a message about a week ago (I forget the name) about a
persistent reference index, sort of like CTID, but basically a table
lookup. The idea is to simulate a structure that ISAM sort of technique
> Thanks very much for doing this work. Is there some way you can
> summarize what you did so others can join you in working on it? If it
> is easier for you to write this in some language other than English,
> please do, and we'll find translators :)
>
> I noticed that the patch touches the par
> > Ok, I'm started porting it to 8.0.1 and will fix this also.
> > By the way, did you know any test suit for such queries? To make some
> > regression test.
> >
> Hello, I can find some examples on internet and prepare regression tests.
> I think PostgreSQL can support all syntax H.Q. Is more eas
48 matches
Mail list logo
