On Fri, Jun 27, 2008 at 8:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Andrew Hammond" <[EMAIL PROTECTED]> writes:
>> (I thought this line was interesting)
>> Jun 27 15:54:31 qadb2 postgres[92519]: [44-1] PANIC: could not open
>> relation 1663/16386/679439393: No such file or directory
>
>> I goo
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We might have to rearrange the logic a bit to make that happen (I'm not
> >> sure what order things get tested in), but a log message does seem like
> >> a good idea. I'd go for logging anytime an orphaned table
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We might have to rearrange the logic a bit to make that happen (I'm not
>> sure what order things get tested in), but a log message does seem like
>> a good idea. I'd go for logging anytime an orphaned table is seen,
>> and dropping o
"Ana Carolina Brito de Almeida" <[EMAIL PROTECTED]> writes:
> So, I would like to know the differences between bucket and batch.
A bucket is, well, one bucket of a hash table --- it holds all the
tuples that have the same hash code (for as many bits of the hash
code as we are choosing to use). We
Richard Huxton <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So put forward a worked-out proposal for some other behavior.
> IMHO the time a dump/restore should be issuing ALTER...SET on a database
> is when it has issued the corresponding CREATE DATABASE.
So pg_dump would produce this info w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In any case, this seems a case of stuffing too much in the primary
> message.
Yeah, good point.
> I think it should be something like
> errmsg("parameter \"shared_buffer\" change in configuration file ignored"),
> errdetail("This parameter cannot be ch
Bruce Momjian wrote:
Dave Page wrote:
On Sun, May 18, 2008 at 1:38 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
I don't know how you tested,
Copy a large file across a relatively slow network, and check the size
on the destination drive before it finishes.
but could yo
I just noticed that identify_system_timezone() tries to match our
timezones to the system timezone on the basis of probing the date
range 1904-2004. While doubtless this seemed like a good idea at
the time, it means that we'll be unable to distinguish zones whose
histories diverge after 2004. I t
Bruce Momjian escribió:
> Gurjeet Singh wrote:
> > May 14 21:38:40 sfphotodb001 postgres[29658]: [19-1] 2008-05-14 21:38:40
> > PDTLOG: received SIGHUP, reloading configuration files
> > May 14 21:38:40 sfphotodb001 postgres[29658]: [20-1] 2008-05-14 21:38:40
> > PDTLOG: parameter "shared_buffer
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Gurjeet Singh wrote:
> >> May 14 21:38:40 sfphotodb001 postgres[29658]: [20-1] 2008-05-14 21:38:40
> >> PDTLOG: parameter "shared_buffers" cannot be changed after server start;
> >> configuration file change ignored
> >>
> >> The mes
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Gurjeet Singh wrote:
>> May 14 21:38:40 sfphotodb001 postgres[29658]: [20-1] 2008-05-14 21:38:40
>> PDTLOG: parameter "shared_buffers" cannot be changed after server start;
>> configuration file change ignored
>>
>> The message probably should be rephra
Bernd Helmle wrote:
> Now that we have customizable segment sizes for heap and WAL at compilation
> time i would like to have some runtime variables to query that information
> (besides pg_controldata). I can imagine to have the following names:
>
> segment_size: Reports heap segment size
> wal_
Gurjeet Singh wrote:
> Hi All,
>
> I changed the postgresql.conf file (of an 8.2.4 server), and issued
> relaod using pg_reload_config(). Following are the messages I see in the log
> files:
>
> May 14 21:38:40 sfphotodb001 postgres[29658]: [19-1] 2008-05-14 21:38:40
> PDTLOG: received SIGHU
Marc Munro wrote:
-- Start of PGP signed section.
> The statement:
>
> revoke all on view internal.all_objects from public;
>
> yields a syntax error. The docs show that the word "view" is not
> acceptable in this statement which is fine but the surprising thing is
> that:
>
> ? revoke all o
Dave Page wrote:
> On Sun, May 18, 2008 at 1:38 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >
> > I don't know how you tested,
>
> Copy a large file across a relatively slow network, and check the size
> on the destination drive before it finishes.
>
> > but could you please repeat the test w
Andrew Dunstan wrote:
>
> I have just been working on setting up a continuous recovery failover
> system, and noticed some odd log lines, shown below. (Using 8.3).
>
> First note that our parsing of recovery.conf in xlog.c is pretty bad,
> and at least we need to document the quirks if it's not
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, my point was that there are three possible states of sync_bit and
>> your patch only accounted for transitions between two of 'em.
> Did this every get addressed? I don't see a commit for it.
I thought it got fixed here:
2008-05
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Right, but I still need the other part of the check, right? This one
> > still fails the same check as my patch, no? Because I assume the hole
> > you found there was that get_sync_bit() will return 0 for two different
> > sync metho
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Does this patch look like what you meant? It should split them apart,
>> and it also hides the undocumented levels, but still accept it (now that
>> we have the ability to hide GUC vars)
>
> Seems reasonable, although I'm still dissa
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Does this patch look like what you meant? It should split them apart,
> and it also hides the undocumented levels, but still accept it (now that
> we have the ability to hide GUC vars)
Seems reasonable, although I'm still dissatisfied with the handling
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Yeah: LOG level sorts differently in the two cases; it's fairly high
>>> priority for server log output and much lower for client output.
>
>> Ok, easy fix if we break them apart. Should we continue to accept
>> v
Bruce Momjian wrote:
> Also, about the format 'auto' idea that uses expanded display, I am
> thinking because expanded is a separate setting and not a format, I
> should just add a possible 'auto' value to the expanded format that
> could be triggered by either 'aligned' or 'wrapped' formats when t
Bryce Nesbitt wrote:
>
> Brendan Jurd wrote:
> > I really like the idea of wrapping, but after playing with the format
> > a bit myself, I have to agree with Tom that breaking in the middle of
> > words produces some very nasty output.
> >
> > If the format could be improved to only wrap on word b
Hi!
I saw that functions which use hash join, like as ExecHashGetBucketAndBatch
and ExecScanHashBucket, have bucket and batch concepts.
So, I would like to know the differences between bucket and batch.
I dont understand tables partitioning mechanism in hash join.
Thanks,
Ana Carolina
1. Respects ShortWord and MinWords
2. Uses hlCover instead of Cover
3. Does not store norm (or lexeme) for headline marking
4. Removes ts_rank.h
5. Earlier it was counting even NONWORDTOKEN in the headline. Now it
only counts the actual words and excludes spaces etc.
I have also changed NumFrag
"Tom Lane" <[EMAIL PROTECTED]> writes:
> After playing with it for a little bit, I'm not convinced that it buys
> enough performance win to be worth applying --- the restriction of cache
> lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive.
> (For example, sorts that involve to
On Mon, Jun 30, 2008 at 6:34 AM, Dean Rasheed <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> This is a small patch I posted a few months back, and then kinda forgot
> about / got distracted with other things.
>
> Is there any interest in this? If so I am willing to put more work into
> it, if people like i
David Fetter wrote:
> On Mon, Jun 30, 2008 at 01:50:26PM +0200, Magnus Hagander wrote:
>> David Fetter wrote:
> [gitosis]
>>> It *would* be good, if the author seemed even vaguely interested
>>> in packaging up so much as a tarball, but he is not. His attitude
>>> is (paraphrasing from conversatio
"David Fetter" <[EMAIL PROTECTED]> writes:
> Please explain your reasoning here. The project has taken nasty hits
> on its infrastructure already (pgfoundry) because the author of the
> software had a go-it-alone, I-know-best attitude that sooner than
> later forced us to fork. As a direct conse
Simon Riggs <[EMAIL PROTECTED]> writes:
> So there is no attempt to migrate the vxid lock queue onto the xid lock
> queue because it doesn't matter now/yet. That seems fragile, but as long
> as we know about it we're OK.
It never will matter, because vxids and xids are unrelated.
On Mon, Jun 30, 2008 at 12:57:03AM -0400, Tom Lane wrote:
>
> So is that a "golf club gun"?
Maybe a gun club?
A footclub?
A foot-gun that can create 18 holes (36 for professionals)?
Anyway, with recent USian legal rulings, I anticipate we'll have to
stop talking about feet-guns. People will c
On Mon, Jun 30, 2008 at 01:50:26PM +0200, Magnus Hagander wrote:
> David Fetter wrote:
[gitosis]
> > It *would* be good, if the author seemed even vaguely interested
> > in packaging up so much as a tarball, but he is not. His attitude
> > is (paraphrasing from conversations with him the past few
On 6/30/08, Dean Rasheed <[EMAIL PROTECTED]> wrote:
> This is a small patch I posted a few months back, and then kinda forgot
> about / got distracted with other things.
>
> Is there any interest in this? If so I am willing to put more work into
> it, if people like it or have suggested improve
Hello
I wish to ask, whether is somebody working on this TODO point:
---
GRANT/REVOKE
* Allow column-level privileges
* %Allow GRANT/REVOKE permissions to be applied to all schema
objects with one command
The proposed syntax is:
GRANT SELECT ON ALL
Hi,
This is a small patch I posted a few months back, and then kinda forgot
about / got distracted with other things.
Is there any interest in this? If so I am willing to put more work into
it, if people like it or have suggested improvements. Otherwise I'll let it
drop.
Here's what is does:
A
David Fetter wrote:
> On Tue, Jun 24, 2008 at 10:27:28PM +0200, Magnus Hagander wrote:
>> Now, if you can give us a step-by-step on how to set it up, that
>> would certainly help ;-)
> Gitosis does not, as far as I can tell, have that delegation
> capability, but I've come up with a
At 2008-06-30 13:17:42 +0200, [EMAIL PROTECTED] wrote:
>
> It seems that the most efficient way to communicate with the
> DB would be through PQexecParams(), which avoids the whole
> bytea-encoding issues.
Yes.
> Does it become $10 or ${10} or $(10) or is it simply not possible
> te reference
I'm looking at the most efficient and lean way to interface with the
DB in a least-overhead scenario to process large(r) amounts of binary
data.
For simplicity, I want to avoid using the Large-Object facility.
It seems that the most efficient way to communicate with the DB would
be through PQexec
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I'm not sure I have enough time to get all that done for 8.4, it's looking bad
> at the moment, so help would be much appreciated. If you don't agree with
> taking the visibility map approach, I would suggest working on the indexam API
> changes f
Hi,
I am trying to build a new installer application.
I am in the process of upgrading postgresql 8.1 to 8.3.3 but i am having
a issue which i can't seemed to resolve.
Error output from rpmbuilder
+ su -c - user'$RPM_BUILD_ROOT/usr/local/app/pgsql/bin/postmaster -D
$RPM_BUILD_ROOT/usr/local/
Tom Lane wrote:
So put forward a worked-out proposal for some other behavior.
OK
My first thought is that the -c and -C options create a lot of the
issues in this area. -c in particular is evidently meant for merging a
dump into a database that already contains unrelated objects. (In fact
Karl Schnaitter wrote:
The main difference between (1) & (4) is that (1) will sometimes require
heap lookups and (4) never will. Moreover, the heap lookups in (1) will
be difficult for the optimizer to estimate, unless some special
statistics can be maintained for this purpose.
Yeah, we certa
42 matches
Mail list logo
