Greg Copeland writes:
Just a reminder, there still doesn't appear to be a 7.3.1 tag.
There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Serguei Mokhov writes:
#if defined(HAVE_GETOPT_LONG)
#define xo(long,short,desc) printf(%s %s\n, long, desc)
#else
#define xo(long,short,desc) printf(%s %s\n, short, desc)
#endif
seems relatively generic, so it could be used by more than one tool.
As long as we're spending time on this,
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
Greg Copeland writes:
Just a reminder, there still doesn't appear to be a 7.3.1 tag.
There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.
It was I who suggested that a release team
Umm. No. User or system level threads, the statement is true. If a
thread kills over, the process goes with it. Furthermore, on Win32
Hm. This is a database system. If one of the backend processes dies
unexpectedly, I'm not sure I would trust the consistency and state of the
others.
Or
Oliver Elphick [EMAIL PROTECTED] writes:
On Sat, 2003-01-04 at 02:17, Tom Lane wrote:
There isn't any simple way to lock *everyone* out of the DB and still
allow pg_upgrade to connect via the postmaster, and even if there were,
the DBA could too easily forget to do it.
I tackled this issue
Dan Langille [EMAIL PROTECTED] writes:
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.
It was I who suggested that a release team would be a good idea.
We *have* a release team.
On Sat, 2003-01-04 at 04:27, Peter Eisentraut wrote:
Greg Copeland writes:
Just a reminder, there still doesn't appear to be a 7.3.1 tag.
There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.
Well, I thought I remembered from
On Sat, 2003-01-04 at 06:59, Kaare Rasmussen wrote:
Umm. No. User or system level threads, the statement is true. If a
thread kills over, the process goes with it. Furthermore, on Win32
Hm. This is a database system. If one of the backend processes dies
unexpectedly, I'm not sure I
On Sat, 2003-01-04 at 09:53, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
On Sat, 2003-01-04 at 02:17, Tom Lane wrote:
There isn't any simple way to lock *everyone* out of the DB and still
allow pg_upgrade to connect via the postmaster, and even if there were,
the DBA could
msg resent because I incorrectly copied/pasted some addresses.
Sorry.
On 4 Jan 2003 at 11:08, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
There is a long tradition of systematically failing to tag releases
in this project. Don't
msg resent because I incorrectly copied/pasted some addresses. Sorry.
On 4 Jan 2003 at 11:08, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
There is a long tradition of systematically failing to tag releases
in this project. Don't
Tom Lane writes:
As long as we're spending time on this, why not just write our own version
of getopt_long()?
Seems like a fine idea to me ... who's volunteering?
Doing it now...
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
I'm just announcing here, since I'd like to see some ppl testing this out
and let us know if there are any problems ... DNS is going to take a
little while to propogate, so the old site may still come up in the
interium ... another reason not to announce it right away :)
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm just announcing here, since I'd like to see some ppl testing this out
and let us know if there are any problems ... DNS is going to take a
little while to propogate, so the old site may still come up in the
interium ... another reason not to
On Sat, 4 Jan 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm just announcing here, since I'd like to see some ppl testing this out
and let us know if there are any problems ... DNS is going to take a
little while to propogate, so the old site may still come up in the
Marc G. Fournier [EMAIL PROTECTED] writes:
the portal itself is not mirrored, butif you go to, for instance
UsersLounge or Downloads, it then gives you the option of which mirror to
go to ...
Ah. But if I do either, I see
Warning: pg_exec(): supplied argument is not a valid PostgreSQL link
Let me know how it goes, and what the project is ... that way we can move
the current CVS over so that we don't lose the extensive logging history
...
On Fri, 3 Jan 2003, D'Arcy J.M. Cain wrote:
On Friday 03 January 2003 15:24, Tom Lane wrote:
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
On Sat, 4 Jan 2003, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.
It was I who suggested that a release team would be a
--On Saturday, January 04, 2003 21:04:32 -0400 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Sat, 4 Jan 2003, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
There is a long tradition of systematically failing to tag releases in
this
Marc G. Fournier [EMAIL PROTECTED] writes:
I never considered tag'ng for minor releases as having any importance,
since the tarball's themselves provide the 'tag' ... branches give us the
ability to back-patch, but tag's don't provide us anything ... do they?
Well, a tag makes it feasible for
On Sat, 4 Jan 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
the portal itself is not mirrored, butif you go to, for instance
UsersLounge or Downloads, it then gives you the option of which mirror to
go to ...
Ah. But if I do either, I see
Warning: pg_exec():
Marc G. Fournier wrote:
On Sat, 4 Jan 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
the portal itself is not mirrored, butif you go to, for instance
UsersLounge or Downloads, it then gives you the option of which mirror to
go to ...
Ah. But if I do either, I see
On Sun, 5 Jan 2003, Justin Clift wrote:
www.postgresql.org/doc - www.ca.postgresql.org/users-lounge/
If we can avoid it, let's ... if I recall correctly, we originally set
that up in order to get around some issues we had with originally moving
over to the new site way way back ...
Bear Giles writes:
The server policy is easy to handle - it would probably go into a
new text configuration file pg_ssl.conf.
postgresql.conf should serve you fine.
The client policy is much harder to handle, since the details need
to be hidden in the libpg library. I know how to handle
Tom Lane writes:
This would require a nontrivial amount of work (notably, we'd have to
be able to get pg_dump to run against a standalone backend) but I don't
think I'd trust pg_upgrade as a production-grade tool until its
invocation method looks like the above.
I would recommend requiring
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
This would require a nontrivial amount of work (notably, we'd have to
be able to get pg_dump to run against a standalone backend) but I don't
think I'd trust pg_upgrade as a production-grade tool until its
invocation method looks
Hi Tom,
Sorry about that. Was a combo of two simple problems.
It's fixed now. :-)
Regards and best wishes,
Justin Clift
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
the portal itself is not mirrored, butif you go to, for instance
UsersLounge or Downloads, it then gives you
Justin Clift [EMAIL PROTECTED] writes:
It's fixed now. :-)
Better, thanks.
Minor suggestion: could we get ALT text for all the flags? Right now
it's there for USA, UK, Italy, but not the rest ...
regards, tom lane
---(end of
Tom Lane wrote:
Any other arguments out there?
Per-release tags make it easier to see quickly if some code has
changed in -current or not. As the CVS tree is available via anoymous
CVS (I think?), CVSup, and via the web so there are many potential
users who are not active developers and who
Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
On Sat, 2003-01-04 at 02:17, Tom Lane wrote:
There isn't any simple way to lock *everyone* out of the DB and still
allow pg_upgrade to connect via the postmaster, and even if there were,
the DBA could too easily forget to do it.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's a good kluge, but still a kluge: it doesn't completely guarantee
that no one else connects while pg_upgrade is trying to do its thing.
I was thinking about using GUC:
#max_connections = 32
I have started experimenting with an access layer for pgsql and have a
question. I had someone on this list tell me that the oid values that
come back from the server are tag identifiers for that row/column
combination and are not type indicators. Yet, when I create multiple
tables/columns each
Ok, that adds some clarity. Have base types (int32, etc) had the same
oid values for a significant number of versions of PgSQL? What I am
getting at is this: can I hard code oid values into an access layer for
PgSQL? I see that the Java driver uses select statements back into the
db to
33 matches
Mail list logo
