Robert Treat <[EMAIL PROTECTED]> writes:
> I think better would be a GUC "log_to_table" which wrote all standard
> out/err to a pg_log table. of course, I doubt you could make this
> foolproof (how to log startup errors in this table?) but it could be a
> start.
How would a failed transaction mak
OK, on it now!
---
Tom Lane wrote:
> I said:
> >> I have a theory about the failures that occur while creating tables.
> >> If a relcache flush were to occur due to SI buffer overrun between
> >> creation of the new rel's re
I said:
>> I have a theory about the failures that occur while creating tables.
>> If a relcache flush were to occur due to SI buffer overrun between
>> creation of the new rel's relcache entry by RelationBuildLocalRelation
>> and completion of the command, then you'd see an error exactly like the
Merlin Moncure wrote:
Dear hackers,
Do you think there would be any use for an aggregate which returns an
array of the aggregated (usually simple) type? Has this already been
done by anyone? I looked at the source and noticed that for each
inserted item, the array utility functions perform a de
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, is the attached regression diff considered normal? This was
> > generated by current CVS.
>
> Well, this *looks* like it could be an example of the SI-overrun-
> during-create behavior I was talking about. But if you weren't ru
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, is the attached regression diff considered normal? This was
> generated by current CVS.
Well, this *looks* like it could be an example of the SI-overrun-
during-create behavior I was talking about. But if you weren't running
a verbose log to show
Good evening.
RPMs for PostgreSQL 7.3.4, built on three architectures, are in the midst of
uploading to ftp.postgresql.org, in /pub/binary/v7.3.4/RPMS. As usual,
inside that directory is the directory SRPMS, which contains the source RPM,
as well as the three binary RPM directories I am upload
Tom, is the attached regression diff considered normal? This was
generated by current CVS.
I am trying to determine what is a normal error and what is something to
be concerned about.
Also, I am up to Feb 25 with no errors, but am still testing.
Dear hackers,
Do you think there would be any use for an aggregate which
returns an array of the aggregated (usually simple) type? Has this already been done by anyone? I looked at the source and noticed that
for each inserted item, the array utility functions perform a deep copy of t
On Sun, 27 Jul 2003, Tom Lane wrote:
> ivan <[EMAIL PROTECTED]> writes:
> > declaration is setof record array_to_setof ( anyarray);
>
> > i trayed created it like "any" array_to_setof( anyarray) but i had problem
> > with select. i also trying write setof_to_array as aggregate, but i have
> > pr
On Mon, 2003-07-28 at 11:04, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Vacuum full locks the entire table and moves tuples between pages. It
> > leaves all pages full of tuples (except, obviously, the last one), so it
> > doesn't need to record them in the FSM.
>
> This is
Robert Treat <[EMAIL PROTECTED]> writes:
>> This is overoptimistic :-(. VACUUM FULL cannot necessarily compact the
>> table completely, and so it will record free space in FSM (if there is
>> any worth recording). An example situation is that page 1000 may
>> contain a very large tuple, which wil
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am now seeing this error in 2003-03-03.
> CREATE TABLE INSERT_CHILD (cx INT default 42,
> cy INT CHECK (cy > x))
> INHERITS (INSERT_TBL);
> + ERROR: RelationClearRelation: relation 130996 deleted while still in use
Define "now seein
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am now seeing this error in 2003-03-03.
>
> > CREATE TABLE INSERT_CHILD (cx INT default 42,
> > cy INT CHECK (cy > x))
> > INHERITS (INSERT_TBL);
> > + ERROR: RelationClearRelation: relation 130996 deleted while s
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am now seeing this error in 2003-03-03.
> CREATE TABLE INSERT_CHILD (cx INT default 42,
> cy INT CHECK (cy > x))
> INHERITS (INSERT_TBL);
> + ERROR: RelationClearRelation: relation 130996 deleted while still in use
I have a theory about the failures
in psql , file command.c : 1473 there is a query to check state for
superuser, and this query is in begin/end transaction.
When user dont have perm to read pg_user its fail but transation is never
end, and ist make some confusion because user have to write "END;" or
"ROLLBACK;" themself. I just re
elein wrote:
Do you want me to try to write this up into
more formal definitions?
I think it would be a useful starting point for future discussions, but
it goes way beyond what I was looking for at the moment.
Joe
---(end of broadcast)---
TIP 5:
Bruce Momjian wrote:
I assume this will not be completed for 7.4. I will keep the emails for
7.5.
One idea I had was to use the existing sort_mem parameter to control
when to force the deferred trigger queue to disk --- it doesn't have
anything to do with sorting, but it does have the same purpose
On Thu, 2003-07-24 at 11:23, [EMAIL PROTECTED] wrote:
> Also I was thinking that we could "hide" a log table into a "special"
> schema like this:
>
> CREATE TABLE log (
> when timestamp,
> user text,
> table name,
> query text,
> error text);
>
> So that iff this table exists in a databse, all
On Mon, 28 Jul 2003, Robert Treat wrote:
> Date: 28 Jul 2003 13:50:27 -0400
> From: Robert Treat <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Larry Rosenman <[EMAIL PROTECTED]>, Josh Berkus <[EMAIL PROTECTED]>,
> pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Feature req
I am now seeing this error in 2003-03-03.
CREATE TABLE INSERT_CHILD (cx INT default 42,
cy INT CHECK (cy > x))
INHERITS (INSERT_TBL);
+ ERROR: RelationClearRelation: relation 130996 deleted while still in use
-
The following lines are from readme file present in the
\src\backend\storage\lmgr folder of postgresql
"If we are setting a table level lock
Both the blockId and tupleId (in an item pointer this is called
the position) are set to invalid, if it is a page level lock the
blockId is valid, while the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> In other words, an info, notice, or warning must have a class 00, 01, 02.
I suspect though that the spec is assuming that the SQLSTATE code is the
*only* way for the application to determine whether the message is
success, warning, or error. Since we
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Has anyone thought of what will happen to the server_encoding parameter
> when the character set/encoding will be settable for individual columns
> and the concept of a global server encoding will go away? What will
> happen to clients that make use o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Presumably, the "is_superuser" parameter was intended to make the updating
> of psql's prompt more accurate when SET SESSION AUTHORIZATION is used.
> However, if the prompt is customized to include the user name (%n), then
> the prompt changes to refle
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> My copy of SQL99 assigns
> most specific type mismatch 2200G
> null value, no indicator parameter22002
> but elog.h has it set up the other way around. Can someone clear this up
> for me?
Hoo, that's interesting. I believe that I actua
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Vacuum full locks the entire table and moves tuples between pages. It
> leaves all pages full of tuples (except, obviously, the last one), so it
> doesn't need to record them in the FSM.
This is overoptimistic :-(. VACUUM FULL cannot necessarily compa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> Should we create some user-friendly macros for the error field codes?
> I was actually talking of the single-letter codes that are used on the
> protocol layer to tag the different fields of an error or notice result.
Oh, those things. Sure, if yo
"Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> 1. IIRC vacuum recovers/reuses dead tuples generated from update but can not do
> so for delete? Why?
This is not correct.
> 2. Vacuum full locks entire table, is it possible that it locks a page at a
> time and deal with it.
No. You can't c
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> In backend/commands/portalcmds.c we have
> /* FIXME: shouldn't this be an ERROR? */
> The effect of this is that you can fetch from an undefined cursor and
> (successfully) get zero rows plus this warning. I propose that we change
> this to a
I am testing this today. I found 2003-03-03 to not generate a failure
in 20 tests, so I am moving forward to April/May.
---
Robert Creager wrote:
-- Start of PGP signed section.
>
> I will stand by the fact that I cannot g
On Mon, Jul 28, 2003 at 02:29:36PM +0530, Shridhar Daithankar wrote:
> I was just wondering over it. This is for difference between vacuum full and
> vacuum analyze. Can somebody enlighten,
Actually, the different concepts are "lazy vacuum" (plain VACUUM
command, with or without ANALYZE) and ful
My copy of SQL99 assigns
most specific type mismatch 2200G
null value, no indicator parameter 22002
but elog.h has it set up the other way around. Can someone clear this up
for me?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... I'm wondering what kind of
> scheme we should use to allow clients to reserve some SQLSTATE codes for
> their own use.
> The errors I'm currently looking at can be thought of as "internal
> errors", so should I be using the class XX, or maybe XY a
On 28 Jul 2003 at 9:11, Doug McNaught wrote:
> "Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I was just wondering over it. This is for difference between vacuum full and
> > vacuum analyze. Can somebody enlighten,
> >
> > 1. IIRC vacuum recovers/reuses dead tuples generat
"Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I was just wondering over it. This is for difference between vacuum full and
> vacuum analyze. Can somebody enlighten,
>
> 1. IIRC vacuum recovers/reuses dead tuples generated from update but can not do
> so for delete? Why?
YDNRC.
I will stand by the fact that I cannot generate failures from
2003-02-15 (200+ runs), and I can from 2003-02-16. Just to make sure I
didn't screw up the cvs usage, I'll try again tonight if I get the
chance and re-download re-test these two days.
I can set up a script that will step through week
already fixed
On Mon, 28 Jul 2003, Christopher Kings-Lynne wrote:
> It's showing the apache page.
>
> Chris
>
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [E
I'm currently fixing up ecpg for the new error codes. (ecpg was doing
string comparisons to detect certain failure conditions, which no longer
works, so this is a must-fix.) Many of the failure conditions that ecpg
detects explicitly can be mapped to SQLSTATE codes that are defined in the
standar
In backend/commands/portalcmds.c we have
/* FIXME: shouldn't this be an ERROR? */
ereport(WARNING,
(errcode(ERRCODE_UNDEFINED_CURSOR),
errmsg("portal \"%s\" does not exist", stmt->portalname)));
The effect of this is that you can fetch from an unde
Hi,
I was just wondering over it. This is for difference between vacuum full and
vacuum analyze. Can somebody enlighten,
1. IIRC vacuum recovers/reuses dead tuples generated from update but can not do
so for delete? Why?
2. Vacuum full locks entire table, is it possible that it locks a page at
Tom Lane writes:
> > Should we create some user-friendly macros for the error field codes? I
> > have a feeling that PGXYZ_SQLSTATE may make for better code than just 'C'.
>
> I just pushed the ERRCODE_ macros out into their own file. How about
> placing that file where client apps can include i
On Wed, 16 Jul 2003 03:56 am, Tom Lane wrote:
> > osf-template.patch: adds pthread support for OSF
> > tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha)
>
> Applied; it would be a good idea to get some more testing of it, but
> that's what beta is for ...
Yes, I only have access to one versi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Should we create some user-friendly macros for the error field codes? I
> have a feeling that PGXYZ_SQLSTATE may make for better code than just 'C'.
I just pushed the ERRCODE_ macros out into their own file. How about
placing that file where client
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I seem to be missing an equivalent of PQresultErrorField() that operates
> on a PGconn object (like PQerrorMessage() does). This would be useful to
> detect errors that occur outside of a statement execution.
Yeah. I thought about that, but the infr
Presumably, the "is_superuser" parameter was intended to make the updating
of psql's prompt more accurate when SET SESSION AUTHORIZATION is used.
However, if the prompt is customized to include the user name (%n), then
the prompt changes to reflect the real superuser status, but does not
change the
Has anyone thought of what will happen to the server_encoding parameter
when the character set/encoding will be settable for individual columns
and the concept of a global server encoding will go away? What will
happen to clients that make use of this parameter?
--
Peter Eisentraut [EMAIL PROT
The SQL standard states
An implementation-defined completion condition shall be indicated by
returning an implementation-defined subclass in conjunction with one of
the classes successful completion, warning, or no data.
In other words, an info, notice, or warning must have a class 00, 01, 02.
Ho
Should we create some user-friendly macros for the error field codes? I
have a feeling that PGXYZ_SQLSTATE may make for better code than just 'C'.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at
I seem to be missing an equivalent of PQresultErrorField() that operates
on a PGconn object (like PQerrorMessage() does). This would be useful to
detect errors that occur outside of a statement execution.
(One particular case I'm looking at is the message "fe_sendauth: no
password supplied", whic
50 matches
Mail list logo
