Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think the reason is that it's both an input and an output parameter,
>> to handle the case where the cast function returns NULL.
> [ no it ain't ]
In that case feel free to clean it up ...
regards, tom lane
-
On Wed, 27 Jul 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I ran across this yesterday on HEAD:
>
> > template1=# grant select on foo, foo to swm;
> > ERROR: tuple already updated by self
>
> Seems to fail similarly in every version back to 7.2; probably further,
> but th
Tom Lane wrote:
I think the reason is that it's both an input and an output parameter,
to handle the case where the cast function returns NULL.
The only reference to `isnull' in the body of exec_cast_value() is:
if (!*isnull)
{
/* ... */
}
i.e. it is never referenced again, let alone writ
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> I finally noticed that when we are building the postgres.imp file, we
> are not pulling in the pgport symbols, since they are not being linked
> into the local SUBSYS.o before running mkldexport.sh.
> The solution was to suck in libpgport.a before we ex
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, is there a reason why exec_cast_value() and friends take a bool *,
> rather than a bool?
I think the reason is that it's both an input and an output parameter,
to handle the case where the cast function returns NULL.
This is obviously a pretty bug-p
Tom Lane wrote:
The other spots seem to be OK. Thanks for the report and fix!
Woops, my apologies for introducing the bug. In general I think it's
worth removing explicit initialization of out parameters unless that
initialization is actually needed. I thought I had checked that
`isnull=fal
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> The comment in regress/GNUmakefile about the pgport symbols not being
> found got me thinking about why that might be the case.
> I finally noticed that when we are building the postgres.imp file, we
> are not pulling in the pgport symbols, since they a
"Kevin McArthur" <[EMAIL PROTECTED]> writes:
> This patch will resolve the oid retrieval bugs from plpgsql.
Applied.
> There are
> however several other places where isnull=false was removed and
> replaced with isnull which may also need to be corrected.
The other spots seem to be OK. Thanks
The comment in regress/GNUmakefile about the pgport symbols not being
found got me thinking about why that might be the case.
I finally noticed that when we are building the postgres.imp file, we
are not pulling in the pgport symbols, since they are not being linked
into the local SUBSYS.o before
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ok, so there's a reason for having a manual stat-reset. However what's
> the rationale for cleaning stats at postmaster start? In fact I think
> it's actively bad because you lose any data you had before postmaster
> stop/crash.
We probably *should* d
This patch will resolve the oid retrieval bugs from
plpgsql. There are however several other places where isnull=false was removed
and replaced with isnull which may also need to be corrected.
Kevin McArthur
StormTide Digital Studios Inc.
Index:
src/pl/plpgsql/src/pl_exec.c===
On Mon, Jul 25, 2005 at 09:31:15AM +0800, Christopher Kings-Lynne wrote:
> >> We have to consider what
> >> happens at stat reset -- AFAICS there's no problem, because as soon as
> >> the table sees some activity, it will be picked up by pgstat.
> >> However, it would be bad if stats are reset righ
Adrian Maier wrote:
> On 6/30/05, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, 30. Juni 2005 09:34 schrieb Adrian Maier:
> > > The attached patch modifies the message displayed by psql
> > > when asking the password "Password: "
> > > to include the username as well: "Password fo
Hi again.
Here's an updated patch, that fixes several bugs and is synced with HEAD.
--
Victor Y. Yegorov
diff-20050727-2.gz
Description: Binary data
---(end of broadcast)---
TIP 6: explain analyze is your friend
I've had this small patch in my local tree for a while. It documents
new commands which may make an SPI call fail.
--
Alvaro Herrera ()
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)
Index: doc/src/sgml/spi.sgml
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Did we forget to remove it when mm.c was removed?
Yup :-(. Thanks for catching it.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
ITAGAKI Takahiro wrote:
> Thanks for reviewing!
> But the patch does not work on HEAD, because of the changes in
> BootStrapXLOG().
> I send the patch with a fix for it.
Thanks.
> > If you are doing fsync(), I don't see how O_DIRECT
> > makes any sense because O_DIRECT is writing to disk on ever
ITAGAKI Takahiro wrote:
Are there any reasons MMCacheLock has been left yet?
Not as far as I can see -- good catch. Patch applied to HEAD.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
Hi,
Are there any reasons MMCacheLock has been left yet?
Did we forget to remove it when mm.c was removed?
*** lwlock.hSat Jun 18 07:32:50 2005
--- lwlock-nomm.h Wed Jul 27 16:18:42 2005
***
*** 33,39
ProcArrayLock,
SInvalLock,
FreeSpaceLock,
-
19 matches
Mail list logo
