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
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 u
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. T
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
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 r
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
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
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 mo
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 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 ha
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
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.
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'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 optimization/preventio
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
---
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.
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 unnec
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 m
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 w
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.
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
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 que
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
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 question, has a logical break
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 p
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 in
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
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 n
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 be
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 chang
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 sho
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
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
On Sat, 2004-11-06 at 00:54, Joachim Wieland wrote:
> Hi,
>
> On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote:
> > That is exactly the situation Timelines are designed to avoid. This
> > should not have happened. What leads you to think it has? My guess is
> > that it has not. If it ha
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 open-sou
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
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 unkn
37 matches
Mail list logo