Simon Riggs <[EMAIL PROTECTED]> writes:
> I agree with everything you just said.
As AndrewSN already pointed out, the argument is all wet because it
ignores the use of OIDs for toasted values ... not to mention large
objects. Yeah, it would take a while to wrap the counter, but it's
hardly out of
On Wed, 2005-08-10 at 14:42 -0400, Greg Stark wrote:
> Bruce Momjian writes:
>
> > Just to chime in --- I have been surprised how _few_ complaints we have
> > gotten about oid wraparound hitting system table oid conflicts. I agree
> > that telling people to retry their CREATE statements isn't re
On 2005-08-10, Greg Stark <[EMAIL PROTECTED]> wrote:
> But with no OIDs on user tables it must take a really long time for this to
> happen. I mean, even if you have thousands of tables you would have to go
> through thousands (many thousands even) of dump/reload cycles before you push
> oid to 4 b
Bruce Momjian writes:
> Just to chime in --- I have been surprised how _few_ complaints we have
> gotten about oid wraparound hitting system table oid conflicts. I agree
> that telling people to retry their CREATE statements isn't really an
> ideal solution, and the idea of looping to find a fr
Simon Riggs wrote:
On Tue, 2005-08-09 at 16:01 +0100, Richard Huxton wrote:
Tom Lane wrote:
What if there aren't any "untouched chunks"? With only 64K-chunk
granularity, I think you'd hit that condition a lot more than you are
hoping. Also, this seems to assume uniqueness across all tables
On Mon, Aug 08, 2005 at 11:28:54PM +0100, Simon Riggs wrote:
> As I mentioned, as time goes on, this is very likely to occur with older
> installations before it occurs with newer ones. Older databases tend to
> have older releases, hence the comment to backpatch. I regard this as a
Well, as an al
Just to chime in --- I have been surprised how _few_ complaints we have
gotten about oid wraparound hitting system table oid conflicts. I agree
that telling people to retry their CREATE statements isn't really an
ideal solution, and the idea of looping to find a free oid is a good one.
-
On Tue, 2005-08-09 at 16:01 +0100, Richard Huxton wrote:
> Tom Lane wrote:
> >
> > What if there aren't any "untouched chunks"? With only 64K-chunk
> > granularity, I think you'd hit that condition a lot more than you are
> > hoping. Also, this seems to assume uniqueness across all tables in an
Tom Lane wrote:
What if there aren't any "untouched chunks"? With only 64K-chunk
granularity, I think you'd hit that condition a lot more than you are
hoping. Also, this seems to assume uniqueness across all tables in an
entire cluster, which is much more than we want; it makes the 32-bit
size
Richard Huxton writes:
> Can I ask what happens if we end up re-using a recently de-allocated
> OID? Specifically, can a cached plan (e.g. plpgsql function) end up
> referring to an object created after it was planned:
Definitely a potential risk, but not one to be solved by the sorts
of mechan
Simon Riggs <[EMAIL PROTECTED]> writes:
> We either need to have a special routine for each catalog table, or we
> scan all tables, all of the time. The latter is a disaster, so lets look
> at the former: spicing the code with appropriate catalog checks would be
> a lot of work and probably very er
On Mon, 2005-08-08 at 19:50 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
> >> Considering we don't even have code to do this, much less have expended
> >> one day of beta testing on it, back-patching seems a bit premature.
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
>> Considering we don't even have code to do this, much less have expended
>> one day of beta testing on it, back-patching seems a bit premature.
> You provided a patch and explained your testing of it. It
On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
> >> We've sort of brushed this problem aside in the past by telling people
> >> they could just retry their transaction ... but why don't we make the
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
>> We've sort of brushed this problem aside in the past by telling people
>> they could just retry their transaction ... but why don't we make the
>> database do the retrying? I'm envisioning something lik
On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
> I was reminded again today of the problem that once a database has been
> in existence long enough for the OID counter to wrap around, people will
> get occasional errors due to OID collisions, eg
>
> http://archives.postgresql.org/pgsql-general
Tom Lane sss.pgh.pa.us> writes:
>
> I was reminded again today of the problem that once a database has been
> in existence long enough for the OID counter to wrap around, people will
> get occasional errors due to OID collisions, eg
>
> http://archives.postgresql.org/pgsql-general/2005-08/msg001
On Thu, Aug 04, 2005 at 12:20:24PM -0400, Tom Lane wrote:
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
> >> I'm too lazy to run an experiment, but I believe it would. Datum is
> >> involved in almost every function-call API in the backend. In
> >> particular this means that it would affect perfor
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>>> I'm too lazy to run an experiment, but I believe it would. Datum is
>>> involved in almost every function-call API in the backend. In
>>> particular this means that it would affect performance-critical code
>>> paths.
>
>> I hear you on the "lazy"
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> I'm too lazy to run an experiment, but I believe it would. Datum is
>> involved in almost every function-call API in the backend. In
>> particular this means that it would affect performance-critical code
>> paths.
> I hear you on the "lazy" part, bu
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>>> 2. Performance. Doing this would require widening Datum to 64 bits,
>>> which is a system-wide performance hit on 32-bit machines.
>
>> Do you really think it would make a measurable difference, more so than
>> your proposed solution? (I'm skeptica
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> 2. Performance. Doing this would require widening Datum to 64 bits,
>> which is a system-wide performance hit on 32-bit machines.
> Do you really think it would make a measurable difference, more so than
> your proposed solution? (I'm skeptical it wo
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>> Why is there collision? It is because the number range of an OID is
>> currently smaller than the possible usage.
>
> Expanding OIDs to 64 bits is not really an attractive answer, on several
> grounds:
>
> 1. Disk space.
I don't really see this as a
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> Why is there collision? It is because the number range of an OID is
> currently smaller than the possible usage.
Expanding OIDs to 64 bits is not really an attractive answer, on several
grounds:
1. Disk space.
2. Performance. Doing this would requir
> I was reminded again today of the problem that once a database has been
> in existence long enough for the OID counter to wrap around, people will
> get occasional errors due to OID collisions, eg
>
> http://archives.postgresql.org/pgsql-general/2005-08/msg00172.php
>
> Getting rid of OID usage i
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Looks good. Another approach would be to put the existing code in a
> PG_TRY() block and catching the duplicate key violation.
Not really feasible from a code-structure point of view, I'm afraid.
Also there is the issue of cleaning up leaked resources (bu
On Wed, 3 Aug 2005, Tom Lane wrote:
> I seem to recall having thought of this idea before, and having rejected
> it as being too much overhead to solve a problem that occurs only rarely
> --- but in a quick test involving many repetitions of
>
> create temp table t1(f1 int, f2 int);
>
27 matches
Mail list logo
