Hello ,
Can i get any design documentation apart from the readme files and the
comments those are available with the source code .
In particular any document explaining the data structures related to
optimizer and executor parts of the system
Thansk in adv,
-regards
Ramu
Simon,
On Thu, 19 Feb 2004 00:05:15 -, Simon Riggs
[EMAIL PROTECTED] wrote:
POSTGRESQL: Summary of Changes since last release (7.4.1)
--
18 Feb 2004
this is getting long over time. If you plan to post it once a week,
flagging items
I believe the ODBC driver uses CTID for this sort of problem. CTID is
guaranteed to exist and to be fast to access (since it's a physical
locator). Against this you have the problem that concurrent updates
of the record will move it, leaving your CTID invalid. However, that
IIRC the ctid
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait locking. (We
already have two voting for such a variable.)
I vote against. We got bit by both the
Zeugswetter Andreas SB SD wrote:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait locking. (We
already have two voting for such a variable.)
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
IIRC the ctid access follows the chain up to the currently valid
tuple ?
No.
I think Hiroshi or someone put in a function you can use to follow the
chain, but a simple WHERE ctid = whatever won't do it. In any case,
if you're not holding an
I vote for the GUC. Imho it is not comparable to the autocommit case,
since it does not change the way your appl needs to react (appl needs to
react to deadlock already).
Wrote one program a while ago that was very time sensitive. By the time
deadlock detection had been kicked off, the data
I personally think a wait period in seconds would be more useful.
Milli second timeouts tend to be misused with way too low values
in this case, imho.
I understand, but GUC lost the vote. I have updated the TODO list to
indicate this. Tatsuo posted a patch to add NO WAIT to the LOCK
On Mon, Feb 16, 2004 at 10:16:39AM -0800, John Li wrote:
I just implemented eRServer for one of my clients and found many problems
with it.
Yep. There's a list dedicated to it, by the way, available through
the gborg site.
1.It crashes when using ?ers_addtable? to add big tables. The
Thomas Hallgren wrote:
Some very good suggestions where made here. What happens next? Will this end
up in a TODO list where someone can claim the task (I'm trying to learn
how the process works) ?
If someone doesn't jump right on it and make a diff -c proposal, it
probably belongs on the TODO
Joe Conway wrote:
Thomas Hallgren wrote:
Some very good suggestions where made here. What happens next? Will this end
up in a TODO list where someone can claim the task (I'm trying to learn
how the process works) ?
If someone doesn't jump right on it and make a diff -c proposal, it
Ramanujam H S Iyengar [EMAIL PROTECTED] writes:
Can i get any design documentation apart from the readme files and the
comments those are available with the source code .
Not really. There's some information in the Internals section of the
main docs:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Either way, we should make them a WARNING for 7.5, then error in
7.6.
Ok, I'll make this change soon.
If we end up marking more 7.5 changes using this mechanism
(i.e. deprecate for 7.5, disallow for 7.6), we could use an #ifdef
symbol to mark
Sorry for rising up old issue again but the problem still persists.
And database cluster is not being created with Turkish locale
If you have any doubts about how Turkish users will react to the fact
that both I and I WITH DOT will be treated as same character, rest
assured that this behavior is
No, this was not related to triggers at all. The original discussion
concerned GUC functionality to handle configuration settings for pllang
extensions.
- thomas
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Joe Conway [EMAIL PROTECTED]
Cc: Thomas Hallgren [EMAIL
Thomas Hallgren wrote:
No, this was not related to triggers at all. The original discussion
concerned GUC functionality to handle configuration settings for pllang
extensions.
OK. If you guys agree on TODO wording, I will add it.
--
Bruce Momjian|
16 matches
Mail list logo
