Re: [HACKERS] Upgrading my BSDI box, again

[Patrick Welche]

On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote:
> 
> [ CC to Kurt and Steven on bsdi list.]
> 
> Guys, I just replied to this email on the BSDi email list.  The issue is
> that someone found that some(most?) IDE drives have write cache enabled,
> though the drives do not preserve the write cache data on power failure.
> 
> I am surprised we have not heard of this failure before because I know
> most vendors who ship PostgreSQL test our crash recovery thoroughly. 
> Are they testing only using SCSI drives?
> 
> Below you will read that my Seagate SCSI drive has write cache disabled,
> but another guy has a Seagate IDE drive that has it enabled, though it
> loses data on power failure.
> 
> Scarey!
> 
> Does anyone have any more detailed information on this?

Not really, just that I had data corruption on SCSI disks which had write
cache enabled and tagged queueing. Disabling write cache has allowed them
to function flawlessly since. The moral seems to be: write cache gives
pretty performance figures, but you really want it swiched off.

Cheers,

Patrick

---(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] Feature request -- Log Database Name

[ohp]

On Mon, 28 Jul 2003, Tom Lane wrote:

> Date: Mon, 28 Jul 2003 21:39:23 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Robert Treat <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], Larry Rosenman <[EMAIL PROTECTED]>,
>  Josh Berkus <[EMAIL PROTECTED]>,
>  pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Feature request -- Log Database Name
>
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I think better would be a GUC "log_to_table" which wrote all standard
> > out/err to a pg_log table.  of course, I doubt you could make this
> > foolproof (how to log startup errors in this table?) but it could be a
> > start.
>
> How would a failed transaction make any entries in such a table?  How
> would you handle maintenance operations on the table that require
> exclusive lock?  (vacuum full, reindex, etc)
>
> It seems possible that you could make this work if you piped stderr to a
> buffering process that was itself a database client, and issued INSERTs
> to put the rows into the table, and could buffer pending data whenever
> someone else had the table locked (eg for vacuum).  I'd not care to try
> to get backends to do it locally.
>
>   regards, tom lane
Not quite, my goal is to have a log per database, the stderr dosn't
contain enough information to split it.

As an ISP, I would like that each customer having one or more databases
being able to see any error on their database.
I imagine have a log file per database would be toot complicated...
>

-- 
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou   +33-5-61-50-97-01 (Fax)
31190 AUTERIVE   +33-6-07-63-80-64 (GSM)
FRANCE  Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] using adbin, conbin, etc.

[Tom Lane]

Rod Taylor <[EMAIL PROTECTED]> writes:
> On Tue, 2003-07-29 at 21:45, Christopher Kings-Lynne wrote:
>> I hear that we're supposed to use the 'bin' versions of the 'src' columns
>> where possible. I would like then to use them in phpPgAdmin for displaying
>> defaults and stuff.  Is there some way to use them from SQL?  Cos it all
>> looks like garbage to me :)

> Use the various pg_get_...() functions wherever you can.

And if you can't find one that does what you want, ask for it.
The last thing we want is client-side code digging into those internal
representations --- we change 'em frequently.

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] bug in current_timestamp(1)

[Tom Lane]

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Going from precision 3 down to 0 - note the bug in (1).  It always displays
> a trailing zero.

It's not a bug, it's a feature, or at least Tom Lockhart once thought so.
See TrimTrailingZeros() in datetime.c:
/* chop off trailing zeros... but leave at least 2 fractional digits */

I don't recall the history behind that choice, and I'm disinclined to
mess with it without knowing why it was set up to do that.  I have a
feeling it might have something to do with compatibility with some
non-Postgres code.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Feature request -- Log Database Name

[Andrew Dunstan]

There seem to be 2 orthogonal issues here - in effect how to log and 
where to log. I had a brief look and providing an option to log the 
dbname where appropriate seems to be quite easy - unless someone else is 
already doing it I will look at it on the weekend. Assuming that were 
done you could split the log based on dbname.

For the reasons Tom gives, logging to a table looks much harder and 
possibly undesirable - I would normally want my log table(s) in a 
different database, possibly even on a different machine, from my 
production transactional database. However, an ISP might want to provide 
the logs for each client in their designated db. It therefore seems to 
me far more sensible to do load logs into tables out of band as Tom 
suggests, possibly with some helper tools in contrib to parse the logs, 
or even to load them in more or less real time (many tools exist to do 
this sort of thing for web logs, so it is hardly rocket science - 
classic case for a perl script ;-).

cheers

andrew

[EMAIL PROTECTED] wrote:

On Mon, 28 Jul 2003, Tom Lane wrote:

 

Date: Mon, 28 Jul 2003 21:39:23 -0400
From: Tom Lane <[EMAIL PROTECTED]>
To: Robert Treat <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Larry Rosenman <[EMAIL PROTECTED]>,
Josh Berkus <[EMAIL PROTECTED]>,
pgsql-hackers list <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] Feature request -- Log Database Name
Robert Treat <[EMAIL PROTECTED]> writes:
   

I think better would be a GUC "log_to_table" which wrote all standard
out/err to a pg_log table.  of course, I doubt you could make this
foolproof (how to log startup errors in this table?) but it could be a
start.
 

How would a failed transaction make any entries in such a table?  How
would you handle maintenance operations on the table that require
exclusive lock?  (vacuum full, reindex, etc)
It seems possible that you could make this work if you piped stderr to a
buffering process that was itself a database client, and issued INSERTs
to put the rows into the table, and could buffer pending data whenever
someone else had the table locked (eg for vacuum).  I'd not care to try
to get backends to do it locally.
			regards, tom lane
   

Not quite, my goal is to have a log per database, the stderr dosn't
contain enough information to split it.
As an ISP, I would like that each customer having one or more databases
being able to see any error on their database.
I imagine have a log file per database would be toot complicated...
 

 



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [GENERAL] concurrent writes

[Andrew Sullivan]

On Tue, Jul 29, 2003 at 01:07:57PM +0200, Andreas Jung wrote:
> 
> This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3.
> Our administrator complained that there has not been a notice in the
> CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-)

I think your administrator is talking out of his hat.  We switch back
and forth between Linux and Solaris all the time here, and PostgreSQL
works the same all the time.

A

-- 

Andrew Sullivan 204-4141 Yonge Street
Liberty RMS   Toronto, Ontario Canada
<[EMAIL PROTECTED]>  M2P 2A8
 +1 416 646 3304 x110


---(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

[HACKERS] psql no longer handles fatal/panic errors well

[Tom Lane]

The following test cases were created by modifying int4div and int2div
to produce FATAL and PANIC, respectively, instead of plain ERROR for
division-by-zero.

Using an older psql, all is well:

template1=# select 2/0;
FATAL:  division by zero
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
template1=# select 1::int2/0::int2;
PANIC:  division by zero
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!# 

Using CVS-tip psql, things are weird:

template1=# select 2/0;
The connection to the server was lost. Attempting reset: Succeeded.
FATAL:  division by zero
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
template1=# select 1::int2/0::int2;
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL
!> 

It seems odd that the FATAL error is reported after, rather than before,
the reconnection attempt; and it's really not acceptable to lose the
PANIC message entirely.

I checked that the server does still fflush the message before dying,
so the problem is on the client side.  It's possible that my recent
libpq hacks have something to do with it, but I don't think libpq is
at fault for the connection retry occuring before the message is
printed.  Any idea what was changed?

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] psql no longer handles fatal/panic errors well

[Tom Lane]

I said:
> It seems odd that the FATAL error is reported after, rather than before,
> the reconnection attempt; and it's really not acceptable to lose the
> PANIC message entirely.

Also, both classes of messages seem to be dropped if psql is not running
interactively (probably since it exits without trying to reconnect).
If I run the regression tests against my hacked backend, the errors test
fails with:

--- 241,244 
  -- Check that division-by-zero is properly caught.
  --
  select 1/0;
! connection to server was lost

==

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Upgrading my BSDI box, again

[Andrew Sullivan]

On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote:
> Guys, I just replied to this email on the BSDi email list.  The issue is
> that someone found that some(most?) IDE drives have write cache enabled,
> though the drives do not preserve the write cache data on power failure.

It's yet worse than this.  Some IDE drives will respond to the
command to turn off write cacheing, but they _don't actually turn it
off_.  In other words, you think you've done the right thing, and you
haven't anyway.

A

-- 

Andrew Sullivan 204-4141 Yonge Street
Liberty RMS   Toronto, Ontario Canada
<[EMAIL PROTECTED]>  M2P 2A8
 +1 416 646 3304 x110


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

[HACKERS] pkglibdir versus libdir?

[Tom Lane]

Peter, I'm a little confused about the difference between the libdir and
pkglibdir settings created by configure.  What's supposed to go where?

I got a complaint from a Red Hat person that the regression tests failed
on a 64-bit machine.  Some investigation revealed that the problem was
that plpgsql.so got installed into $libdir while pg_regress.sh expected
to find it in $pkglibdir.  (The fact that they were different was an
RPM configuration bug, but if we are going to have two variables we
certainly ought to support their being different...)  I don't know how
to decide which one is wrong.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Feature request -- Log Database Name

[Bruce Momjian]

One idea would be to output log information as INSERT statements, so we
could log connection/dbname/username to one table, and per-session
information to another table, and server-level info in a third table.

If you want to analyze the logs, you could load the data into a database
via inserts, and even do joins and analyze the output using SQL!

This would solve the problem of failed transactions exporting
information, would not be extra overhead for every log message, and
would handle the problem of analyzing the log tables while the system
was running and continuing to emit more log output.

---

Andrew Dunstan wrote:
> There seem to be 2 orthogonal issues here - in effect how to log and 
> where to log. I had a brief look and providing an option to log the 
> dbname where appropriate seems to be quite easy - unless someone else is 
> already doing it I will look at it on the weekend. Assuming that were 
> done you could split the log based on dbname.
> 
> For the reasons Tom gives, logging to a table looks much harder and 
> possibly undesirable - I would normally want my log table(s) in a 
> different database, possibly even on a different machine, from my 
> production transactional database. However, an ISP might want to provide 
> the logs for each client in their designated db. It therefore seems to 
> me far more sensible to do load logs into tables out of band as Tom 
> suggests, possibly with some helper tools in contrib to parse the logs, 
> or even to load them in more or less real time (many tools exist to do 
> this sort of thing for web logs, so it is hardly rocket science - 
> classic case for a perl script ;-).
> 
> cheers
> 
> andrew
> 
> 
> [EMAIL PROTECTED] wrote:
> 
> >On Mon, 28 Jul 2003, Tom Lane wrote:
> >
> >  
> >
> >>Date: Mon, 28 Jul 2003 21:39:23 -0400
> >>From: Tom Lane <[EMAIL PROTECTED]>
> >>To: Robert Treat <[EMAIL PROTECTED]>
> >>Cc: [EMAIL PROTECTED], Larry Rosenman <[EMAIL PROTECTED]>,
> >> Josh Berkus <[EMAIL PROTECTED]>,
> >> pgsql-hackers list <[EMAIL PROTECTED]>
> >>Subject: Re: [HACKERS] Feature request -- Log Database Name
> >>
> >>Robert Treat <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>>I think better would be a GUC "log_to_table" which wrote all standard
> >>>out/err to a pg_log table.  of course, I doubt you could make this
> >>>foolproof (how to log startup errors in this table?) but it could be a
> >>>start.
> >>>  
> >>>
> >>How would a failed transaction make any entries in such a table?  How
> >>would you handle maintenance operations on the table that require
> >>exclusive lock?  (vacuum full, reindex, etc)
> >>
> >>It seems possible that you could make this work if you piped stderr to a
> >>buffering process that was itself a database client, and issued INSERTs
> >>to put the rows into the table, and could buffer pending data whenever
> >>someone else had the table locked (eg for vacuum).  I'd not care to try
> >>to get backends to do it locally.
> >>
> >>regards, tom lane
> >>
> >>
> >Not quite, my goal is to have a log per database, the stderr dosn't
> >contain enough information to split it.
> >
> >As an ISP, I would like that each customer having one or more databases
> >being able to see any error on their database.
> >I imagine have a log file per database would be toot complicated...
> >  
> >
> >
> >  
> >
> 
> 
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  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 8: explain analyze is your friend

Re: [HACKERS] Feature request -- Log Database Name

[Andrew Dunstan]

That assumes we know what the shape of the log tables will be, but this 
isn't quite clear to me - I can imagine it being different for different 
needs.  Having an external program to parse the logs into INSERT 
statements would not be hard, anyway, so I'm not sure that this would 
buy us much. I'll think about it more. In any case, it should be done in 
stages, I think, with the first stage simply being what we do now with 
the optional dbname field added.

cheers

andrew

Bruce Momjian wrote:

One idea would be to output log information as INSERT statements, so we
could log connection/dbname/username to one table, and per-session
information to another table, and server-level info in a third table.
If you want to analyze the logs, you could load the data into a database
via inserts, and even do joins and analyze the output using SQL!
This would solve the problem of failed transactions exporting
information, would not be extra overhead for every log message, and
would handle the problem of analyzing the log tables while the system
was running and continuing to emit more log output.
---

Andrew Dunstan wrote:
 

There seem to be 2 orthogonal issues here - in effect how to log and 
where to log. I had a brief look and providing an option to log the 
dbname where appropriate seems to be quite easy - unless someone else is 
already doing it I will look at it on the weekend. Assuming that were 
done you could split the log based on dbname.

For the reasons Tom gives, logging to a table looks much harder and 
possibly undesirable - I would normally want my log table(s) in a 
different database, possibly even on a different machine, from my 
production transactional database. However, an ISP might want to provide 
the logs for each client in their designated db. It therefore seems to 
me far more sensible to do load logs into tables out of band as Tom 
suggests, possibly with some helper tools in contrib to parse the logs, 
or even to load them in more or less real time (many tools exist to do 
this sort of thing for web logs, so it is hardly rocket science - 
classic case for a perl script ;-).

cheers

andrew

   



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Feature request -- Log Database Name

[Josh Berkus]

Guys:

> That assumes we know what the shape of the log tables will be, but this 
> isn't quite clear to me - I can imagine it being different for different 
> needs.  Having an external program to parse the logs into INSERT 
> statements would not be hard, anyway, so I'm not sure that this would 
> buy us much. I'll think about it more. In any case, it should be done in 

My simple suggestion would be to have the option of outputting log entries as 
tab-delimited data.   Then the admin could very easily write a script to load 
it into a table or tables; we could even supply a sample perl script on 
techdocs or somewhere.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Feature request -- Log Database Name

[Bruce Momjian]

I was thinking of outputing CREATE TABLE at the start of the log file.

I see what you mean that the schemas could be different, so we would
have to output the relevant fields all the time, like timestamp and
username, but because the username would be joined, you would only
output it on connection start, and not for each output line.

---

Andrew Dunstan wrote:
> 
> That assumes we know what the shape of the log tables will be, but this 
> isn't quite clear to me - I can imagine it being different for different 
> needs.  Having an external program to parse the logs into INSERT 
> statements would not be hard, anyway, so I'm not sure that this would 
> buy us much. I'll think about it more. In any case, it should be done in 
> stages, I think, with the first stage simply being what we do now with 
> the optional dbname field added.
> 
> cheers
> 
> andrew
> 
> Bruce Momjian wrote:
> 
> >One idea would be to output log information as INSERT statements, so we
> >could log connection/dbname/username to one table, and per-session
> >information to another table, and server-level info in a third table.
> >
> >If you want to analyze the logs, you could load the data into a database
> >via inserts, and even do joins and analyze the output using SQL!
> >
> >This would solve the problem of failed transactions exporting
> >information, would not be extra overhead for every log message, and
> >would handle the problem of analyzing the log tables while the system
> >was running and continuing to emit more log output.
> >
> >---
> >
> >Andrew Dunstan wrote:
> >  
> >
> >>There seem to be 2 orthogonal issues here - in effect how to log and 
> >>where to log. I had a brief look and providing an option to log the 
> >>dbname where appropriate seems to be quite easy - unless someone else is 
> >>already doing it I will look at it on the weekend. Assuming that were 
> >>done you could split the log based on dbname.
> >>
> >>For the reasons Tom gives, logging to a table looks much harder and 
> >>possibly undesirable - I would normally want my log table(s) in a 
> >>different database, possibly even on a different machine, from my 
> >>production transactional database. However, an ISP might want to provide 
> >>the logs for each client in their designated db. It therefore seems to 
> >>me far more sensible to do load logs into tables out of band as Tom 
> >>suggests, possibly with some helper tools in contrib to parse the logs, 
> >>or even to load them in more or less real time (many tools exist to do 
> >>this sort of thing for web logs, so it is hardly rocket science - 
> >>classic case for a perl script ;-).
> >>
> >>cheers
> >>
> >>andrew
> >>
> >>
> >>
> >>
> 
> 
> 
> ---(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 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] Feature request -- Log Database Name

[Bruce Momjian]

Josh Berkus wrote:
> Guys:
> 
> > That assumes we know what the shape of the log tables will be, but this 
> > isn't quite clear to me - I can imagine it being different for different 
> > needs.  Having an external program to parse the logs into INSERT 
> > statements would not be hard, anyway, so I'm not sure that this would 
> > buy us much. I'll think about it more. In any case, it should be done in 
> 
> My simple suggestion would be to have the option of outputting log entries as 
> tab-delimited data.   Then the admin could very easily write a script to load 
> it into a table or tables; we could even supply a sample perl script on 
> techdocs or somewhere.

The problem with that is needing to output to multiple tables ---
session-level, query-level, and server-level tables.

-- 
  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 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] Upgrading my BSDI box, again

[Bruce Momjian]

Andrew Sullivan wrote:
> On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote:
> > Guys, I just replied to this email on the BSDi email list.  The issue is
> > that someone found that some(most?) IDE drives have write cache enabled,
> > though the drives do not preserve the write cache data on power failure.
> 
> It's yet worse than this.  Some IDE drives will respond to the
> command to turn off write cacheing, but they _don't actually turn it
> off_.  In other words, you think you've done the right thing, and you
> haven't anyway.

Is there an interface to control this with IDE drives? I know there is
scsicmd for SCSI, but I didn't think IDE had any similar interface to
control the drive.

-- 
  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] Upgrading my BSDI box, again

[Þórhallur Hálfdánarson]

Something similar to Linux's hdparm ?

http://www.google.com/search?q=hdparm%20bsd

-*- Bruce Momjian <[EMAIL PROTECTED]> [ 2003-07-30 19:41 ]:
> Andrew Sullivan wrote:
> > On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote:
> > > Guys, I just replied to this email on the BSDi email list.  The issue is
> > > that someone found that some(most?) IDE drives have write cache enabled,
> > > though the drives do not preserve the write cache data on power failure.
> > 
> > It's yet worse than this.  Some IDE drives will respond to the
> > command to turn off write cacheing, but they _don't actually turn it
> > off_.  In other words, you think you've done the right thing, and you
> > haven't anyway.
> 
> Is there an interface to control this with IDE drives? I know there is
> scsicmd for SCSI, but I didn't think IDE had any similar interface to
> control the drive.
> 
> -- 
>   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

-- 
Kveðja,
Tolli
[EMAIL PROTECTED]

---(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] Upgrading my BSDI box, again

[Lamar Owen]

On Wednesday 30 July 2003 15:39, Bruce Momjian wrote:
> Andrew Sullivan wrote:
> > It's yet worse than this.  Some IDE drives will respond to the
> > command to turn off write cacheing, but they _don't actually turn it
> > off_.  In other words, you think you've done the right thing, and you
> > haven't anyway.

> Is there an interface to control this with IDE drives? I know there is
> scsicmd for SCSI, but I didn't think IDE had any similar interface to
> control the drive.

What Andrew is saying is that on some IDE drives it doesn't matter what the OS 
tells the drive to do.  According to the Linux hdparm man page, the desired 
flag is '-W':

   -W Disable/enable the IDE drive’s  write-caching  feature  (default
  state is undeterminable; manufacturer/model specific).

-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Upgrading my BSDI box, again

[Christopher Browne]

Bruce Momjian wrote:
> Andrew Sullivan wrote: 
> > On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote: 
> > > Guys, I just replied to this email on the BSDi email list.  The issue is 
> > > that someone found that some(most?) IDE drives have write cache enabled, 
> > > though the drives do not preserve the write cache data on power failure. 
> >  
> > It's yet worse than this.  Some IDE drives will respond to the 
> > command to turn off write cacheing, but they _don't actually turn it 
> > off_.  In other words, you think you've done the right thing, and you 
> > haven't anyway. 

> Is there an interface to control this with IDE drives? I know there
> is scsicmd for SCSI, but I didn't think IDE had any similar
> interface to control the drive.

On Linux, there's something called "hdparm."  There could be something
analogous, but that misses Andrew's point.

The point is that even if you have a utility that can modify caching
parameters, this is increasingly unlikely to do you any good, because
the hard drive may be lying to you.

The drive happily reports back "Yup!  I shut the cache off for you!"

But then proceeds to cache writes anyways, because it was lying when
it said it shut it off.

What OS you're using is irrelevant if the hardware is lying to you.
-- 
(format nil "[EMAIL PROTECTED]" "cbbrowne" "libertyrms.info")

Christopher Browne
(416) 646 3304 x124 (land)

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Some macros for error field codes

[Bruce Momjian]

Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> >>> Should we create some user-friendly macros for the error field codes?
> 
> > I was actually talking of the single-letter codes that are used on the
> > protocol layer to tag the different fields of an error or notice result.
> 
> Oh, those things.  Sure, if you like, though it might be just namespace
> clutter.

Seems it documents the code more clearly.

-- 
  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 8: explain analyze is your friend

Re: [HACKERS] Warning for undefined cursor

[Bruce Momjian]

Peter, you have brought up some good items recently.  Are you going to
handle them or do you want them added to the TODO list or 7.4 open items
list.


---

Peter Eisentraut wrote:
> In backend/commands/portalcmds.c we have
> 
> /* FIXME: shouldn't this be an ERROR? */
> ereport(WARNING,
> (errcode(ERRCODE_UNDEFINED_CURSOR),
>  errmsg("portal \"%s\" does not exist", stmt->portalname)));
> 
> The effect of this is that you can fetch from an undefined cursor and
> (successfully) get zero rows plus this warning.  I propose that we change
> this to an error.  Does anyone see a reason against this, except possibly
> bugward compatibility?
> 
> -- 
> Peter Eisentraut   [EMAIL PROTECTED]
> 
> ---(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 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

[HACKERS] File Cache

[Nailah Ogeer]

Just wondering if you shut down postmaster and restart, if the contents of
the file cache are written out to disk or still in the file cache. In
other words, will the number of transactions per second change if you shut
down postmaster and restart compared to restarting the machine
thanks
nailah



---(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] Is Patch Ok for deferred trigger disk queue?

[Bruce Momjian]

Stuart wrote:
> Sorry for the tardiness in replying, I've been away for the past week or so.
> I didn't intend for 7.4 partly because I knew I'd be away & partly 
> because I had seen there was a problem I hadn't realised with the 
> previous patch and didn't want to submit something that may not be 
> stable just before beta. Currently it compiles but there are some, er, 
> issues - shouldn't take to long to fix but it might not be till 
> wednesday as I've got a bit of a backlog to get through.
> I could use sortmem, but if this is to be the case maybe there should be 
> a change the call it something like max_local_mem with a way to register 
> that you are using it. Maybe the memory allocs could automatically add 
> to it and remove as memory is assigned. Alternativly just make a global 
> to record the memory currently used by interested parties (currently the 
> trigger & sortmem I'd guess). The only trouble with this that I can see 
> is that the first one to claim the memory may claim it all, leaving 
> nothing for the other. I'll carry on using the dedicated guc variable 
> for the moment as I can't really see the correct way to solve this cleanly.
> regards,

OK, we can do the trigger queue file for 7.5.  The issue with sortmem is
that its effect is to spill a sort out to file when it gets too large,
the same for the trigger queue representation.  We could rename it, but
because it is _mostly_ used for sorts, we would probably keep the name
the same and just mention the trigger queue effect in the docs.

-- 
  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 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] now about psql and one function

[Bruce Momjian]

Why would someone not have the ability to read pg_user?  The query is
gone in 7.4 anyway.

---

ivan wrote:
> 
> in psql , file command.c : 1473 there is a query to check state for
> superuser, and this query is in begin/end transaction.
> When user dont have perm to read pg_user its fail but transation is never
> end, and ist make some confusion because user have to write "END;" or
> "ROLLBACK;" themself. I just removed BEGIN and END from this query.
> 
> 
> ok, and this function :
> create or replace func () returns INT  as '
> DECLARE
>  cnt INT;
> BEGIN
>  CREATE TEMP TABLE ble (i INT);
>  SELECT INTO cnt  count(*) FROM ble;
>  DROP TABLE ble;
>  RETURN cnt;
> END;
> ' LANGUAGE 'plpgsql';
> 
> and at first time everythink is ok, but in next time is error like this :
> pg_class_aclcheck : relation  not found .
> (This function is only example , and i know that it doesnt sens)
> I think its by SysCache, how can i reset it ? or turn off ? or reload ?
> 
> 
> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
>http://archives.postgresql.org
> 

-- 
  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 8: explain analyze is your friend

Re: [HACKERS] using adbin, conbin, etc.

[Christopher Kings-Lynne]

> > Use the various pg_get_...() functions wherever you can.
> 
> And if you can't find one that does what you want, ask for it.
> The last thing we want is client-side code digging into those internal
> representations --- we change 'em frequently.

I want pg_get_* functions for every PostgreSQL object :P

Chris


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] using adbin, conbin, etc.

[Christopher Kings-Lynne]

> > And if you can't find one that does what you want, ask for it.
> > The last thing we want is client-side code digging into those internal
> > representations --- we change 'em frequently.
>
> I want pg_get_* functions for every PostgreSQL object :P

And I want an easy way of parsing aclitem[]'s so I don't have to do it
manually in PHP, trying to handle usernames and grantors that have commas,
spaces, backslashes and double quotes in them...

Chris


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] compile failure

[Bruce Momjian]

Are we removing recode before going into beta?

---

Greg Stark wrote:
> 
> Is recode a feature that's normally enabled?
> 
> ./configure '--enable-recode' '--enable-integer-datetimes' '--enable-debug' 
> '--with-perl' '--with-pam' '--with-openssl' '--with-gnu-ld' '--with-maxbackends=64' 
> '--with-pgport=5432' 'CFLAGS=-O0 -g -pg -DLINUX_PROFILE'
> ...
> gcc -O0 -g -pg -DLINUX_PROFILE -g -Wall -Wmissing-prototypes -Wmissing-declarations 
> -I../../../../src/include   -c -o miscinit.o miscinit.c
> miscinit.c: In function `SetCharSet':
> miscinit.c:205: structure has no member named `in'
> make[4]: *** [miscinit.o] Error 1
> make[4]: Leaving directory `/u6/src/postgres/cvs/pgsql/src/backend/utils/init'
> 
> 
> -- 
> greg
> 
> 
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
> 

-- 
  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 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] Error messages --- now that we've got it, do you like

[Bruce Momjian]

Tom, you saw this suggestion, right?

---

Bruce Momjian wrote:
> Bruce Momjian wrote:
> > 
> > VERBOSE doesn't seem like the right name for the \set parameter.  I
> > consider VERBOSE to be a possible value for error verbosity.  Saying
> > '\set VERBOSE terse' seems like an contradiction.
> > 
> > Should we call it VERBOSITY, or something else?  Seems 'error' or 'err'
> > or 'message' should be in there somewhere too.
> > 
> > Here is a good example of the problem:
> > 
> > > regression=# \set VERBOSE verbose
> > > regression=# \set VERBOSE default
> > > regression=# \set VERBOSE terse
> > 
> > That is just confusing.  It is the parameter name and a possible value.
> > 
> > How about MESSOUTPUT or ERROUTPUT?  Both look ugly, though.
> 
> OK, if people like VERBOSITY, I wonder if the values should be more like
> a tunable parameter, rather than a behavior, meaning VERBOSITY would
> have values like off/default/full, or minimum/default/maximum.
> 
> -- 
>   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
> 

-- 
  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 8: explain analyze is your friend

[HACKERS] Win32 for 7.5... how to help?

[Claudio Natoli]

Hi all,

This probably more than a little premature/ill-timed, but I was hoping to
start a groundswell of support for Win32 port.

I, and I imagine quite a number of capable lurkers on the list, would love
to get involved. Is there a way that work can be doled out now/soon, so that
we can make the next release (and with more stability than we might have
expected had the port squeezed into 7.4).

How do we help? 

No doubt this'll be shelved until some time after 7.4 is pushed out, but it
would be great if one of the Postgres "heavies" (figuratively :-) would
pro-actively lead this...

Best of all,
Claudio


--- 
WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: 
THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 
TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
http://www.memetrics.com/emailpolicy.html

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Error messages --- now that we've got it, do you like

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, you saw this suggestion, right?

I didn't hear anyone else agreeing with it ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[HACKERS] Any unapplied patches out there?

[Tom Lane]

Does anyone have any outstanding patches they expected would be applied
for 7.4?  I think everything in my inbox has been dealt with, but I
might have missed something.

Bruce is not done generating release notes, so we probably will not have
a formal beta package ready until Friday.  However, CVS tip or a nightly
snapshot tarball should be pretty-durn-close-to-the-beta.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Win32 for 7.5... how to help?

[Bruce Momjian]

I am already leading it, I think.

---

Claudio Natoli wrote:
> 
> Hi all,
> 
> This probably more than a little premature/ill-timed, but I was hoping to
> start a groundswell of support for Win32 port.
> 
> I, and I imagine quite a number of capable lurkers on the list, would love
> to get involved. Is there a way that work can be doled out now/soon, so that
> we can make the next release (and with more stability than we might have
> expected had the port squeezed into 7.4).
> 
> How do we help? 
> 
> No doubt this'll be shelved until some time after 7.4 is pushed out, but it
> would be great if one of the Postgres "heavies" (figuratively :-) would
> pro-actively lead this...
> 
> Best of all,
> Claudio
> 
> 
> --- 
> WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: 
> THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 
> TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 
> Certain disclaimers and policies apply to all email sent from Memetrics.
> For the full text of these disclaimers and policies see 
> http://www.memetrics.com/emailpolicy.html
> 
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
> 

-- 
  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]

Re: [HACKERS] Error messages --- now that we've got it, do you like

[Bruce Momjian]

That's what I thought... just checking.

---

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, you saw this suggestion, right?
> 
> I didn't hear anyone else agreeing with it ...
> 
>   regards, tom lane
> 

-- 
  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 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] compile failure

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are we removing recode before going into beta?

I was waiting for someone to holler that they really want it, but so far
the silence is deafening ...

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] compile failure

[Bruce Momjian]

Someone at LinuxTag said they liked it because you can do the conversion
in a text file, rather than compiling a conversion C file.

---

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are we removing recode before going into beta?
> 
> I was waiting for someone to holler that they really want it, but so far
> the silence is deafening ...
> 
>   regards, tom lane
> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
>http://archives.postgresql.org
> 

-- 
  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 4: Don't 'kill -9' the postmaster

Re: [HACKERS] autocommit in 7.4

[Bruce Momjian]

Is there a reason autocommit is implemented in psql and not in libpq via
a C function call?

---

Bruce Momjian wrote:
> I see autocommit as implemented only in psql, not in libpq.  Is that
> what we want to do for 7.4?

-- 
  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]

Re: [HACKERS] this is in plain text (row level locks)

[Bruce Momjian]

I was thinking of adding to TODO:

* Allow shared row locks for referential integrity

but how is that different from:

* Implement dirty reads and use them in RI triggers


---

Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > It may be best to have a locking manager run as a separate process.
> > That way it could store locks in ram or spill over to disk.
> 
> Hmm, that might be workable.  We could imagine that in place of the 
> HEAP_MARKED_FOR_UPDATE status bit, we have a "this row is possibly
> locked" hint bit.  Only if you see the bit set do you need to query
> the lock manager.  If the answer comes back that no lock is held,
> you can clear the bit --- so no need for any painful "undo" stuff
> after a crash, and no communication overhead in the normal case.
> 
>   regards, tom lane
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  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 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Win32 for 7.5... how to help?

[Claudio Natoli]

> I am already leading it, I think.

Ok. How do the willing get involved?

Cheers,
Claudio

--- 
WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: 
THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 
TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
http://www.memetrics.com/emailpolicy.html

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] this is in plain text (row level locks)

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking of adding to TODO:
>   * Allow shared row locks for referential integrity
> but how is that different from:
>   * Implement dirty reads and use them in RI triggers

It'd be a completely different approach to solving the FK locking
problem.  I wouldn't think we'd do both.

Personally I'd feel more comfortable with a shared-lock approach, if we
could work out the scalability issues.  Dirty reads seem ... well ...
dirty.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] php with postgres

[Bruce Momjian]

Are you all done with the PHP persistent connection changes?  Need any
help?


---

Marcus B?rger wrote:
> Hello Christopher,
> 
> Wednesday, July 23, 2003, 6:49:05 AM, you wrote:
> 
> >> > Surely PHP can be modified so as to use the new 3.0 protocol feature to
> >> > detect whether it's in a transaction or not, so as to avoid unnecssary
> >> > querying?
> >>
> >> Yes, you could, but it hardly seems worth it because they have to
> >> support old and new protocols.  Eventually, yes, they could use that to
> >> eliminate the BEGIN;COMMIT.
> 
> CKL> Just use a configure test to see if you have the appropriate function call
> CKL> in your libpq...
> 
> I've put that already into PHP yesturday so i could add the necessary check
> now too.
> 
> -- 
> Best regards,
>  Marcusmailto:[EMAIL PROTECTED]
> 
> 

-- 
  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 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] php with postgres

[Bruce Momjian]

OK, I checked the URL's, and I am a little confused.  I don't understand
why the conditional transaction abort isn't in the same place as the
RESET ALL.  Seems they should be done at the same time, though there is
an advantage to doing the RESET ALL during connect, because if someone
changes the postgres.conf setting between the disconnect and the
connect, you would then see the new values, which seems correct.  

Is that what is happening?  If it is, this line is wrong:

pg_result = PQexec(pgsql, "BEGIN;ROLLBACK;RESET ALL;");

because you have already rolled back the connection during the
disconnect.  This is the code for old servers.

---

Marcus B?rger wrote:
> Hello Bruce,
> 
> Thursday, July 24, 2003, 11:57:39 PM, you wrote:
> 
> BM> Jan Wieck wrote:
> >> Marcus B?rger wrote:
> >> > ATM i have a patch doing the following:
> >> > Connect:
> >> >  If PQprotocolVersion() is available and >= 3 PQparameterStatus() is available
> >> >  then i check the server version. Else i check the lib version (*).
> >> >  If the version to check is >= 7.2 ido one of the following:
> >> >  - If one of PQprotocolVersion() and PQtransactionStatus() is unavailable or
> >> >protocol version < 3:
> >> >  "BEGIN;COMMIT;RESET ALL;"
> >> > 
> >> >  - If protocol version >= 3 and transaction status == PQTRANS_IDLE:
> >> >  "RESET ALL;"
> >> >  - If protocol version >= 3 and transaction status != PQTRANS_IDLE:
> >> >  "COMMIT;RESET ALL;"
> >> 
> >> Shouldn't that be
> >> 
> >>  ROLLBACK; RESET ALL;
> >> 
> >> and the other one "BEGIN; ROLLBACK; RESET ALL;" ?
> >> 
> >> I don't want to have the possibly partial transaction from a crashed PHP 
> >> script to be committed by default. At least it would be a significant 
> >> difference between persistent and non-persistent connections, because we 
> >> rollback if we loose the connection.
> 
> BM> Right, as I just emailed.  I wonder if we made the mistake of
> BM> recommending BEGIN;COMMIT; to the PHP folks a while back, or whether they
> BM> just did it themselves.
> 
> BM> I remember telling them they couldn't just do ROLLBACK because that
> BM> would fill the logs, but I am not sure how they got BEGIN;COMMIT;
> BM> rather than BEGIN;ROLLBACK.  It just shows we need better communication
> BM> between the communities.
> 
> 
> 
> Ok, i'd of course appreciate more eyes before my commit then (i need to become
> more familiar with the whole postgres source). I've put three files online:
> - the diff against current php haed
>   http://marcus-boerger.de/php/ext/pgsql/pgsql-persistent-20030725.diff.txt
> - the complete new file
>   http://marcus-boerger.de/php/ext/pgsql/pgsql.c
> - the parts relevant (request start/stop)
>   http://marcus-boerger.de/php/ext/pgsql/pgsql-request-start-stop.c
> 
>   
> Best regards,
>  Marcusmailto:[EMAIL PROTECTED]
> 
> 

-- 
  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 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] name of configure threading option

[Bruce Momjian]

Change made.

---

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Should the new threading configure option be called:
> > --enable-thread-safeness
> > or 
> > --enable-thread-safety
> 
> safety is a common word, safeness isn't.  (The OED has entries for both,
> but the entry for safety is about 10x longer; a smaller dictionary I
> consulted doesn't list safeness at all.)
> 
>   regards, tom lane
> 
> ---(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 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Win32 for 7.5... how to help?

[Bruce Momjian]

Uh, the two big items are Win32 signal code, and reordering the startup
code to allow exec without fork.  Both are pretty complicated, but I do
ask for assistance on the hackers list.

---

Claudio Natoli wrote:
> 
> > I am already leading it, I think.
> 
> Ok. How do the willing get involved?
> 
> Cheers,
> Claudio
> 
> --- 
> WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: 
> THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 
> TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 
> Certain disclaimers and policies apply to all email sent from Memetrics.
> For the full text of these disclaimers and policies see 
> http://www.memetrics.com/emailpolicy.html
> 
> ---(end of broadcast)---
> TIP 8: explain analyze is your friend
> 

-- 
  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]

Re: [HACKERS] Win32 for 7.5... how to help?

[Claudio Natoli]

> Uh, the two big items are Win32 signal code, and reordering 
> the startup code to allow exec without fork.  Both are pretty 
> complicated, but I do ask for assistance on the hackers list.

Ok. I guess we'll just keep our eyes peeled for the next time we can help
out.

Thanks for the replies...

--- 
WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: 
THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 
TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
http://www.memetrics.com/emailpolicy.html

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] autocommit in 7.4

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there a reason autocommit is implemented in psql and not in libpq via
> a C function call?

One reason is that PQexec accepts multiple-query strings (possibly with
embedded BEGIN/END), so it's not immediately obvious what the semantics
ought to be.  We could probably work out some reasonable definition if
we wanted to put effort into it, but seeing that libpq clients aren't
historically expecting any autocommit support, I didn't find it a high
priority task for 7.4.

At this point it's definitely too late for 7.4, anyway.  Put it on the
TODO list if you feel strongly about it.

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] this is in plain text (row level locks)

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking of adding to TODO:
> > * Allow shared row locks for referential integrity
> > but how is that different from:
> > * Implement dirty reads and use them in RI triggers
> 
> It'd be a completely different approach to solving the FK locking
> problem.  I wouldn't think we'd do both.
> 
> Personally I'd feel more comfortable with a shared-lock approach, if we
> could work out the scalability issues.  Dirty reads seem ... well ...
> dirty.

TODO updated:

* Implement dirty reads or shared locks and use them in RI
  triggers


-- 
  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 4: Don't 'kill -9' the postmaster

Re: [HACKERS] autocommit in 7.4

[Bruce Momjian]

The issue I have is that every interface that relies on libpq is going
to have to code it itself.  Is that OK?

---

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is there a reason autocommit is implemented in psql and not in libpq via
> > a C function call?
> 
> One reason is that PQexec accepts multiple-query strings (possibly with
> embedded BEGIN/END), so it's not immediately obvious what the semantics
> ought to be.  We could probably work out some reasonable definition if
> we wanted to put effort into it, but seeing that libpq clients aren't
> historically expecting any autocommit support, I didn't find it a high
> priority task for 7.4.
> 
> At this point it's definitely too late for 7.4, anyway.  Put it on the
> TODO list if you feel strongly about it.
> 
>   regards, tom lane
> 

-- 
  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 8: explain analyze is your friend

Re: [HACKERS] followup on previous

[Bruce Momjian]

Thomas liked Postgres rather than PostgreSQL in the docs, and I think
that's where it came from.  I use Postgres in speaking, and PostgreSQL
in writing, so I guess either is OK.

---

Christopher Kings-Lynne wrote:
> Just a slight nitpick, shouldn't this line:
> 
> # - Previous Postgres Versions -
> 
> Be this:
> 
> # - Previous PostgreSQL Versions -
> 
> Chris
> 
> 
> ---(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
> 

-- 
  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 8: explain analyze is your friend

[HACKERS] patch queue

[Bruce Momjian]

I see all submitted patches as applied, except from Gavin's WHERE
CURRENT OF patch, and I am asking for opinions on that one.

I will complete the release changes by Friday.

-- 
  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]

Re: [HACKERS] followup on previous

[Christopher Kings-Lynne]

I just seem to recall a discussion where we decided to 'standardise' on
PostgreSQL...I'm not fussed tho.

Chris

- Original Message - 
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
Cc: "Hackers" <[EMAIL PROTECTED]>
Sent: Thursday, July 31, 2003 12:53 PM
Subject: Re: [HACKERS] followup on previous


>
> Thomas liked Postgres rather than PostgreSQL in the docs, and I think
> that's where it came from.  I use Postgres in speaking, and PostgreSQL
> in writing, so I guess either is OK.
>
> --
-
>
> Christopher Kings-Lynne wrote:
> > Just a slight nitpick, shouldn't this line:
> >
> > # - Previous Postgres Versions -
> >
> > Be this:
> >
> > # - Previous PostgreSQL Versions -
> >
> > Chris
> >
> >
> > ---(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
> >
>
> -- 
>   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 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] autocommit in 7.4

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> The issue I have is that every interface that relies on libpq is going
> to have to code it itself.  Is that OK?

So?  Most interfaces have to adhere to their own notions of transaction
semantics and control API anyway.  libpq should stay out of their way
rather than try to be helpful.  I see this as not different from the
lesson we learned that doing it in the backend isn't the right place.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] this is in plain text (row level locks)

[Sailesh Krishnamurthy]

> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:

Tom> Personally I'd feel more comfortable with a shared-lock
Tom> approach, if we could work out the scalability issues.  Dirty
Tom> reads seem ... well ...  dirty.

Tom

I was going to do some experiments to measure the costs of our shared
memory MemoryContext.

Is there something specific you'd be interested in ? My first goal is
mainly to measure the amount of time it takes to allocate and
deallocate shared memory in the contested and uncontested cases.

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh



---(end of broadcast)---
TIP 8: explain analyze is your friend

[HACKERS] version mismatch message

[Christopher Kings-Lynne]

I get this in my logs from our backups.  I ahve explicitly put -i in
pg_dumpall.  How about we totally suppress this message if -i is supplied,
because obviously the person knows perfectly well it's proceeding despite
version mismatch?

Chris

pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch
pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch
pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch
pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch
pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch
pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch
pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7,
compiled by GCC 2.95.4; pg_dump version: 7.3.2
pg_dump: proceeding despite version mismatch


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] pgsql 7.3.4 (bz2 format)

[Pieter du Plooy]

Hi

When will the bz2 (cygwin package release) be available?

Pieter
 
==
Download ringtones, logos and picture messages at Ananzi Mobile Fun.
http://www.ananzi.co.za/cgi-bin/goto.pl?mobile

---(end of broadcast)---
TIP 8: explain analyze is your friend