> > Since pg_upgrade will not work for 7.1, should its installation be
> > prevented and the man page be disabled?
>
> Probably. I am not sure it will ever be used again now that we have
> numeric file names.
Perhaps we should leave it for 7.1 because people will complain when
they can not find
* Larry Rosenman <[EMAIL PROTECTED]> [010316 20:47]:
> * Jan Wieck <[EMAIL PROTECTED]> [010316 16:35]:
> $ ./queuetest
> Pipe buffer is 32768 bytes
> Sys-V message queue buffer is 4096 bytes
> $ uname -a
> UnixWare lerami 5 7.1.1 i386 x86at SCO UNIX_SVR5
> $
>
> I think some of these are configu
* Jan Wieck <[EMAIL PROTECTED]> [010316 16:35]:
> Jan Wieck wrote:
> > Tom Lane wrote:
> > > Now this would put a pretty tight time constraint on the collector:
> > > fall more than 4K behind, you start losing data. I am not sure if
> > > a UDP socket would provide more buffering or not; anyone k
> Since pg_upgrade will not work for 7.1, should its installation be
> prevented and the man page be disabled?
Probably. I am not sure it will ever be used again now that we have
numeric file names.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Is there a timeout setting I can use to abort transactions that aren't
deadlocked, but which have been blocked waiting for locks greater than some
amount of time? I didn't see anything in the docs on this and observed with
2 instances of psql that a transaction waiting on a lock seems to wait
fore
> > Ah, but is the LD_LIBRARY_PATH the same inside that su? A change of
> > environment might explain why this works "by hand" and not through su
> > ...
> This #$^%^*$%ยค Solaris!!
> Check this out, and tell me I shouldn't yell out at SUN:
> root@ultra31 / # su - postgres -c 'echo $PATH'
> /u
Since pg_upgrade will not work for 7.1, should its installation be
prevented and the man page be disabled?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> > And you know - I've run same tests on ~ Mar 9 snapshot
> > without any problems.
> >>
> >> That was before I changed the code to pre-fill the file ---
> >> now it takes longer to init a log segment. And we're only
> >> using a plain SpinAcquire, not the flavor with a longer timeout.
>
> >
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> And you know - I've run same tests on ~ Mar 9 snapshot
> without any problems.
>>
>> That was before I changed the code to pre-fill the file ---
>> now it takes longer to init a log segment. And we're only
>> using a plain SpinAcquire, not the flav
> Just to get some evidence at hand - could some owners of
> different platforms compile and run the attached little C
> source please?
$ uname -srm
FreeBSD 4.1.1-STABLE
$ ./jan
Pipe buffer is 16384 bytes
Sys-V message queue buffer is 2048 bytes
$ uname -srm
NetBSD 1.5 alph
> >> Got it at spin.c:156 with 50 clients doing inserts into
> >> 50 tables (int4, text[1-256 bytes]).
> >> -B 16384, -wal_buffers=256 (with default others wal params).
>
> > SpinAcquire() ... but on which lock?
>
> After a little bit of thought I'll bet it's ControlFileLockId.
I see "XLogWrite
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Alternatively, could we avoid holding that lock while initializing a
>> new log segment?
> How to synchronize with checkpoint-er if wal_files > 0?
I was sort of visualizing assigning the created xlog files dynamically:
create a temp file o
> > How to synchronize with checkpoint-er if wal_files > 0?
>
> I was sort of visualizing assigning the created xlog files
> dynamically:
>
> create a temp file of a PID-dependent name
> fill it with zeroes and fsync it
> acquire ControlFileLockId
> rename temp file into
Jan Wieck <[EMAIL PROTECTED]> writes:
> Just to get some evidence at hand - could some owners of
> different platforms compile and run the attached little C
> source please?
HPUX 10.20:
Pipe buffer is 8192 bytes
Sys-V message queue buffer is 16384 bytes
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Got it at spin.c:156 with 50 clients doing inserts into
>> 50 tables (int4, text[1-256 bytes]).
>> -B 16384, -wal_buffers=256 (with default others wal params).
> SpinAcquire() ... but on which lock?
After a little bit of thought I'll bet it's Contr
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Got it at spin.c:156 with 50 clients doing inserts into
> 50 tables (int4, text[1-256 bytes]).
> -B 16384, -wal_buffers=256 (with default others wal params).
SpinAcquire() ... but on which lock?
regards, tom lane
---
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
> Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it
> that Solaris doesn't load the .profile in the postgres directory.
Ah, but is the LD_LIBRARY_PATH the same inside that su? A change of
environment might explain why this
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> will do an announce later on tonight, to give the mirrors a chance to
> start syncing ... can others confirm that the packaging once more looks
> clean?
The main tar.gz matches what I have here. Didn't look at the partial
tarballs.
> There is a HP_UX kernel flag 'o_sync_is_o_dsync' which will cause
> O_DSYNC to be treated as O_SYNC. It defaults to being off -- it
... other way around there, of course. Trying to clarify and
adding confusion instead. :-(
> is/was a backward compatibility "feature" since HP-UX 9.X (which i
Jan Wieck wrote:
> Tom Lane wrote:
> > Now this would put a pretty tight time constraint on the collector:
> > fall more than 4K behind, you start losing data. I am not sure if
> > a UDP socket would provide more buffering or not; anyone know?
>
> Looks like Linux has something around 16-32K
Got it at spin.c:156 with 50 clients doing inserts into
50 tables (int4, text[1-256 bytes]).
-B 16384, -wal_buffers=256 (with default others wal params).
Vadim
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
will do an announce later on tonight, to give the mirrors a chance to
start syncing ... can others confirm that the packaging once more looks
clean?
thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTE
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
>> Hm, that 'Killed' looks suspicious. What shows up in the
>> /dbs/postgres/sql.log file?
> Nothing at all.
That's no help :-(. Please alter the command to trace the shell script,
ie
su postgres -c 'sh -x /dbs/postgres/bin/pg_ctl -o ... 2>trace
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
>> Please define "doesn't work". What happens exactly? What messages
>> are produced?
> root@ultra31 /space/pruebas/postgres-cvs # su postgres -c
> '/dbs/postgres/bin/pg_ctl -o "-i" -D /dbs/postgres/data/ start -l
> /dbs/postgres/sql.log'
> 1905
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> It's great as long as you never block, but it sucks for making things
>> wait, because the wait interval will be some multiple of 10 msec rather
>> than just the time till the lock comes free.
> On the AIX platform usleep (3) is able to reall
[ Drifting off topic ... ]
> Well, that guy might know all about Linux, but he doesn't know anything
> about HPUX (at least not any version I've ever run). O_SYNC is
> distinctly different from O_DSYNC around here.
There is a HP_UX kernel flag 'o_sync_is_o_dsync' which will cause
O_DSYNC to be
Tom Lane wrote:
> Now this would put a pretty tight time constraint on the collector:
> fall more than 4K behind, you start losing data. I am not sure if
> a UDP socket would provide more buffering or not; anyone know?
Looks like Linux has something around 16-32K of buffer space
for UDP
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Does a pipe guarantee that a buffer, written with one atomic
> > write(2), never can get intermixed with other data on the
> > readers end?
>
> Yes. The HPUX man page for write(2) sez:
>
> o Write requests of
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
> ... my startup scripts don't work anymore.
> What the script has, works if I try to do it as postgres, but with a
> su -l postgres -c 'command' as root it doesn't work.
Please define "doesn't work". What happens exactly? What messages
are produ
Jan Wieck <[EMAIL PROTECTED]> writes:
> Does a pipe guarantee that a buffer, written with one atomic
> write(2), never can get intermixed with other data on the
> readers end?
Yes. The HPUX man page for write(2) sez:
o Write requests of {PIPE_BUF} bytes or less will
* Tom Lane <[EMAIL PROTECTED]> [010316 10:06] wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Uh - not much time to spend if the statistics should at least
> > be half accurate. And it would become worse in SMP systems.
> > So that was a nifty idea, but I think it'd cause much
> On 3/16/01, 11:10:34 AM, The Hermit Hacker <[EMAIL PROTECTED]> wrote
> regarding Re: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC :
>
> > But, with shared libraries, are you really pulling in a "whole
> > thread-support library"? My understanding of shared libraries (altho it
> >
Barry Lind <[EMAIL PROTECTED]> writes:
> What I would expect the syntax to be is:
> table as alias (columna as aliasa, columnb as aliasb,...)
> This will allow the query to work regardless of what the table column
> order is. Generally the SQL spec has tried not to tie query behaviour
> to the
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Uh - not much time to spend if the statistics should at least
> > be half accurate. And it would become worse in SMP systems.
> > So that was a nifty idea, but I think it'd cause much more
> > statistic losses than I
On Fri, Mar 16, 2001 at 12:01:36AM +, Thomas Lockhart wrote:
> > > You are not quite factually correct above, even given your definition of
> > > "bug". PostgreSQL does reuse deleted record space, but requires an
> > > explicit maintenance step to do this.
> > Could you tell us what that maint
Alfred Perlstein wrote:
> * Jan Wieck <[EMAIL PROTECTED]> [010316 08:08] wrote:
> > Philip Warner wrote:
> > >
> > > But I prefer the UDP/Collector model anyway; it gives use greater
> > > flexibility + the ability to keep stats past backend termination, and,as
> > > you say, removes any possible
> > I don't understand the attraction of the UDP stuff. If we have the
> > stuff in shared memory, we can add a collector program that gathers info
> > from shared memory and allows others to access it, right?
>
> There are a couple of problems with shared memory. First you
> have to de
At 17:10 15/03/01 -0800, Alfred Perlstein wrote:
>>
>> Which is why the backends should not do anything other than maintain the
>> raw data. If there is atomic data than can cause inconsistency, then a
>> dropped UDP packet will do the same.
>
>The UDP packet (a COPY) can contain a consistant sna
My problem is that my two outer joined tables have columns that have the
same names. Therefore when my select list tries to reference the
columns they are ambiguously defined. Looking at the doc I see the way
to deal with this is by using the following syntax:
table as alias (column1alias, c
[ Charset ISO-8859-1 unsupported, converting... ]
> Yes, you are. On UnixWare, you need to add -Kthread, which CHANGES a LOT
> of primitives to go through threads wrappers and scheduling.
This was my concern; the change that happens on startup and lib calls
when thread support comes in through
> For a log file on a busy system, this could improve throughput a lot--batch
> commit. You end up with fewer than one fsync() per transaction.
This is not the issue, since that is already implemented.
The current bunching method might have room for improvement, but
there are currently fewer fs
Tom Lane <[EMAIL PROTECTED]> writes:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as
Jan Wieck <[EMAIL PROTECTED]> writes:
> Uh - not much time to spend if the statistics should at least
> be half accurate. And it would become worse in SMP systems.
> So that was a nifty idea, but I think it'd cause much more
> statistic losses than I assumed at first.
> B
Yes, you are. On UnixWare, you need to add -Kthread, which CHANGES a LOT
of primitives to go through threads wrappers and scheduling.
See the doc on the http://UW7DOC.SCO.COM or http://www.lerctr.org:457/
web pages.
Also, some functions are NOT available without the -Kthread or -Kpthread
dir
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as long as you never block, but it sucks for making things
I like optimistic approach
> So are we still thinking about preallocating log files as a
> performance hack? It does seem that using preallocated files along
> with O_DATASYNC will eliminate pretty much all metadata writes under
> Linux in future...
>
> [NOT suggesting we try to add anything to 7.1, I'm eagerly awaiting R
Doug McNaught <[EMAIL PROTECTED]> writes:
> So are we still thinking about preallocating log files as a
> performance hack?
We're not just thinking about it, we're doing it in current sources ...
regards, tom lane
---(end of broadcast)
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> But, with shared libraries, are you really pulling in a "whole
>> thread-support library"?
> Yes, you are. On UnixWare, you need to add -Kthread, which CHANGES a LOT
> of primitives to go through threads wrappers and scheduling.
Right, it's not so
Tom Lane <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> forwards:
> >> 2.4's O_SYNC actually does a fdatasync internally. This is also the
> >> default behaviour of HPUX, which requires you to set a sysctl variable
> >> if you want O_SYNC to flush timestamp changes to disk.
>
>
> We've speculated about using Posix semaphores instead, on platforms
For spinlocks we should use pthread mutex-es.
> where those are available. I think Bruce was concerned about the
And nutex-es are more portable than semaphores.
Vadim
---(end of broadcast)--
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> I was wondering if the multiple writes performed to the
> XLOG could be grouped into one write().
>>
>> That would require fairly major restructuring of xlog.c, which I don't
> Restructing? Why? It's only XLogWrite() who make writes.
I was thinkin
On Fri, 16 Mar 2001, Tom Lane wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as l
> > I was wondering if the multiple writes performed to the
> > XLOG could be grouped into one write().
>
> That would require fairly major restructuring of xlog.c, which I don't
Restructing? Why? It's only XLogWrite() who make writes.
> want to undertake at this point in the cycle (we're tryi
* Jan Wieck <[EMAIL PROTECTED]> [010316 08:08] wrote:
> Philip Warner wrote:
> >
> > But I prefer the UDP/Collector model anyway; it gives use greater
> > flexibility + the ability to keep stats past backend termination, and,as
> > you say, removes any possible locking requirements from the backen
Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> definitely need before considering this is to replace the existing
>> spinlock mechanism with something more efficient.
> What sort of problems are you seeing with the spinlock code?
It's great as long as you never block, but it sucks for making th
Philip Warner wrote:
>
> But I prefer the UDP/Collector model anyway; it gives use greater
> flexibility + the ability to keep stats past backend termination, and,as
> you say, removes any possible locking requirements from the backends.
OK, did some tests...
The postmaster can create a
* Tom Lane <[EMAIL PROTECTED]> [010316 08:16] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> couldn't the syncer process cache opened files? is there any problem I
> >> didn't consider ?
>
> > 1) IPC latency, the amount of time it takes to call fsync will
> >increase by at least t
Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> couldn't the syncer process cache opened files? is there any problem I
>> didn't consider ?
> 1) IPC latency, the amount of time it takes to call fsync will
>increase by at least two context switches.
> 2) a working set (number of files needed
Doug McNaught <[EMAIL PROTECTED]> forwards:
>> 2.4's O_SYNC actually does a fdatasync internally. This is also the
>> default behaviour of HPUX, which requires you to set a sysctl variable
>> if you want O_SYNC to flush timestamp changes to disk.
Well, that guy might know all about Linux, but he
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> tried test cases with both journaling and non-journaling file systems?
> Perhaps the flag choice would be markedly different for the different
> options?
Good point. Another reason we don't have enough data to nail this down
yet. Anyway, the code is
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> > > Could anyone consider fork a syncer process to sync data to disk ?
> > > build a shared sync queue, when a daemon process want to do sync after
> > > write() is called, just put a sync request to the queue. this can
release
> > > process from blocked
* Bruce Momjian <[EMAIL PROTECTED]> [010316 07:11] wrote:
> > > Could anyone consider fork a syncer process to sync data to disk ?
> > > build a shared sync queue, when a daemon process want to do sync after
> > > write() is called, just put a sync request to the queue. this can release
> > > proc
My UnixWare box runs Veritas' VXFS, and has Online-Data Manager
installed. Documentation is available at http://www.lerctr.org:457/
There are MULTIPLE sync modes, and there are also hints an app can give
to the FS.
More info is available if you want.
LER
--
Larry Rosenman
> > Could anyone consider fork a syncer process to sync data to disk ?
> > build a shared sync queue, when a daemon process want to do sync after
> > write() is called, just put a sync request to the queue. this can release
> > process from blocked on writing as soon as possible. multipile sync
>
Just a quick delurk to pass along this tidbit from linux-kernel on
Linux *sync() behavior, since we've been talking about it a lot...
-Doug
Hi,
On Wed, Mar 14, 2001 at 10:26:42PM -0500, Tom Vier wrote:
> fdatasync() is the same as fsync(), in linux.
No, in 2.4 fdatasync does the right thing
> > Okay ... we can fall back to O_FSYNC if we don't see either of the
> > others. No problem. Any other weird cases out there? I think Andreas
> > might've muttered something about AIX but I'm not sure now.
> You can safely use O_DSYNC on AIX, the only special on AIX is,
> that it does not mak
> Okay ... we can fall back to O_FSYNC if we don't see either of the
> others. No problem. Any other weird cases out there? I think Andreas
> might've muttered something about AIX but I'm not sure now.
You can safely use O_DSYNC on AIX, the only special on AIX is,
that it does not make a spee
* Xu Yifeng <[EMAIL PROTECTED]> [010316 01:15] wrote:
> Hello Alfred,
>
> Friday, March 16, 2001, 3:21:09 PM, you wrote:
>
> AP> * Xu Yifeng <[EMAIL PROTECTED]> [010315 22:25] wrote:
> >>
> >> Could anyone consider fork a syncer process to sync data to disk ?
> >> build a shared sync queue, when
Hello Alfred,
Friday, March 16, 2001, 3:21:09 PM, you wrote:
AP> * Xu Yifeng <[EMAIL PROTECTED]> [010315 22:25] wrote:
>>
>> Could anyone consider fork a syncer process to sync data to disk ?
>> build a shared sync queue, when a daemon process want to do sync after
>> write() is called, just put
69 matches
Mail list logo
