On Tue, March 14, 2006 22:14, Paulina Quezada wrote:
> Hola, necesito saber con que sentencias sql puedo controlar desde un
> trigger
> el número de registros a actualizar o a borrar, esto para que desde la
> consola no se hagan deletes o updates masivos.
Aqui se habla ingles.
Jeroen
Christopher Kings-Lynne wrote:
Hi guys,
I've been trying to build the cvs checkout of 8.1.3 on my freebsd 4.9
box with a STATIC psql utility. I keep getting failures trying to hook
in libreadline I think:
lreadline -lcrypt -lcompat -lm -lutil -o psql
/usr/lib/libreadline.a(terminal.o): In
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I've been trying to build the cvs checkout of 8.1.3 on my freebsd 4.9
> box with a STATIC psql utility. I keep getting failures trying to hook
> in libreadline I think:
> lreadline -lcrypt -lcompat -lm -lutil -o psql
> /usr/lib/libreadline.
Hi guys,
I've been trying to build the cvs checkout of 8.1.3 on my freebsd 4.9
box with a STATIC psql utility. I keep getting failures trying to hook
in libreadline I think:
lreadline -lcrypt -lcompat -lm -lutil -o psql
/usr/lib/libreadline.a(terminal.o): In function `_rl_get_screen_size':
Hola, necesito saber con que sentencias sql puedo controlar
desde un trigger el número de registros a actualizar o a borrar, esto para que
desde la consola no se hagan deletes o updates masivos.
Gracias!
On 3/15/06, Andreas Kretschmer <[EMAIL PROTECTED]> wrote:
> Merlin Moncure <[EMAIL PROTECTED]> schrieb:
>
> > On 3/15/06, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> > > Attached is a simplified example of a performance problem we have seen,
> > > with a workaround and a suggestion for enhancement
On 3/15/06, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> Attached is a simplified example of a performance problem we have seen,
> with a workaround and a suggestion for enhancement (hence both the
> performance and hackers lists).
Hi Kevin. In postgres 8.2 you will be able to use the row-wise
co
Attached is a simplified example of a performance problem we have seen,
with a workaround and a suggestion for enhancement (hence both the
performance and hackers lists).
Our software is allowing users to specify the start and end dates for a
query. When they enter the same date for both, the opt
On Wed, 15 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > The main options seem to be:
> > When we're allowing other order access, immediately reorder the
> > constraint information to match the primary key order. This helps out
> > with IS since the loaded constraint
Stephan Szabo <[EMAIL PROTECTED]> writes:
> The main options seem to be:
> When we're allowing other order access, immediately reorder the
> constraint information to match the primary key order. This helps out
> with IS since the loaded constraint should display properly, but
> theoretically cou
On 3/15/06, Charlie Wang <[EMAIL PROTECTED]> wrote:
Could you tell me something about the internal structure of the WAL Files?
Aside from looking at all the xlog code, the easiest way to understand
the logs is to look at Tom's xlogdump utility. You can find it in
the archives somewhere but it need
Simon Riggs wrote:
> On Wed, 2006-03-15 at 09:12 -0400, Alvaro Herrera wrote:
> > Charlie Wang wrote:
> > > I want to write a function to expose the content of WAL Files as streams,
> > > and then send to somewhere else, record by record.
> >
> > Re: the WAL records, most likely they are useless
On Wed, 2006-03-15 at 09:12 -0400, Alvaro Herrera wrote:
> Charlie Wang wrote:
> > I want to write a function to expose the content of WAL Files as streams,
> > and then send to somewhere else, record by record.
>
> Re: the WAL records, most likely they are useless outside the server
> that gener
Charlie Wang wrote:
> I want to write a function to expose the content of WAL Files as streams,
> and then send to somewhere else, record by record.
This is not a patch -- please do not write to the pgsql-patches list.
Thanks.
Re: the WAL records, most likely they are useless outside the server
Well, actually we're ain't gonna do this procedure regularly, but just in case of failure - if it ever happens.For the moment, I did the dump/restore and it worked, but took almost 1 hour, due to tsearch2 indexes on a table.
Yeah, I thought 64-bit data could be stored on other files than pg_control
Magnus Hagander wrote:
On Monday 13 March 2006 12:27, Magnus Hagander wrote:
Great. That'll certainly help - now you don't have to wait for
binaries from me.
What I'd be interested in seeing is new stackdumps from a version
where
you:
1) Do *not* have the patch for mutexes applied
2) Have re
16 matches
Mail list logo
