Peter,
finally I had a chance to check it out. One word: perfect!
Thanks
Paul
On 25-feb-2008, at 19:09, Peter Eisentraut wrote:
Am Mittwoch, 6. Februar 2008 schrieb Paul van den Bogaard:
I was hoping someone in the community already has a makefile that
"just" creates object files from C-sour
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> wrote:
> I think the creation of minimal_tuple in the middle is a overhead which can
> be avoided by creating a mem-map and directly creating the minimal_tuple in
> the mem-map.
Many implementations of mem-map disallow to extend the sizes.
Do you h
Bruce, you seem to have removed one of my three patches from the queue. I
would actually prefer you remove the other two and put back that one. It's the
one I most urgently need feedback on to continue.
The patch I'm so interested in receiving feedback on is the patch to preread
pages in bitmap i
On Fri, 2008-03-28 at 00:54 -0400, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > ... That was a small change in a utility that should never be run on a
> > production system. You're trying to get a change made to the code path
> > people rely on for their *backups*. Good luck wit
On Fri, 2008-03-28 at 09:08 +, Gregory Stark wrote:
> A more invasive form of this patch would be to assign and pin a buffer when
> the preread is done. That would men subsequently we would have a pinned buffer
> ready to go and not need to go back to the buffer manager a second time. We
> wou
Hi Alex,
On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 5:14 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> > * Add logic to disallow ADD CONSTRAINT ONLY to parent of an inheritance
> > hierarchy
> >
> > * Add logic to mark inherited constraints in t
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
You mentioned in an earlier mail that the information exposed was
inadequate. Could you sketch out what information would really be
needed and where to find it?
The main problem with what you suggest is that it'll fail utterly
on join q
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2008-03-28 at 09:08 +, Gregory Stark wrote:
>
>> A more invasive form of this patch would be to assign and pin a buffer when
>> the preread is done. That would men subsequently we would have a pinned
>> buffer
>> ready to go and not need to
On Fri, 2008-03-28 at 11:26 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> For heaven's sake. I've been posting about this for months.
Any chance of getting all that together on a single Wiki page, so we can
review everything? We'll need those docs after its committed
NikhilS escribió:
> P.S Alvaro, I think this patch did not reach the mailing list and was
> stalled due to size restrictions or something.
Argh, you are right. We don't have this on the archives anywhere :-(
Probably it got stuck on Maia ...
--
Alvaro Herrerahtt
NikhilS escribió:
> P.S Alvaro, I think this patch did not reach the mailing list and was
> stalled due to size restrictions or something.
OK, it's archived now:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00392.php
Thanks.
--
Alvaro Herrerahttp://www
Tom Lane wrote:
> What I'm envisioning is that we lose the notion of "this is a
> serializable snapshot" that that function currently has, and just
> give it the rule "if MyProc->xmin is currently zero, then set it".
> Then the only additional mechanism needed is for the snapshot
> manager to dete
Gregory Stark wrote:
I described which interfaces worked on Linux and Solaris based on empirical
tests. I posted source code for synthetic benchmarks so we could test it on a
wide range of hardware. I posted graphs based on empirical results. I posted
mathematical formulas analysing just how much
On Fri, 2008-03-28 at 10:35 -0300, Alvaro Herrera wrote:
> The problem is that we always consider every transaction's PGPROC->xid
> in calculating MyProc->xmin. So if you have a long running
> transaction, it doesn't matter how far beyond the snapshots are -- the
> value returned by GetOldestXmin
Simon Riggs wrote:
> On Fri, 2008-03-28 at 10:35 -0300, Alvaro Herrera wrote:
>
> > The problem is that we always consider every transaction's PGPROC->xid
> > in calculating MyProc->xmin. So if you have a long running
> > transaction, it doesn't matter how far beyond the snapshots are -- the
> >
* Brendan Jurd <[EMAIL PROTECTED]> [080327 16:36]:
> Ah, the old "post-maintenance-disabled-cron" gaff. One of my personal
> favourites. =)
>
> I'm not sure that the git repos has fully recovered. There seems to a
> block of commits missing, between 2008-03-25 13:09 and 2008-03-27
> 17:24 UTC.
On Fri, 2008-03-28 at 11:26 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Fri, 2008-03-28 at 10:35 -0300, Alvaro Herrera wrote:
> >
> > > The problem is that we always consider every transaction's PGPROC->xid
> > > in calculating MyProc->xmin. So if you have a long running
> > > transa
Hello,
I have a custom code in postgres which runs properly in some occasions and
segfaults some times. The trace is as below :
Program received signal SIGSEGV, Segmentation fault.
0x081ae8c4 in LWLockRelease (lockid=664)
at ../../../../src/include/storage/s_lock.h:128
128 __asm_
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> As far as I can see, for the purposes of VACUUM we can remove any tuple
> that was deleted after the old transaction's Xid but before that
> transaction's Xmin (i.e. all of its live snapshots). This means we get
> to ignore Xid in GetOldestXmin and in t
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > As far as I can see, for the purposes of VACUUM we can remove any tuple
> > that was deleted after the old transaction's Xid but before that
> > transaction's Xmin (i.e. all of its live snapshots). This means we get
> > to ignore Xid
Suresh <[EMAIL PROTECTED]> writes:
> I have a custom code in postgres which runs properly in some occasions and
> segfaults some times. The trace is as below :
The traceback you show appears to lead through code that doesn't exist
in any public version of Postgres. So I think it's your own bug t
On Fri, Mar 28, 2008 at 4:07 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
>
> On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> > Attached is a WIP patch I have been playing with in my spare time. It
> > should take care of the first 2. It does nothing for pg_dump
Heikki wrote:
> It seems that the worst case for this patch is a scan on a table that
> doesn't fit in shared_buffers, but is fully cached in the OS cache. In
> that case, the posix_fadvise calls would be a certain waste of time.
I think this is a misunderstanding, the fadvise is not issued to
On 29/03/2008, Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> * Brendan Jurd <[EMAIL PROTECTED]> [080327 16:36]:
> >
> > Looking at the CVS logs, there was definitely commit action in that
> > timeframe, but none of it is showing up on the git shortlog.
>
> OK, so it should all be valid again.
>
Lo
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
As far as I can see, for the purposes of VACUUM we can remove any tuple
that was deleted after the old transaction's Xid but before that
transaction's Xmin (i.e. all of its live snapshots). This means we get
to ig
Zeugswetter Andreas OSB SD wrote:
Heikki wrote:
It seems that the worst case for this patch is a scan on a table that
doesn't fit in shared_buffers, but is fully cached in the OS cache. In
that case, the posix_fadvise calls would be a certain waste of time.
I think this is a misunderstandin
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
As far as I can see, for the purposes of VACUUM we can remove any tuple
that was deleted after the old transaction's Xid but before that
transaction's Xmin (i.e. all of
Heikki Linnakangas wrote:
> > So it has nothing to do with table size. The fadvise calls need to be
> > (and are)
> > limited by what can be used in the near future, and not for the whole
> > statement.
>
> Right, I was sloppy. Instead of table size, what matters is the amount
> of data the scan
It seems I've found the cause and the workaround of the problem.
MSVC's stat() is implemented by using FindNextFile().
MSDN contains the following suspicious paragraph аbout FindNextFile():
"In rare cases, file attribute information on NTFS file systems may not be
current at the time you call th
Gregory Stark wrote:
>
> Bruce, you seem to have removed one of my three patches from the queue. I
> would actually prefer you remove the other two and put back that one. It's the
> one I most urgently need feedback on to continue.
I talked to Greg on IM. The complaint was that his posix_fadvise
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Right, I was sloppy. Instead of table size, what matters is the amount of data
> the scan needs to access. The point remains that if the data is already in OS
> cache, the posix_fadvise calls are a waste of time, regardless of how many
> pages ahe
On Fri, Mar 28, 2008 at 11:41:58AM -0400, Bruce Momjian wrote:
> Should we consider only telling the kernel X pages ahead, meaning when
> we are on page 10 we tell it about page 16?
It's not so interesting for sequential reads, the kernel can work that
out for itself. Disk reads are usually in blo
Bruce Momjian wrote:
Heikki Linnakangas wrote:
So it has nothing to do with table size. The fadvise calls need to be
(and are)
limited by what can be used in the near future, and not for the whole
statement.
Right, I was sloppy. Instead of table size, what matters is the amount
of data the sc
We are not alone ;-)
http://sourceforge.net/project/shownotes.php?group_id=129038&release_id=557649
Version 1.02
2007-01-25
* Fix the stat function (on Windows) to use GetFileAttributesEx insead of
FindFirstFile
-Original Message-
From: Zubkovsky, Sergey
Sent: Friday, March 28,
On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> There are no textout/textin calls left, but I may have missed some
> places that were doing it the hard way with direct palloc/memcpy
> manipulations. It might be worth trolling all the VARDATA() references
> to see if any more are easily re
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
As far as I can see, for the purposes of VACUUM we can remove any tuple
that was deleted after the old transaction's Xid but before that
transaction's Xmin (i.e. al
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Added to TODO:
>
> * Allow one transaction to see tuples using the snapshot of another
> transaction
>
> This would assist multiple backends in working together.
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php
FYI, code for this
Heikki Linnakangas wrote:
> > Should we consider only telling the kernel X pages ahead, meaning when
> > we are on page 10 we tell it about page 16?
>
> Yes. You don't want to fire off thousands of posix_fadvise calls
> upfront. That'll just flood the kernel, and it will most likely ignore
> any
When I try run psql with a option on HEAD I get following message:
-bash-3.2$ /var/tmp/pg84_upg/bin/psql template1 -t
psql: FATAL: role "-t" does not exist
when I change a order to
var/tmp/pg84_upg/bin/psql -t template1
then everything is OK.
Does it intention or it is a bug? Current behavio
Neil Conway wrote:
> On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:
> > As suggested in the TODO list (and as I need the functionality
> > myself), I have implemented the current_query interface to
> > debug_query_string.
It actually has been removed from the TODO list since you saw it
Someone wrote:
>>>
>>> Should we consider only telling the kernel X pages ahead, meaning when
>>> we are on page 10 we tell it about page 16?
The patch I posted specifically handles bitmap heap scans. It does in fact
prefetch only a limited number of pages from the bitmap stream based on a guc,
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>>
>> Bruce, you seem to have removed one of my three patches from the queue. I
>> would actually prefer you remove the other two and put back that one. It's
>> the
>> one I most urgently need feedback on to continue.
>
> I talk
On 28 Mar 2008, at 17:23, Bruce Momjian wrote:
Neil Conway wrote:
On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:
As suggested in the TODO list (and as I need the functionality
myself), I have implemented the current_query interface to
debug_query_string.
It actually has been removed f
Tomas Doran wrote:
> On 28 Mar 2008, at 17:23, Bruce Momjian wrote:
>> Perhaps we could name it received_query() to indicate it is what the
>> backend received and it not necessarily the _current_ query.
>
> reveived_query() sounds like a very sane name for me, and documenting it
> as such would
Alvaro Herrera wrote:
> Tomas Doran wrote:
>
> > On 28 Mar 2008, at 17:23, Bruce Momjian wrote:
>
> >> Perhaps we could name it received_query() to indicate it is what the
> >> backend received and it not necessarily the _current_ query.
> >
> > reveived_query() sounds like a very sane name for m
Gregory Stark wrote:
I want to know if we're interested in the more invasive patch restructuring
the buffer manager. My feeling is that we probably are eventually. But I
wonder if people wouldn't feel more comfortable taking baby steps at first
which will have less impact in cases where it's not
On Fri, Mar 28, 2008 at 05:34:30PM +, Gregory Stark wrote:
> But what I really need is someone to read the patch and say "looks good" or
> point out things they don't like. In particular, what I really, really want is
> some guidance on the singular key question I asked.
I was going to write a
On Fri, 2008-03-28 at 11:33 -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Added to TODO:
> >
> > * Allow one transaction to see tuples using the snapshot of another
> > transaction
> >
> > This would assist multiple backends in working together.
> > http://archive
On Fri, 2008-03-28 at 14:32 -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Tomas Doran wrote:
> >
> > > On 28 Mar 2008, at 17:23, Bruce Momjian wrote:
> >
> > >> Perhaps we could name it received_query() to indicate it is what the
> > >> backend received and it not necessarily the _curre
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There are no textout/textin calls left, but I may have missed some
>> places that were doing it the hard way with direct palloc/memcpy
>> manipulations. It might be worth trolling all the VARDATA() r
On 29/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> I intentionally didn't touch xml.c, nor anyplace that is not dealing
> in text, even if it happens to be binary-compatible with text.
>
Hmm, okay. My original submission did include a few such changes; for
example, in xml_in and xml_out_intern
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> When I try run psql with a option on HEAD I get following message:
> -bash-3.2$ /var/tmp/pg84_upg/bin/psql template1 -t
> psql: FATAL: role "-t" does not exist
That has never been considered supported. Some versions of getopt,
on some platforms, will r
Simon Riggs wrote:
> On Fri, 2008-03-28 at 14:32 -0400, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Tomas Doran wrote:
> > >
> > > > On 28 Mar 2008, at 17:23, Bruce Momjian wrote:
> > >
> > > >> Perhaps we could name it received_query() to indicate it is what the
> > > >> backend receive
I just realized that the patch I applied here
http://archives.postgresql.org/pgsql-committers/2008-03/msg00531.php
for Taiki Yamaguchi's bug report here
http://archives.postgresql.org/pgsql-bugs/2008-03/msg00275.php
really doesn't work. It assumes that an ungrouped aggregate
query can't return mor
I wrote:
> Plan B was to try to revert to the way sort clause matching was
> done pre-8.3, that is have make_sort_from_pathkeys check first
> for a matching ressortgroupref tag before it goes looking for equal()
> expressions. I had actually tried to do that first but got hung
> up on the problem
On Sat, Mar 29, 2008 at 3:21 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I just realized that the patch I applied here
> http://archives.postgresql.org/pgsql-committers/2008-03/msg00531.php
> for Taiki Yamaguchi's bug report here
> http://archives.postgresql.org/pgsql-bugs/2008-03/msg00275.php
> rea
56 matches
Mail list logo
