With some time to spare, I thought I'd submit a quick-fix patch to the
issue I reported here:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00339.php
This should preclude optimizing away a deferred RI trigger if the
UPDATEd row (in the FK table) was inserted by "current" transact
Quick progress report:
On Thu, 2007-06-21 at 16:05 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Completed all of the agreed changes for TG:
All comments changed, plus some refactoring of code.
> Can we fix it to be a read test instead of a write test, that is, if
> we k
On Fri, 2007-07-13 at 14:00 -0500, Jim C. Nasby wrote:
> On Fri, Jul 13, 2007 at 07:11:54PM +0100, Simon Riggs wrote:
> > On Fri, 2007-07-13 at 12:38 -0500, Jim C. Nasby wrote:
> > > One question... can operations that shortcut the WAL by fsyncing direct
> > > to disk also use async commit? I suspe
On Fri, Jul 13, 2007 at 07:11:54PM +0100, Simon Riggs wrote:
> On Fri, 2007-07-13 at 12:38 -0500, Jim C. Nasby wrote:
> > One question... can operations that shortcut the WAL by fsyncing direct
> > to disk also use async commit? I suspect the answer is an implicit "no"
> > because the only examples
Michael Glaesemann wrote:
On Jul 13, 2007, at 8:31 , Heikki Linnakangas wrote:
Row-level fragmentation
---
If there's no LP_DELETEd tuples large enough to fit the new tuple in,
the row-level fragmentation is repaired in the hope that some of the
slots were actually big en
On Fri, 2007-07-13 at 12:38 -0500, Jim C. Nasby wrote:
> One question... can operations that shortcut the WAL by fsyncing direct
> to disk also use async commit? I suspect the answer is an implicit "no"
> because the only examples I can think of all involve DDL, but it's
> probably worth spelling t
One question... can operations that shortcut the WAL by fsyncing direct
to disk also use async commit? I suspect the answer is an implicit "no"
because the only examples I can think of all involve DDL, but it's
probably worth spelling that out...
--
Jim Nasby [
Heikki,
Thanks for providing this summary. As someone unfamiliar with the
domain (both HOT development specifically and tuple management in
general), I found it easy to follow.
On Jul 13, 2007, at 8:31 , Heikki Linnakangas wrote:
Pruning
---
To reclaim the index-visible (i.e. first)
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A much simpler approach would be to try to acquire the vacuum lock, and
compact the page the usual way, and fall back to a cold update if we
can't get the lock immedia
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> A much simpler approach would be to try to acquire the vacuum lock, and
>>> compact the page the usual way, and fall back to a cold update if we
>>> can't get the lock immediatel
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A much simpler approach would be to try to acquire the vacuum lock, and
compact the page the usual way, and fall back to a cold update if we
can't get the lock immediately.
Seems like that could work.
I just realized that there'
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> A much simpler approach would be to try to acquire the vacuum lock, and
> compact the page the usual way, and fall back to a cold update if we
> can't get the lock immediately.
Seems like that could work.
> I'm looking for ways to make the patch
Heikki Linnakangas wrote:
I have some suggestions which I'll post separately,
A significant chunk of the complexity and new code in the patch comes
from pruning hot chains and reusing the space for new updates. Because
we can't reclaim dead space in the page like a VACUUM does, without
holdi
On Fri, 2007-07-13 at 14:59 +0100, Simon Riggs wrote:
> On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote:
...A few more minor changes... thanks very much.
I'll wrap these into a final submission with the main patch.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---
On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote:
> I just read your patch in order to understand a little bit what will
> happen in the next release.
Thanks for the review. v2 attached.
> About the guc variable wal_writer_delay, you say at the end:
> "This parameter can only
> + be se
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I'm worried that we leave garbage entries in the stats. As you suggested,
> don't we need to remove unreferenced entries from stats periodically?
VACUUM does that already.
regards, tom lane
---(end of
Pavan Deolasee wrote:
Please see updated version of the patch. This includes further code
refactoring and bug fixes.
Thanks for the update, Pavan!
I've been looking at this patch in the last couple of weeks in detail. I
wrote a short summary of how it works (attached) to help reviewing it.
E
Doc patch only...
To aid with the understanding of the synchronous commit technique, I've
completed the docs prior to the completion of the final version of the
patch.
Any review comments, final doubts etc.., please say them now...
Applies cleanly to CVS HEAD, sgml make OK.
--
Simon Riggs
Hi Can anytone tell me how can i get the pgestraier test database
On 13/07/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
On Fri, Jul 13, 2007 at 09:29:59AM +0100, Simon Riggs wrote:
> On Thu, 2007-07-12 at 19:36 +, ISHIDA Akio wrote:
> > The following bug has been logged online:
> >
> > B
On Fri, Jul 13, 2007 at 09:29:59AM +0100, Simon Riggs wrote:
> On Thu, 2007-07-12 at 19:36 +, ISHIDA Akio wrote:
> > The following bug has been logged online:
> >
> > Bug reference: 3439
> > Operating system: Windows XP
> > Description:pg_standby and path name with space
> > Det
On Thu, 2007-07-12 at 19:36 +, ISHIDA Akio wrote:
> The following bug has been logged online:
>
> Bug reference: 3439
> Operating system: Windows XP
> Description:pg_standby and path name with space
> Details:
>
> pg_standby failed if path name containing spaces.
>
> C:\Docum
Tom Lane <[EMAIL PROTECTED]> wrote:
> > What I'm inclined to propose is that we just remove the
> > pgstat_drop_relation() call from smgr_internal_unlink
> On checking the CVS history, that in fact is how the code worked before
> 8.1.3, when I introduced the bogus call in a fit of over-optimizati
22 matches
Mail list logo
