I recently posted a patch to pg_regress to limit
parallelism for cygwin to a maximum of 10, so that "make check" could
succeed. Tom preferred that this should be settable by the user explicitly
rather than hard coded (and hidden), and not limited by platform, so that you
could say
make M
Only regproc adds the unnecessary pg_catalog. qualification, why is that?
Er, I couldn't see the part of your example where that happened?
Basically, my question is why ::regproc alone always addes the catalogue
qualification in this case?
Rows below correspond to:
::regtype
::regtype
::regpro
Oops, I have two words for you, "yesterday" and "tomorrow". ;-)
Seems the problem spans almost three days.
---
Christopher Kings-Lynne wrote:
> I thought you said that yesterday?
>
> Chris
>
> Bruce Momjian wrote:
>
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We only have a few open items left. Can we finish them so we can move
> > toward final release?
>
> Okay, here's my two cents:
>
> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> > constraints/triggers, n
er, plus 3 hours, I think, i.e. just under 2 hours from now ... (unless you
posted this in the future :-) )
[EMAIL PROTECTED] andrew]$ TZ=PST8PDT date
Mon Oct 27 22:07:22 PST 2003
[EMAIL PROTECTED] andrew]$ date
Tue Oct 28 01:07:28 EST 2003
[EMAIL PROTECTED] andrew]$
cheers
andrew
- Origi
what about my Privilege regression failure?
I'm not sure why it's dying...
LER
--On Monday, October 27, 2003 23:32:45 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
We only have a few open items left. Can we finish them so we can move
toward final release?
Thiago Fernandes Moesch wrote:
It would be great for maintainance if every object had a timestamp of
the last vaccum run on it. From time to time we're working with several
databases and I can't tell wich one needs a new vacuum.
Another important information would be the rate of disposable data
Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
What are (more) reasons for not adding transaction information to
index tuple, in addition to heap tuple?
Cons are bloated indexes. The index tuple size will be close to 30
bytes minimum.
And extra time to perform an update or del
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Only regproc adds the unnecessary pg_catalog. qualification, why is that?
Er, I couldn't see the part of your example where that happened?
regards, tom lane
---(end of broadcast)
Marc G. Fournier wrote:
>
>
> > On Mon, 27 Oct 2003, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > >
> > > >
> > > > On Mon, 27 Oct 2003, Bruce Momjian wrote:
> > > >
> > > > > Changes
> > > > > ---
> > > > > Allow superuser (dba?) the ability to turn off foreign key checks/all
I said:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I'm still seeing Horology failures on FreeBSD 4.9...
> Should stop at midnight Tuesday, PST8PDT time (about 45 minutes
> from now) ... see prior discussion ...
Argh ... make that "3 hours from now" ... you'd think I could remember
t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We only have a few open items left. Can we finish them so we can move
> toward final release?
Okay, here's my two cents:
> Allow superuser (dba?) the ability to turn off foreign key checks/all
> constraints/triggers, not settable from postgresql.conf
> On Mon, 27 Oct 2003, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > >
> > >
> > > On Mon, 27 Oct 2003, Bruce Momjian wrote:
> > >
> > > > Changes
> > > > ---
> > > > Allow superuser (dba?) the ability to turn off foreign key checks/all
> > > > constraints/triggers, not settable fr
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I'm still seeing Horology failures on FreeBSD 4.9...
Should stop at midnight Tuesday, PST8PDT time (about 45 minutes
from now) ... see prior discussion ...
regards, tom lane
---(end of broadcast
On Mon, 27 Oct 2003, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> >
> >
> > On Mon, 27 Oct 2003, Bruce Momjian wrote:
> >
> > > Changes
> > > ---
> > > Allow superuser (dba?) the ability to turn off foreign key checks/all
> > > constraints/triggers, not settable from postgresql.conf?
> >
I thought you said that yesterday?
Chris
Bruce Momjian wrote:
Time zone changes --- will be OK tomorrow.
---
Christopher Kings-Lynne wrote:
I'm still seeing Horology failures on FreeBSD 4.9...
See attached diff.
Chris
On Mon, Oct 27, 2003 at 07:45:53PM -0800, Joshua D. Drake wrote:
> Hello,
>
> Well the reason I brought it up was the rather interesting discussion
> that Jan had today about Vacuum.
> I was wondering if we were going to explore that before the 7.4 release?
I would expect that to be left for 7.
Joshua D. Drake wrote:
> Hello,
>
> Well the reason I brought it up was the rather interesting discussion
> that Jan had today about Vacuum.
> I was wondering if we were going to explore that before the 7.4 release?
No, I am afraid we are way past time time for that kind of addition.
--
Br
When you do this query:
SET SEARCH_PATH TO pg_catalog;
SELECT castsource::pg_catalog.regtype AS castsource,
casttarget::pg_catalog.regtype AS casttarget,
castfunc::pg_catalog.regprocedure AS castfunc,
castfunc::pg_catalog.regproc AS castfunc2 FROM pg_catalog.pg_cast ORDER
BY 1, 2;
Only regpr
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
Sincerely,
Joshua Drake
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Joshua D. Drake
Marc G. Fournier wrote:
>
>
> On Mon, 27 Oct 2003, Joshua D. Drake wrote:
>
> > Hello,
> >
> > Based on the current open items... when do we expect release?
>
> As soon as the items are fixed? :)
I am confused why we aren't wrapping up these items. I have waited for
the people who proposed
Time zone changes --- will be OK tomorrow.
---
Christopher Kings-Lynne wrote:
> I'm still seeing Horology failures on FreeBSD 4.9...
>
> See attached diff.
>
> Chris
>
> *** ./expected/horology.out Thu Sep 25 14:58:06
On Mon, 27 Oct 2003, Joshua D. Drake wrote:
> Hello,
>
> Based on the current open items... when do we expect release?
As soon as the items are fixed? :)
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropr
I'm still seeing Horology failures on FreeBSD 4.9...
See attached diff.
Chris
*** ./expected/horology.out Thu Sep 25 14:58:06 2003
--- ./results/horology.out Tue Oct 28 11:29:24 2003
***
*** 577,583
SELECT (timestamp with time zone 'today' = (timestamp with time zone
Hello,
Based on the current open items... when do we expect release?
Sincerely,
Joshua Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandpro
Marc G. Fournier wrote:
>
>
> On Mon, 27 Oct 2003, Bruce Momjian wrote:
>
> > Changes
> > ---
> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> > constraints/triggers, not settable from postgresql.conf?
>
> feature, not bug fix, no?
It became important when ever
On Mon, 27 Oct 2003, Bruce Momjian wrote:
> Changes
> ---
> Allow superuser (dba?) the ability to turn off foreign key checks/all
> constraints/triggers, not settable from postgresql.conf?
feature, not bug fix, no?
---(end of broadcast)---
We only have a few open items left. Can we finish them so we can move
toward final release?
---
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://mo
Bruce Momjian wrote:
Jan Wieck wrote:
> In fact, even though I was debugging the backend regularly, I removed -g
> and added it only when I wanted to debug.
>
It did somethimes in the past proove to be good luck to have symbols in
a core file accidentially. If you want to find them in an arbitra
However, you're not the first to get burnt by this mis-assumption,
so maybe we should do something about it.
The low-tech solution to this would be to stop listing the default
values as commented-out entries, but just make them ordinary uncommented
entries. That way people who think "undoing my ed
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> So it would appear to be that the automatic assumptions about what is
> float and what is numeric changed from 7.2 to 7.3, i.e. it's assumed that
> numeric is the input type.
That's correct.
Looking at the code, round(numeric) always rounds xxx.5 va
Jan Wieck wrote:
> > In fact, even though I was debugging the backend regularly, I removed -g
> > and added it only when I wanted to debug.
> >
>
> It did somethimes in the past proove to be good luck to have symbols in
> a core file accidentially. If you want to find them in an arbitrary out
>
Bruce Momjian wrote:
pgman wrote:
Jan Wieck wrote:
> >> >> > What Peter was advocating in that thread was that we enable -g by
> >> >> > default *when building with gcc*. I have no problem with that, since
> >> >> > there is (allegedly) no performance penalty for -g with gcc. However,
> >> >> >
Here is what I am trying to do. I have a table with two fields, both of which
are supposed to contain a serial number. The first one is the primary key
and is setup to default to a sequence in the normal way. The second one can
be one of any number of sequences. The sequence to use is calcul
Multiple database services and multiple versions on Red Hat Linux systems
The way it works is that we require a specific service script for each
database service (that is listening on each port). Each of these
services has a init script in /etc/init.d and a corresponding
configuration file in
ivan wrote:
hi
can we change initdb when view pg_user is createing to :
CREATE VIEW pg_user AS \
SELECT \
usename, \
usesysid, \
usecreatedb, \
usesuper, \
usecatupd, \
''::text as passwd, \
valuntil, \
useconfig \
F
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
What happens instead is that vacuum not only evicts the whole buffer
cache by forcing all blocks of said table and its indexes in, it also
dirties a substantial amount of that and leaves the dirt to be cleaned
up by all the other backends.
[
tgl wrote:
> strk <[EMAIL PROTECTED]> writes:
> >> From whitin an aggregate sfunc I did:
> > oldcontext = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt);
> > geom = (GEOMETRY *)PG_DETOAST_DATUM(datum);
> > MemoryContextSwitchTo(oldcontext);
>
> > And later in aggregate's fi
Hi,
It would be great for maintainance if every object had a timestamp of
the last vaccum run on it. From time to time we're working with several
databases and I can't tell wich one needs a new vacuum.
Another important information would be the rate of disposable data in
every table (like old
How do I find out in Embedded SQL that a transaction has been aborted
due to a deadlock?
The closes error message in sqlca seems to be:
-401 (ECPG_TRANS): Error in transaction processing line %d.
PostgreSQL signaled that we cannot start, commit, or rollback the
transaction.
but it does
> > They stopped at 7.2.4 because "they're finishing some usefull APIs,
> > which'll make the port much more "easy"."
>
> Will this involve using a Linux kernel ;)
:) No, a NW kernel with a POSIX library. This'll be great, because you'll
can run powerfull opensource software with an enterprise-c
Gaetano Mendola wrote:
Bruce Momjian wrote:
I can confirm this bug in CVS.
Dropping the pkey from table b in fact drops the unique index from it.
The SPI plan cached to check if a row deleted from table a is still
referenced from table b "can" (and in your case does) use an index scan
on table
Jan Wieck <[EMAIL PROTECTED]> writes:
> What happens instead is that vacuum not only evicts the whole buffer
> cache by forcing all blocks of said table and its indexes in, it also
> dirties a substantial amount of that and leaves the dirt to be cleaned
> up by all the other backends.
[ thinks
To add some medium-hard data to the discussion, I hacked a PG 7.3.4 a
little. The system I am talking about below run's an artificial
application that very well resembles the behaviour of a TPC-C benchmark
implementation. Without vacuuming the database, it can just so sustain a
factor 5 scaled
strk <[EMAIL PROTECTED]> writes:
>> From whitin an aggregate sfunc I did:
> oldcontext = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt);
> geom = (GEOMETRY *)PG_DETOAST_DATUM(datum);
> MemoryContextSwitchTo(oldcontext);
> And later in aggregate's finalfunc:
> pfree(ge
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We can also try to come up with a better scheme for verifying that we
have started properly - I will think about that.
There have been previous suggestions for a "pg_ping" functionality, in
which you could simply send a packet to
>From whitin an aggregate sfunc I did:
oldcontext = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt);
geom = (GEOMETRY *)PG_DETOAST_DATUM(datum);
MemoryContextSwitchTo(oldcontext);
And later in aggregate's finalfunc:
pfree(geom);
Result:
segfault!
What's wro
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, do we want to put back the mention of these in the release notes?
> The non-zulu ones sound pretty strange to me and might be better left
> undocumented.
AFAICS the updated docs are correct. Since the code behavior has not
changed, there is no need
Tom, thanks again for the quick answer and
sorry for the lame question about memor allocation.
I hope this is acceptable:
Is there a way to make PG_DETOAST_DATUM and friends allocate
memory in a custom memory context ?
Right now I'm DETOASTing, memcopying in a custom context
and pfreeing the DETO
Anthony W. Youngman wrote:
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
[EMAIL PROTECTED]> writes
Anthony W. Youngman wrote:
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
<[EMAIL PROTECTED]> writes
Anthony W. Youngman wrote:
Well, if it is normalised, how easy
I am putting together a DB that records information about a set of web
sites and how they link to one another. As one site refers to another, I
monitor the first site and then record when I find the referred site.
I have a table called sa_site like this:
ensa1.1: sa_site
Field
Type
Not Nu
In article <[EMAIL PROTECTED]>, Lauri Pietarinen writes
>Anthony W. Youngman wrote:
>
>>In article <[EMAIL PROTECTED]>, Lauri Pietarinen
>><[EMAIL PROTECTED]> writes
>>
>>
>>>Anthony W. Youngman wrote:
>>>
>>>
>>>
Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
>
In article <[EMAIL PROTECTED]>, Marshall Spight
<[EMAIL PROTECTED]> writes
>"Bob Badour" <[EMAIL PROTECTED]> wrote in message news:W46dnf4tbfF1DwiiU-
>[EMAIL PROTECTED]
>>
>> All physical structures will bias performance for some operations and
>> against others.
>
>This strikes me as a succinct st
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We can also try to come up with a better scheme for verifying that we
> have started properly - I will think about that.
There have been previous suggestions for a "pg_ping" functionality, in
which you could simply send a packet to the postmaster and i
"Yurgis Baykshtis" <[EMAIL PROTECTED]> writes:
> In pgerr.log this always go together:
> WARNING: ShmemAlloc: out of memory
> ERROR: FreeSpaceMap hashtable out of memory
If you have a large number of tables in your database, it might be that
you need to increase max_locks_per_transaction.
In article <[EMAIL PROTECTED]>, Anthony W. Youngman
<[EMAIL PROTECTED]> writes
>>Really, however you calculate it, it is an order of magnitude less
>>than your alternative.
>>
>>And please don't tell me that using indexes is not fair or not in the
>>spirit of the
>>relational model ;-)
>
>Well, it
"Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Anthony W. Youngman wrote:
>
> >In article <[EMAIL PROTECTED]>, Anthony W. Youngman
> ><[EMAIL PROTECTED]> writes
> > But it does seem strange indexing on a composite field
> >like that ...
> >
> But why does it seem
"Christopher Browne" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Anthony W. Youngman" <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>, Marshall Spight
> > <[EMAIL PROTECTED]> writes
> >>Unless one has data independence, one does not have
> >>this option; one will be
Anthony W. Youngman wrote:
In article <[EMAIL PROTECTED]>, Anthony W. Youngman
<[EMAIL PROTECTED]> writes
Really, however you calculate it, it is an order of magnitude less
than your alternative.
And please don't tell me that using indexes is not fair or not in the
spirit of the
relational mod
"Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Anthony W. Youngman wrote:
>
> >In article <[EMAIL PROTECTED]>, Lauri Pietarinen >[EMAIL PROTECTED]> writes
> >
> >>Anthony W. Youngman wrote:
> >>>In article <[EMAIL PROTECTED]>, Lauri Pietarinen
> >>><[EMAIL PROTE
"Anthony W. Youngman" <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Marshall Spight
> <[EMAIL PROTECTED]> writes
>>Unless one has data independence, one does not have
>>this option; one will be locked into a particular
>>performance model. This is why I found the MV
>>guy's obvious p
pgman wrote:
> Jan Wieck wrote:
> > >> >> > What Peter was advocating in that thread was that we enable -g by
> > >> >> > default *when building with gcc*. I have no problem with that, since
> > >> >> > there is (allegedly) no performance penalty for -g with gcc. However,
> > >> >> > the actual p
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Shouldn't it revert to the default value?
>
> No, not unless you think the postmaster should react to comments in the
> postgresql.conf file, which is rather against my idea of a comment.
>
> However, you're not the first to get burnt by t
Windows client port list updated:
http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html
---
Dave Page wrote:
> Yup, that works fine (just a few warnings about ERROR being redefined).
>
> Thanks,
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> What are (more) reasons for not adding transaction information to
> index tuple, in addition to heap tuple?
> Cons are bloated indexes. The index tuple size will be close to 30
> bytes minimum.
And extra time to perform an update or delete, and ex
Jan Wieck wrote:
> >> >> > What Peter was advocating in that thread was that we enable -g by
> >> >> > default *when building with gcc*. I have no problem with that, since
> >> >> > there is (allegedly) no performance penalty for -g with gcc. However,
> >> >> > the actual present behavior of our
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>>> The latter...why won't it affect the postmaster state?
>>
>> Because it's a *comment*.
> Shouldn't it revert to the default value?
No, not unless you think the postmaster should react to comments in the
postgresql.conf file, which is rather
strk <[EMAIL PROTECTED]> writes:
> My question is: if I write in the "state" array
> pointers to DETOASTED input args,
> will I find them intact at finalfunc time ?
No, not without pushups. You are called in a short-lived memory
context. You could allocate query-lifetime memory in fcinfo->fn_mcx
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Tom Lane writes:
>>
>> > What Peter was advocating in that thread was that we enable -g by
>> > default *when building with gcc*. I have no problem with that, since
>> > there is (allegedly) no performance pen
Dear pg-hackers,
Making an aggregate I want to stuff all input values (detoasted)
in an array and process them all togheter with finalfunc.
This is because in order to process them a conversion is involved
and I'm trying to reduce the number of conversions to the lowest
possible.
My question is:
Hi,
Last week, there was a thread whether solely in memory vacuum can be performed
or not.(OK, that was a part of thread but anyways)
I suggested that a page be vacuumed when it is pushed out of buffer cache. Tom
pointed out that it can not be done as index tuples stote heap tuple id and
depen
Hello:
In src/backend/utils/adt/timestamp.c, interval_send looks like what you
are looking for.
Thanks :)
--
Best regards
Carlos Guzmán Álvarez
Vigo-Spain
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTE
On Sun, 2003-10-26 at 17:24, Oliver Elphick wrote:
> If it were possible to have two separate versions of the PostgreSQL
> packages installed simultaneously, it would be simple to do database
> upgrades by dumping from the old version and uploading to the new.
You'd need some mechanism to prevent
On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote:
> configure --enable-debug will use -g for the compile, and with
> optimization.
I'm just curious: would there be any benefit to using -g3 when
--enable-debug is specified and -g3 is supported by gcc? From the gcc
man page:
-glevel
[...]
R
Christopher Kings-Lynne wrote:
>> I think because START TRANSACTION is SQL standard? However, I thought
>> BEGIN WORK was SQL standard, and we don't support READ ONLY there
>> either --- hmmm.
>
>
> BEGIN is no part of the SQL standard. The only way to begin a
> transaction under the SQL standar
On Sun, 2003-10-26 at 19:22, Gaetano Mendola wrote:
> Hi all,
> why START TRANSACTION READ ONLY is allowed
> and not BEGIN READ ONLY ?
As Chris KL points out, it's not required by the standard (since BEGIN
isn't part of the standard to begin with). I suppose we could add it,
but it seems a little
Yup, that works fine (just a few warnings about ERROR being redefined).
Thanks, Dave.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 27 October 2003 02:50
> To: Dave Page
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Call for port reports (Win32 Cli
Bruce Momjian wrote:
> Well, we don't want to use debug for non-gcc (no optimization) so do we
> do -g for gcc, and then --enable-debug does nothing. Seems people can
> decide for themselves.
But doesn't --enable-debug turn off optimization?
It's really a question of what the default behavior s
78 matches
Mail list logo