On Thu, 19 May 2005, Neil Conway wrote:
> > +errmsg("currval of sequence with OID %d is not
> > yet defined in this session",
> > + last_used_seq->relid)));
>
> See above; however, when will this error actually be invoked? (Th
On Thu, 2 Jun 2005, Neil Conway wrote:
> > Here is a small patch that implements a function lastval() that
>
> Have you had a chance to respin this patch per my earlier comments on
> the implementation, Dennis?
I've been spending my free time on another project and I don't multitask
very well :
Bruce,
Attached patch replaces the original, applied today against CVS HEAD.
Fixes the surrogates, and limits to 4 byte utf8 as per spec.
Also extends UtfToLocal to 4 byte characters (tho, it does not add any,
just enables the code to handle them. If my interpretation of this code
is wrong, pleas
On Sun, 5 Jun 2005 10:29 am, Neil Conway wrote:
> Bruce Momjian wrote:
> > Well, it isn't going to help us for 8.1 because 8.0 will not have it,
> > and if we add the clause we make loading the data into previous releases
> > harder.
>
> pg_dump output in general is not compatible with prior relea
Bruce Momjian writes:
>> BTW, I found memory leak in BootStrapXLOG(). The buffer allocated by malloc()
>> is not free()ed. ISSUE_BOOTSTRAP_MEMORYLEAK in this patch points out it.
>> (But this leak is not serious, because this function is called only once.)
> Does the following patch fix the memor
Bruce Momjian writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:
> a_ogawa00 wrote:
>> This patch provides a new function regexp_replace.
>> regexp_replace extends a replace function and enables text search
>> by the regular expression. And, a back reference can be u
Bruce,
Please note that this patch is a correction and replacement for an
earlier patch in the queue. The patch accompanying the message
http://candle.pha.pa.us/mhonarc/patches/msg8.html
should be removed from the queue and not applied.
The one (originally) attached to this message should
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
Chris
Bruce Momjian wrote:
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
-
ITAGAKI Takahiro wrote:
> Hello everyone.
>
> I fixed two bugs in the patch that I sent before.
> Check and test new one, please.
>
> 1. Fix update timing of Write->curridx. (pointed by Tom)
> Change to update it soon after write().
>
> 2. Fix buffer alignment routine on 64bit cpu. (pointed
Yes, I assume that the patch to group the writes isn't something we want
right now, and the one for O_DIRECT is going to need an additional
fsync, and I have asked for testing on that.
I have posted a patch that I think fixes the memory leak reported and am
waiting for feedback on that.
Patch applied. Thanks.
---
Abhijit Menon-Sen wrote:
> At 2005-06-04 17:27:10 -0500, [EMAIL PROTECTED] wrote:
> >
> > > OK, would you please submit a patch to fix it. Thanks.
> >
> > I will unless someone beats me to it in
At 2005-06-04 17:27:10 -0500, [EMAIL PROTECTED] wrote:
>
> > OK, would you please submit a patch to fix it. Thanks.
>
> I will unless someone beats me to it in the next 2 weeks
Here's a patch to do the following:
1. Rename spi_return_next to return_next.
2. Add a new test for return_next.
3. Upda
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
---
Oliver Jowett wrote:
> (cc'ing -hackers)
>
> Karel Zak wrote:
>
> > I think command status is common and nice fe
Later version of this patch added to the patch queue.
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.
-
Updated description added.
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.
Addition to postgresql.conf.sample is missing. I will add 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.
Do we want to make this superuser-only?
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 think we are best with just pg_startime. If people want the interval
they can subtract it from CURRENT_TIMESTAMP. I have added Matthias's
version to the patch queue.
---
Euler Taveira de Oliveira wrote:
>
> Bruce Momjia
[EMAIL PROTECTED] wrote:
> > I must be missing something, but AFAICS this patch doesn't actually *do*
> > anything useful. It looks to me like you've implemented a write-only
> > addition to the system catalogs. (And not even done a very good job of
> > that --- no documentation, no pg_dump suppo
I am using 'cp' in current CVS for this. I assume it is as fast as the
C implementation, but if not, please let me know.
---
Alvaro Herrera wrote:
> Patchers,
>
> I wrote an "install" program in C. It's supposed to replac
This patch is has been removed from the patch queue for the following
reason:
---
This patch is not ready to be applied -- we're waiting for Pavel to
submit a revised version with the semantics described here:
http://archiv
Bruce Momjian wrote:
Well, it isn't going to help us for 8.1 because 8.0 will not have it,
and if we add the clause we make loading the data into previous releases
harder.
pg_dump output in general is not compatible with prior releases. It
would be a nice feature to have, but until we have it,
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
This patch is not ready to be applied -- we're waiting for Pavel to
submit a revised version with the semantics described here:
http://archives.postgresql.org/pgsql-committers/2005-06/msg00017.php
-Neil
Neil Conway wrote:
> Bruce Momjian wrote:
> > Could we do your NOLOGGING automatically in COPY if we test to see if
> > anyone else is connected to our current database?
>
> That seems pretty fragile -- what happens if someone connects after the
> COPY has started? Considering that many COPY oper
Bruce Momjian wrote:
Could we do your NOLOGGING automatically in COPY if we test to see if
anyone else is connected to our current database?
That seems pretty fragile -- what happens if someone connects after the
COPY has started? Considering that many COPY operations can take many
minutes or
I will add documentation for 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.
--
Patch additions added to the patch queue.
---
Andrew Dunstan wrote:
>
>
> Ed L. wrote:
>
> >Attached also is a patch to comments in sample postgresql.conf file.
> >
> >Subject: [PATCHES] log_line_prefix additions
> >Dat
I am thinking some day we will need:
ALTER SCHEMA ... SET NEW TABLESPACE
and
ALTER SCHEMA ... SET CURRENT TABLESPACE
to specify if existing objects are moved, but at this point we aren't
going to get the later in 8.1, so I guess we will just go with an
unadorned stynax.
In fac
Bruce Momjian said:
> Andrew Dunstan wrote:
>>
>>
>> This has broken the regression tests for plperl - see for example
>>
>>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=panda&dt=2005-06-04%2021:20:01>>
That's because, as Abhijit noted in point 4 below, select foo_srf() no
>> longer works.
>>
I will add the documentation and make sure your oids are not duplicates.
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.
--
Andrew Dunstan wrote:
>
>
> This has broken the regression tests for plperl - see for example
>
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=panda&dt=2005-06-04%2021:20:01
> That's because, as Abhijit noted in point 4 below, select foo_srf() no
> longer works.
>
> At a minimum those call
Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. Thanks. (The first if == NULL test was already in CVS).
>
> The first if == NULL test was the only part I wanted to apply ...
> I do not think this patch is a performance win in general.
OK, patch reverted. a_ogawa, would you run test
Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. Thanks. (The first if == NULL test was already in CVS).
>
> The first if == NULL test was the only part I wanted to apply ...
> I do not think this patch is a performance win in general.
Attached is the part I backed out of CVS.
--
This has broken the regression tests for plperl - see for example
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=panda&dt=2005-06-04%2021:20:01
That's because, as Abhijit noted in point 4 below, select foo_srf() no
longer works.
At a minimum those calls need to be removed from the regression
Bruce Momjian writes:
> Patch applied. Thanks. (The first if == NULL test was already in CVS).
The first if == NULL test was the only part I wanted to apply ...
I do not think this patch is a performance win in general.
regards, tom lane
---(end
I see Tatsuo already applied this, which is great. I added a little
comment:
/* if multi-byte, take len and find # characters */
---
Yoshiyuki Asaba wrote:
> Character type value including multibyte characters is n
Patch applied. Thanks. I manually updated postgresql.conf.sample.
---
Magnus Hagander wrote:
> Here's an updated version of the patch, with the following changes:
>
> 1) No longer uses "service name" as "application vers
Mega-patch version applied. Thanks.
---
Abhijit Menon-Sen wrote:
> At 2005-05-21 20:18:50 +0530, [EMAIL PROTECTED] wrote:
> >
> > > The second issue is where plperl returns a large result set.
>
> I have attached the foll
Patch applied. Thanks. (The first if == NULL test was already in CVS).
---
a_ogawa wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
> > a_ogawa <[EMAIL PROTECTED]> writes:
> > > It is a reasonable idea. However, the major
>> >> A quick-check (haven't checked any details) - your
>> >unconditional use of
>> >> Global\ will not work on NT4. With 8.0 we said we wanted to
>> >support NT4
>> >> with some limits (IIRC, tablespaces don't work, and the intaller
>> >> definitly doesn't work). If we want to continue doing
>
Simon Riggs wrote:
> I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS
> SELECT, when not in archive mode (PITR). The main use case for this is
> large BI environments that create summary tables or prejoined tables,
> though there are many general applications.
>
> There is no
Magnus Hagander wrote:
> >> Hi!
> >>
> >> A quick-check (haven't checked any details) - your
> >unconditional use of
> >> Global\ will not work on NT4. With 8.0 we said we wanted to
> >support NT4
> >> with some limits (IIRC, tablespaces don't work, and the intaller
> >> definitly doesn't work).
>> Hi!
>>
>> A quick-check (haven't checked any details) - your
>unconditional use of
>> Global\ will not work on NT4. With 8.0 we said we wanted to
>support NT4
>> with some limits (IIRC, tablespaces don't work, and the intaller
>> definitly doesn't work). If we want to continue doing that (whi
Magnus Hagander wrote:
> Hi!
>
> A quick-check (haven't checked any details) - your unconditional use of
> Global\ will not work on NT4. With 8.0 we said we wanted to support NT4
> with some limits (IIRC, tablespaces don't work, and the intaller
> definitly doesn't work). If we want to continue do
Andreas Pflug wrote:
> This patch reenables pg_terminate_backend, allowing (superuser only, of
> course) to terminate a backend. As taken from the discussion some weeks
> earlier, SIGTERM seems to be used quite widely, without a report of
> misbehavior so while the code path is officially not to
Tom Lane wrote:
> Bruce Momjian writes:
> > Is reading postgresql.conf
> > from pg_ctl without a parser really accurate?
>
> The brute-force solution is to duplicate guc-file.l.
>
> That seems pretty ugly but in the long run it might be the most
> maintainable solution. We eventually gave up tr
I think the conclusion from the discussion is that O_DIRECT is in
addition to the sync method, rather than in place of it, because
O_DIRECT doesn't have the same media write guarantees as fsync(). Would
you update the patch to do O_DIRECT in addition to O_SYNC or fsync() and
see if there is a per
Hi!
A quick-check (haven't checked any details) - your unconditional use of
Global\ will not work on NT4. With 8.0 we said we wanted to support NT4
with some limits (IIRC, tablespaces don't work, and the intaller
definitly doesn't work). If we want to continue doing that (which I
think we do), the
Is this patch being worked on?
---
Oliver Jowett wrote:
> Tom Lane wrote:
> > Oliver Jowett <[EMAIL PROTECTED]> writes:
> >
> >>Here's a patch that adds four new GUCs:
> >
> >
> >> tcp_keepalives (defaults to on, control
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Mon, May 30, 2005 at 11:29:48PM -0400, Bruce Momjian wrote:
> >
> > > test=> select 12345678901234567890 / 123;
> > > ?column?
> > >
> > >100371373180768845
> > > (1 row)
> >
> > Well, that's a bug, right?
Revised patch to avoid "lost signals before signaling mechanism is set up
in Win32". This was tested by plus a line:
Sleep(10*1000);
in the front of pgwin32_signal_initialize().
Regards,
Qingqing
Index: src/port/kill.c
===
>> Do you agree that using a hashtable for it in general is a good idea
>> assuming this sideeffect is removed, though?
>
>I have no problem with the hashtable, only with preloading it with
>everything. What I'd like to see is that the table inherited at fork()
>contains just the data for the defa
Now \d show tablespace of indices per discussion.
test=# \d e
Table "public.e"
Column | Type | Modifiers
+-+---
i | integer | not null
j | integer | not null
k | integer |
Indexes:
"e_pkey" PRIMARY KEY, btree (i, j), tablespace "haha"
"
53 matches
Mail list logo
