2011/2/1 Magnus Hagander :
> On Tue, Feb 1, 2011 at 05:53, Pavel Stehule wrote:
>> Hello
>>
>> There are broken links inside messages from commiters.
>>
>> projects /
>>
>>
>> 404 - No such project
>
> Are you using gmail? They have made some changes recently that breaks
> the viewing of the URLs.
On Tue, Feb 1, 2011 at 05:53, Pavel Stehule wrote:
> Hello
>
> There are broken links inside messages from commiters.
>
> projects /
>
>
> 404 - No such project
Are you using gmail? They have made some changes recently that breaks
the viewing of the URLs. Haven't heard any non-gmail user complain
On Tue, Feb 1, 2011 at 03:29, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane 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
On Mon, Jan 31, 2011 at 17:19, Alexey Klyukin wrote:
> 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},{
2011/1/27 Hiroshi Inoue :
> 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 the curren
On Tue, Feb 1, 2011 at 00:37, Thom Brown 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.
Thanks. It's
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
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 :
> 2011/2/1 Robert Haas :
>> On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick
>> wrote:
>>> Interesting... I remember that some years ago, I fiddled around w
2011/2/1 Robert Haas :
> On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick
> 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
2011/2/1 Hitoshi Harada :
> 2011/2/1 Tom Lane :
>> Hitoshi Harada 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),
On Tue, Feb 1, 2011 at 1:31 AM, Heikki Linnakangas
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 file if archiving is not enabled.
Robert Haas 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
> college course,
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 gist index not v
On Mon, Jan 31, 2011 at 5:40 PM, Nick Rudnick 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 terribly worse
> then more
On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick 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
> principal hindrances to h
On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane 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...
>
> Yeah, th
On Mon, Jan 31, 2011 at 10:01 AM, Robert Haas wrote:
> On Fri, Jan 28, 2011 at 3:39 PM, Robert Haas 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
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 using
2011/2/1 Tom Lane :
> Hitoshi Harada 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),
> but it seems fragile as can be.
Robert Haas writes:
> On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane wrote:
>> Robert Haas 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 the
>> system to disconnect standby sessions.
> Wel
On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane 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 vot
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" (hardco
Simon Riggs 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 to trap the error
On Mon, 2011-01-31 at 19:12 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs wrote:
> >> I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
> >> rather than a Transaction Rollback code. So sqlstate 28P02
>
> > ISTM it should still b
Robert Haas writes:
> On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane 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 class 57 (operator
>> intervention),
On Mon, Jan 31, 2011 at 7:13 PM, Josh Berkus 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 support auto
On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs 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 c
> 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?
--
Robert Haas writes:
> On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs 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 nothing wrong with the
> user's authori
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 PL
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 t
Jeff Davis 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 have alrea
On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs wrote:
> On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
>> Simon Riggs 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
On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
> Simon Riggs 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 tha
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
co
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, Bucar
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 askin
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 straigh
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 th
On 31.01.2011 20:05, Robert Haas wrote:
On Mon, Jan 31, 2011 at 12:31 PM, Kevin Grittner
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 tha
Tom Lane wrote:
Robert Haas 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 out of a "total
time
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 sensibl
Jeff Davis 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 original switc
Robert Haas 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 I meant to suggest
Simon Riggs 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 think
>> this is a
Jeff Davis 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. Either of these alt
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 th
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 whe
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 cha
Jeff Davis 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
>> concurrent with
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.
>
On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
> Jeff Davis 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
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 mode
On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
> Simon Riggs 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
Jeff Davis 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
> looking for, a comm
Simon Riggs 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 current
> catc
Jeff Davis 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 because that other
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 HeapTupleSat
On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
> wrote:
> > Bruce Momjian 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
Jeff Davis 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 might
On 01/15/2011 12:31 AM, Alex Hunsaker wrote:
On Tue, Dec 7, 2010 at 07:24, Tim Bunce 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 arguments for sligh
>>> 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
>
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, pg_ct
On Mon, Jan 31, 2011 at 19:34, Andrew Dunstan wrote:
>
>
> On 01/31/2011 12:17 PM, Magnus Hagander wrote:
>>
>> On Mon, Jan 31, 2011 at 18:14, Andrew Dunstan wrote:
>>>
>>> Following recent discussions and the enabling of 64 bit Mingw builds, I
>>> propose to make the attached changes to the docs
On Mon, Jan 31, 2011 at 12:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 31, 2011 at 11:51 AM, 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
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 01/31/2011 12:17 PM, Magnus Hagander wrote:
On Mon, Jan 31, 2011 at 18:14, Andrew Dunstan 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 Min
On Mon, Jan 31, 2011 at 12:31 PM, Kevin Grittner
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 soon, since we are running
On Mon, Jan 31, 2011 at 18:14, Andrew Dunstan 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
> have 64 bit sup
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 C
Robert Haas writes:
> On Mon, Jan 31, 2011 at 11:51 AM, 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
>> lim
On Mon, Jan 31, 2011 at 12:01 PM, Tom Lane wrote:
> Robert Haas 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 was - I think it's probably a go
Robert Haas 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 (pgsql-hackers@postgresql.org)
On Mon, Jan 31, 2011 at 11:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 31, 2011 at 11:29 AM, Tom Lane 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
Robert Haas writes:
> On Mon, Jan 31, 2011 at 11:29 AM, Tom Lane 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. But it
> seems to me that there is p
On Mon, Jan 31, 2011 at 11:29 AM, Tom Lane wrote:
> Heikki Linnakangas 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
>>
On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
wrote:
> Bruce Momjian 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 t
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 should
Heikki Linnakangas 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 and so on.
Isn't that going to m
On 25.01.2011 06:02, Fujii Masao wrote:
On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
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 boolean indicating if one of the in-
Hitoshi Harada 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. They're not guaranteed t
Kevin Grittner wrote:
> Bruce Momjian 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
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): dark_ixion
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
Bruce Momjian 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 already a lot of so
On 31.01.2011 16:44, Robert Haas wrote:
On Mon, Jan 31, 2011 at 3:04 AM, Itagaki Takahiro
wrote:
On Mon, Jan 31, 2011 at 13:41, Robert Haas 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 seco
On Fri, Jan 28, 2011 at 8:08 PM, Tom Lane 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 still have a torn
2011/1/31 Hitoshi Harada :
> 2011/1/31 Robert Haas :
>> On Tue, Jan 25, 2011 at 10:24 AM, Hitoshi Harada
>> wrote:
>>> I'll check the code more if we have better alternatives.
>>
>> Where are we with this?
>
> I'll post another version today.
Here's the patch.
Finally I concluded the concern It
Tom Lane wrote:
> Thom Brown writes:
> > On 29 January 2011 11:12, Magnus Hagander 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 linkends
> > point to shoul
On Fri, Jan 28, 2011 at 3:39 PM, Robert Haas 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 encounter an FPI befo
> 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_SHUT
On Mon, Jan 31, 2011 at 3:04 AM, Itagaki Takahiro
wrote:
> On Mon, Jan 31, 2011 at 13:41, Robert Haas 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
On Mon, Jan 31, 2011 at 3:32 AM, Jörg Roman Rudnick
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
> examples to students.
On Mon, Jan 31, 2011 at 4:34 AM, Pavel Stehule 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 commiters. And I have to sa
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 8:00 AM, Shigeru HANADA
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 one without
> re-cr
On Mon, 24 Jan 2011 15:08:11 +0200
Heikki Linnakangas 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 documentation, but this
> at least marks the
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 cyc
Itagaki Takahiro 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 can either setup the s
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 iss
1 - 100 of 104 matches
Mail list logo
