Christopher Kings-Lynne wrote:
People have been complaining (not without reason) that without any
documentation they can hardly test the new PITR code. I have hacked
up and committed some rough docs that should be enough for testing.
They're on-line now at
Bruce Momjian [EMAIL PROTECTED] writes:
. Allow multi-column indexes to be used to optimize row-value expressions. Ie,
allow a btree index on a,b to be used to execute an expression like (a,b)
(x,y).
I have not heard of any of those so I have not been actively excluding
them from
I think we need to deny changing column types if a function is using the
table type as a return set.
test=# create table test (a int4);
CREATE TABLE
test=# create function test () returns setof test as 'select 1' language
sql;
CREATE FUNCTION
test=# alter table test alter a type bigint;
ALTER
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
What about refusing to change client_encoding to something other than
SQL_ASCII on SQL_ASCII databases?
Not sure that would do anything very useful. People who aren't thinking
about this probably aren't thinking about setting
Peter/Fabien,
Just to say thank you for all your hard work in getting pgxs working in
CVS. I've successfully managed to get a contrib module to build outside
of the source tree, which will help simplify a lot of things.
I have one question though: the comments in pgxs.mk suggested that I
needed
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Here are the open items. They all have to be addressed before final,
but not all before beta starts.
P O S T G R E S Q L
7 . 5 O P E NI T E M S
Well, we could start
Mark Cave-Ayland wrote:
Peter/Fabien,
Just to say thank you for all your hard work in getting pgxs working in
CVS. I've successfully managed to get a contrib module to build outside
of the source tree, which will help simplify a lot of things.
I have one question though: the comments in pgxs.mk
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I think we need to deny changing column types if a function is using the
table type as a return set.
I disagree. There are many cases where it will work, and AFAIK none
in which you'll get worse than an error message. A couple of examples
Hi All!
Please note that the following functions are not implemented in the
postgres driver
even though they are a part of the JDBC 2.0 standard.
Some of these may be party implemented, but may not be complete.
differences
Blob.java
public long position(byte[] pattern, long start) throws
First, there is a list for the jdbc driver.
Second, which version are you using?
I know some of these are implemented already.
getUDT's, setFetchDirection, gettime, ...
Dave
On Wed, 2004-08-04 at 10:20, chinni wrote:
Hi All!
Please note that the following functions are not implemented in the
On Tue, Aug 03, 2004 at 11:27:35PM -0400 I heard the voice of
Mike Mascari, and lo! it spake thus:
Christopher Kings-Lynne wrote:
The ability to restore the database to a previous point in time creates
some complexities that are akin to science-fiction stories about time
travel and
The PITR docs that have just been put up say:
But if you want to recover to some previous point in time (say,
right before the junior DBA dropped your main transaction
table), just specify the required stopping point in
recovery.conf. You can specify the stop point
8.0 || 7.5??
g:)
The PITR docs that have just been put up say:
But if you want to recover to some previous point in time (say,
right before the junior DBA dropped your main transaction
table), just specify the required stopping point in
recovery.conf. You
On Wed, Aug 04, 2004 at 09:46:22AM +0800, Christopher Kings-Lynne wrote:
Depending on how tense you want to be about Oracle compatibility, we
could make people actually write their blocks as above --- that is,
the SAVEPOINT and ROLLBACK commands would be a required part of the
exception-block
Andrew Dunstan wrote:
Mark Cave-Ayland wrote:
This is because I only get the pgxs directory returned by pgconfig
--pgxs as opposed to the path to the pgxs.mk file itself - is that the
correct thing to do (i.e. the comment is wrong?) or is pgconfig --pgxs
returning the wrong thing?
needs to be
Oliver Elphick [EMAIL PROTECTED] writes:
How about adding a logging option to put the transaction id on the log
for every statement that modifies the database? Would that be a small
enough change to be allowed into 8.0?
I think we could get away with adding transaction ID as one of the
In CVS tip, try running the regression tests against an installed
postmaster (ie, make installcheck); then as soon as the tests are
done, kill -9 the bgwriter process to force a database restart.
Most of the time you'll get a PANIC during recovery:
LOG: background writer process (PID 2493) was
2) If I want to add these features to JDBC driver, is there anything
that has to go to database itself.
Generally JDBC questions are best discussed on the
[EMAIL PROTECTED] list. First make sure you are working with the
latest source code available from
On Wed, 2004-08-04 at 19:16, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
How about adding a logging option to put the transaction id on the log
for every statement that modifies the database? Would that be a small
enough change to be allowed into 8.0?
I think we could get
You seem to be suggesting that using the id is less useful than the
time, but surely it's going to be easier to say this disaster happened
in transaction 123 so lets do a PITR up to 122 than to say this
Transaction IDs are assigned at transaction start but what you really
want is some
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm playing with complex row type:
...
kalman=# alter table test drop column b;
ALTER TABLE --- Here I think the server shall complain about
~ ( 7.4 doesn't complain neither )
Actually, on looking back at the
If %t is used in log_line_prefix, win32's strftime will print a very
long timezone information, e.g. W. Europe Daylight Time where Linux
would write UTC. This makes the timestamp consuming more than half of
an average line length.
Do we have alternatives to the long form? Do we need the
Andreas Pflug wrote:
If %t is used in log_line_prefix, win32's strftime will print a very
long timezone information, e.g. W. Europe Daylight Time where Linux
would write UTC. This makes the timestamp consuming more than half
of an average line length.
Do we have alternatives to the long form?
On Tuesday 03 August 2004 08:38 pm, Greg Stark wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
On Tue, 2004-08-03 at 13:05, CSN wrote:
Just wondering, is updateable views slated for a
future version of Postgresql? In addition to using
rules that is.
I would think that a basic
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Changing to a domain and back doesn't do dependencies correctly:
Fixed. Thanks.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Hi,
If I want the planner/optimizer to always choose merge join when it needs to
join relations. How can I do it ?
Thanks,
--h
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Rod Taylor wrote:
You seem to be suggesting that using the id is less useful than the
time, but surely it's going to be easier to say this disaster happened
in transaction 123 so lets do a PITR up to 122 than to say this
Transaction IDs are assigned at transaction start but what you
Andrew Dunstan [EMAIL PROTECTED] writes:
Andreas Pflug wrote:
If %t is used in log_line_prefix, win32's strftime will print a very
long timezone information, e.g. W. Europe Daylight Time where Linux
would write UTC. This makes the timestamp consuming more than half
of an average line
Tom Lane wrote:
Does Windows' strftime have any short zone name %-spec? Seems like a
quick #ifdef WIN32 to use a more compact zone name would be the best
solution.
I already checked; unfortunately there's no short zone option. %z and %Z
give identical output.
I'd be inclined to leave out the
Is there an easy way to select, say, the 15th row in a table? I can't
use a sequence number because rows will sometimes be deleted resulting
in the 15th row now being a different row. I need to be able to select
the 15th row regardless of whether it is the same 15th row as the last
select.
Well, I see this in pgtz.c:
{Eastern Standard Time, Eastern Daylight Time,
US/Eastern}, /* (GMT-05:00) Eastern Time (US Canada) */
Can't we use this to map to slightly shorter names?
---
Andreas
Cason, Kenny [EMAIL PROTECTED] writes:
Is there an easy way to select, say, the 15th row in a table? I can't
use a sequence number because rows will sometimes be deleted resulting
in the 15th row now being a different row. I need to be able to select
the 15th row regardless of whether it is
On Wed, 2004-08-04 at 16:11, Cason, Kenny wrote:
Is there an easy way to select, say, the 15th row in a table? I can't
use a sequence number because rows will sometimes be deleted resulting
in the 15th row now being a different row. I need to be able to select
the 15th row regardless of
Would it be possible to report the integer_datetimes GUC in the V3
startup packet?
Currently if you want to use binary-format parameters or results that
might involve dates/times, you have to explicitly check
integer_datetimes first; this means another roundtrip on startup for
generic client
On Wed, 2004-08-04 at 14:53, Hicham G. Elmongui wrote:
Hi,
If I want the planner/optimizer to always choose merge join when it needs to
join relations. How can I do it ?
From my past experience, I'd guess what you're really trying to do is
STOP the planner from choosing a nested_loop join, in
I didn't mean about doing this from a front end. I want to disable
nested_loop and hash_join from the backend.
I tried to set the variables (enable_nestloop and enable_hashjoin) in
costsize.c, but this didn't do it.
Thanks,
--h
-Original Message-
From: Scott Marlowe [mailto:[EMAIL
As this is not really a hacking issue, I'm moving it out of hackers and
into general. Please post all replies there not in hackers.
Anyway, I'm afraid I'd have to ask WHY you're trying to just disable
it? Is the query planner making the wrong decision with good
statistics, or are you getting
Maybe I didn't make myself clear enough. I didn't have a problem with
postgresql. I am just playing around with the code, tracing some parts in
order to understand the code well.
This is just an experiment with the code. That's why I posted it to hackers.
Please let me know if this is still the
Tom Lane wrote:
In CVS tip, try running the regression tests against an installed
postmaster (ie, make installcheck); then as soon as the tests are
done, kill -9 the bgwriter process to force a database restart.
Most of the time you'll get a PANIC during recovery:
[...]
This is impossible
I disagree. There are many cases where it will work, and AFAIK none
in which you'll get worse than an error message. A couple of examples
where it works:
OK, fair enough.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
What we really need is dependencies within the function body and the
ability to clear the function cache (recompile).
Can the new function validator function for pl/pgsql add dependencies
perhaps?
Chris
---(end of broadcast)---
TIP 6: Have you
I didn't mean about doing this from a front end. I want to disable
nested_loop and hash_join from the backend.
I tried to set the variables (enable_nestloop and enable_hashjoin) in
costsize.c, but this didn't do it.
Turn them off in your postgresql.conf then.
Chris
---(end
If I want the planner/optimizer to always choose merge join when it needs to
join relations. How can I do it ?
You can't, unless in your transaction you set enable_nestloop,
enable_seqscan, etc. all to off except for the join type you want.
Chris
---(end of
Andreas Pflug [EMAIL PROTECTED] writes:
I don't have a problem with either way, but it appears desirable if
there would be a log_line_prefix option that gives identical result on
all systems.
Well, the Right Thing (TM) would be to use our src/timezone code instead
of the local C library.
Tom Lane said:
Since we do have control over the timezone library now, one possible
answer is to extend the src/timezone API so that it's possible to
convert/format against more than a single timezone. We could then
remember the zone setting inherited from the postmaster and always use
that
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 4 Aug 2004, Tom Lane wrote:
Not really. If the replay code encounters an update to a table file
that's not there, it simply creates the file and plows ahead. The thing
that I'm stuck on about tablespaces is that if the symlink in
On Wed, 4 Aug 2004, Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is impossible to fix nicely because the information to reconstruct
the tablespace is simply not available. We could make an ordinary
directory (not a symlink) under pg_tblspc and then limp
On Wed, 4 Aug 2004, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 4 Aug 2004, Tom Lane wrote:
Not really. If the replay code encounters an update to a table file
that's not there, it simply creates the file and plows ahead. The thing
that I'm stuck on about tablespaces
Tom Lane [EMAIL PROTECTED] writes:
However, this is probably a bit more work than is reasonable to
undertake right now, when we're already overdue for beta. For the
moment I'm really thinking that we ought to just #ifdef out the %Z
on Windows, and plan to do something nicer in 8.1.
Could
We do need to do that, but it will *not* solve this problem. The
scenario that causes the problem is
CREATE TABLESPACE
...
much time passes
...
CHECKPOINT
...
modify tables in tablespace
drop tables in tablespace
DROP
Tom Lane said:
The
scenario that causes the problem is
CREATE TABLESPACE
...
much time passes
...
CHECKPOINT
...
modify tables in tablespace
drop tables in tablespace
DROP TABLESPACE
...
system crash
Now the system
Gavin Sherry [EMAIL PROTECTED] writes:
CREATE TABLESPACE
...
much time passes
...
CHECKPOINT
...
modify tables in tablespace
drop tables in tablespace
DROP TABLESPACE
...
system crash
What happens here if no table spaces are
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, why is the symlink not going to be there already?
Because we removed it at the DROP TABLESPACE.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your
Uh, why is the symlink not going to be there already?
Because we removed it at the DROP TABLESPACE.
Maybe we could avoid removing it until the next checkpoint? Or is that
not enough. Maybe it could stay there forever :/
Chris
---(end of
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Maybe we could avoid removing it until the next checkpoint? Or is that
not enough. Maybe it could stay there forever :/
Part of the problem here is that this code has to serve several
purposes. We have different scenarios to worry about:
55 matches
Mail list logo
