>
> Would you send me documentation explaining how to register this DLL with
> the event logger on Win32? Ideally you could send me a diff against
> installation.sgml.
>
Hello Bruce,
After the DLL was in it target directory (C:\msys\1.0\local\pgsql\lib with
make install)
You can register the
Some nitpicking on details:
The comment above AutoVacMain() claims:
! * Main entry point for bgwriter process
I also see a bunch of // comments, I think those are not appreciated.
Haven't had time to look much at the actual functionality. Just did a
quick look-through for win32 showstoppers,
Here's a rough first cut, close to application state but not a finished
work.
Might be pushed for time over the next week, so if there are major
criticisms it might need someone else to pick this up in the short term.
I'll happily redo any minor bits.
Comments?
Cheers,
Claudio
---
Certain di
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I also noticed:
> ! elog(ERROR, "pg_autovacuum: GUC variable stats_row_level
> must be enabled.");
> ! elog(ERROR, " Please fix the problems and try
> again.");
> If you use the ereport() call instead of elog, you can se
On Wed, 2004-06-16 at 10:01, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > I also noticed:
> > ! elog(ERROR, "pg_autovacuum: GUC variable stats_row_level
> > must be enabled.");
> > ! elog(ERROR, " Please fix the problems and try
> > again.");
>
> >
Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
I also noticed:
! elog(ERROR, "pg_autovacuum: GUC variable stats_row_level
must be enabled.");
! elog(ERROR, " Please fix the problems and try
again.");
If you use the ereport() call instead of elog, you can set the
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Claudio Natoli
> Sent: 16 June 2004 14:49
> To: [EMAIL PROTECTED]
> Subject: [PATCHES] pg_ctl service integration for WIN32
>
>
> Here's a rough first cut, close to application state but not
>
Wow, my START /B code stays in pg_ctl? Interesting. I thought that was
going to be ripped out.
---
Claudio Natoli wrote:
>
> Here's a rough first cut, close to application state but not a finished
> work.
>
> Might be pu
Bruce Momjian writes:
> Wow, my START /B code stays in pg_ctl? Interesting. I
> thought that was going to be ripped out.
Didn't touch on anything other than service integration.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of
I'm starting to review this patch, and almost immediately came across
what seemed a spectacularly bad idea:
*** src/backend/storage/buffer/bufmgr.c8 May 2004 19:09:25 -1.165
--- src/backend/storage/buffer/bufmgr.c26 May 2004 06:21:01 -
***
*** 1148,1152
Hi Tom,
On Wed, 16 Jun 2004, Tom Lane wrote:
> I'm starting to review this patch, and almost immediately came across
> what seemed a spectacularly bad idea:
>
> *** src/backend/storage/buffer/bufmgr.c8 May 2004 19:09:25 -1.165
> --- src/backend/storage/buffer/bufmgr.c26 May 2004 0
On Tue, 2004-06-08 at 23:23, Alvaro Herrera wrote:
> Hackers,
>
> Here is the latest installment of the nested transactions patch.
>
> What's in the current patch:
>
First of all, thank you for all your helpful comments recently.
The patch looks impressively technical, but overall I'm not exac
Dave Page writes:
> Looks OK to me at a quick glance. One thought though, whilst I like the
> idea of using service pause to do a SIGHUP from a convenience point of
> view, it's not exactly the expected behaviour and might leave the
> inexperienced user wondering why the server is still running no
I agree with Simon's comments. And to them I would add: I had assumed
that the requirements for 'nested transactions' was following some
standard definition or specification (i.e. the ANSI SQL spec). But from
what I can tell, we are rolling our own definition here, not following a
specificat
Barry Lind wrote:
> I agree with Simon's comments. And to them I would add: I had assumed
> that the requirements for 'nested transactions' was following some
> standard definition or specification (i.e. the ANSI SQL spec). But from
> what I can tell, we are rolling our own definition here, n
On Wed, Jun 16, 2004 at 11:45:36PM +0100, Simon Riggs wrote:
> The patch looks impressively technical, but overall I'm not exactly sure
> what it does...I guess I'm just not clear why I would want it, except as
> the main technical pre-work to later syntax changes. I'm sure some short
> explanatio
And consider this case:
BEGIN;
...
SAVEPOINT x;
SELECT func_call();
SELECT func_call();
COMMIT;
Now if func_call has a savepoint, it is really nested because it can't
know whether the savepoint X will be used to roll back, so its status is
dependent o
On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote:
> >And consider this case:
> >
> > BEGIN;
> > ...
> > SAVEPOINT x;
> > SELECT func_call();
> > SELECT func_call();
> > COMMIT;
> >
> >Now if func_call has a savepoint, it is really nested because it can
Christopher Kings-Lynne wrote:
> > And consider this case:
> >
> > BEGIN;
> > ...
> > SAVEPOINT x;
> > SELECT func_call();
> > SELECT func_call();
> > COMMIT;
> >
> > Now if func_call has a savepoint, it is really nested because it can't
> > know whether the savepoint X wi
On Wed, Jun 16, 2004 at 09:36:33PM -0400, Bruce Momjian wrote:
> And consider this case:
>
> BEGIN;
> ...
> SAVEPOINT x;
> SELECT func_call();
> SELECT func_call();
> COMMIT;
>
> Now if func_call has a savepoint, it is really nested because it can't
> know whe
Alvaro Herrera wrote:
> On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote:
> > >And consider this case:
> > >
> > > BEGIN;
> > > ...
> > > SAVEPOINT x;
> > > SELECT func_call();
> > > SELECT func_call();
> > > COMMIT;
> > >
> > >Now if func_call has a savepoint, it
The attached patch adds some index entries pointing to the cursor
reference pages. Please apply.
--
Alvaro Herrera ()
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be short and readable and thy days pleasant
and productive. (7th Commandment for C
22 matches
Mail list logo