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:
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 broadcast)---
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
Andrew Dunstan wrote:
> 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
> > .
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
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
>
> No
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 TABLESPA
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.
Co
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 abou
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
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
>> $PGD
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 along in the
>> expectation that it w
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
>
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.
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 broadcast)-
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 o
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 searc
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
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 impossib
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 wro
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 bad
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 PROTE
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,
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 d
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 whe
"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
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?
---
Andre
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.
Thanks,
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 zon
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 aver
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
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
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, plea
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
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 for
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 time
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
> 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 ind
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 c
> 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
http:
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 te
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
av
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 f
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
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.
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
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
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 th
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.
Blob.java
public long position(byte[] pattern, long start) throws SQLException
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
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 su
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
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 t
53 matches
Mail list logo
