On Sun, 13 Jun 2004, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
(viz, log at the instant of file creation, and the replayer would have
to keep track of whether it sees the creating transaction commit and
delete the file if not).
I don't see how we could WAL log it because
Marc G. Fournier wrote:
On Sun, 13 Jun 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
Anyone else, please test the tar ball for any bug/nits ...
specifically, Peter, can you check that I've built/included the
right documentation?
Try reading the list of supported platforms at
Joshua D. Drake wrote:
The PostgreSQL Enhanced Server (How's that name? Maybe we call it Zerver
and use PEZ?) idea is how to take the excellent core of PostgreSQL and
productize it in much the same way distributions take the Linux kernel and
may a GNU/Linux system.
It would seem to me that
What is the recommended way to create mutex objects
(CreateMutex) from
Win32 libraries? There must be a clean way like there is
in pthreads.
A mutex is inherently a global object. CreateMutex(NULL,
FALSE, NULL)
will return a handle to an unowned mutex.
That's not the
Magnus Hagander wrote:
What is the recommended way to create mutex objects
(CreateMutex) from
Win32 libraries? There must be a clean way like there is
in pthreads.
A mutex is inherently a global object. CreateMutex(NULL,
FALSE, NULL)
will
The PostgreSQL Enhanced Server (How's that name? Maybe we call it
Zerver
and use PEZ?) idea is how to take the excellent core of PostgreSQL and
productize it in much the same way distributions take the Linux kernel
and
may a GNU/Linux system.
It would seem to me that this is more correct in
Peter Eisentraut [EMAIL PROTECTED] writes:
The INSTALL file looks quite bad.
It's clearly been freshly generated. The formatting does seem worse
than in previous versions, but it's not so bad I'd want to hold up
the release to fix it.
My guess is that the wrong version of lynx is being used to
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm afraid that's not enough. Checkpoints spoil it, think:
1. CREATE TABLE foobar ...
2. INSERT
3. checkpoint
4. crash
The replay would not see the file-creation WAL record.
Good point. That makes it messy enough that we probably don't
I wrote:
My guess is that the wrong version of lynx is being used to build it.
I remember being dissatisfied with the output of developer.pg.org's
version of lynx back when we were making this file manually.
(The version I have here is 2.8.5rel.1 (04 Feb 2004) and it seems to
do fine.)
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is there any reason for this behaviour:
test=# select 1::bit;
bit
-
0
(1 row)
This is actually 1::int4::bit(1), and what you are getting is
the sign bit. See previous discussions about int-to-bit conversion
and which part of the int
Oliver Jowett [EMAIL PROTECTED] writes:
I guess that ExprState does not live long enough to be useful.
Actually the opposite: it lasts too long, namely the entire execution of
a query. I don't think there's any convenient way to reset it on the
timescale appropriate for STABLE values (ie, once
Chris K-L's recent complaint reminded me that we had been talking about
redefining int-to-bit(n) casting to take the rightmost n bits of the
integer value, instead of the leftmost n bits. The implementation
reason why it works the way it does is that the existing cast function
effectively
Bruce Momjian wrote:
Tom Lane wrote:
Now that I think about it, I believe Bruce recently removed this on my
advice; I was thinking that the problem shouldn't occur anymore now that
True.
we WAL-log file creation and deletion. But actually the present form of
the WAL entries doesn't ensure that
Scott Marlowe wrote:
On Fri, 2004-06-11 at 11:02, Bruce Momjian wrote:
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|Bruce Momjian wrote:
|
| I understand your points below. However,
On Mon, 14 Jun 2004, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The INSTALL file looks quite bad.
It's clearly been freshly generated. The formatting does seem worse
than in previous versions, but it's not so bad I'd want to hold up
the release to fix it.
My guess is that the
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
I guess that ExprState does not live long enough to be useful.
Actually the opposite: it lasts too long, namely the entire execution of
a query. I don't think there's any convenient way to reset it on the
timescale appropriate for STABLE
Oliver Jowett [EMAIL PROTECTED] writes:
But there are still other expression trees
that would benefit, e.g. those involving an IMMUTABLE function with
parameterized arguments.
Oh, you are thinking of some very-long-lived cache. This has been
proposed and rejected before; it's just not
[EMAIL PROTECTED] wrote:
I have been talking about two types of problems which are both based on
PostgreSQL's behavior with frequently updated tables.
Summary table: In the single row table system, you have to vacuum very
requently, and this affects performance.
Frequently updated tables:
[EMAIL PROTECTED] wrote:
I have been talking about two types of problems which are both based on
PostgreSQL's behavior with frequently updated tables.
Summary table: In the single row table system, you have to vacuum very
requently, and this affects performance.
Frequently updated tables: think
Hi,
I think replacing the RELOID with TYPEOID should get you the required Datum
...
later you may have to use
Form_pg_type pform = (Form_pg_type) GETSTRUCT(tuple);
to get a reference to the type tuple.
I have worked this way but iam not sure whether this is correct or not !!
If iam wrong some
Pursuant to the gripes raised by Martin Pitt ---
I've consulted some gcc experts within Red Hat and come to the following
conclusions:
* We should consistently refer to the spinlock contents via a
read/write operand declared like +m(*lock). This is consistent
with longstanding practice in the
Steve Atkins [EMAIL PROTECTED] writes:
On Fri, Jun 11, 2004 at 12:17:57PM -0400, Greg Stark wrote:
no, read committed would see any other updates that have been committed since
the start of your transaction.
Uhm... only updates within the current transaction.
No, read committed refers
I am getting the following error:
error: parse error in expression
error: /usr/src/redhat/SPECS/postgresql-7.4.2-1PGDG.spec:98:
parseExpressionBoolean returns -1
error: Package has no %description: postgresql
When I execute
rpmbuild --rebuild --define 'build9x 1' --define 'tcldevel 0' --define
got everything built this evening, just giving it a bit of time to
propogate out to the mirrors before announcing ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
Now that cast functions are selected through pg_cast, this should be a
fairly straightforward change. Does anyone have a problem with it?
I'm not sure the functionality is actually useful for anything except
this one issue, but arguably it's a general-purpose mechanism...
Does that help with
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
But there are still other expression trees
that would benefit, e.g. those involving an IMMUTABLE function with
parameterized arguments.
Oh, you are thinking of some very-long-lived cache. This has been
proposed and rejected before; it's
Sounds good to me. Consistencyis important because it lets us fix
problems across all cpu types. I am not 100% excited about the memory
part because it invalidates all register memory values, not just the
shared memory location. We are specifically accessing a memory address
as part of the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Does that help with making CREATE TABLE AS SELECT pick up varchar
lengths, etc.?
Not any better than it does now, no ... but AFAIK simple cases work okay
on that. What's your gripe exactly?
regards, tom lane
Not any better than it does now, no ... but AFAIK simple cases work okay
on that. What's your gripe exactly?
No gripe - was just pointing out a situation that might be improved
slightly be carrying around typmod info.
Chris
---(end of
Hi,
This is a preview patch - DON'T COMMIT IT TO HEAD!
What I've done in this patch is add the following:
ALTER AGGREGATE / OWNER TO
ALTER CONVERSION / OWNER TO
ALTER FUNCTION / OWNER TO
ALTER OPERATOR / OWNER TO
ALTER OPERATOR CLASS / OWNER TO
ALTER SCHEMA / OWNER TO
ALTER TYPE / OWNER TO
That
Dave Cramer [EMAIL PROTECTED] writes:
I am getting the following error:
error: parse error in expression
What does this have to do with accelerating aggregates?
Please don't start new threads by responding to existing threads.
--
greg
---(end of
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Then I made it so that pg_dump will output an OWNER TO statement after
every object creation.
Perhaps better to put these out towards the end of the dump, not right
after the creation of the object? Or is that what you're doing?
I would
Bruce Momjian [EMAIL PROTECTED] writes:
I am not 100% excited about the memory
part because it invalidates all register memory values, not just the
shared memory location.
That's exactly the point.
We are specifically accessing a memory address
as part of the ASM, so I don't see how it
Marc G. Fournier [EMAIL PROTECTED] writes:
got everything built this evening, just giving it a bit of time to
propogate out to the mirrors before announcing ...
Final tarball looks good from here ... but don't forget to update
the symlinks at the top level of the ftp site.
Perhaps better to put these out towards the end of the dump, not right
after the creation of the object? Or is that what you're doing?
I just inserted the ALTER OWNER statement between the CREATE and the
GRANTs. Why do you want them at the end of the dump?
I would envision the safest procedure
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I just inserted the ALTER OWNER statement between the CREATE and the
GRANTs. Why do you want them at the end of the dump?
So that the initial owner is still owner when he does COPY, ALTER TABLE
ADD PRIMARY KEY, etc etc. Else you're gonna have
So that the initial owner is still owner when he does COPY, ALTER TABLE
ADD PRIMARY KEY, etc etc. Else you're gonna have problems.
I was thinking of doing all COPY and ALTER as superuser as well...
Or are you trying to make it work when run as non-super? Which is won't
since ALTER OWNER will
37 matches
Mail list logo
