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 ite
> 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 ct
> > 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
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
"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 hol
> 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 dat
> > 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 th
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 p
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" propos
"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:
http://www.postgresql.org/docs/7.4/s
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 mar
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
No, this was not related to triggers at all. The original discussion
concerned GUC functionality to handle configuration settings for pl
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 pl
> extensions.
OK. If you guys agree on TODO wording, I will add it.
--
Bruce Momjian| http://candle.pha.
16 matches
Mail list logo
