Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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: * crash recovery from the most recent checkpoint * PITR replay over a long interval (many checkpoints) * recovery in the face of a partially corrupt filesystem It's the last one that is mostly bothering me at the moment. I don't want us to throw away data simply because the filesystem forgot an inode. Yeah, we might not have enough data in the WAL log to completely reconstruct a table, but we should push out what we do have, *not* toss it into the bit bucket. In the first case (straight crash recovery) I think it is true that any reference to a missing file is a reference to a file that will get deleted before recovery finishes. But I don't think that holds for PITR (we might be asked to stop short of where the table gets deleted) nor for the case where there's been filesystem damage. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 free space map settings
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 > > ... > > system crash > > > > Now the system needs to replay from the last checkpoint. It's going to > > hit updates to tables that aren't there anymore in a tablespace that's > > not there anymore. There will not be anything in the replayed part of > > the log that will give a clue where that tablespace was physically. > > > > Could we create the tables in the default tablespace? Or create a dummy > tablespace (since it's not there we expect it to be removed anyway, don't > we?) I guess the big danger would be running out of disk space, but maybe > that is a lower risk than this one. Uh, why is the symlink not going to be there already? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 involved? It just creates bogus tables with partial data counting on the restore to see the drop table command later and delete the corrupt tables? Does that pose any danger with PITR? The scenario above seems ok since if the PITR starting point is after the drop table/tablespace then presumably the recovery target has to be after that as well? Is there any other scenario where the partial data files could escape the recovery process? -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 needs to replay from the last checkpoint. It's going to > hit updates to tables that aren't there anymore in a tablespace that's > not there anymore. There will not be anything in the replayed part of > the log that will give a clue where that tablespace was physically. > Could we create the tables in the default tablespace? Or create a dummy tablespace (since it's not there we expect it to be removed anyway, don't we?) I guess the big danger would be running out of disk space, but maybe that is a lower risk than this one. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 TABLESPACE ... system crash Now the system needs to replay from the last checkpoint. It's going to hit updates to tables that aren't there anymore in a tablespace that's not there anymore. There will not be anything in the replayed part of the log that will give a clue where that tablespace was physically. Maybe we need to create a new system tablespace: pg_recovery Then when this situation occurs, if the tablespace cannot be located, we recrated the objects in the system 'pg_recovery' tablespace or something. I dunno :) Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Timezone for %t log_line_prefix
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 it just print numeric time zones on windows? -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 is that if the symlink in > >> $PGDATA/pg_tblspc isn't there, there's no evident way to recreate it > >> correctly --- we have no idea where it was supposed to point. > > > I don't think we have any choice but to log the symlink creation. Will > > this solve the problem? > > 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 TABLESPACE > ... > system crash > > Now the system needs to replay from the last checkpoint. It's going to > hit updates to tables that aren't there anymore in a tablespace that's > not there anymore. There will not be anything in the replayed part of > the log that will give a clue where that tablespace was physically. Ahh, yes of course. Seems like the best way would be to create the path under pg_tblspc as directories and plough ahead, like you said. The only alternatively that comes to mind is that we could keep all the directory structure and symlinks around until the next checkpoint. But that would be messy and may well not solve the problem anyway for things like PITR. Gavin ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 along in the > >> expectation that it would get removed before we finish replay. Or we > >> could just skip logged operations on files within the tablespace, but > >> that feels pretty uncomfortable to me --- it amounts to deliberately > >> discarding data ... > > > How is a dropped table handled by the recovery code? Doesn't it present > > the same sort of issues (though on a smaller scale)? > > 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 > $PGDATA/pg_tblspc isn't there, there's no evident way to recreate it > correctly --- we have no idea where it was supposed to point. I don't think we have any choice but to log the symlink creation. Will this solve the problem? Gavin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 >> $PGDATA/pg_tblspc isn't there, there's no evident way to recreate it >> correctly --- we have no idea where it was supposed to point. > I don't think we have any choice but to log the symlink creation. Will > this solve the problem? 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 TABLESPACE ... system crash Now the system needs to replay from the last checkpoint. It's going to hit updates to tables that aren't there anymore in a tablespace that's not there anymore. There will not be anything in the replayed part of the log that will give a clue where that tablespace was physically. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 would get removed before we finish replay. Or we >> could just skip logged operations on files within the tablespace, but >> that feels pretty uncomfortable to me --- it amounts to deliberately >> discarding data ... > How is a dropped table handled by the recovery code? Doesn't it present > the same sort of issues (though on a smaller scale)? 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 $PGDATA/pg_tblspc isn't there, there's no evident way to recreate it correctly --- we have no idea where it was supposed to point. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Timezone for %t log_line_prefix
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 when formatting timestamps for the log, while not changing the > behavior for operations at the SQL level. > > 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. > I think this counts as a bug, but I don't see that it needs to hold up the beta release - I am assuming we expect several betas before we go gold. Could it be fixed nicely in the next week or so? cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Timezone for %t log_line_prefix
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. The reason I didn't do that was that I thought the log timestamps shouldn't be affected by whatever TimeZone happens to be set in a particular backend. 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 when formatting timestamps for the log, while not changing the behavior for operations at the SQL level. 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. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] enforcing a join type
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)--- TIP 8: explain analyze is your friend
Re: [HACKERS] enforcing a join type
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 of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bug in ALTER COLUMN/TYPE
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 searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bug in ALTER COLUMN/TYPE
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
Re: [HACKERS] DROP TABLESPACE causes panic during recovery
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 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 would get removed before we finish replay. Or we > could just skip logged operations on files within the tablespace, but > that feels pretty uncomfortable to me --- it amounts to deliberately > discarding data ... > > Any thoughts? How is a dropped table handled by the recovery code? Doesn't it present the same sort of issues (though on a smaller scale)? -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] enforcing a join type
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 wrong place for this question. --h -Original Message- From: Scott Marlowe [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 6:42 PM To: Hicham G. Elmongui Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS] enforcing a join type 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 statistics? Can you post an explain analyze of the query(s) that are making you want to make this change? Just turning off a join method isn't the way to fix PostgreSQL, getting it to pick the right one is. On Wed, 2004-08-04 at 17:26, Hicham G. Elmongui wrote: > 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 PROTECTED] > Sent: Wednesday, August 04, 2004 5:41 PM > To: Hicham G. Elmongui > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] enforcing a join type > > 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 which case it's > quite easy: > > set enable_nestloop = off; > select * from ... > > Of course, you could apply the same basic trick to all other join > methods, and postgresql would then favor using the merge join. > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] enforcing a join type
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 statistics? Can you post an explain analyze of the query(s) that are making you want to make this change? Just turning off a join method isn't the way to fix PostgreSQL, getting it to pick the right one is. On Wed, 2004-08-04 at 17:26, Hicham G. Elmongui wrote: > 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 PROTECTED] > Sent: Wednesday, August 04, 2004 5:41 PM > To: Hicham G. Elmongui > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] enforcing a join type > > 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 which case it's > quite easy: > > set enable_nestloop = off; > select * from ... > > Of course, you could apply the same basic trick to all other join > methods, and postgresql would then favor using the merge join. > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] enforcing a join type
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 PROTECTED] Sent: Wednesday, August 04, 2004 5:41 PM To: Hicham G. Elmongui Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] enforcing a join type 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 which case it's quite easy: set enable_nestloop = off; select * from ... Of course, you could apply the same basic trick to all other join methods, and postgresql would then favor using the merge join. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] enforcing a join type
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 which case it's quite easy: set enable_nestloop = off; select * from ... Of course, you could apply the same basic trick to all other join methods, and postgresql would then favor using the merge join. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] making integer_datetimes report on startup
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 drivers such as JDBC (they don't know if they will encounter timestamps in results until it's too late, otherwise). -O ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Selecting a specific row
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 whether it is the same 15th row as the last > select. SQL itself has no natural ordering, so I'll assume you're doing something like this: select * from table order by seq_field Just add offset and limit to the end: select * from table order by seq_fields limit 1 offset 15; ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Selecting a specific row
"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 the same 15th row as the last > select. You can use LIMIT and OFFSET in your SELECT for this, but bear in mind that rows are not stored in any guaranteed order, so use ORDER BY if you need to. -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Timezone for %t log_line_prefix
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 Pflug wrote:
> 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 zone field *on Windows only* if there
> > is no %-spec that uses something more reasonable. I don't think this
> > problem justifies adding more %-options to log_line_prefix.
>
> 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.
>
> Regards,
> Andreas
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Selecting a specific row
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, Kenny Cason The Boeing Company ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Timezone for %t log_line_prefix
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 zone field *on Windows only* if there is no %-spec that uses something more reasonable. I don't think this problem justifies adding more %-options to log_line_prefix. 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. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Timezone for %t log_line_prefix
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 length. >> Do we have alternatives to the long form? Do we need the timezone >> information at all? We know already it's the server's time. Another >> alternative would be a short timestamp (%t vs. %T) to have both. > That's ugly, and unfortunately %z is GNU-specific. 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'd be inclined to leave out the zone field *on Windows only* if there is no %-spec that uses something more reasonable. I don't think this problem justifies adding more %-options to log_line_prefix. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PITR - recovery to a particular transaction
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 really > want is some indicator of when the commit occurred. > > Transaction 123 may have committed while 122 was still running. True. In fact this brings up a problem of using the xid for recovery stop. The interesting point is that you might recover to just before xact 123, but that doesn't mean you get xact 122. Still I think we need to add xid to the log_line_prefix for PITR and make it clear that specifying a recovery xid doesn't always include earlier xids. I have added this to the open items list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] enforcing a join type
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
Re: [HACKERS] More ALTER TABLE/TYPE bugs
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 send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Updateable Views?
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 fleshing out of the logic with some kind of > > stored proc to make the views and triggers would likely get someone > > started on the backend work. You know, a proof of concept thingy. > > I have some fears here. It seems everyone's first thought when they think > about updateable views is to think about constructing rules on the views. > > How would that approach help with inline views? Things like: > > UPDATE (SELECT a+b AS x, c AS y FROM foo) SET c=1 WHERE x = 10 > > It seems like starting with these types of views in the backend would be > more productive than implementing something in rules. Once postgres can > handle inline views it should be trivial to handle persistent views just > like they're handled on selects. I think you are putting the cart before the horse. We have to get things working and get the rules figured out before we can start modifying the backend. Once we get it all figured out, implemented, tested, and debugged, then maybe we can start considering modifying the backend. -- Jonathan Gardner [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Timezone for %t log_line_prefix
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? Do we need the timezone information at all? We know already it's the server's time. Another alternative would be a short timestamp (%t vs. %T) to have both. That's ugly, and unfortunately %z is GNU-specific. The quick fix for now does seem to be providing alternative forms - %T and %S make sense. Of course, if we wanted it *really* short we could just print out the current epoch time in 8 hex digits :-) cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Timezone for %t log_line_prefix
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 timezone information at all? We know already it's the server's time. Another alternative would be a short timestamp (%t vs. %T) to have both. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.5 backend crash
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 code, the intention was that should work. The DROP doesn't have to alter physical storage of the table, so there's no need for rowtype columns in other tables to change either. > the following select on table test1 will crash the back end > kalman=# select * from test1; > server closed the connection unexpectedly Fixed --- it was just an oversight in record_out(). regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PITR - recovery to a particular transaction
> 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 indicator of when the commit occurred. Transaction 123 may have committed while 122 was still running. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PITR - recovery to a particular transaction
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 away with adding transaction ID as one of the > available %-items in log_line_prefix. I'm not sure how useful this > really is though --- timestamps are probably more useful overall to > have in your log. Why not both? 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 happened at time x so do PITR up to x - 1 second"; the latter might miss several tranactions. Have I got the concepts wrong here? > The direction I was expecting we'd head in is to > provide WAL logfile examination tools. But that's not going to happen for 8.0, so any means of getting the transaction id is better than none. -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA "And not only so, but we glory in tribulations also; knowing that tribulation worketh patience; And patience, experience; and experience, hope." Romans 5:3,4 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] postgres and Jdbc 2.0
> 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://gborg.postgresql.org/project/pgjdbc/projdisplay.php which as Dave mentioned has implemented some of these methods already. As to whether anything needs to be added to the server, that depends on your implementation. The Blob/Clob positioning seems like it could be done more efficiently on the server side. Also the server doesn't have a Ref datatype, so you really can't implement get/setRef without it. Kris Jurka ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] DROP TABLESPACE causes panic during recovery
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 terminated by signal 9
LOG: server process (PID 2493) was terminated by signal 9
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2004-08-04 14:26:23 EDT
LOG: checkpoint record is at 0/4C1CA28
LOG: redo record is at 0/4BFD510; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 11269; next OID: 294376
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 0/4BFD510
PANIC: could not create directory
"/home/postgres/testversion/data/pg_tblspc/301180/163304": No such file or directory
LOG: startup process (PID 4560) was terminated by signal 6
LOG: aborting startup due to startup process failure
The panic is here:
(gdb) bt
#0 0xc0141220 in ?? () from /usr/lib/libc.1
#1 0xc00aa7ec in ?? () from /usr/lib/libc.1
#2 0xc008c2b8 in ?? () from /usr/lib/libc.1
#3 0xc0086d9c in ?? () from /usr/lib/libc.1
#4 0x2c6080 in errfinish (dummy=1) at elog.c:454
#5 0x185984 in TablespaceCreateDbspace (spcNode=1074100592, dbNode=0,
isRedo=1 '\001') at tablespace.c:140
#6 0x23c90c in smgrcreate (reln=0x400a1d80, isTemp=0 '\000', isRedo=1 '\001')
at smgr.c:327
#7 0x23d6cc in smgr_redo (lsn={xlogid = 0, xrecoff = 86455912},
record=0x40067be8) at smgr.c:876
#8 0x115714 in StartupXLOG () at xlog.c:4229
#9 0x11dc5c in BootstrapMain (argc=4, argv=0x7b03b630) at bootstrap.c:426
#10 0x20b7dc in StartChildProcess (xlop=2) at postmaster.c:3233
and of course the problem is that log replay is not prepared to cope
with a reference to a table that's in a tablespace that no longer
exists. The regression tests trigger the problem because they do a
DROP TABLESPACE near the end.
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 would get removed before we finish replay. Or we
could just skip logged operations on files within the tablespace, but
that feels pretty uncomfortable to me --- it amounts to deliberately
discarding data ...
Any thoughts?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PITR - recovery to a particular transaction
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 available %-items in log_line_prefix. I'm not sure how useful this really is though --- timestamps are probably more useful overall to have in your log. The direction I was expecting we'd head in is to provide WAL logfile examination tools. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgxs: build infrastructure for extensions v4
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 fixed in pg_config.c I think - should be a one-liner.
If the attached looks correct I'll apply it.
Joe
Index: src/bin/pg_config/pg_config.c
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_config/pg_config.c,v
retrieving revision 1.3
diff -c -r1.3 pg_config.c
*** src/bin/pg_config/pg_config.c 2 Aug 2004 12:34:14 - 1.3
--- src/bin/pg_config/pg_config.c 4 Aug 2004 18:00:51 -
***
*** 141,147
else if (strcmp(argv[i],"--pgxs") == 0)
{
get_pkglib_path(mypath,otherpath);
! strncat(otherpath, "/pgxs", MAXPGPATH-1);
}
printf("%s\n",otherpath);
--- 141,147
else if (strcmp(argv[i],"--pgxs") == 0)
{
get_pkglib_path(mypath,otherpath);
! strncat(otherpath, "/pgxs/src/makefiles/pgxs.mk", MAXPGPATH-1);
}
printf("%s\n",otherpath);
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Anybody have an Oracle PL/SQL reference at hand?
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 syntax. They wouldn't actually *do* anything, but > >they would make the code look more like its Oracle equivalent. I'm not > >for this, but maybe someone wants to make the case for it? > > So long as I can emulate SQL MERGE with it, I'm happy. ie. I need a > solution to the 'try update, if no rows changed then insert (unique > index)' common race condition issue. If I cannot keep looping that > until it succeeds, then exceptions don't help me... Honestly, I'd *love* to see a merge command built in, assuming it's not very difficult. I would think that having the database handle this internally would be much more performant than using pgsql for it. > Chris > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command >(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PITR - recovery to a particular transaction
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 can specify the stop point either by > date/time or by transaction ID. As of this writing only the > date/time option is very usable, since there are no tools to > help you identify which transaction ID to use. > > 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? > -- > Oliver Elphick [EMAIL PROTECTED] > Isle of Wight http://www.lfix.co.uk/oliver > GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA > > "And not only so, but we glory in tribulations also; > knowing that tribulation worketh patience; And > patience, experience; and experience, hope." > Romans 5:3,4 > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] PITR - recovery to a particular transaction
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 either by date/time or by transaction ID. As of this writing only the date/time option is very usable, since there are no tools to help you identify which transaction ID to use. 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? -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA "And not only so, but we glory in tribulations also; knowing that tribulation worketh patience; And patience, experience; and experience, hope." Romans 5:3,4 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Preliminary PITR documentation available
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 parallel universes." > > Is it science-fiction, or just relativity? Depends on how fast you read it. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres and Jdbc 2.0
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 > 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 > > Clob.java > public long position(String pattern, long start) throws SQLException > public long position(Clob pattern, long start) throws SQLException > > Connection.java > public Object getObject(String type, String value) throws SQLException > > DatabaseMetaData.java > public java.sql.ResultSet getUDTs(String catalog,String > schemaPattern,String typeNamePattern,int[] types) throws SQLException > > ResultSet.java > public Object getObject(int i, java.util.Map map) throws SQLException > public Ref getRef(int i) throws SQLException > public void setFetchDirection(int direction) throws SQLException > public boolean rowDeleted() throws SQLException > public boolean rowInserted() throws SQLException > public boolean rowUpdated() throws SQLException > > Statement.java > public int getFetchDirection() throws SQLException > public void setFetchDirection(int direction) throws SQLException > public void setRef(int i, Ref x) throws SQLException > public Blob getBlob(int i) throws SQLException > public Clob getClob(int i) throws SQLException > public Object getObject(int i, java.util.Map map) throws SQLException > public Ref getRef(int i) throws SQLException > public java.sql.Date getDate(int i, java.util.Calendar cal) throws > SQLException > public Time getTime(int i, java.util.Calendar cal) throws SQLException > public Timestamp getTimestamp(int i, java.util.Calendar cal) throws > SQLException > public void registerOutParameter(int parameterIndex, int sqlType, > String typeName) throws SQLException > public java.sql.Array getArray(int i) throws SQLException > > Array.java > public Object getArray(long index, int count, Map map) throws > SQLException > public java.sql.ResultSet getResultSet(long index, int count, > java.util.Map map) throws SQLException > > > > There are a few things which I want to know. > > 1) Is there anything more which I am missing wrt JDBC 2.0 and postgres. > > 2) If I want to add these features to JDBC driver, is there anything > that has to go to database itself. > > > thanks > naveen > > -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] postgres and Jdbc 2.0
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 Clob.java public long position(String pattern, long start) throws SQLException public long position(Clob pattern, long start) throws SQLException Connection.java public Object getObject(String type, String value) throws SQLException DatabaseMetaData.java public java.sql.ResultSet getUDTs(String catalog,String schemaPattern,String typeNamePattern,int[] types) throws SQLException ResultSet.java public Object getObject(int i, java.util.Map map) throws SQLException public Ref getRef(int i) throws SQLException public void setFetchDirection(int direction) throws SQLException public boolean rowDeleted() throws SQLException public boolean rowInserted() throws SQLException public boolean rowUpdated() throws SQLException Statement.java public int getFetchDirection() throws SQLException public void setFetchDirection(int direction) throws SQLException public void setRef(int i, Ref x) throws SQLException public Blob getBlob(int i) throws SQLException public Clob getClob(int i) throws SQLException public Object getObject(int i, java.util.Map map) throws SQLException public Ref getRef(int i) throws SQLException public java.sql.Date getDate(int i, java.util.Calendar cal) throws SQLException public Time getTime(int i, java.util.Calendar cal) throws SQLException public Timestamp getTimestamp(int i, java.util.Calendar cal) throws SQLException public void registerOutParameter(int parameterIndex, int sqlType, String typeName) throws SQLException public java.sql.Array getArray(int i) throws SQLException Array.java public Object getArray(long index, int count, Map map) throws SQLException public java.sql.ResultSet getResultSet(long index, int count, java.util.Map map) throws SQLException There are a few things which I want to know. 1) Is there anything more which I am missing wrt JDBC 2.0 and postgres. 2) If I want to add these features to JDBC driver, is there anything that has to go to database itself. thanks naveen -- "Stand for something, or you will fall for nothing." ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bug in ALTER COLUMN/TYPE
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 where it works: regression=# create table test (f1 int); CREATE TABLE regression=# insert into test values(42); INSERT 155117 1 regression=# create function test () returns setof test as regression-# 'select * from test' language sql; CREATE FUNCTION regression=# alter table test add column f2 text default 'foo'; ALTER TABLE regression=# select * from test(); f1 | f2 +- 42 | foo (1 row) regression=# alter table test alter f1 type bigint; ALTER TABLE regression=# select * from test(); f1 | f2 +- 42 | foo (1 row) regression=# regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgxs: build infrastructure for extensions v4
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 suggested that I needed to do the following to include the pgxs.mk: # Use the following layout for your Makefile: # # [variable assignments, see below] # [custom rules, rarely necessary] # # PGXS := $(shell pg_config --pgxs) # include $(PGXS) However, on my CVS version from about an hour ago, I needed to change this to: PGXS := $(shell pg_config --pgxs)/src/makefiles/pgxs.mk include $(PGXS) 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 fixed in pg_config.c I think - should be a one-liner. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items
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 with s/7.5/8.0/ ... Done. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pgxs: build infrastructure for extensions v4
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 to do the following to include the pgxs.mk: # Use the following layout for your Makefile: # # [variable assignments, see below] # [custom rules, rarely necessary] # # PGXS := $(shell pg_config --pgxs) # include $(PGXS) However, on my CVS version from about an hour ago, I needed to change this to: PGXS := $(shell pg_config --pgxs)/src/makefiles/pgxs.mk include $(PGXS) 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? Kind regards, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
