On Tue, Mar 20, 2007 at 12:12:45PM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>> I think you do still need the on_shmem_exit detach callback.
> >>
> >> Ok, will look into that. Haven't tested that scenario.
>
> > That was indeed so. Added in new version, attached.
>
"Jeremy Drake" <[EMAIL PROTECTED]> writes:
> BTW, should I be calling get_typlenbyvalalign on TEXTOID or are there macros
> for those also?
Hardcoding -1 for typlen of varlenas is one of the few (the only?) magic
constants used throughout the source code. I'm surprised there isn't a macro
for it
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Jeremy Drake" <[EMAIL PROTECTED]> writes:
>
>> BTW, should I be calling get_typlenbyvalalign on TEXTOID or are there macros
>> for those also?
>
> Hardcoding -1 for typlen of varlenas is one of the few (the only?) magic
> constants used throughout th
Jeremy Drake <[EMAIL PROTECTED]> writes:
> BTW, should I be calling
> get_typlenbyvalalign on TEXTOID or are there macros for those also?
By and large we tend to hard-wire those properties too, eg there are
plenty of places that do things like this:
/* XXX: this hardcodes assumptions about th
On Tue, 2007-03-20 at 18:20 +, Heikki Linnakangas wrote:
> This patch makes CLUSTER MVCC-safe. Visibility information and update
> chains are preserved like in VACUUM FULL.
Sounds good.
> CLUSTER is currently the only user of the facility, but I'm envisioning
> we might have other users in
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
He
On Wed, 21 Mar 2007, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > BTW, should I be calling
> > get_typlenbyvalalign on TEXTOID or are there macros for those also?
>
> By and large we tend to hard-wire those properties too, eg there are
> plenty of places that do things like this:
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Bah, sorry about the noise. It was the effect of
> > PGSTAT_RESTART_INTERVAL.
> > Do we want to add some logging when we don't restart it due to repeated
> > failures?
>
> Not really, but maybe it would be sensible to reset last_pgs
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not really, but maybe it would be sensible to reset last_pgstat_start_time
>> when doing a database-wide restart?
> You mean like this, attached?
I'd be fairly surprised if resetting the variable in the child process
had any effect on
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Wed, 21 Mar 2007, Tom Lane wrote:
>> By and large we tend to hard-wire those properties too, eg there are
>> plenty of places that do things like this:
> So, what action (if any) should be taken? Should all (or some) of these
> values be hardcoded, or
On Wed, 21 Mar 2007, Gregory Stark wrote:
> The only thing I would say is that this should maybe be a TextGetDatum() just
> for code hygiene. It should be exactly equivalent though:
I could not find such a thing using ctags, nor TextPGetDatum(). I looked
at PG_RETURN_TEXT_P and it just uses PG_R
On Thu, 22 Mar 2007, Tom Lane wrote:
> I'd vote for making this new code look like the rest of it, to wit
> hardwire the values.
Attached please find a patch which does this.
--
Although written many years ago, Lady Chatterley's Lover has just been
reissued by the Grove Press, and this pictor
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I could not find such a thing using ctags, nor TextPGetDatum(). I looked
> at PG_RETURN_TEXT_P and it just uses PG_RETURN_POINTER, which in turn uses
> PointerGetDatum. If there is such a thing, it is well camoflaged...
AFAIR, the reason there's no Text
Hello,
I found LIKE operators are slower on multi-byte encoding databases
than single-byte encoding ones. It comes from difference between
MatchText() and MBMatchText().
We've had an optimization for single-byte encodings using
pg_database_encoding_max_length() == 1 test. I'll propose to extend
On Thu, 22 Mar 2007, Tom Lane wrote:
> AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
> datatypes) is lack of obvious usefulness. A function dealing with a
> "text *" doesn't normally have reason to convert that to a Datum until
> it returns --- and at that point PG_RETUR
15 matches
Mail list logo
