On Mon, Jan 31, 2011 at 13:41, Robert Haas robertmh...@gmail.com wrote:
1. Absorb fsync requests a lot more often during the sync phase.
2. Still try to run the cleaning scan during the sync phase.
3. Pause for 3 seconds after every fsync.
So if we want the checkpoint
to finish in, say, 20
Hi,
While working on PL/Perl patch for arrays as input arguments I've noticed that
PostgreSQL reports one less dimension in the 'number of array dimensions (%d)
exceeds the maximum allowed (%d), i.e.
select
'{{{1,2},{3,4}},{{5,6},{7,8}}},{{{9,10},{11,12}},{{13,14},{15,16,
On Jan 29, 2011, at 12:27 AM, Alex Hunsaker wrote:
On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check
Dear all,
for the sake academic teaching, a colleague asked me in how far
PostgreSQL does support object functionality these days.
I am afraid my web research was not very fruitful to him; the impression
is that hardly anybody is occupied in working on PostgreSQL object
functionality --
Hello
What I know no body is working on SQL/OLB ISO/IEC 9075-10 now.
I proposed a 3 years ago a support of methods, but without success.
This propose was rejected. There isn't a real interest to implement it
from commiters. And I have to say - users doesn't request it too. And
there are a few
Itagaki Takahiro itagaki.takah...@gmail.com writes:
* relocatable and schema seems to be duplicated options.
They are not, really. If you have a relocatable extension, then there's
no schema option in the control file (setting it is an ERROR). If you
have a non-relocatable extension, then you
On Sun, Jan 30, 2011 at 04:01:56PM -0600, Kevin Grittner wrote:
I'm wondering how this differs from what is discussed in Section 2.7
(Serialization Graph Testing) of Cahill's doctoral thesis. That
discusses a technique for trying to avoid false positives by testing
the full graph for cycles,
On Mon, 24 Jan 2011 15:08:11 +0200
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I've gone through the code in a bit more detail now. I did a bunch of
cosmetic changes along the way, patch attached. I also added a few
paragraphs in the docs. We need more extensive
On Mon, Jan 31, 2011 at 8:00 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
* Is there any use case for changing the handler or validator function
of an existign FDW with ALTER? To me it just seems like an unnecessary
complication.
AFAICS, the only case for that is upgrading FDW to new
Jeff Davis wrote:
1. In CheckForSerializableConflictIn(), I think the comment above
may be out of date. It says:
2. Also in the comment above CheckForSerializableConflictIn(), I
see:
3. The comment above CheckForSerializableConflictOut() seems to
trail off, as though you may have
On Mon, Jan 31, 2011 at 4:34 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
What I know no body is working on SQL/OLB ISO/IEC 9075-10 now.
I proposed a 3 years ago a support of methods, but without success.
This propose was rejected. There isn't a real interest to implement it
from
On Mon, Jan 31, 2011 at 3:32 AM, Jörg Roman Rudnick
joerg.rudn...@t-online.de wrote:
* are there any people / projects known which are interested in ORDBMS /
OODBMS usage of PostgreSQL? Strict SQL standard conformance is less
important than the possibility to provide instructive and impressive
On Mon, Jan 31, 2011 at 3:04 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 31, 2011 at 13:41, Robert Haas robertmh...@gmail.com wrote:
1. Absorb fsync requests a lot more often during the sync phase.
2. Still try to run the cleaning scan during the sync phase.
3. Pause for
Actually, it was Simon and Florian who were arguing that we needed to
distinguish these cases from other types of recovery conflict;
Tatsuo-san was arguing that we needed to distinguish a
dropped-database-recovery-conflict from a cluster shutdown - the
current choice of ERRCODE_ADMIN_SHUTDOWN
On Fri, Jan 28, 2011 at 3:39 PM, Robert Haas robertmh...@gmail.com wrote:
What happens if we (a) keep the current rule after reaching
consistency and (b) apply any such updates *unconditionally* - that
is, without reference to the LSN - prior to reaching consistency?
Under that rule, if we
Tom Lane wrote:
Thom Brown t...@linux.com writes:
On 29 January 2011 11:12, Magnus Hagander mag...@hagander.net wrote:
Any idea why this is happening?
I don't know what's causing that since I can see both of those IDs are
present, but I should also mention that the identities those
2011/1/31 Hitoshi Harada umi.tan...@gmail.com:
2011/1/31 Robert Haas robertmh...@gmail.com:
On Tue, Jan 25, 2011 at 10:24 AM, Hitoshi Harada umi.tan...@gmail.com
wrote:
I'll check the code more if we have better alternatives.
Where are we with this?
I'll post another version today.
On Fri, Jan 28, 2011 at 8:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
3. Page LSN WAL location: do NOT apply field update or change LSN.
I don't think this works. There could be multiple writes to a page for
different records before the crash occurs. The LSN could be far in the
future and yet
On 31.01.2011 16:44, Robert Haas wrote:
On Mon, Jan 31, 2011 at 3:04 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 31, 2011 at 13:41, Robert Haasrobertmh...@gmail.com wrote:
1. Absorb fsync requests a lot more often during the sync phase.
2. Still try to run the cleaning
Bruce Momjian br...@momjian.us wrote:
As a novice I am not sure why we _wouldn't_ create two new
separate error codes
The argument for using SQLSTATE 40001 for failures which are
strictly due to concurrency problems, and are likely to work if the
transaction is retried, is that there is
On Mon, 2011-01-31 at 09:46 -0500, Bruce Momjian wrote:
Actually, it was Simon and Florian who were arguing that we needed to
distinguish these cases from other types of recovery conflict;
Tatsuo-san was arguing that we needed to distinguish a
dropped-database-recovery-conflict from a
Hi,
I've attached a small patch for the docs which adds a reference to the
client_encoding parameter description. This is in response to someone
attempting to submit a comment which explains where available
encodings can be found.
Thanks
Thom Brown
Twitter: @darkixion
IRC (freenode):
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
As a novice I am not sure why we _wouldn't_ create two new
separate error codes
The argument for using SQLSTATE 40001 for failures which are
strictly due to concurrency problems, and are likely to work if the
transaction is
Hitoshi Harada umi.tan...@gmail.com writes:
Finally I concluded the concern Itagaki-san raised can be solved by
adding code that restores client_encoding in copy_in_error_callback.
That seems like an absolutely horrid idea. Error context callbacks
should not have side-effects like that.
On 25.01.2011 06:02, Fujii Masao wrote:
On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, perhaps the code would be more readable if instead of the
forcePageWrites counter that counts exclusive and non-exclusive backups, and
an exclusiveBackup
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
IMHO we should re-consider the patch to sort the writes. Not so much
because of the performance gain that gives, but because we can then
re-arrange the fsyncs so that you write one file, then fsync it, then
write the next file
On 27.01.2011 15:15, Fujii Masao wrote:
When I read the patch, I found that pg_stop_backup removes the backup history
file as soon as it creates the file, if archive_mode is not enabled.
This looks like
oversight. We should prevent pg_stop_backup from removing the fresh history
file? Or we
On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Bruce Momjian br...@momjian.us wrote:
As a novice I am not sure why we _wouldn't_ create two new
separate error codes
The argument for using SQLSTATE 40001 for failures which are
strictly due to concurrency
On Mon, Jan 31, 2011 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
IMHO we should re-consider the patch to sort the writes. Not so much
because of the performance gain that gives, but because we can then
re-arrange the fsyncs so
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That sounds like you have an entirely wrong mental model of where the
cost comes from. Those times are not independent.
Yeah, Greg Smith made the same point a week or three ago.
On Mon, Jan 31, 2011 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That sounds like you have an entirely wrong mental model of where the
cost comes from. Those times are not
Robert Haas robertmh...@gmail.com writes:
3. Pause for 3 seconds after every fsync.
I think something along the lines of #3 is probably a good idea,
Really? Any particular delay is guaranteed wrong.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Mon, Jan 31, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
3. Pause for 3 seconds after every fsync.
I think something along the lines of #3 is probably a good idea,
Really? Any particular delay is guaranteed wrong.
What I was getting at
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder whether it'd be useful to keep track of the total amount of
data written-and-not-yet-synced, and to issue fsyncs often enough to
keep that below some parameter; the idea
Following recent discussions and the enabling of 64 bit Mingw builds, I
propose to make the attached changes to the docs. I don't see any great
reason for us to advise against building with Mingw, especially now that
we have 64 bit support for it, so I removed that, amd also clarified
where
On Mon, Jan 31, 2011 at 18:14, Andrew Dunstan and...@dunslane.net wrote:
Following recent discussions and the enabling of 64 bit Mingw builds, I
propose to make the attached changes to the docs. I don't see any great
reason for us to advise against building with Mingw, especially now that we
On Mon, Jan 31, 2011 at 12:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Pretty minimal differences from V14, but I figured it would save the
committer some work if I rolled them all up here.
Sounds good. I believe Heikki is planning to work on this one.
Hopefully that will happen
On 01/31/2011 12:17 PM, Magnus Hagander wrote:
On Mon, Jan 31, 2011 at 18:14, Andrew Dunstanand...@dunslane.net wrote:
Following recent discussions and the enabling of 64 bit Mingw builds, I
propose to make the attached changes to the docs. I don't see any great
reason for us to advise
On Mon, 2011-01-31 at 07:26 -0600, Kevin Grittner wrote:
And why are you reading the infomask directly? Do the existing
visibility functions not suffice?
It's possible we re-invented some code somewhere, but I'm not clear
on what code from this patch might use what existing function.
On Mon, Jan 31, 2011 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder whether it'd be useful to keep track of the total amount of
data written-and-not-yet-synced, and to issue
On Mon, Jan 31, 2011 at 19:34, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2011 12:17 PM, Magnus Hagander wrote:
On Mon, Jan 31, 2011 at 18:14, Andrew Dunstanand...@dunslane.net wrote:
Following recent discussions and the enabling of 64 bit Mingw builds, I
propose to make the
On 01/31/2011 01:51 PM, Magnus Hagander wrote:
I just tested by setting my machine to fr_FR, and also setting
LANG=fr_FR.utf8 under Cygwin. The build failed. The I set Cygwin back to
LANG=C.utf8 and the build/install succeeded. After that, I switched back to
LANG=fr_FR.utf8, and initdb,
I just tested by setting my machine to fr_FR, and also setting
LANG=fr_FR.utf8 under Cygwin. The build failed. The I set Cygwin back to
LANG=C.utf8 and the build/install succeeded. After that, I switched back
to
LANG=fr_FR.utf8, and initdb, pg_ctl start and psql all behaved as
expected.
I'm
On 01/15/2011 12:31 AM, Alex Hunsaker wrote:
On Tue, Dec 7, 2010 at 07:24, Tim Buncetim.bu...@pobox.com wrote:
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with our $_TD; local $_TD = shift;
Pre-extend stack for trigger
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2011-01-31 at 07:26 -0600, Kevin Grittner wrote:
And why are you reading the infomask directly? Do the existing
visibility functions not suffice?
It's possible we re-invented some code somewhere, but I'm not
clear on what code from this patch
On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Bruce Momjian br...@momjian.us wrote:
As a novice I am not sure why we _wouldn't_ create two new
separate error codes
The argument for using
On Mon, 2011-01-31 at 13:32 -0600, Kevin Grittner wrote:
Ah, now I see what you're talking about. Take a look at where that
valid flag come from -- the CheckForSerializableConflictOut are
all place right after calls to HeapTupleSatisfiesVisibility. The
valid value is what
Jeff Davis pg...@j-davis.com wrote:
I don't think this function really cares about the visibility with
respect to the current snapshot, right?
What it cares about is whether some other particular top level
transaction wrote a tuple which we *would* read except that it is
not visible to us
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
, or to use a new
error code. ERRCODE_ADMIN_SHUTDOWN is just strange.
It's not strange at all. It's the same error code as we use for all of
the other cases listed. We need that because it is the
Jeff Davis pg...@j-davis.com wrote:
Really, I think this should be using HTSV to separate concerns
better and improve readability. My first reaction was to try to
find out what the function was doing that's special. If it is
doing something special, and HTSV is not what you're really
On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
, or to use a new
error code. ERRCODE_ADMIN_SHUTDOWN is just strange.
It's not strange at all. It's the same error code as we use for all
Hello,
I discussed my problem at www.pg-forum.de with Mr. Scherbaum (ADS) and he
recommended me to inform you about this problem.
I worked on my Mac-Book (Mac OS X 10.6.6) with postgresql database version 9
(postgresql-9.0.1-1-osx.dmg). After installing and connecting my HUAWEI E122
data
On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
I don't think this function really cares about the visibility with
respect to the current snapshot, right?
What it cares about is whether some other particular top level
transaction wrote a
Robert Haas wrote:
Back to the idea at hand - I proposed something a bit along these
lines upthread, but my idea was to proactively perform the fsyncs on
the relations that had gone the longest without a write, rather than
the ones with the most dirty data. I'm not sure which is better.
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
What it cares about is whether some other particular top level
transaction wrote a tuple which we *would* read except that it is
not visible to us because that other top level transaction is
I wrote:
We follow this by a check for the top-level xid, and return if
that's early enough to have overlapped our transaction.
s/early enough to have overlapped/early enough not to have
overlapped/
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Mon, 2011-01-31 at 14:38 -0600, Kevin Grittner wrote:
It is at least as likely that I'm missing something. If I'm
following you, we're talking about these 24 lines of code, where
valid is the what was just returned from
HeapTupleSatisfiesVisibility:
Yes.
(1) Do you see a case where
Tom Lane wrote:
I wonder whether it'd be useful to keep track of the total amount of
data written-and-not-yet-synced, and to issue fsyncs often enough to
keep that below some parameter; the idea being that the parameter would
limit how much dirty kernel disk cache there is. Of course, ideally
Jeff Davis pg...@j-davis.com wrote:
Ok, great. When I read that before I thought that WAL might need
to be sent for implicit RO transactions. I will read it more
carefully again.
In looking back over recent posts to see what I might have missed or
misinterpreted, I now see your point.
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
connection pooler to expect that *all* its connections are going bad,
not just the ones that are connected to a specific database. I
Robert Haas robertmh...@gmail.com writes:
Back to the idea at hand - I proposed something a bit along these
lines upthread, but my idea was to proactively perform the fsyncs on
the relations that had gone the longest without a write, rather than
the ones with the most dirty data.
Yeah. What
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2011-01-31 at 14:38 -0600, Kevin Grittner wrote:
If I want to try the switch statement from your recent
post, what should I use as the OldestXmin value on the call to
HTSV?
I believe RecentGlobalXmin should work.
And I don't think the
On 1/31/11 11:26 AM, Simon Riggs wrote:
The purpose of errcodes is to allow programs to check them and then act.
It's pointless to add a new errcode that is so rare that nobody will
ever program for it because they won't expect it, let alone test for it.
Or at least won't assign any sensible
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
3. Pause for 3 seconds after every fsync.
I think something along the lines of #3 is probably a good idea,
Really? Any particular delay is guaranteed wrong.
'3 seconds' is just a placeholder for whatever comes
On 31.01.2011 20:05, Robert Haas wrote:
On Mon, Jan 31, 2011 at 12:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Pretty minimal differences from V14, but I figured it would save the
committer some work if I rolled them all up here.
Sounds good. I believe Heikki is planning to
On Mon, 2011-01-31 at 15:30 -0600, Kevin Grittner wrote:
I'll try to set this up and see if I can get it to pass the check
and dcheck make targets. Can we assume that the performance impact
would be too small to matter when we know for sure that hint bits
have already been set?
I think
Interesting... I remember that some years ago, I fiddled around with
functions, operators etc. to allow a method like syntax -- but I ever
was worried this approach would have serious weaknesses -- are there any
principal hindrances to having methods, if no, can this be implemented
in a
Hello Robert,
a good moment to clear things up:
* Of course, compliance with an ISO-SQL standard is of minimal
importance -- I just grabbed it from the docs.
* The same holds (in a somewhat weaker way) for Java -- I would even
prefer the more general notion type instead of OO, but I am
All,
This year we will be having a Cluster Hackers summit at pgCon. You
are invited if you are currently working on any PostgreSQL replication
or clustering solution, or core features to support such solutions.
This includes, but is not limited to: PostgreXC, GridSQL, Postgres-R,
Slony-I,
On Mon, 2011-01-31 at 23:35 +0200, Heikki Linnakangas wrote:
Yeah, I can commit this. Jeff, are you satisfied with this patch now?
I'm glad you're reviewing this, more eyeballs helps a lot with a big
patch like this.
I think the patch is very close. I am doing my best in my free time to
On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
connection pooler to expect that *all* its connections are going bad,
not just
On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2011-01-31 at 15:30 -0600, Kevin Grittner wrote:
I'll try to set this up and see if I can get it to pass the check
and dcheck make targets. Can we assume that the performance
impact would be too small to matter when we know for sure that
hint bits
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
the attached patch is to avoid unnecessary detoast'ing and EOF marker pages
when possible. does it make sense?
The blob page size is already chosen not to allow for out-of-line
storage, not to mention that pg_largeobject doesn't have a TOAST
On Mon, 2011-01-31 at 18:21 -0500, Robert Haas wrote:
Ready to commit if no objection.
ISTM it should still be in class 40. There's nothing wrong with the
user's authorization; we've just decided to roll back the transaction
for our own purposes.
OK.
BTW, anybody know why we have
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
rather than a Transaction Rollback code. So sqlstate 28P02
ISTM it should still be in class 40. There's
BTW, anybody know why we have PL/pgSQL condition codes for conditions
that can't be trapped by PL/pgSQL? ERRCODE_ADMIN_SHUTDOWN and
ERRCODE_DATABASE_DROPPED are always FATAL. Seems like pointless code to
me.
So we can support autonomous transactions in the future?
--
On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
rather than a Transaction Rollback code.
On Mon, Jan 31, 2011 at 7:13 PM, Josh Berkus j...@agliodbs.com wrote:
BTW, anybody know why we have PL/pgSQL condition codes for conditions
that can't be trapped by PL/pgSQL? ERRCODE_ADMIN_SHUTDOWN and
ERRCODE_DATABASE_DROPPED are always FATAL. Seems like pointless code to
me.
So we can
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree, 28 is a completely off-point category. But it wasn't in 40
before, either --- we are talking about where it currently says
ADMIN_SHUTDOWN, no? I'd vote for keeping it in
On Mon, 2011-01-31 at 19:12 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
rather than a Transaction Rollback code. So sqlstate
Simon Riggs si...@2ndquadrant.com writes:
BTW, anybody know why we have PL/pgSQL condition codes for conditions
that can't be trapped by PL/pgSQL? ERRCODE_ADMIN_SHUTDOWN and
ERRCODE_DATABASE_DROPPED are always FATAL. Seems like pointless code to
me.
There's a difference between not being able
Magnus Hagander wrote:
I just tried doing pg_upgrade on a database when logged in as user
mha rather than postgres on my system. And it failed. Even though
the db was initialized with superuser mha. The reason for this was
that pg_upgrade tried to connect to the database mha (hardcoded to
be
On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree, 28 is a completely off-point category. But it wasn't in 40
before, either --- we are talking about where
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Seems a little weird to me, since the administrator hasn't done
anything.
Sure he has: he issued the DROP DATABASE command that's causing
2011/2/1 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
Finally I concluded the concern Itagaki-san raised can be solved by
adding code that restores client_encoding in copy_in_error_callback.
It might happen to work today (or at least in the scenarios you tested),
To All,
I would like to propose (and volunteer to do if its considered to be a
decent idea) to extend the mapping of users to roles in the pg_ident.conf to
incorporate groups. This would allow any user who belonged to a particular
group in certain authentication systems to be mapped to a role
On Mon, Jan 31, 2011 at 10:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 28, 2011 at 3:39 PM, Robert Haas robertmh...@gmail.com wrote:
What happens if we (a) keep the current rule after reaching
consistency and (b) apply any such updates *unconditionally* - that
is, without
On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Then again - in theory, there's no reason why we couldn't drop a
database on the master when it's in use, kicking out everyone using it
with this very same error code. We don't happen to handle it that way
right now, but...
On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick joerg.rudn...@t-online.de wrote:
Interesting... I remember that some years ago, I fiddled around with
functions, operators etc. to allow a method like syntax -- but I ever was
worried this approach would have serious weaknesses -- are there any
On Mon, Jan 31, 2011 at 5:40 PM, Nick Rudnick joerg.rudn...@t-online.de wrote:
* In this regard it is of interest in how far there are principal efficiency
problems with the support of (deeply nested) object like structure by the
backend, or if the backend may be expected to do this job not
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
OK, now it works flawlessly as far as I can tell. Will mark it as Ready
for Committer.
Applied with mostly-stylistic corrections, plus addition of
documentation and a minimal regression test.
I did *not* apply this bit:
2) I found
Robert Haas robertmh...@gmail.com writes:
It would help if you were a bit more specific. Do you mean you want
to write something like foo.bar(baz) and have that mean call the bar
method of foo and pass it baz as an argument?
If so, that'd certainly be possible to implement for purposes of a
On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, good point. It's harmless, but creating the history file in the first
place sure seems like a waste of time.
The attached patch changes pg_stop_backup so that it doesn't create
the backup history
2011/2/1 Hitoshi Harada umi.tan...@gmail.com:
2011/2/1 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
Finally I concluded the concern Itagaki-san raised can be solved by
adding code that restores client_encoding in copy_in_error_callback.
It might happen to work
2011/2/1 Robert Haas robertmh...@gmail.com:
On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick joerg.rudn...@t-online.de
wrote:
Interesting... I remember that some years ago, I fiddled around with
functions, operators etc. to allow a method like syntax -- but I ever was
worried this approach
Hello
it is part of ANSi SQL 2003
http://savage.net.au/SQL/sql-2003-2.bnf.html#method%20specification%20designator
2011/2/1 Pavel Stehule pavel.steh...@gmail.com:
2011/2/1 Robert Haas robertmh...@gmail.com:
On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick joerg.rudn...@t-online.de
wrote:
Hello
There are broken links inside messages from commiters.
projects /
404 - No such project
OPML TXT
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 1, 2011 at 00:37, Thom Brown t...@linux.com wrote:
I've attached a small patch for the docs which adds a reference to the
client_encoding parameter description. This is in response to someone
attempting to submit a comment which explains where available
encodings can be found.
2011/1/27 Hiroshi Inoue in...@tpf.co.jp:
I see now the following lines in libintl.h of version
0.18.1.1 which didn't exist in 0.17 version.
The macro may cause a trouble especially on Windows.
Attached is a patch to disable the macro on Windows.
Can anyone test the fix?
I added the patch to
1 - 100 of 104 matches
Mail list logo
