On Wed, 2006-01-11 at 20:46 -0500, Qingqing Zhou wrote:
On Wed, 11 Jan 2006, Simon Riggs wrote:
Probably good idea to read Gray Reuter or Vekum Vossen books on
transactional systems theory before any such discussion.
So can you give me some hints why my thoughts are just wrong?
On Wed, 2006-01-11 at 22:33 -0500, Qingqing Zhou wrote:
On Wed, 11 Jan 2006, Tom Lane wrote:
It'd be possible to do something like this: after establishing
RedoRecPtr, make one quick pass through the buffers and make a list of
what needs to be dumped at that instant. Then go back and do
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 11 Jan 2006, Tom Lane wrote:
It'd be possible to do something like this: after establishing
RedoRecPtr, make one quick pass through the buffers and make a list of
what needs to be dumped at that instant. Then go back and do the actual
I/O for
On Thu, 12 Jan 2006, Simon Riggs wrote:
The only buffers this will miss are ones that were clean throughout the
whole of the last checkpoint cycle, yet have been dirtied between the
start of the checkpoint pass and when the pass reaches it.
I agree on the analysis but I am not sure current
Tom,
It's not enough better, because it will still deadlock given a
sufficiently large message-to-send. I don't think you can postpone
the clearing-input action until after all the data is sent.
regards, tom lane
Please help me understand this better. It appears to me that when the
On Thu, Jan 12, 2006 at 04:50:30AM -0500, Qingqing Zhou wrote:
On Thu, 12 Jan 2006, Simon Riggs wrote:
The only buffers this will miss are ones that were clean throughout the
whole of the last checkpoint cycle, yet have been dirtied between the
start of the checkpoint pass and when
On Thu, 12 Jan 2006, Jim C. Nasby wrote:
It sounds like worrying about this would be much more interesting on a
machine that is seeing both a fairly heavy IO load (meaning checkpoint
will both take longer and affect other workloads more) and is seeing a
pretty high rate of buffer updates
Alon Goldshuv [EMAIL PROTECTED] writes:
Please help me understand this better. It appears to me that when the
client-backend pipe fills up, pqSendSome() consumes any incoming
NOTICE/WARNING messages before waiting, which should prevent deadlock.
Hm, I had forgotten that the low-level
David Fetter wrote:
Folks,
I'm picturing something like this:
make install # Option 0 Leave as-is
make install --auto_schema [--generate_path_mod] # Option 1
make install --schema=contrib # Option 2
make install --schema=foo
Through googling, i found that Normal Disk has external data transfer rate of
around 40MBps,
^^
Does this includes, seek and rotational latency ?
where as Main Memory has Data transfer rate
David Fetter said:
I'm picturing something like this:
make install # Option 0 Leave
as-is make install --auto_schema [--generate_path_mod] # Option 1
make install --schema=contrib # Option 2
make install --schema=foo
David Fetter [EMAIL PROTECTED] writes:
What do you think?
I think it's not broken and doesn't need fixing. I have not seen any
groundswell of demand for moving the contrib stuff out of the public
schema. On the other hand, doing so *will* break many if not all
existing applications that use
Tom,
People who want the contrib stuff segregated can easily make it
happen by modifying the contrib .sql files before they run them.
The .sql files already have a skeleton for this, eg
-- Adjust this setting to control where the objects get created.
SET search_path = public;
I
Folks,
For the same reason they feel that *n*x installs shouldn't be messing
around in /usr/local, some people also feel that contrib modules
shouldn't install in the public schema by default. Before I go
a-patching, I'd like to see what people think about how to handle
this. A few of
Default schema really has to be public to help the newbies out there.
All contribs should come with some sort of standard uninstall.sql script
though.
Chris
Mark Kirkwood wrote:
David Fetter wrote:
Folks,
I'm picturing something like this:
make install
On Jan 12, 2006, at 9:03 PM, Christopher Kings-Lynne wrote:
Default schema really has to be public to help the newbies out
there. All contribs should come with some sort of standard
uninstall.sql script though.
Speaking of contrib newbies and install/uninstall, I recently had the
need
I'm sorry when you have received mails of the same content. I had sent
a mail but it seemed not to be delivered, so I'll send it again.
Tom Lane [EMAIL PROTECTED] wrote:
I encountered overflow of bgwriter's file-fsync request queue.
I can't help thinking that this is a situation that could
[ moved to -hackers ]
Michael Fuhr [EMAIL PROTECTED] writes:
On Thu, Jan 12, 2006 at 11:21:28PM -0500, Tom Lane wrote:
plpgsql is not very good about reserving words minimally, ie, not
treating a word as a keyword outside the context where the keyword
is meaningful.
This could probably be
18 matches
Mail list logo
