Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> When you get a chance, would you see if the SHLIB_LINK += $(LIBS)
>> bit is still needed?
> I commented it out of the Cygwin stanza and all seemed fine - contrib
> built and passed installcheck quite happily.
Great ... one less plat
On Sun, Aug 07, 2005 at 02:51:12PM -0400, Tom Lane wrote:
> I back-patched 7.4 as well, which is the oldest branch that has this
> code. The Cygwin people still need to fix their bug, since it's
> entirely possible to run the system out of FDs after we're up and
> running ... but it's surely a was
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Marko Kreen wrote:
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
Couple thoughts here --- one, someone upthread suggested
"cyg$(NAME)$(DLSUFFIX" as the proper value for shlib.
.exe's in different
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> As I have been laboring over the documentation of the postgresql.conf
> file for 8.1dev it seems that it may be useful to rip out most of the
> options in this file?
What? The contents of postgresql.conf *are* documentation.
I wrote:
>> I could not provoke the same crash in 8.0, but I suspect this may just
>> be a chance timing difference, and that the bug may be of long standing.
> I haven't done the experiment, but I'm pretty certain that it's possible
> to provoke this same crash in 8.0 if the timing is right, whic
Hello,
As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?
Considering many of the options can already be altered using SET why
not make it the default for many of them?
Sincerely,
On Sun, Aug 07, 2005 at 03:45:10PM -0400, Tom Lane wrote:
> I'm thinking that the correct fix is to forget the notion that it's
> safer to do a subset of AbortTransaction than to do the whole thing.
> We should make ShutdownPostgres do this:
>
> AbortOutOfAnyTransaction();
>
> /* Dro
I wrote:
> I can fairly consistently crash CVS tip with the following:
> ...
> Apparently, session 1's locks are being released while it still shows as
> an active transaction in the PGPROC array, causing XactLockTableWait to
> suppose it was a subtransaction and look for the parent. This indicate
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> *) there is no backslash command for getting a list of Roles (like \du &
> \dg for Users and Groups) - I'm considering using \dr for that - does
> that sound sensible ?
We could just recycle \du and/or \dg for the purpose. If those should
still e
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Marko Kreen wrote:
>> On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
>>> Couple thoughts here --- one, someone upthread suggested
>>> "cyg$(NAME)$(DLSUFFIX" as the proper value for shlib.
>>
>> .exe's in different directories than .dll's but
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Looking at that code, I wonder why we don't make the loop stop at
>> max_files_per_process opened files --- the useful result will be
>> bounded by that anyhow. Actively running the system out of FDs,
>> even momentarily, doesn't seem
Marko Kreen wrote:
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
Couple thoughts here --- one, someone upthread suggested
"cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. I didn't
see why at first, but now it occurs to me that it might avoid name
collisions with Windows-n
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... The second part should not be
applied - I simply include it to illustrate the hack (taken from a
recent clue on the Cygwin mailing list) that I found necessary to get
around brokenness on the latest release of Cygwin. The goo
Hi,
I'm currently working on syncing psql's tab-complete code with the docs
especially wrt ROLES. while working on this I noticed the following things:
*) there is no backslash command for getting a list of Roles (like \du &
\dg for Users and Groups) - I'm considering using \dr for that - does
th
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
> Couple thoughts here --- one, someone upthread suggested
> "cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. I didn't
> see why at first, but now it occurs to me that it might avoid name
> collisions with Windows-native builds, which
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> With a help from Bruce, I wrote a small function which returns row
> locking information(see attached file if you are interested).
Scanning the whole table seems a bit slow :-(
There is another possibility: in CVS tip, anyone who is actually blocked
on a
I can fairly consistently crash CVS tip with the following:
Session 1:
regression=# begin;
BEGIN
regression=# select * from int4_tbl where f1 = 123456 for update;
f1
123456
(1 row)
Session 2:
regression=# begin;
BEGIN
regression=# select * from int4_tbl where f1 = 123456 for upd
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Seems to me that defining shlib that way for Cygwin too would be a
>>> reasonable answer, but I'm not sure if there will be any side-effects.
>>> Can someone try it?
>>
>> The attached patch worked for me.
> ifeq ($(PORTNAME),
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ... The second part should not be
> applied - I simply include it to illustrate the hack (taken from a
> recent clue on the Cygwin mailing list) that I found necessary to get
> around brokenness on the latest release of Cygwin. The good news is
> tha
er that would be this patch.
Andrew Dunstan wrote:
Tom Lane wrote:
"Rocco Altier" <[EMAIL PROTECTED]> writes:
It looks like when we changed regress/GNUmakefile to pull rules from
Makefile.shlib, cygwin got broken in the process.
...
I don't know enough about the rest of the way the cygw
Tom Lane wrote:
"Rocco Altier" <[EMAIL PROTECTED]> writes:
It looks like when we changed regress/GNUmakefile to pull rules from
Makefile.shlib, cygwin got broken in the process.
...
I don't know enough about the rest of the way the cygwin port is put
together, but it seems that the other p
Hi,
With a help from Bruce, I wrote a small function which returns row
locking information(see attached file if you are interested). Here is
a sample result:
test=# select * from pgrowlocks('t1');
locked_row | lock_type | locker | multi
+---++---
(0,1) | Sh
22 matches
Mail list logo
