"Ramanujam H S Iyengar" writes:
iam in need of a function through which i can get a Relation Node given
its name ..
precisely the same one equivalent to " RelationSysNameGetRelation " ..
which works for all types of relations (system and user tables)
The reason RelationSysNameGetRelation only w
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> What I think is possible is the following (continuous backup of WAL assumed):
> - disable VACUUM
> - issue CHECKPOINT "C1"
> - backup all files
> - reenable VACUUM
> - restore files
> - adapt pg_control (checkpoint "C1")
> - recover WAL unt
"Marcelo Carvalho Fernandes" <[EMAIL PROTECTED]> writes:
> I have a PostgreSQL (7.3) with lots of databases. I can't start it after a
> power failure. I´m trying this...
> NS2 - /var/lib/pgsql/data >pg_ctl start
> postmaster successfully started
> PANIC: The database cluster was initialized with
On Thu, 11 Mar 2004, Neil Conway wrote:
> Fair enough. Attached is a patch that implements this. I chose to
> remove UNSAFE_FLOATS: if anyone thinks that is worth keeping, speak up
> now.
I have one question about the use of HUGE_VAL in postgresql. I got the
impression that the whole thing was de
On Thu, 11 Mar 2004, Neil Conway wrote:
> So, what is the correct behavior: if you multiply two values and get a
> result that exceeds the range of a float8, should you get
> 'Infinity'/'-Infinity', or an overflow error?
That's the issue and I think we should allow infinity as a result of a
floa
On Wed, 10 Mar 2004, Andreas Pflug wrote:
> Kris Jurka wrote:
>
> >On Wed, 10 Mar 2004, Andreas Pflug wrote:
> >
> >The problem that cannot be solved with either this or a function that
> >loops and grants on each table is that it is not a permanent grant of what
> >the admin had in mind. If
"Ramanujam H S Iyengar" <[EMAIL PROTECTED]> writes:
> iam in need of a function through which i can get a Relation Node given its
> name ..
> precisely the same one equivalent to " RelationSysNameGetRelation " .. which
> works for all types of relations (system and user tables)
The reason Relati
Hello,
Sorry for the previous confusing mail ..
iam in need of a function through which i can get a Relation Node given its
name ..
precisely the same one equivalent to " RelationSysNameGetRelation " .. which
works for all types of relations (system and user tables)
On Wednesday 10 March 2004 09
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The issue is allowing only logging of DDL statements, or DDL and data
> modification statements, as listed on the TODO list. If they ask for
> all statements, certainly we should log all statements.
just make syntax errors one of the types. So you cou
As some may remember, there has been talk about shipping our own
timezone implementation with PostgreSQL. This will remove reliance on
possible broken timezone OS implementations, and give us added
capabilities. The Win32 port will also need this functionality.
SRA has implemented similar functi
Hi,everyone, I am afraid why not make postgreSQL support ADTs such as bag,list and so on.In mymind,all these will make the system more diversiform,aren't they? Thanks!
==
263电子邮件-信赖邮自专业
Bruce Momjian wrote:
> Manfred Spraul wrote:
> > Hi,
> >
> > I've searched through libpq and looked for global or static variables as
> > indicators of non-threadsafe code. I found:
> > - Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it
> > seems to be a dummy variable that is
Andrew Dunstan wrote:
Actually, I think I can improve the present situation. Currently, if
log_statement is not turned on and you send a query that doesn't
parse, all you get is the error trace. By deferring it till right
after the parse we can force logging of the query string on a parse
er
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If people are happy with suppressing statement logging on a parse error,
OK.
I think that's a really, really awful idea. Not infrequently, the
postmaster log is the easiest way of debugging applications that are
sending bogus S
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > If people are happy with suppressing statement logging on a parse error,
> > OK.
>
> I think that's a really, really awful idea. Not infrequently, the
> postmaster log is the easiest way of debugging applications that are
> sending
On Wednesday 10 March 2004 09:58 am, Ramanujam H S Iyengar wrote:
> Hello,
>
> How can i get the name of a relation from its Oid ?? I have seen some
> functions in utils/cache/relcache.h like RelationIdGetRelation - which
> gives Relation Node from Oid RelationSysNameGetRelation - which gives
> Rel
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If people are happy with suppressing statement logging on a parse error,
> OK.
I think that's a really, really awful idea. Not infrequently, the
postmaster log is the easiest way of debugging applications that are
sending bogus SQL. If you fail to lo
Neil Conway <[EMAIL PROTECTED]> writes:
> What number would you like 'Infinity'::float4 and 'Infinity'::float8
> to produce? Is this actually useful functionality?
On an IEEE-spec machine, it's highly useful functionality. +Infinity
and -Infinity are special values.
BTW the float4out and float8o
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> So I'd vote for ripping out the range check, or at least reversing
>> the default state of UNSAFE_FLOATS.
> This would surely be wrong. Defining UNSAFE_FLOATS will make
> float4in() not check that its input fits into
Andrew Dunstan wrote:
> >Sure you sure? I didn't think you would get a tag on a syntax error, so
> >no log would print, which I think is OK.
> >
> >
> >
> If people are happy with suppressing statement logging on a parse error,
> OK. For the remainder I would just defer the logging till immedia
On Wed, 10 Mar 2004, Neil Conway wrote:
> No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
> is defined or not.
Yes, the tests are:
if (fabs(val) > FLOAT8_MAX)
if (val != 0.0 && fabs(val) < FLOAT8_MIN)
and only infinity and not NaN will trigger the overflow. I read it wr
Tom Lane <[EMAIL PROTECTED]> writes:
> Nowadays, IEEE float math is nearly universal, and we would be
> offering better functionality if we allowed access to Infinity and
> Nan by default.
This is faulty reasoning: we *do* allow NaN by default (although
you're correct that we reject Infinity in fl
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> When UNSAFE_FLOATS is defined there is a check that float results
> are within the min and max limits, which excludes values like
> 'Infinity', '-Infinity' and 'Nan'.
No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
is defined or n
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> When UNSAFE_FLOATS is defined there is a check that float results are
> within the min and max limits, which excludes values like 'Infinity',
> '-Infinity' and 'Nan'.
> Is the above something from the SQL standard or just a bug?
I think it was prob
Bruce Momjian wrote:
Andrew Dunstan wrote:
Yes, look at how the command tag is grabbed for the PS display, and do
the log checks at that point.
Yes, I thought about that. But it would delay the logging of statements,
and I'm not sure that's a good idea. What would happen on parse erro
When UNSAFE_FLOATS is defined there is a check that float results are
within the min and max limits, which excludes values like 'Infinity',
'-Infinity' and 'Nan'.
Is the above something from the SQL standard or just a bug?
The input rules for float8 accepts 'Infinity' as a value, and then it ju
Josh Berkus kirjutas T, 09.03.2004 kell 19:46:
> In my personal experience, the *primary* use of PITR is recovery from User
> Error. For example, with one SQL Server 7.0 installation for a law firm,
> I've made use of PITR 4 times over the last 4 years: once was because and HDD
> failed, the
Christopher Browne wrote:
Further bonus: the "GUI project" need only have a database connection
to one of the databases to control things. No need for ANYTHING else.
After fleshing it out a little, that's a pretty slick approach.
You miss the point, sorry.
This "make GUI easy to write" approach
Andrew Dunstan wrote:
> >Yes, look at how the command tag is grabbed for the PS display, and do
> >the log checks at that point.
> >
> >
> >
> Yes, I thought about that. But it would delay the logging of statements,
> and I'm not sure that's a good idea. What would happen on parse errors,
> for
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> If I do a query on localhost with lots of data, I get a small
> time in the log, if I do it over a slow link the time get higher.
> It changes from 1 second to 2 minutes or something.
> So I think it's until the client has received the data.
It'll at leas
Merlin Moncure kirjutas K, 10.03.2004 kell 17:00:
> Bruce Momjian wrote:
> > I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> > 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> > longer, so I am wondering why a simpler query isn't faster.
> >
> > Loo
Bruce Momjian wrote:
Andrew Dunstan wrote:
The TODO list contains this item which I said I would look at:
Allow logging of only data definition(DDL), or DDL and modification
statements
The trouble I see is that we currently do statement logging before we
have examined the query string at a
> Bill Moran <[EMAIL PROTECTED]> writes:
>> Am I missing something here?
>
> Hmm. It seems like int-to-bit casting ought to be aware of the
> bit-width one is casting to, and take that number of bits from
> the right end of the integer. This would make it be the inverse
> of the other direction.
Hi,
I have a PostgreSQL (7.3) with lots of databases. I can't start it after a
power failure. I´m trying this...
NS2 - /var/lib/pgsql/data >pg_ctl start
postmaster successfully started
PANIC: The database cluster was initialized with LC_CTYPE 'pt_BR',
which is not recognized by setlocale
> > To clarify:
> > I'd expect a cluster to be workable, if I
> > - disable VACUUM until backup completed
> > - issue CHECKPOINT
> > - backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
> > - backup all datafiles (which include at least all completed transaction
> > data at chec
"Thomas Swan" <[EMAIL PROTECTED]> writes:
> To convert low bits ot high bits you pad 0 bits on the left. To convert
> from high to low you strip bits off the left hand side. This allows
> reasonable behavior.
Unfortunately, the SQL spec is perfectly clear that you pad or strip
zero bits on the
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >>There seems to be a 'PostgreSQL ping' time of about 1-2 ms in best case
> >>conditions which limits the amount of queries you can fire off in 1
> >>second, no matter how simple. In certain rare cases this is something
> >>of a bottleneck. In my p
Folks,
Early on in the default_stats thread, I made a proposal that got dropped
without discussion. I'd like to revisit it, because I still think it's a
good idea.
The Issue: The low default_stats_target of 10 is not sufficient for many
complex queries involving multi-column correlation or
Andrew Dunstan wrote:
>
> The TODO list contains this item which I said I would look at:
>
> Allow logging of only data definition(DDL), or DDL and modification
> statements
>
> The trouble I see is that we currently do statement logging before we
> have examined the query string at all, in
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
To clarify:
I'd expect a cluster to be workable, if I
- disable VACUUM until backup completed
- issue CHECKPOINT
- backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
- backup all datafiles (which include at least all co
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> > 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> > longer, so I am wondering why a simpler query isn't faster.
>
> Define "normal SELEC
Kris Jurka wrote:
On Wed, 10 Mar 2004, Andreas Pflug wrote:
Edgar Mares wrote:
hi there i'm having troubles to find how to
GRANT SELECT ON all-tables-onmydb TO specificuser
this is just to give the access to "specificuser" to query the
database and find troubles on it
Merlin Moncure wrote:
> Bruce Momjian wrote:
> > I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> > 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> > longer, so I am wondering why a simpler query isn't faster.
> >
> > Looking at log_executor_stats,
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am timing small queries, and found that a PREPARE/EXECUTE of
> > "SELECT 1" takes about 1.2ms on my machine. A normal SELECT doesn't
> > take much longer, so I am wondering why a simpler query isn't
> > faster.
>
> log_executor_
On Wed, 10 Mar 2004, Li Yuexin wrote:
> Who can tell me how to complete oracle's hierarchical_query through
> postgresql?
Look in the contrib/tablefunc directory for the connect_by function.
---(end of broadcast)---
TIP 3: if posting/reading
The TODO list contains this item which I said I would look at:
Allow logging of only data definition(DDL), or DDL and modification
statements
The trouble I see is that we currently do statement logging before we
have examined the query string at all, in the code shown below from
src/backend/t
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Why is that a useful approach? You might as well shut down the
postmaster and do a cold filesystem backup,
We're talking about *hot* backup, aren't we?
Exactly. The approach you're sketching can't wor
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why is that a useful approach? You might as well shut down the
>> postmaster and do a cold filesystem backup,
>>
> We're talking about *hot* backup, aren't we?
Exactly. The approach you're sketching can't work for hot backup,
becau
> The only way we can support file-level hot backup is in conjunction with
> PITR-style WAL log archiving. It is okay for the data area dump to be
> inconsistent, so long as your recovery process includes replay of WAL
> starting at some checkpoint before the filesystem dump started, and
> extend
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >> Please don't. Declare them obsolete for 7.5 and remove them in a later
> >> release.
>
> > Nah, just remove them. We've removed, added and changed so many config
> > options and no-one's ever complained...
>
> I agree wi
Chad,
> I'm talking about the stuff that the other poster (cant see his name
> right now, sorry) doubts will ever be in postgres. ie you can seek to
> anywhere in the Btree using a row offset as a "search" key.
And this is more useful than LIMIT # OFFSET # on queries, how, exactly?
> I'd love to
Tom Lane wrote:
> The optimizer has no knowledge of specific operators except what it
> finds in the system catalogs. It has no way in general to determine
> that a comparison involving nonconstant values must always fail.
> Even if we could do it, I am dubious that it would be worth expending
> t
Tom Lane wrote:
I agree with Chris; this would be taking compatibility concerns a bit
far. None of these variables are likely to be touched except through
postgresql.conf (I don't think we even allow them to be SET interactively).
And you can never simply take your old .conf file and plop it down
Fabien COELHO <[EMAIL PROTECTED]> writes:
> If not, what are the other options?
I don't think you have any: you have to use PQmblen. Depending on wchar
facilities would be unportable even if they did everything you wanted.
It might be convenient to build an integer array of character start
offse
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> > SIGHUP - seems to allow different parameter settings in each backend
>
> Nope. SIGHUP means that you need to send a HUP to the postmaster,
such
> as
> you would with changes to pg_hba.conf.
>
> > SUSET - maybe what you're looking for???
>
>
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Please don't. Declare them obsolete for 7.5 and remove them in a later
>> release.
> Nah, just remove them. We've removed, added and changed so many config
> options and no-one's ever complained...
I agree with Chris; this would be taking c
>Josh Berkus [mailto:[EMAIL PROTECTED]
> > wal_archive_policy and enable/disable archiving accordingly. This
> > parameter can only be changed at server start. (This is required
because
> > the initial step of archiving each xlog is performed by the backend;
if
> > this were changeable after boot,
On Wed, 10 Mar 2004, Andreas Pflug wrote:
> Edgar Mares wrote:
>
> > hi there i'm having troubles to find how to
> > GRANT SELECT ON all-tables-onmydb TO specificuser
> >
> > this is just to give the access to "specificuser" to query the
> > database and find troubles on it
>
> pg
> > If not, what are the other options?
>
> I don't think you have any: you have to use PQmblen. Depending on wchar
> facilities would be unportable even if they did everything you wanted.
I meant pg_wchar. It's in the postgres source, should be pretty portable.
> It might be convenient to buil
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Is this really as simple as it seems?
No.
The optimizer has no knowledge of specific operators except what it
finds in the system catalogs. It has no way in general to determine
that a comparison involving nonconstant values must always fail.
Even i
Andreas Pflug <[EMAIL PROTECTED]> writes:
> To clarify:
> I'd expect a cluster to be workable, if I
> - disable VACUUM until backup completed
> - issue CHECKPOINT
> - backup clog (CHECKPOINT and backup clog are the "backup checkpoint")
> - backup all datafiles (which include at least all completed
Bruce Momjian wrote:
> I am timing small queries, and found that a PREPARE/EXECUTE of "SELECT
> 1" takes about 1.2ms on my machine. A normal SELECT doesn't take much
> longer, so I am wondering why a simpler query isn't faster.
>
> Looking at log_executor_stats, I see the following. Execute show
On Wed, 10 Mar 2004, Shachar Shemesh wrote:
> >IBM has rewritten their Domino database system to use the new
> >sys_epoll call available in the Linux 2.6 kernel.
> >
> >Would Postgresql benefit from using this API? Is anyone looking at
> >this?
> I'm not familiar enough with the postgres internal
Hello hackers,
I'm working on a very small patch to add syntax error localisation on the
client side in psql, as it seems to be the place. Something like:
ERROR: syntax error at character 12345
QUERY: ... WHERE foo IS NUL AND ...
QUERY: ^
My current issue is how to build the q
> Please don't. Declare them obsolete for 7.5 and remove them in a later
> release.
Nah, just remove them. We've removed, added and changed so many config
options and no-one's ever complained...
Chris
---(end of broadcast)---
TIP 2: you can get
Edgar Mares wrote:
hi there i'm having troubles to find how to
GRANT SELECT ON all-tables-onmydb TO specificuser
this is just to give the access to "specificuser" to query the
database and find troubles on it
pgAdmin II has a tool for that (Security wizard; pgAdmin III has it on
the
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
When I'm doing a file level hot backup, I can't be sure about the backup
order. To be sure the cluster is in a consistent state regarding
checkpoints, pg_clog must be the first directory backed up.
You are going off in the wrong d
On Tue, 09 Mar 2004 10:02:14 -0500, Andrew Dunstan <[EMAIL PROTECTED]>
wrote:
>>>After this is applied (fingers crossed) and everyone is happy, I will
>>>submit a patch to remove log_timestamp, log_pid and (if we are agreed on
>>>it) log_source_port.
>Is there agreement on removing these 3 confi
Anthony_Barker wrote:
IBM has rewritten their Domino database system to use the new
sys_epoll call available in the Linux 2.6 kernel.
Would Postgresql benefit from using this API? Is anyone looking at
this?
Anthony
http://xminc.com/mt/
I'm not familiar enough with the postgres internals, but is
69 matches
Mail list logo