On Sun, Sep 8, 2013 at 10:21 PM, Peter Geoghegan wrote:
> This necessitated inventing entirely new LWLock semantics around
> "weakening" (from exclusive to shared) and "strengthening" (from
> shared to exclusive) of locks already held. Of course, as you'd
> expect, there are some tricky race hazar
于 2013-09-09 20:54, Peter Eisentraut 回复:
On 9/3/13 3:13 AM, wangs...@highgo.com.cn wrote:
Drop/build and disable/enable constraint has no fundamental
difference,
and could achieve the same purpose.What I do also more convenient
for
the user.
Recording the disabled constraints is easier than re
> On Sat, Jan 26, 2013 at 09:25:56AM +0900, Tatsuo Ishii wrote:
>> Sorry for confusion.
>>
>> I knew an unamed portal only lasts until current transaction ends. I
>> was confused in the case when no explicit transaction is used.
>>
>> At completion of each series of extended-query messages, th
On Wed, Sep 11, 2013 at 2:06 AM, Bruce Momjian wrote:
> On Sat, Jan 26, 2013 at 09:25:56AM +0900, Tatsuo Ishii wrote:
>> Sorry for confusion.
>>
>> I knew an unamed portal only lasts until current transaction ends. I
>> was confused in the case when no explicit transaction is used.
>>
>> At com
2013/9/10 Robert Haas :
> On Mon, Sep 9, 2013 at 1:20 PM, Tom Lane wrote:
>> Let me be clear that I'm not against the concept of custom plan nodes.
>> But it was obvious from the beginning that making the executor deal with
>> them would be much easier than making the planner deal with them. I do
(2013/09/10 22:48), Peter Eisentraut wrote:
> On 9/10/13 3:37 AM, Satoshi Nagayasu wrote:
>> Thanks for checking. Revised one attached.
>
> Please fix compiler warning:
>
> walwriter.c: In function ‘WalWriterMain’:
> walwriter.c:293:3: warning: implicit declaration of function
> ‘pgstat_send_walw
If a starting postmaster's CreateLockFile() finds an existing postmaster.pid,
it subjects the shared memory segment named therein to the careful scrutiny of
PGSharedMemoryIsInUse(). If that segment matches the current data directory
and has any attached processes, we bail with the "pre-existing sh
On Fri, Sep 06, 2013 at 09:55:09PM +0100, Greg Stark wrote:
> On Sun, Jun 9, 2013 at 10:25 PM, Noah Misch wrote:
> > - Memcheck has support for detecting leaks. I have not explored that
> > side at
> > all, always passing --leak-check=no. We could add support for freeing
> > "everything" at
On Tue, Sep 10, 2013 at 07:13:16PM -0700, David Johnston wrote:
> Noah Misch-2 wrote
> > The errfinish() pertaining to that WARNING issues CHECK_FOR_INTERRUPTS(),
> > and
> > the query cancel pending since before the SIGQUIT arrived then takes
> > effect.
> > This is less bad on 9.4, because the po
Noah Misch-2 wrote
> The errfinish() pertaining to that WARNING issues CHECK_FOR_INTERRUPTS(),
> and
> the query cancel pending since before the SIGQUIT arrived then takes
> effect.
> This is less bad on 9.4, because the postmaster will SIGKILL the backend
> after
> 5s. On older releases, the back
On Wed, Feb 27, 2013 at 01:02:22PM +, Albe Laurenz wrote:
> The comment says:
>
> [...]
> and the original article describing it can be found at
> http://www.cuj.com/documents/s=8038/cuj0006philips/
>
> This link does not work any more.
>
> I tried a web search for a replacement and ca
I've been doing an excess of immediate shutdowns lately, and that has turned
up bugs old and new. This one goes back to 8.4 or earlier. If a query cancel
is pending when a backend receives SIGQUIT, the cancel takes precedence and
the backend survives:
[local] test=# select nmtest_spin(false);
Ca
Applied.
---
On Tue, Feb 19, 2013 at 06:40:07PM -0500, Gurjeet Singh wrote:
> Hopefully I am not wrong.
>
>
> +/* Size of a varlena data, excluding header */
> #define VARSIZE_ANY_EXHDR(PTR) \
>
>
> --
> Gurjeet Singh
>
I've been getting some failures after an immediate shutdown or crash,
during severe IO stress, with the message:
LOG: XX000: select() failed in postmaster: Invalid argument
LOCATION: ServerLoop, postmaster.c:1560
It is trying to sleep for -1 seconds.
I think the problem is here, where there sh
On Tue, Feb 19, 2013 at 08:30:29AM +0100, Pavel Stehule wrote:
> Hello
>
> There was a proposal to change flag of function to immutable - should
> be used in indexes
>
> CREATE FUNCTION unaccent(regdictionary, text)
> RETURNS text
> AS 'MODULE_PATHNAME', 'unaccent_dict'
>
On Thu, Feb 7, 2013 at 09:45:17PM +0900, Etsuro Fujita wrote:
> Through the work on the patch [1], I had a question about the psql \copy
> command. We are permitted 1) but not permitted 2):
> 1) \copy foo from stdin ;
> 2) \copy foo from stdin;
> Is this intentional? I think it would be better t
On Sun, Feb 3, 2013 at 07:19:14AM +, Amit kapila wrote:
>
> On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
> On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
> >> I think user should be aware of effect before using SET commands, as these
> >> are used at various levels (TRANSA
Continuing my "novice interpretation" from before...
Tatsuo Ishii-4 wrote
> It would be nice if something like "unnamed portal will be destroyed
> by a Sync message if you are in an explicit transaction" is in our
> manual.
I do not believe this to be true from what I've scanned. Inside an
"imp
On Tue, Sep 10, 2013 at 5:08 PM, Josh Berkus wrote:
> Merlin,
>
>> I vote 4x on the basis that for this setting (unlike almost all the
>> other memory settings) the ramifications for setting it too high
>> generally aren't too bad. Also, the o/s and temporary memory usage as
>> a share of total p
Merlin,
> I vote 4x on the basis that for this setting (unlike almost all the
> other memory settings) the ramifications for setting it too high
> generally aren't too bad. Also, the o/s and temporary memory usage as
> a share of total physical memory has been declining over time
If we're doing
Hackers,
The next CommitFest starts this coming Sunday. If you plan to have
your patches reviewed during this CF, please make sure that they are
mailed to -hackers and registered in the CF by Saturday 14 September.
Lots of patches are already pending!
If you are available to do reviews for the C
Tatsuo Ishii-4 wrote
>
> From these statements, I would think #4 will fail in the following
> sequence of commands because #3 closes transaction and it destroys
> unnamed portal: 1)Parse/Bind creates unnamed portal,
> 2)Parse/Bind/Execute creates named portal and executes, 3)Send Sync
> message (b
This is almost but not quite entirely unlike the NULL row issues
Bruce has been raising lately. It is related to some
infrastructure work I've been doing to fix some edge conditions I
discovered (based on reviewing issues raised by Noah) with REFRESH
MATERIALIZED VIEW CONCURRENTLY and also with wo
Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Hmm. Are you sure you're getting an SSL connection? Run it with
> something like this to make sure:
sslmode=require doesn't help on Unix domain connections. :)
Was able to get it to lock with both 9.2.4 and master, and with both
ver
On Sat, Jan 26, 2013 at 09:25:56AM +0900, Tatsuo Ishii wrote:
> Sorry for confusion.
>
> I knew an unamed portal only lasts until current transaction ends. I
> was confused in the case when no explicit transaction is used.
>
> At completion of each series of extended-query messages, the
> fr
On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp wrote:
> While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
> % make DESTDIR=/tmp/foo install
> /usr/bin/install: will not overwrite just-created
> ‘/tmp/foo/usr/share/postgresql/extension/semver--0.3.0.sql’ with
> ‘./sql/semver--0.3.
On 03-09-2013 23:41, Peter Eisentraut wrote:
> The maintainer-check target never really caught on, I think. Most
> people don't run it, and that in turn annoys those who do. Also, it
> doesn't provide much functionality.
>
It has its use (before each release) but I agree that it isn't used
durin
On Tue, Sep 10, 2013 at 1:54 PM, Bruce Momjian wrote:
> On Tue, Sep 10, 2013 at 10:50:32AM -0400, Bruce Momjian wrote:
>> > have to hit all the targets. If not, I'd either A: leave things alone
>> > or B: remove the special case logic in IS NULL (so that it behaves as
>> > coalesce() does) and do
On 9/4/13 11:12 AM, Andres Freund wrote:
> Maybe we should also badger cpluspluscheck into a state where it can be
> run as part of a normal build if a c++ compiler was detected?
>
> I think it misses vpath support and it might be dependant on some
> bashims.
That might also be doable. If we cou
Bruce Momjian wrote:
> FYI, I think these queries below prove that NOT NULL constraints do not
> follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> and that my patch was trying to promote for queries:
>
> CREATE TABLE test2(x test NOT NULL);
> CREATE TABLE
> INS
On Tue, Sep 10, 2013 at 12:48:08PM -0700, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > FYI, I think these queries below prove that NOT NULL constraints do not
> > follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> > and that my patch was trying to promote for queries:
Bruce Momjian wrote:
> Is IS DISTINCT FROM correct though?
>
> SELECT ROW(NULL) IS DISTINCT FROM NULL;
> ?column?
> --
> t
> (1 row)
My recollection from previous discussions is that this is what is
required by the standard. ROW(NULL) IS NULL, but it is DISTINCT
FROM
On Tue, Sep 10, 2013 at 10:50:32AM -0400, Bruce Momjian wrote:
> > have to hit all the targets. If not, I'd either A: leave things alone
> > or B: remove the special case logic in IS NULL (so that it behaves as
> > coalesce() does) and document our divergence from the standard. Point
> > being: B
On 9/9/13 5:56 PM, David Fetter wrote:
> On Mon, Sep 02, 2013 at 12:13:56PM -0700, David Fetter wrote:
>> On Mon, Sep 02, 2013 at 12:00:02PM -0500, Josh Berkus wrote:
>>> Hackers,
>>>
>>> We need a Commit Fest manager for the September CF. I'm not going
>>> to do it; this month is a heavy travel m
On Tue, Sep 10, 2013 at 01:27:37PM -0400, Peter Eisentraut wrote:
> On 9/9/13 5:56 PM, David Fetter wrote:
> > On Mon, Sep 02, 2013 at 12:13:56PM -0700, David Fetter wrote:
> >> On Mon, Sep 02, 2013 at 12:00:02PM -0500, Josh Berkus wrote:
> >>> Hackers,
> >>>
> >>> We need a Commit Fest manager for
On 9/9/13 9:54 PM, Noah Misch wrote:
> On Mon, Sep 09, 2013 at 05:49:38PM -0400, Peter Eisentraut wrote:
>> > On 9/9/13 2:57 PM, Noah Misch wrote:
>>> > > Actually, GNU libiconv's iconv() decides that //translit is
>>> > > unimplementable
>>> > > for some of the characters in that file, and it fai
On Tue, Sep 10, 2013 at 11:39 AM, Jeff Janes wrote:
> On Mon, Sep 9, 2013 at 6:29 PM, Bruce Momjian wrote:
>> On Thu, Sep 5, 2013 at 09:02:27PM -0700, Josh Berkus wrote:
>>> On 09/05/2013 03:30 PM, Merlin Moncure wrote:
>>>
>>> >> Standard advice we've given in the past is 25% shared buffers, 75
On 10.09.2013 18:10, Stephen Frost wrote:
I've run your test program against both git master and 9.2.4 on a couple
of Ubuntu 13.04 boxes and all I see are tons of these:
1: DEBUG: database connection established
1: DEBUG: about to call PQfinish()
1: DEBUG: database connection established
1: DEBU
On Mon, Sep 9, 2013 at 6:29 PM, Bruce Momjian wrote:
> On Thu, Sep 5, 2013 at 09:02:27PM -0700, Josh Berkus wrote:
>> On 09/05/2013 03:30 PM, Merlin Moncure wrote:
>>
>> >> Standard advice we've given in the past is 25% shared buffers, 75%
>> >> effective_cache_size. Which would make EFS *3X* sh
On Tue, Sep 10, 2013 at 8:12 PM, Andres Freund wrote:
> Hi,
>
> The subject says it all.
Thanks! Committed.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
The subject says it all.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From 572b6bf6527829e215aedfd42a3de755357ce8f1 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Tue, 10 Sep 2013
On Tue, Sep 10, 2013 at 09:12:08AM -0500, Merlin Moncure wrote:
> > FYI, I think these queries below prove that NOT NULL constraints do not
> > follow the single-depth ROW NULL inspection rule that PL/pgSQL follows,
> > and that my patch was trying to promote for queries:
> >
> > CREATE TAB
Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Thanks! I tested with git master.
I've run your test program against both git master and 9.2.4 on a couple
of Ubuntu 13.04 boxes and all I see are tons of these:
1: DEBUG: database connection established
1: DEBUG: about to call PQfi
I tested this patch and it is not patchable now. Please, can you fix patch?
Regards
Pavel
On Tue, Sep 10, 2013 at 8:56 AM, Bruce Momjian wrote:
> On Tue, Sep 10, 2013 at 08:45:14AM -0400, Robert Haas wrote:
>> On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
>> > The problem is that I don't believe this patch is commit-ready ---
>> > someone needs to research the IS NULL tests in
Greg Stark writes:
> It's hard to imagine how the planner could possibly be pluggable in a
> generally useful way. It sounds like putting an insurmountable barrier
> in place that blocks a feature that would be useful in the Executor.
But it's *not* useful without a credible way to modify the pla
On Tue, Sep 10, 2013 at 08:45:14AM -0400, Robert Haas wrote:
> On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
> > The problem is that I don't believe this patch is commit-ready ---
> > someone needs to research the IS NULL tests in all areas of our code to
> > see if they match this patch, a
On Tue, Sep 10, 2013 at 3:53 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-09-10 12:31:22 +0200, Magnus Hagander wrote:
>>> On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane wrote:
I've been thinking of late that it might be time to retire libpq's
support for V2 protocol (other than i
Andres Freund writes:
> On 2013-09-10 12:31:22 +0200, Magnus Hagander wrote:
>> On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane wrote:
>>> I've been thinking of late that it might be time to retire libpq's
>>> support for V2 protocol (other than in the specific context of the first
>>> error message re
On 9/10/13 3:37 AM, Satoshi Nagayasu wrote:
> Thanks for checking. Revised one attached.
Please fix compiler warning:
walwriter.c: In function ‘WalWriterMain’:
walwriter.c:293:3: warning: implicit declaration of function
‘pgstat_send_walwriter’ [-Wimplicit-function-declaration]
--
Sent via pg
On Mon, Sep 9, 2013 at 3:51 PM, Bruce Momjian wrote:
> The problem is that I don't believe this patch is commit-ready ---
> someone needs to research the IS NULL tests in all areas of our code to
> see if they match this patch, and I can't do that. Is that something a
> reviewer is going to be wi
From: "Greg Stark"
Wait, why does the ctype of the database affect the ctype of the
messages? Shouldn't these be two separate things? One describes the
character set being used to store data in the database and the other
the character set the log file and clients are in.
At session start, Pos
From: "Noah Misch"
I like (2), at least at a high level. The concept of errno_str.patch is
safe
enough to back-patch. One can verify that it only changes behavior when
strerror() returns NULL, an empty string, or something that begins with
'?'.
I can't see resenting the change when that has
Hello.
I wanted to know what it would take to implement triggers on foreign tables.
It seems that statement-level triggers can work provided they are allowed in
the code.
Please find attached a simple POC patch that implement just that.
For row-level triggers, it seems more complicated. From w
Blake,
Teodor will review your patch, but I have one consideration about the patch
in context of future hstore, which supports hierarchical structures. In
that case overhead of composite keys will be enormous and the only way in
this direction is to think about idea suffix array instead of btree t
On Tue, Sep 10, 2013 at 11:33 AM, Robert Haas wrote:
>> I'd be willing to put in the infrastructure as soon as it's clear that we
>> have a way forward, but not if it's never going to be more than a kluge.
>
> Fair enough, I think. So the action item for KaiGai is to think of
> how the planner in
On Mon, Sep 9, 2013 at 11:27 PM, MauMau wrote:
> 1. Recreate the database with LC_CTYPE = ja_JP.UTF-8. This changes various
> behaviors such as ORDER BY, index scan, and the performance of LIKE clause.
> This is almost impossible.
Wait, why does the ctype of the database affect the ctype of the
On 2013-09-10 12:31:22 +0200, Magnus Hagander wrote:
> On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane wrote:
> > Maciek Sakrejda writes:
> >> One of our customers seems to be running into exactly the issue
> >> hypothesized about by Tom here:
> >> http://www.postgresql.org/message-id/8040.1314403...@s
On Mon, Sep 9, 2013 at 1:20 PM, Tom Lane wrote:
> Let me be clear that I'm not against the concept of custom plan nodes.
> But it was obvious from the beginning that making the executor deal with
> them would be much easier than making the planner deal with them. I don't
> think we should commit
On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane wrote:
> Maciek Sakrejda writes:
>> One of our customers seems to be running into exactly the issue
>> hypothesized about by Tom here:
>> http://www.postgresql.org/message-id/8040.1314403...@sss.pgh.pa.us
>> Was the possibility of an inadvertent protocol
Thanks for checking. Revised one attached.
(2013/09/10 6:43), Peter Eisentraut wrote:
> On 9/6/13 11:32 PM, Satoshi Nagayasu wrote:
>> The revised patch for wal buffer statistics is attached.
>> A test script is also attached. Please take a look.
>
> You have duplicate OIDs. Run the script dupli
61 matches
Mail list logo
