Hello PostgreSQL gurus,
(I have already posted a very similar message to comp.mail.sendmail
newsgroup on August 22nd, but I haven't received any responses there. I
have also tried pgsql-interfa...@postgresql.org but to no avail. Solving
this problem requires some Sendmail/Postfix experience
(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 sn...@uptime.jp
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
On 09/06/2013 01:02 AM, Robert Haas wrote:
On Wed, Sep 4, 2013 at 11:02 PM, Quan Zongliang quanzongli...@gmail.com 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
From: MauMau maumau...@gmail.com
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
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
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
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
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/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 that
Peter Eisentraut pete...@gmx.net 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
On 9/9/13 10:25 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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 have
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
On Mon, Sep 9, 2013 at 5:22 AM, Quan Zongliang quanzongli...@gmail.com 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
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
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 Sat, Sep 7, 2013 at 6:55 PM, Greg Stark st...@mit.edu 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
On Fri, Sep 6, 2013 at 3:40 PM, Jim Nasby j...@nasby.net 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
On Sun, Sep 8, 2013 at 8:49 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 9, 2013 at 2:35 AM, Jeff Janes jeff.ja...@gmail.com 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,
On Sat, Sep 7, 2013 at 3:57 AM, Pavel Stehule pavel.steh...@gmail.com 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
On Sat, Sep 7, 2013 at 6:57 PM, Tomas Vondra t...@fuzzy.cz 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:
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
glance.
On Fri, Sep 6, 2013 at 7:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On 9 Září 2013, 18:50, Robert Haas wrote:
On Sat, Sep 7, 2013 at 6:57 PM, Tomas Vondra t...@fuzzy.cz 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
Robert Haas robertmh...@gmail.com 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
On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian br...@momjian.us 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
Peter Eisentraut pete...@gmx.net 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
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 xid is
* 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't
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
On Mon, Sep 9, 2013 at 12:37:25PM -0400, Robert Haas wrote:
On Sat, Sep 7, 2013 at 10:59 AM, Bruce Momjian br...@momjian.us 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
Noah Misch n...@leadboat.com 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
Tom Lane writes:
Andres Freund and...@2ndquadrant.com 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
On 2013-09-09 21:41:00 +0200, Daniel Vérité wrote:
Tom Lane writes:
Andres Freund and...@2ndquadrant.com 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
On Thu, Sep 5, 2013 at 3:23 PM, Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
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
From: Tom Lane t...@sss.pgh.pa.us
Noah Misch n...@leadboat.com 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
From: Peter Eisentraut pete...@gmx.net
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
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() called by
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.
2.
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
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 wedding).
From: Peter Eisentraut pete...@gmx.net
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,
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
On Mon, Sep 9, 2013 at 2:43 PM, Peter Eisentraut pete...@gmx.net 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.
--
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
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 5, 2013 at 3:23 PM, Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
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
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
On 2013-09-09 18:43:51 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 5, 2013 at 3:23 PM, Andres Freund and...@2ndquadrant.com
wrote:
So, a very slightly updated patch attached.
Committed.
Hmm ... shouldn't this patch adjust the error messages in
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
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, 2013-09-09 at 14:51 -0700, Peter Geoghegan wrote:
On Mon, Sep 9, 2013 at 2:43 PM, Peter Eisentraut pete...@gmx.net 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
On Tue, Jan 22, 2013 at 07:30:59PM -0500, Tom Lane wrote:
Ian Lawrence Barwick barw...@gmail.com 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
On Mon, Sep 9, 2013 at 6:05 PM, Peter Eisentraut pete...@gmx.net 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
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 conventional
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 hand,
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 seems a
tad
On Tue, Sep 10, 2013 at 05:42:06AM +0900, MauMau wrote:
From: Tom Lane t...@sss.pgh.pa.us
Noah Misch n...@leadboat.com 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
Maciek Sakrejda m.sakre...@gmail.com 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
2013/9/10 Bruce Momjian br...@momjian.us:
On Tue, Jan 22, 2013 at 07:30:59PM -0500, Tom Lane wrote:
Ian Lawrence Barwick barw...@gmail.com writes:
Related email from the archives on this subject:
http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com
On Mon, Sep 9, 2013 at 9:33 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sun, Sep 8, 2013 at 8:49 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 9, 2013 at 2:35 AM, Jeff Janes jeff.ja...@gmail.com wrote:
I thought it was well known, but maybe I was overly optimistic. I've
65 matches
Mail list logo
