The attached is a patch to define O_DIRECT by ourselves on Windows,
and to map O_DIRECT to FILE_FLAG_NO_BUFFERING.
There will be a consistency in our support between Windows and other OSes
that have O_DIRECT. Also, there is the following comment that says, I read,
we should do so.
| handle other f
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> pg_dumpall -g -- Dump roles and tablespaces per current behaviour
>> pg_dumpall -gr -- Dump roles only (or users and groups)
>> pg_dumpall -gt -- Dump tablespaces only
>
> This seems a bit ugly, mainly because (1) it doesn't have a natura
On Mon, Jan 15, 2007 at 05:36:09PM +0900, ITAGAKI Takahiro wrote:
> The attached is a patch to define O_DIRECT by ourselves on Windows,
> and to map O_DIRECT to FILE_FLAG_NO_BUFFERING.
>
> There will be a consistency in our support between Windows and other OSes
> that have O_DIRECT. Also, there i
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> FILE_FLAG_NO_BUFFERING requires that *all* I/O follows:
> * File access must begin at offsets that are integer multples of the
> volume sector size.
> * File access must be for number of bytes that are integer multiples of
> the volume sector size.
Per discussion on -hackers, the attached patch allow the default
database to be specified on the pg_dumpall command line, eg.
pg_dumpall [options...] [dbname]
If dbname is not specified, postgres/template1 are used per current
behaviour. If a connection cannot be made to dbname, an error is
retur
Hi Bruce,
I have not been able to send this file across since the last two days.
In the past I have been able to send 31KB attachments to patches, but I
donno why it's not getting through this time. I have tried different levels
of compression in different formats, and still it won't let the m
Am Montag, 15. Januar 2007 14:44 schrieb Dave Page:
> Per discussion on -hackers, the attached patch allow the default
> database to be specified on the pg_dumpall command line, eg.
>
> pg_dumpall [options...] [dbname]
I think this should be a separate option. Otherwise it would be too easy to
c
Gurjeet Singh wrote:
Please find attached two patches:
1) pg_post_planner_plugin-REL8_2_STABLE-v1.patch.gz
2) pg_index_adviser-REL8_2_STABLE-v26.patch.gz
Why are these patches against 8.2 rather than CVS HEAD? Is this not a
new feature? We never backport new features to
> Please find attached two patches:
>
> 1) pg_post_planner_plugin-REL8_2_STABLE-v1.patch.gz
> 2) pg_index_adviser-REL8_2_STABLE-v26.patch.gz
>
Why are these patches against 8.2 rather than CVS HEAD? Is this not a
new feature? We never backport new features to the stable branches
Peter Eisentraut wrote:
> Am Montag, 15. Januar 2007 14:44 schrieb Dave Page:
>> Per discussion on -hackers, the attached patch allow the default
>> database to be specified on the pg_dumpall command line, eg.
>>
>> pg_dumpall [options...] [dbname]
>
> I think this should be a separate option. Ot
This patch makes some minor improvements to the TODO list:
* add URLs for some TODO items (I think we ought to try to associate
at least one URL with each non-trivial TODO item)
* re-add a TODO item for an "estimated count"-like facility
* add a TODO item for considering changing how e
On Mon, 2007-01-15 at 17:07 +, Dave Page wrote:
> You're thinking the user might expect it dump all of that database? Not
> sure I agree with that, but I'm not wedded to the syntax. Any other
> opinions?
I agree with Peter: specifying the database name as implemented seems
like it would be pro
On Sun, 2007-01-14 at 13:57 +0100, Pavel Stehule wrote:
> this patch adds scrollable support functions to SPI. It's necessary for
> scrollable cursors in plpgsql. Original API is without changes.
One trivial point is that if you're going to use an int * to represent
an "optional int" argument, it
ITAGAKI Takahiro wrote:
> Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
>> FILE_FLAG_NO_BUFFERING requires that *all* I/O follows:
>> * File access must begin at offsets that are integer multples of the
>> volume sector size.
>> * File access must be for number of bytes that are integer multiples
Neil Conway <[EMAIL PROTECTED]> writes:
> * add a TODO item for considering changing how equality comparisons
> treat NaN values, per recent discussion
Seems like a complete nonstarter, unfortunately. btree requires the
datatype to have a total order, and I can't see that changing, so NaN
l
On Mon, 2007-01-15 at 13:29 -0500, Tom Lane wrote:
> Seems like a complete nonstarter, unfortunately. btree requires the
> datatype to have a total order, and I can't see that changing, so NaN
> loses.
Well, yeah, that would be the major impediment to implementing it. We
could just not define a t
On Mon, 2007-01-15 at 12:26 -0500, Neil Conway wrote:
> Barring any objections, I'll apply a slightly improved version of this
> patch tomorrow.
BTW, how do people feel about the function names:
SPI_cursor_open_with_options
SPI_scroll_cursor_fetch
SPI_scroll_cursor_move
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, how do people feel about the function names:
> SPI_cursor_open_with_options
> SPI_scroll_cursor_fetch
> SPI_scroll_cursor_move
I dislike the SPI_cursor_open_with_options API on the grounds that it
lets people break things (CURSOR_OP
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Note that currently there's no way for a backend to know whether another
> > backend is autovacuum or not. I thought about adding a flag to PGPROC,
> > but eventually considered it ugly,
>
> No, that was exactly the way I thought we
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here it is.
I'd drop the InitProcess API change, which touches many more places than
you really need, and just have InitProcess check IsAutoVacuumProcess(),
which should be valid by the time control gets to it. This is more like
the way that InitPostgr
I wrote:
> Please release the LWLock *before* executing a kernel call ...
Oh, and there had definitely better be a CHECK_FOR_INTERRUPTS in
this loop ...
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support
Neil Conway wrote:
> On Mon, 2007-01-15 at 17:07 +, Dave Page wrote:
>> You're thinking the user might expect it dump all of that database? Not
>> sure I agree with that, but I'm not wedded to the syntax. Any other
>> opinions?
>
> I agree with Peter: specifying the database name as implemente
* After Markos patch, now builds pgcrypto without zlib again
* Updates README with xml info
* xml requires xslt and iconv
* disable unnecessary warning about __cdecl()
* Add a buildenv.bat called from all other bat files to set up things
like PATH for flex/bison. (Can't just set it before calling,
Magnus Hagander wrote:
> * After Markos patch, now builds pgcrypto without zlib again
> * Updates README with xml info
> * xml requires xslt and iconv
> * disable unnecessary warning about __cdecl()
> * Add a buildenv.bat called from all other bat files to set up things
> like PATH for flex/bison.
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> * After Markos patch, now builds pgcrypto without zlib again
>> * Updates README with xml info
>> * xml requires xslt and iconv
>> * disable unnecessary warning about __cdecl()
>> * Add a buildenv.bat called from all other bat files to set up things
On 1/16/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
* xml requires xslt and iconv
Why xslt is requred? XML type doesn't depend on libxslt, only on libxml2.
--
Best regards,
Nikolay
---(end of broadcast)---
TIP 9: In versions below 8.0, the pl
Nikolay Samokhvalov wrote:
> On 1/16/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> * xml requires xslt and iconv
>
> Why xslt is requred? XML type doesn't depend on libxslt, only on libxml2.
>
Enabling xml in the vcbuild stuff also enalbes contrib/xml2 which does.
I'm considering splitting th
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Here it is.
> >
> > I'd drop the InitProcess API change, which touches many more places than
> > you really need, and just have InitProcess check IsAutoVacuumProcess(),
> > which should be valid by the tim
Neil Conway wrote:
> On Mon, 2007-01-15 at 13:29 -0500, Tom Lane wrote:
> > Seems like a complete nonstarter, unfortunately. btree requires the
> > datatype to have a total order, and I can't see that changing, so NaN
> > loses.
>
> Well, yeah, that would be the major impediment to implementing i
From: "Magnus Hagander" <[EMAIL PROTECTED]>
> ITAGAKI Takahiro wrote:
>> Do you mean there are drives that have larger sector size than 8kB?
>> We've already put the xlog buffer along the alignment of
>> ALIGNOF_XLOG_BUFFER (typically 8192 bytes).
>> But if there are such drives, using FILE_FLAG_NO
Alvaro Herrera wrote:
Alvaro Herrera wrote:
New version of the patch attached.
I'll probably apply this tomorrow morning unless there are objections.
An important difference from the previous patch is that
DatabaseHasActiveBackends (now renamed to
DatabaseCancelAutovacuumActivity) cycles throug
"Matthew T. O'Connor" writes:
> Is there any chance of a race condition here? That is, can the launcher
> process start a new autovacuum process against that database that your
> code will miss since it was started after you began your search?
No; we're holding a lock against incoming processe
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, how do people feel about the function names:
>SPI_cursor_open_with_options
>SPI_scroll_cursor_fetch
>SPI_scroll_cursor_move
I dislike the SPI_cursor_open_with_options API on the grounds that it
lets people break things (CURSOR_OPT_HOLD f
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is cheap
> (not when is possible). It's true?
Nope. If you want a scrollable plan you need to make sure you tell the
planner about it. SPI_cursor_open is not in charge, it's merely
Dave Page <[EMAIL PROTECTED]> writes:
> OK, updated patch attached. This has
> -E or --default-database=
Not sure that "default" database is a particularly helpful adjective;
why shouldn't the switch just be --database?
Other than that, looks fine.
regards, tom lane
--
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is
cheap
> (not when is possible). It's true?
Nope. If you want a scrollable plan you need to make sure you tell the
planner about it. SPI_cursor_open is not in charge, it's mere
Dave Page wrote:
>> I agree with Peter: specifying the database name as implemented seems
>> like it would be prone to confusion.
>
> OK, updated patch attached. This has
>
> -E or --default-database=
Ouch. This calls for confusion with the -E flag of pg_dump,
which means 'encoding'. Something
37 matches
Mail list logo
