Here's a patch that:
Moves the logic to find a page with enough room from _bt_insertonpg to a
new function, _bt_findinsertloc. It makes the code more readable, and
simplifies the forthcoming Grouped Index Tuples patch.
Also, the insert location within page used to be calculated twice for
Hi,
I was wondering if we can apply the same logic of recalculating OldestXmin
within IndexBuildHeapScan which occurs as part of create index operation?
Having to index lesser number of tuples should be a good save in the CREATE
INDEX CONCURRENTLY case, if the above is possible?
Regards,
Peter Eisentraut wrote:
Zdenek Kotala wrote:
There is Solaris FAQ update. Please, look on it and let me know any
comments.
The actual answer to the question Can I compile PostgreSQL with
Kerberos v5 support? is Yes, why not?. I don't think Can I use
this weird internal private library
Updated patch at:
http://community.enterprisedb.com/varlena/patch-varvarlena-12.patch.gz
This fixes a rather critical oversight which caused it all to appear to work
but not actually save any space. I've added an assertion check that the
predicted tuple size matches the tuple size generated
I've uploaded a quick hack to store numerics in 8 bytes when possible.
http://community.enterprisedb.com/numeric-hack-1.patch
This is a bit of a kludge since it doesn't actually provide any interface for
external clients of the numeric module to parse the resulting data. Ie, the
macros in
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
file.
So, by default, the INFO is going to go to the user terminal, and not to
the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
file.
Yeh, LOG would
Simon Riggs [EMAIL PROTECTED] writes:
Yeh, LOG would be most appropriate, but thats not possible.
You have not given any good reason for that.
log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1,
INFO, NOTICE and WARNING for non-error states.
I don't think you understand
On Mon, 2007-02-26 at 14:11 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Yeh, LOG would be most appropriate, but thats not possible.
You have not given any good reason for that.
The idea of the patch is that it generates a log message which then
invokes
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the SQL statement is displayed.
LOG is not on the list of options there, otherwise I would use it.
As I said, you don't understand how the logging
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the SQL statement is displayed.
LOG is not on the list of options there, otherwise I would use
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the SQL statement is displayed.
LOG is not on the list of
On Mon, 2007-02-26 at 14:52 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the
Simon Riggs wrote:
On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
Bruce Momjian [EMAIL PROTECTED] writes:
This is not the first GUC that has needed this.
Exactly. I think that we simply made a mistake in the initial
implementation of log_min_error_statement: we failed to think about
whether it should use client or server priority ordering, and the
Simon Riggs [EMAIL PROTECTED] writes:
A prototype patch is posted to -patches, which is WORK IN PROGRESS.
[This patch matches discussion thread on -hackers.]
What does this accomplish other than adding syntactic sugar over a
feature that really doesn't work well anyway? I don't see any point
On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A prototype patch is posted to -patches, which is WORK IN PROGRESS.
[This patch matches discussion thread on -hackers.]
What does this accomplish other than adding syntactic sugar over a
feature that
Josh Berkus josh@agliodbs.com wrote:
Can I have a copy of the patch to add to the Sun testing queue?
This is the revised version of the patch. Delay factors in checkpoints
can be specified by checkpoint_write_percent, checkpoint_nap_percent
and checkpoint_sync_percent. They are relative to
Hi,
This is the first posting to the community of the WIP patch for the
Updatable Cursor implementation.
I want to confirm that the community is satisfied that the effort to date is
in a suitable direction and to get comments on the development to date.
The patch is in the following
Recapitulating and addressing some of the issues with my previous
attempt at this feature:
PostgreSQL currently uses the System V shared memory APIs to access
shared memory. On Mac OS X and other BSDs,
the default System V shared memory limits are often very low and
require adjustment for
Chris Marcellino [EMAIL PROTECTED] writes:
The System V shared memory facilities provide a method to determine
who is attached to a shared memory segment.
This is used to prevent backends that were orphaned by crashed or
killed database processes from corrupting the data-
base as it is
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
What does this accomplish other than adding syntactic sugar over a
feature that really doesn't work well anyway?
This patch doesn't intend to implement group commit. I've changed the
meaning of
On 2/26/07, ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
Josh Berkus josh@agliodbs.com wrote:
Can I have a copy of the patch to add to the Sun testing queue?
This is the revised version of the patch. Delay factors in checkpoints
can be specified by checkpoint_write_percent,
On Feb 26, 2007, at 10:43 PM, Tom Lane wrote:
Chris Marcellino [EMAIL PROTECTED] writes:
The System V shared memory facilities provide a method to determine
who is attached to a shared memory segment.
This is used to prevent backends that were orphaned by crashed or
killed database processes
27 matches
Mail list logo
