Hi Hackers,
I have created a table with an unknown column in it.
CREATE table test AS select 'a' as columna, 'b' as columnb;
will create a table with columna and columnb as an unknown type.
This in itself is not strictly a problem. However there are not functions in
postgresql to convert
On Fri, 2004-11-05 at 15:37 -0500, Tom Lane wrote:
One of the reasons I'm disinclined to move is that none of the proposed
alternatives seem especially, um, mature. AFAIK this project has never
had CVS lose any data in the eight years we've used it. I'd want a
comparable level of trust in
Andrew McMillan wrote:
Switching to Arch is more work, but it also offers a lot more benefits -
including the opportunity for individuals to maintain their own trees,
and be able to work out which patchsets from someone else's tree have
not been applied. If anything is going to become the
On Sat, 2004-11-06 at 04:38, Bruce Momjian wrote:
In talking to people working on various items, I think we should plan
for a beta next week once we have completed all the major open 8.0
items. Only the tablespace and win32 lost signals seem major.
And, once the beta has been tested for a
It seems that in the new PL/Perl, the result of the spi_exec_query
function changes in meaning depending on the command. For a SELECT,
the value of
$res-{rows}
is a reference to an array of the result rows.
For a different command
$res-{rows}
is a scalar containing the number of affected
Hi,
On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote:
The timeline code only comes into effect when you request an archive
recovery. If you do not, it has no way of knowing it should have.
Ok. However these details should be added to the docs as well.
At least a short warning should
The PG buildfarm has been operational for a little while now, thanks to
Joshua and CommandPrompt for the server space. You can see the current
status at:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Today for the first time I got a Windows client working, and will be
putting the code
Andrew Dunstan schrieb:
The PG buildfarm has been operational for a little while now, thanks to
Joshua and CommandPrompt for the server space. You can see the current
status at:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Today for the first time I got a Windows client working, and will
Simon Riggs [EMAIL PROTECTED] writes:
Peter has is thinking of freezing error message strings next week so
others can start on translations, and we should start collecting port
reports after the next beta too.
Is there a doc freeze as well as the error message string freeze?
No, we never
Reini Urban wrote:
Andrew Dunstan schrieb:
The PG buildfarm has been operational for a little while now, thanks
to Joshua and CommandPrompt for the server space. You can see the
current status at:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Today for the first time I got a Windows client
Andrew Dunstan schrieb:
Could loris also be used to do the cygwin and MSVC builds?
Cygwin is next on my list. The buildfarm client script does full server
builds, so MSVC isn't on the radar right now. FYI the steps in the
process are (more or less):
configure
make
make check
make contrib
make
As requested by Reini I set up a Cygwin buildfarm client, and immediately got this
build failure:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o
pg_backup_db.o pg_backup_custom.o pg_backup_files.o
Andrew Dunstan wrote:
As requested by Reini I set up a Cygwin buildfarm client, and immediately got this
build failure:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o
pg_backup_db.o
Sean Chittenden wrote:
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
Why can't it be a pointer to the currently running query?
Seems silly to me and is a PITA to try and use as a debugging tool only
to find out that the query in
On Sat, 2004-11-06 at 15:03, Joachim Wieland wrote:
Hi,
On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote:
The timeline code only comes into effect when you request an archive
recovery. If you do not, it has no way of knowing it should have.
Ok. However these details should be
Philip Warner [EMAIL PROTECTED] writes:
Attached. It has some trivial-looking rejects on current CVS. Let me know
if you would prefer me to do the work, or want some testing done. It was
tested (in terms of output validity) with 8.0b1.
Applied with minor cleanups.
Sean Chittenden [EMAIL PROTECTED] writes:
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
The reason for a limit is to avoid fragmentation of UDP messages.
I believe we've set it at 1K for 8.0, though, and if you are on
a platform with
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
The reason for a limit is to avoid fragmentation of UDP messages.
I believe we've set it at 1K for 8.0, though, and if you are on
a platform with a higher message size limit you could raise it
There's at least one bug in path.c's relative_path(): it will think
/foo/a/b is equal to /foo/ab because it skips directory separators
independently in the two strings. The code is sufficiently complex that
I have little faith in it not having any other bugs, either.
I believe that it's
Bruce Momjian [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
/home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple
definition of `_pg_tolower'
The _pg_tolower problem started when I changed exec.c to use the more
standard pg_strcasecmp rather than stricmp.
Since
Sean Chittenden [EMAIL PROTECTED] writes:
I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and
NFS over UDP often runs at 32K... where is UDP used in the backend?
pgstat messages travel over UDP/IP.
regards, tom lane
I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and
NFS over UDP often runs at 32K... where is UDP used in the backend?
pgstat messages travel over UDP/IP.
Over the loopback interface, right? Then why worry about
fragmentation? This seems like premature
Tom Lane wrote:
There's at least one bug in path.c's relative_path(): it will think
/foo/a/b is equal to /foo/ab because it skips directory separators
independently in the two strings. The code is sufficiently complex that
I have little faith in it not having any other bugs, either.
I
Sean Chittenden [EMAIL PROTECTED] writes:
Would you be open to increasing this further after the 8.0 release?
Nope.
I haven't heard of anyone complaining about dropped/fragmented pgstat
messages. :) -sc
That's because we keep 'em small enough to not fragment.
On Sat, 2004-11-06 at 19:44, Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Is there any reason the length of
pg_catalog.pg_stat_activity.current_query is capped at 255 characters?
The reason for a limit is to avoid fragmentation of UDP messages.
I believe we've set it at 1K
Bruce Momjian wrote:
Tom Lane wrote:
There's at least one bug in path.c's relative_path(): it will think
/foo/a/b is equal to /foo/ab because it skips directory separators
independently in the two strings. The code is sufficiently complex that
I have little faith in it not having any
Joachim Wieland has diligently and sensibly pointed out a potential for
user error with the current PITR implementation. This is not a bug *per
se*, but is a design flaw that more than one person could fall into. It
is a minor issue and not that likely, since the manual describes what to
do...but
Bruce Momjian [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Tom Lane wrote:
What I'd like to do is simplify it to just check for exact equality
up through the last directory separator in bin_path. Any objections?
If you can simplify it, feel free. I found that code much more complex
Simon Riggs [EMAIL PROTECTED] writes:
Not having the whole query is painful. Raising it to 1K doesn't get
round the fact that it's the longer queries that tend to be the more
painful ones, and so they are the ones you want to trap in full and
EXPLAIN, so you can find out if they are *ever*
Simon Riggs [EMAIL PROTECTED] writes:
If a further pg_ctl mode, recover, were implemented, this would allow a
fail safe mode for recovery.
e.g. pg_ctl -D datadir recover
pg_ctl could then check for the existence of a recovery.conf file and
return an error if none were found.
I can't get
I like it - nice and simple, but targets a large (and likely) foot gun
situation.
regards
Mark
Simon Riggs wrote:
If a further pg_ctl mode, recover, were implemented, this would allow a
fail safe mode for recovery.
e.g.pg_ctl -D datadir recover
pg_ctl could then check for the existence of a
I wrote:
A possibly more reliable interlock would involve having the postmaster
probe during normal startup to see if there is already an archived WAL
segment for what it thinks is the current segment.
Another and simpler way is to recommend that people use archive_command
strings that won't
Sean Chittenden [EMAIL PROTECTED] writes:
Having a 1K query isn't uncommon on some of the stuff I work on, an 8K
query...
that's a tad different and would stick out like a sore thumb.
Just as a point of reference, I've been processing my logs to see how large my
queries work out to. They
While this is nice, it will not help you if the restoration directory is
different from your archive directory. That is : restore_command in
recovery.conf fetches from somewhere other than where archive_command in
postgresql.conf copied.
I am not sure how likely this situation is, but setting
I was thinking that even mildly experienced folks could benefit from a
helpful sanity check. Typically the need to recover a system never comes
at a good time, and features that help prevent silly mistakes are a
great stress saver.
As an aside, while testing recovery during pre beta, I think I
35 matches
Mail list logo
