Hi,
This is a proposal to implement support for 'OR REPLACE' in 'CREATE
TRIGGER' command as an optional clause.
The aim of this proposal is to present a way to support replace trigger
functionality.
Adding the optional clause 'OR REPLACE' in CREATE TRIGGER syntax gives
users the option o
On Mon, Sep 9, 2013 at 9:33 PM, Jeff Janes wrote:
> On Sun, Sep 8, 2013 at 8:49 PM, Amit Kapila wrote:
>> On Mon, Sep 9, 2013 at 2:35 AM, Jeff Janes wrote:
>>> I thought it was well known, but maybe I was overly optimistic. I've
>>> considered IOS to be mostly useful for data mining work on rea
2013/9/10 Bruce Momjian :
> On Tue, Jan 22, 2013 at 07:30:59PM -0500, Tom Lane wrote:
>> Ian Lawrence Barwick writes:
>> > Related email from the archives on this subject:
>> > http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com
>>
>> I agree with the o
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 downgrade addressed as part
> of that patch? I read thro
On Tue, Sep 10, 2013 at 05:42:06AM +0900, MauMau wrote:
> From: "Tom Lane"
>> Noah Misch writes:
>>> ... I think
>>> MauMau's original bind_textdomain_codeset() proposal was on the right
>>> track.
>>
>> It might well be. My objection was to the proposal for back-patching it
>> when we have lit
On Sat, 2013-09-07 at 14:01 -0400, Bruce Momjian wrote:
> > > pg_has_role(n.nspowner, 'USAGE')
> > > OR has_schema_privilege(n.oid, 'CREATE, USAGE')
> > >
> > > As things stand, a non-superuser won't see "public", "pg_catalog",
> > > nor even "information_schema" itself in this view, which
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 fails the conversion. GNU
> > libc's iconv(), on the other ha
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* shared_buffers, not 4X.
> >> Maybe we're changing the conven
On Mon, Sep 9, 2013 at 6:05 PM, Peter Eisentraut wrote:
> It is automated.
Oh, yeah. I see that the maintainer-check target does that. I should
probably get into the habit of using targets other than
check/installcheck, as you recently demonstrated.
--
Peter Geoghegan
--
Sent via pgsql-hacke
On Tue, Jan 22, 2013 at 07:30:59PM -0500, Tom Lane wrote:
> Ian Lawrence Barwick writes:
> > Related email from the archives on this subject:
> > http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com
>
> I agree with the opinion stated there that \cd wit
On Mon, 2013-09-09 at 14:51 -0700, Peter Geoghegan wrote:
> On Mon, Sep 9, 2013 at 2:43 PM, Peter Eisentraut wrote:
> > You have duplicate OIDs. Run the script duplicate_oids to find them.
>
> Are you considering picking up the script that Andrew wrote to
> automate that as part of the build? I
You need to update the dblink regression tests.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 9, 2013 at 06:39:39PM -0400, Andrew Dunstan wrote:
>
> On 09/09/2013 06:20 PM, Jeff Janes wrote:
> >pg_upgrade reserves 5 times MAXPGPATH, or 5120 characters, for the
> >tablespace name of every object (table, toast table, index) in the
> >database being upgraded. This adds up pretty
On 2013-09-09 18:43:51 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Sep 5, 2013 at 3:23 PM, Andres Freund
> > wrote:
> >> So, a very slightly updated patch attached.
>
> > Committed.
>
> Hmm ... shouldn't this patch adjust the error messages in
> CommandCounterIncrement? We just t
On 09/09/2013 06:20 PM, Jeff Janes wrote:
pg_upgrade reserves 5 times MAXPGPATH, or 5120 characters, for the
tablespace name of every object (table, toast table, index) in the
database being upgraded. This adds up pretty quickly when there is a
very large number of objects. It could be changed
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
That is, the server is in low-memory conditions, and the client
occasionally issues an error saying it can't complete a certain action
Andres Freund writes:
> On 2013-09-09 18:43:51 -0400, Tom Lane wrote:
>> Hmm ... shouldn't this patch adjust the error messages in
>> CommandCounterIncrement?
> Hm. You're talking about "cannot have more than 2^32-2 commands in a
> transaction"? If so, the patch and the commit seem to have adjust
Robert Haas writes:
> On Thu, Sep 5, 2013 at 3:23 PM, Andres Freund wrote:
>> So, a very slightly updated patch attached.
> Committed.
Hmm ... shouldn't this patch adjust the error messages in
CommandCounterIncrement? We just took away one possible command.
It's pretty nitpicky, especially sin
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 fails the conversion. GNU
> libc's iconv(), on the other hand, emits the question marks.
That can't be right, because the examples I
On Mon, Sep 9, 2013 at 2:43 PM, Peter Eisentraut wrote:
> You have duplicate OIDs. Run the script duplicate_oids to find them.
Are you considering picking up the script that Andrew wrote to
automate that as part of the build? I wonder why that didn't end up
going anywhere.
--
Peter Geoghegan
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 duplicate_oids to find them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
From: "Peter Eisentraut"
On 9/9/13 4:42 PM, MauMau wrote:
1. Take the approach that doesn't use bind_textdomain_codeset("libc")
(i.e. the second version of errno_str.patch) for 9.4 and older releases.
2. Use bind_textdomain_codeset("libc") (i.e. take
strerror_codeset.patch) for 9.4, and take t
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 month for me (3 conferences
> > and a wedd
pg_upgrade reserves 5 times MAXPGPATH, or 5120 characters, for the
tablespace name of every object (table, toast table, index) in the
database being upgraded. This adds up pretty quickly when there is a
very large number of objects. It could be changed to char* to a
separately allocated name that
On 9/9/13 4:42 PM, MauMau wrote:
> We are using 9.1/9.2 and 9.2 is probably dominant, so I would be
> relieved with either of the following choices:
>
> 1. Take the approach that doesn't use bind_textdomain_codeset("libc")
> (i.e. the second version of errno_str.patch) for 9.4 and older releases.
On 9/6/13 9:40 AM, MauMau wrote:
> $ psql -d postgres -c "SELECT * FROM a"
> ... This outputs, in Japanese, a message meaning "could not open file
> "base/xxx/yyy": ???".
>
> The problem is that strerror() returns "???", which hides the cause of
> the trouble.
>
> The cause is that gettext() call
From: "Peter Eisentraut"
Does anyone know why the PostgreSQL-supplied part of the error message
does not get messed up?
That is because bind_textdomain_codeset() is called for postgres.mo in
src/backend/utils/mb/mbutils.c, specifying the database encoding as the
second argument. This is don
From: "Tom Lane"
Noah Misch writes:
... I think
MauMau's original bind_textdomain_codeset() proposal was on the right
track.
It might well be. My objection was to the proposal for back-patching it
when we have little idea of the possible side-effects. I would be fine
with handling that as
Andres Freund writes
> andres@alap2:~$ ls -l /tmp/frak
> -rw-r- 2 root shadow 1652 Jun 4 22:05 /tmp/frak
Ah, indeed.
It fails for me though (Ubuntu 12.04, linux 3.2.0, ext4):
$ ln /etc/shadow /tmp/frak
ln: failed to create hard link `/tmp/frak' => `/etc/shadow': Operation not
permi
Andres Freund writes:
> On 2013-09-09 21:41:00 +0200, Daniel Vérité wrote:
>> Tom Lane writes:
>>> That would only stop symlink attacks, not hardlink variants;
>> The creation of the hardlink is denied by the OS based on the
>> attacker not having sufficient permissions to the target file.
> It
On Thu, Sep 5, 2013 at 3:23 PM, Andres Freund wrote:
>> > Oh. I hadn't looked at the patch, but I had (mis)read what Robert said
>> > to think that you were proposing introducing InvalidCommandId = 0x
>> > while leaving FirstCommandId alone. That would make more sense to me as
>> > (1) i
On 2013-09-09 21:41:00 +0200, Daniel Vérité wrote:
>Tom Lane writes:
>
> > Andres Freund writes:
>
> > > One would be to use open(O_NOFOLLOW)?
> >
> > That would only stop symlink attacks, not hardlink variants;
> > and it'd probably stop some legitimate use-cases too.
>
> The creation of
Tom Lane writes:
> Andres Freund writes:
> > One would be to use open(O_NOFOLLOW)?
>
> That would only stop symlink attacks, not hardlink variants;
> and it'd probably stop some legitimate use-cases too.
The creation of the hardlink is denied by the OS based on the
attacker not having suffi
Noah Misch writes:
> ... I think
> MauMau's original bind_textdomain_codeset() proposal was on the right track.
It might well be. My objection was to the proposal for back-patching it
when we have little idea of the possible side-effects. I would be fine
with handling that as a 9.4-only patch (
On Mon, Sep 9, 2013 at 12:37:25PM -0400, Robert Haas wrote:
> On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian wrote:
> >> Why don't you add the proposal to the commitfest?
> >
> > This issue is so much larger than the patch's validity that I don't see
> > how that would work.
>
> I hate to be rud
On Mon, Sep 09, 2013 at 08:29:58AM -0400, Peter Eisentraut wrote:
> On 9/6/13 10:37 AM, Tom Lane wrote:
> > BTW: personally, I would say that what you're looking at is a glibc bug.
> > I always thought the contract of gettext was to return the ASCII version
> > if it fails to produce a translated v
* Robert Haas (robertmh...@gmail.com) wrote:
> But, I guess I'm not yet convinced that one-for-one substitution of
> nodes is impossible even with something about this simple.
Couldn't that be done with hooks in those specific plan nodes, or
similar..? Of course, as Tom points out, that wouldn'
On Sun, Sep 8, 2013 at 12:47:35AM +0200, Andres Freund wrote:
> Hi,
>
> On 2013-09-07 12:50:59 -0400, Bruce Momjian wrote:
> > That seems very complicated. I think it would be enough to record the
> > current xid at the time of the vacuum, and when testing for later
> > vacuums, if that saved xi
Peter Eisentraut writes:
> On 9/9/13 10:25 AM, Tom Lane wrote:
>> Meh. Seems that would only prevent one specific instance of the general
>> problem that strerror can fail to translate its result. Other locale
>> combinations might create the same kind of failure.
> True. There isn't much we c
On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian wrote:
>> Why don't you add the proposal to the commitfest?
>
> This issue is so much larger than the patch's validity that I don't see
> how that would work.
I hate to be rude here, but I think you're being ridiculous. We have
a well-established pr
Robert Haas writes:
> But, I guess I'm not yet convinced that one-for-one substitution of
> nodes is impossible even with something about this simple. If someone
> can do a post-pass over the plan tree and replace a SeqScan node with
> an AwesomeSeqScan node or a Sort node with a RadixSort node,
On 9 Září 2013, 18:50, Robert Haas wrote:
> On Sat, Sep 7, 2013 at 6:57 PM, Tomas Vondra wrote:
>> Don't forget the stats are written only by the postmaster, all the
>> regular backends only read it (and eventually send updates back).
>
> The postmaster, or the stats collector?
Stats collector,
On Fri, Sep 6, 2013 at 7:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> I find this a somewhat depressing response. Didn't we discuss this
>> exact design at the developer meeting in Ottawa? I thought it sounded
>> reasonable to you then, or at least I don't remember you panning it.
>
> What I
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Heikki Linnakangas wrote:
> > I'll dig into that, but right now it seems like an OpenSSL or
> > libcrypto bug to me. Or something in the way we use them, although I
> > can't see anything obviously wrong in the libpq code at a quick
> >
On Sat, Sep 7, 2013 at 6:57 PM, Tomas Vondra wrote:
> Don't forget the stats are written only by the postmaster, all the
> regular backends only read it (and eventually send updates back).
The postmaster, or the stats collector?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enter
On Sun, Sep 8, 2013 at 8:49 PM, Amit Kapila wrote:
> On Mon, Sep 9, 2013 at 2:35 AM, Jeff Janes wrote:
>> I thought it was well known, but maybe I was overly optimistic. I've
>> considered IOS to be mostly useful for data mining work on read-mostly
>> tables, which you would probably vacuum manu
On Sat, Sep 7, 2013 at 3:57 AM, Pavel Stehule wrote:
> when I checked "psql and pset without any arguments" patch, I found so only
> popt->topt.line_style is initialized to NULL as default. All other popt
> variables are not null.
>
> Can we fixed?
I suggest that you reply to the correct thread i
On Sat, Sep 7, 2013 at 6:55 PM, Greg Stark wrote:
>> Should these patches be applied?
>
> I have a copy of the program and was going to take care of this.
When?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (
On Fri, Sep 6, 2013 at 3:40 PM, Jim Nasby wrote:
> The specific scenario I'm worried about is something like a PANIC in the
> middle of the snprintf call in dsm_write_state_file(). That would leave that
> file in a completely unknown state so who knows what would then happen on
> restart. ISTM tha
Heikki Linnakangas wrote:
> I'll dig into that, but right now it seems like an OpenSSL or
> libcrypto bug to me. Or something in the way we use them, although I
> can't see anything obviously wrong in the libpq code at a quick
> glance.
Can you please try with ssl_renegotiation_limit=0?
[ looks
On 09.09.2013 18:20, Stephen Frost wrote:
Vesa-Matti, Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
On 09.09.2013 15:36, Vesa-Matti J Kari wrote:
If I interpret this correctly, threads #2 and #3 are waiting for the same
lock but they make no progress.
A-ha, the deadlock happe
On Mon, Sep 9, 2013 at 5:22 AM, Quan Zongliang wrote:
> Understood.
>
> I just try to speed up text compare, not redesign locale.
>
> Do you have a plan to do this?
Not any time soon, anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
On 09.09.2013 15:36, Vesa-Matti J Kari wrote:
It looks like a deadlock situation of some kind...
(gdb) thread 2
[Switching to thread 2 (Thread 0x7fe62f7fe700 (LWP 27284))]
#0 0x7fe64c0b589c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0 0x7fe64c0b589c in
Vesa-Matti, Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 09.09.2013 15:36, Vesa-Matti J Kari wrote:
> >If I interpret this correctly, threads #2 and #3 are waiting for the same
> >lock but they make no progress.
>
> A-ha, the deadlock happens while doing SSL stuff. I didn't
Thanks for getting back to me about this change Oleg. I took your advice
and reworked the patch by adding a new hstore gin opclass
(gin_hstore_combined_ops) and leaving the functionality of the default
hstore gin opclass the same. This should prevent the on-disk compatibility
issues from the first
On 9/9/13 10:25 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> My suggestion in this matter is to disable gettext processing when
>> LC_CTYPE is set to C. We could log a warning when LC_MESSAGES is set to
>> something and LC_CTYPE is set to C. Or just do the warning and keep
>> logging. Some
Peter Eisentraut writes:
> My suggestion in this matter is to disable gettext processing when
> LC_CTYPE is set to C. We could log a warning when LC_MESSAGES is set to
> something and LC_CTYPE is set to C. Or just do the warning and keep
> logging. Something like that.
Meh. Seems that would o
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 recoding all the
> constrains.
Note tha
Hello,
On Mon, 9 Sep 2013, Heikki Linnakangas wrote:
> I managed to set that up and got it running.
Many thanks for taking the time.
> But it works fine for me, does not hang.
Okay. Have you tried increasing the iterations for the smtp sender
scripts? And could you please specify what is your
On 9/6/13 10:37 AM, Tom Lane wrote:
> BTW: personally, I would say that what you're looking at is a glibc bug.
> I always thought the contract of gettext was to return the ASCII version
> if it fails to produce a translated version. That might not be what the
> end user really wants to see, but su
Hello, Josh, all,
Could you explain why the following paragraph is necessary? I'm afraid this
is not correct and we need to remove it, because:
1. One PostgreSQL instance only needs one shmid.
2. The calculation of the number of semids is shown before, so we don't say
4096.
3. PostgreSQL does
On 09.09.2013 09:34, Vesa-Matti J Kari wrote:
Basically all that the authmilter now does is to connect to PostgreSQL in
authmilt_connect() and close the connection in authmilt_close(). Based on
the authmilter debug logging it seems to me that when the hanging occurs,
the authmilter never complete
From: "MauMau"
OK, I'll take this approach. That is:
I did as Tom san suggested. Please review the attached patch. I chose as
common errnos by selecting those which are used in PosttgreSQL source code
out of the error numbers defined in POSIX 2013.
As I said, lack of %m string has been
On 09/06/2013 01:02 AM, Robert Haas wrote:
On Wed, Sep 4, 2013 at 11:02 PM, Quan Zongliang wrote:
I think of a new idea.
Add a compare method column to pg_collation.
Every collation has its own compare function or null.
When function varstr_cmp is called, if specified collation
has compare func
(2013/09/09 8:19), Tomas Vondra wrote:
On 8.9.2013 23:04, Jeff Janes wrote:
On Tue, Sep 3, 2013 at 10:09 PM, Satoshi Nagayasu
wrote:
Hi,
(2013/09/04 13:07), Alvaro Herrera wrote:
Satoshi Nagayasu wrote:
As you may know, this file could be handreds of MB in size,
because pgstat.stat hol
65 matches
Mail list logo
