On Thu, Dec 2, 2010 at 20:00, Dimitri Fontaine wrote:
> Please find attached the v8 version of the patch, that fixes the following:
I fixed and cleanup some of codes in it; v9 patch attached. Please check
my modifications, and set the status to "Ready to Committer" if you find
no problems. I thin
On 03.12.2010 04:54, Tom Lane wrote:
Robert Haas writes:
I then got to wondering whether we should even go a step further, and
simply decree that a page with only hint bit updates is not dirty and
won't be written, period.
This sort of thing has been discussed before. It seems fairly clear t
On Thu, Dec 2, 2010 at 9:33 PM, Tom Lane wrote:
> In particular, this issue *has* been discussed before, and there was a
> consensus that preserving dump consistency was a requirement. I don't
> think that Joachim gets to bypass that decision just by submitting a
> patch that ignores it.
I am no
On Fri, Dec 3, 2010 at 13:28, Jaime Casanova wrote:
> On Thu, Dec 2, 2010 at 10:57 PM, Tom Lane wrote:
> [...]
>> My answer is "no,
>> and I'm not sure those things should be there in the first place".
>
> i agree. after all the committers give the appropiate credit in the
> commit message so if
On Thu, Dec 2, 2010 at 10:57 PM, Tom Lane wrote:
[...]
> My answer is "no,
> and I'm not sure those things should be there in the first place".
>
i agree. after all the committers give the appropiate credit in the
commit message so if we want history it's there
--
Jaime Casanova www.2nd
Alvaro Herrera writes:
> Excerpts from Bruce Momjian's message of vie dic 03 00:15:28 -0300 2010:
>> When someone writes a file from scratch, we usually keep their name on
>> it so we remember the original author.
> The reason Takahiro-san is asking the question is because one of
> Dimitri's patc
On 12/02/2010 10:15 PM, Bruce Momjian wrote:
Itagaki Takahiro wrote:
I found there are some author names in some of source files.
Will we keep their names? And, will we add new author names
who wrote patches for those files?
src/backend/postmaster/syslogger.c(15) : * Author: Andreas Pflug
sr
Excerpts from Andy Colson's message of vie dic 03 00:37:17 -0300 2010:
> Ok, forget the time thing. Has nothing to do with it. (Which everyone
> already assumed I imagine).
>
> Its truncate.
>
> Create unloged table, fill it, truncate it, fill it again, restart pg, and
> the data will still
Excerpts from Bruce Momjian's message of vie dic 03 00:15:28 -0300 2010:
> Itagaki Takahiro wrote:
> > I found there are some author names in some of source files.
> > Will we keep their names? And, will we add new author names
> > who wrote patches for those files?
> >
> > src/backend/postmaster/
2nd) I can get the data to stick around after restart. Though not reliably. In
general:
create and fill a table, vacuum it (not sure if its important, I do it because
thats what I'd done in my pgbench testing where I noticed the data stuck
around), wait an hour (I usually left it for 12-24 h
Itagaki Takahiro wrote:
> I found there are some author names in some of source files.
> Will we keep their names? And, will we add new author names
> who wrote patches for those files?
>
> src/backend/postmaster/syslogger.c(15) : * Author: Andreas Pflug
> src/backend/utils/adt/genfile.c(9)
On 12/02/2010 09:41 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/02/2010 09:09 PM, Tom Lane wrote:
Now, process 3 is blocked behind process 2 is blocked behind process 1
which is waiting for 3 to complete. Can you say "undetectable deadlock"?
Hmm. Yeah. Maybe we could get around it if
Robert Haas writes:
> I then got to wondering whether we should even go a step further, and
> simply decree that a page with only hint bit updates is not dirty and
> won't be written, period.
This sort of thing has been discussed before. It seems fairly clear to
me that any of these variations r
Andrew Dunstan writes:
> On 12/02/2010 09:09 PM, Tom Lane wrote:
>> Now, process 3 is blocked behind process 2 is blocked behind process 1
>> which is waiting for 3 to complete. Can you say "undetectable deadlock"?
> Hmm. Yeah. Maybe we could get around it if we prefork the workers and
> they a
Andrew Dunstan writes:
> Umm, nobody has attributed ridiculousness to anyone. Please don't put
> words in my mouth. But I think this is a perfectly reasonable discussion
> to have. Nobody gets to come along and get the features they want
> without some sort of consensus, not me, not you, not Jo
On 12/02/2010 09:09 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/02/2010 05:32 PM, Tom Lane wrote:
(I'm not actually convinced that snapshot cloning is the only problem
here; locking could be an issue too, if there are concurrent processes
trying to take locks that will conflict with pg_
Andrew Dunstan writes:
> On 12/02/2010 05:32 PM, Tom Lane wrote:
>> (I'm not actually convinced that snapshot cloning is the only problem
>> here; locking could be an issue too, if there are concurrent processes
>> trying to take locks that will conflict with pg_dump's. But the
>> snapshot issue
On Dec 2, 2010, at 8:11 PM, Andrew Dunstan wrote:
> Umm, nobody has attributed ridiculousness to anyone. Please don't put words
> in my mouth. But I think this is a perfectly reasonable discussion to have.
> Nobody gets to come along and get the features they want without some sort of
> consens
On Thu, Dec 2, 2010 at 12:16 AM, Euler Taveira de Oliveira
wrote:
> As you said, there are platforms that a signal doesn't wake up a
> process, so I suggest (ii) but I'm fine to include (i) at docs too.
Can we use "pg_ctl kill" to send signal on such platforms?
Regards,
--
Fujii Masao
NIPPON T
I found there are some author names in some of source files.
Will we keep their names? And, will we add new author names
who wrote patches for those files?
src/backend/postmaster/syslogger.c(15) : * Author: Andreas Pflug
src/backend/utils/adt/genfile.c(9) : * Author: Andreas Pflug
src/backen
On Tue, Nov 30, 2010 at 12:15 PM, Jeff Janes wrote:
> On Tue, Nov 30, 2010 at 8:38 AM, Greg Smith wrote:
>
>
> Hi Greg,
>
> Thanks for the update.
>
>
>
>> This might be ready for some proper review now. I know there's at least one
>> blatant bug still in here I haven't found yet, related to how
On 12/02/2010 07:48 PM, Robert Haas wrote:
On Thu, Dec 2, 2010 at 7:21 PM, Andrew Dunstan wrote:
In the past, proposals for this have always been rejected on the
grounds
that it's impossible to assure a consistent dump if different
connections are used to read different tables. I fail to und
On Thu, Dec 2, 2010 at 7:21 PM, Andrew Dunstan wrote:
> In the past, proposals for this have always been rejected on the
> grounds
> that it's impossible to assure a consistent dump if different
> connections are used to read different tables. I fail to understand
> why that c
On Thu, 2010-12-02 at 19:06 -0500, Robert Haas wrote:
> I don't think that you can seriously suggest that emitting that volume
> of FPIs isn't going to be a problem immediately. We have to have some
> solution to that problem out of the gate.
Fair enough. I think you understand my point, and it's
On Thu, Dec 2, 2010 at 7:19 PM, Josh Berkus wrote:
> On 12/2/10 4:00 PM, Robert Haas wrote:
>> As soon as all tuples on the page are all-visible, VACUUM will freeze
>> every tuple on the page (setting a HEAP_XMIN_FROZEN bit rather than
>> actually overwriting XMIN, to preserve forensic information
Robert Haas wrote:
> On Thu, Dec 2, 2010 at 7:12 PM, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> On tis, 2010-11-30 at 14:20 -0500, Andrew Dunstan wrote:
> >> > I agree, that argument is completely misconceived. If the DBA is
> >> > paying enough attention to use LIMIT, s/he should be pa
On 12/02/2010 07:13 PM, Robert Haas wrote:
On Thu, Dec 2, 2010 at 5:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/02/2010 05:01 PM, Tom Lane wrote:
In the past, proposals for this have always been rejected on the grounds
that it's impossible to assure a consistent dump if different
c
On 12/2/10 4:00 PM, Robert Haas wrote:
> As soon as all tuples on the page are all-visible, VACUUM will freeze
> every tuple on the page (setting a HEAP_XMIN_FROZEN bit rather than
> actually overwriting XMIN, to preserve forensic information) and mark
> it all-visible in a single WAL-logged operat
Excerpts from Robert Haas's message of jue dic 02 21:10:48 -0300 2010:
> On Thu, Dec 2, 2010 at 3:43 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of jue dic 02 17:27:01 -0300 2010:
> > Yeah, the Oracle system is a lot more complex than SQL Server's, but I
> > was only talki
On Thu, Dec 2, 2010 at 7:12 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On tis, 2010-11-30 at 14:20 -0500, Andrew Dunstan wrote:
>> > I agree, that argument is completely misconceived. If the DBA is
>> > paying enough attention to use LIMIT, s/he should be paying enough
>> > attention no
On Thu, Dec 2, 2010 at 5:32 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 12/02/2010 05:01 PM, Tom Lane wrote:
>>> In the past, proposals for this have always been rejected on the grounds
>>> that it's impossible to assure a consistent dump if different
>>> connections are used to read diffe
Peter Eisentraut wrote:
> On tis, 2010-11-30 at 14:20 -0500, Andrew Dunstan wrote:
> > I agree, that argument is completely misconceived. If the DBA is
> > paying enough attention to use LIMIT, s/he should be paying enough
> > attention not to do damage in the first place. If that were the only
> >
On Thu, Dec 2, 2010 at 2:24 PM, Greg Stark wrote:
> On Wed, Dec 1, 2010 at 4:25 AM, Greg Smith wrote:
>>> I ask because I don't have a mental model of how the pause can help.
>>> Given that this dirty data has been hanging around for many minutes
>>> already, what is a 3 second pause going to hea
On Thu, Dec 2, 2010 at 3:43 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue dic 02 17:27:01 -0300 2010:
>> On Wed, Dec 1, 2010 at 3:55 PM, Alvaro Herrera
>> wrote:
>> > Excerpts from Josh Berkus's message of mié dic 01 17:13:35 -0300 2010:
>> >>
>> >> > Well, porting applic
On Thu, Dec 2, 2010 at 6:37 PM, Jeff Davis wrote:
>> It seems to me that a COPY command executed in a transaction with no
>> other open snapshots writing to a table created or truncated within
>> the same transaction should be able to write frozen tuples from the
>> get-go, regardless of anything
In a sleepy email late last night on the crash-safe visibility map
thread, I proposed introducing a new buffer state BM_UNTIDY. When a
page is dirtied by a hint bit update, we mark it untidy but not dirty.
Untidy buffers would be treated as dirty by the background writer
cleaning scan, but as cle
Andrew Dunstan wrote:
>
>
> On 11/30/2010 11:17 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On 11/30/2010 10:09 PM, Tom Lane wrote:
> >>> We should wait for the outcome of the discussion about whether to change
> >>> the default wal_sync_method before worrying about this.
> >> we've just
On 12/02/2010 05:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/02/2010 05:01 PM, Tom Lane wrote:
In the past, proposals for this have always been rejected on the grounds
that it's impossible to assure a consistent dump if different
connections are used to read different tables. I fail
On Thu, 2010-12-02 at 17:00 -0500, Robert Haas wrote:
> I'm not really convinced that this problem is confined to bulk
> loading. Every INSERT or UPDATE results in a new tuple that may need
> hit bits set and eventually to be frozen. A bulk load is just a time
> when you do lots of inserts all at
Dimitri Fontaine wrote:
> Heikki Linnakangas writes:
> > I don't see the point of the sort-by-relpages code. The order the objects
> > are dumped should be irrelevant, as long as you obey the restrictions
> > dictated by dependencies. Or is it only needed for the multiple-target-dirs
> > feature?
Andrew Dunstan writes:
> On 12/02/2010 05:01 PM, Tom Lane wrote:
>> In the past, proposals for this have always been rejected on the grounds
>> that it's impossible to assure a consistent dump if different
>> connections are used to read different tables. I fail to understand
>> why that consider
On 12/02/2010 05:01 PM, Tom Lane wrote:
Heikki Linnakangas writes:
That's a big patch..
Not nearly big enough :-(
In the past, proposals for this have always been rejected on the grounds
that it's impossible to assure a consistent dump if different
connections are used to read different tab
Heikki Linnakangas writes:
> That's a big patch..
Not nearly big enough :-(
In the past, proposals for this have always been rejected on the grounds
that it's impossible to assure a consistent dump if different
connections are used to read different tables. I fail to understand
why that conside
On Thu, Dec 2, 2010 at 2:01 PM, Jeff Davis wrote:
> * We don't get an exclusive lock when dirtying a page with hint bits
> - Why: we write while reading, and we want good concurrency.
> - Why': because after a bulk load, we don't have any hint bits, and the
> only way to get them set without VACUU
On Thursday 02 December 2010 22:21:37 Alvaro Herrera wrote:
> Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
> > Ill set this up for the next commitfest, I don't think I can do much
> > more without further input.
>
> Are you reserving about 20 bits for levels, and 12 fo
Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
> Ill set this up for the next commitfest, I don't think I can do much more
> without further input.
Are you reserving about 20 bits for levels, and 12 for flags? Given the
relatively scarce growth of levels, I think we co
Excerpts from Heikki Linnakangas's message of jue dic 02 16:52:27 -0300 2010:
> Ok, committed, with some small cleanup since the last patch I posted.
I think the comments on _ReadBuf and friends need to be updated, since
they are not just for headers and TOC stuff anymore. I'm not sure if
they we
Andres Freund wrote:
> On Thursday 02 December 2010 00:48:53 Kevin Grittner wrote:
>> Is there any provision for one backend to cause a *different*
>> backend which is idle in a transaction to terminate cleanly when
>> it attempts to process its next statement?
> You might want to check out Sen
Excerpts from Robert Haas's message of jue dic 02 17:27:01 -0300 2010:
> On Wed, Dec 1, 2010 at 3:55 PM, Alvaro Herrera
> wrote:
> > Excerpts from Josh Berkus's message of mié dic 01 17:13:35 -0300 2010:
> >>
> >> > Well, porting applications from other database systems that support
> >> > synony
On Wed, Dec 1, 2010 at 3:55 PM, Alvaro Herrera
wrote:
> Excerpts from Josh Berkus's message of mié dic 01 17:13:35 -0300 2010:
>>
>> > Well, porting applications from other database systems that support
>> > synonyms
>> > (i.e. Oracle, DB2, SQL Server).
>>
>> SQL Server supports synonyms? If it'
Ok, committed, with some small cleanup since the last patch I posted.
Could you update the directory-format patch on top of the committed
version, please?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> Using sync_file_range you can specify the set of blocks to sync and
> then block on them only after some time has passed. But there's no
> documentation on how this relates to the I/O scheduler so it's not
> clear it would have any effect on the problem. We might still have to
> delay the begini
On Wed, Dec 1, 2010 at 4:25 AM, Greg Smith wrote:
>> I ask because I don't have a mental model of how the pause can help.
>> Given that this dirty data has been hanging around for many minutes
>> already, what is a 3 second pause going to heal?
>>
>
> The difference is that once an fsync call is m
Jeff Davis wrote:
> And, if we had a bulk loading path, we could probably get away
> with writing the data only twice (today, we write it 3 times
> including the hint bits) or maybe once if WAL archiving is off.
If you're counting WAL writes, you're low. If you don't go out of
your way to avo
On Thu, Dec 2, 2010 at 12:56 PM, Josh Berkus wrote:
> Now, if only I could think of some way to write a parallel dump to a set of
> pipes, I'd be in heaven.
What exactly are you trying to accomplish with the pipes?
Joachim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Wed, 2010-12-01 at 23:22 -0500, Robert Haas wrote:
> Well, let's think about what we'd need to do to make CRCs work
> reliably. There are two problems.
>
> 1. [...] If we CRC the entire page, the torn pages are never
> acceptable, so every action that modifies the page must be WAL-logged.
>
Andres Freund wrote:
> Do you wan't to terminate it immediately or on next statement?
I want to have one backend terminate the transaction on another
backend as soon as practicable. If a query is active, it would be
best if it was canceled. It appears that if it is "idle in
transaction" ther
>> Now, if only I could think of some way to write a parallel dump to a
>> set of pipes, I'd be in heaven.
>
> The only way I can see that working sanely would be to have a program
> gathering stuff at the other end of the pipes, and ensuring it was all
> coherent. That would be a huge growth in
On 12/02/2010 12:56 PM, Josh Berkus wrote:
On 12/02/2010 05:50 AM, Dimitri Fontaine wrote:
So the use case of parralel dump in a bunch or user given locations
would be to use different mount points (disk subsystems) at the same
time. Not sure how releveant it is.
I think it will complicate
On 12/02/2010 12:44 PM, Kevin Grittner wrote:
wrote:
If possible can you provide glimpses of History.
http://en.wikipedia.org/wiki/Navigational_database
http://en.wikipedia.org/wiki/MARK_IV_%28software%29
I don't want to go back there, myself. YMMV.
Me either. BTDTGTTS. :-)
cheers
On 12/02/2010 05:50 AM, Dimitri Fontaine wrote:
So the use case of parralel dump in a bunch or user given locations
would be to use different mount points (disk subsystems) at the same
time. Not sure how releveant it is.
I think it will complicate this feature unnecessarily for 9.1.
Personall
wrote:
> If possible can you provide glimpses of History.
http://en.wikipedia.org/wiki/Navigational_database
http://en.wikipedia.org/wiki/MARK_IV_%28software%29
I don't want to go back there, myself. YMMV.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Hitoshi,
I've written twitter_fdw, which makes "twitter" table to get twitter
search result by SELECT statement. This is done against WIP SQL/MED
version PostgreSQL (git sha-1 is
c5e027c32b8faf0e2d25b8deecb4d3c05399411c). To play with it, make&&
make install, run the install script as you usuall
On Thursday 02 December 2010 00:48:53 Kevin Grittner wrote:
> Andres Freund wrote:
> > On Tuesday 19 October 2010 16:18:29 Kevin Grittner wrote:
> >> For SSI purposes, it would be highly desirable to be able to set
> >> the SQLSTATE and message generated when the canceled transaction
> >> terminat
On Thu, Dec 2, 2010 at 6:37 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> Or maybe I do. One other thing I've been thinking about with regard
>> to hint bit updates is that we might choose to mark that are
>> hint-bit-updated as "untidy" rather than "dirty". The background
>
> Please rev
Andres Freund wrote:
> On Tuesday 19 October 2010 16:18:29 Kevin Grittner wrote:
>> For SSI purposes, it would be highly desirable to be able to set
>> the SQLSTATE and message generated when the canceled transaction
>> terminates.
> Ok, I implemented that capability, but the patch feels somew
On 2010-12-02 01:18, Jim Nasby wrote:
On Dec 1, 2010, at 8:07 AM, Yeb Havinga wrote:
FK's cannot refer to rows in inheritance childs.
We have partially solved this issue at work. In our scenario, we're not using inheritance for
partitioning, we're using it for, well, inheriting. As part of tha
Excerpts from Tom Lane's message of mié dic 01 14:44:03 -0300 2010:
> Florian Pflug writes:
> > On Dec1, 2010, at 17:17 , Tom Lane wrote:
> >> There's not enough space in the infomask to record which columns (or
> >> which unique index) are involved. And if you're talking about data that
> >> cou
Joachim Wieland writes:
> A guy called Dimitri Fontaine actually proposed the
> serveral-directories feature here and other people liked the idea.
Hehe :)
Reading that now, it could be that I didn't know at the time that given
a powerful enough subsystem disk there's no way to saturate it with o
Excerpts from Jeff Davis's message of mié dic 01 22:48:36 -0300 2010:
> I can't see any place that "cachedFetchXid" is ever invalidated.
> Shouldn't it be invalidated before transaction ID wraparound?
>
> It's difficult to construct a test case to show whether this is a
> problem or not,
Couldn't
On 2010-12-01 16:58, Florian Pflug wrote:
On Dec1, 2010, at 15:27 , Tom Lane wrote:
Indeed. This isn't even worth the time to review, unless you have a
proposal for fixing the unique-index-across-multiple-tables problem.
I've wondered in the past if a unique index is really necessary on the c
On 12/02/2010 08:10 AM, Devrim GÜNDÜZ wrote:
IIRC we announced that we will EOL 8.1 in 2010 -- given that we are now
in December, will it be done soon?
(As a packager, I'll be happy to drop is ASAP, so that I can use those
VMs for new OSes).
EOL does not mean we simply drop the branch on t
Excerpts from Devrim GÜNDÜZ's message of jue dic 02 10:10:28 -0300 2010:
>
> IIRC we announced that we will EOL 8.1 in 2010 -- given that we are now
> in December, will it be done soon?
>
> (As a packager, I'll be happy to drop is ASAP, so that I can use those
> VMs for new OSes).
My guess is th
On Thu, Dec 2, 2010 at 6:19 AM, Heikki Linnakangas
wrote:
> I don't see the point of the sort-by-relpages code. The order the objects
> are dumped should be irrelevant, as long as you obey the restrictions
> dictated by dependencies. Or is it only needed for the multiple-target-dirs
> feature? Fra
2010/12/2 Devrim GÜNDÜZ :
>
> IIRC we announced that we will EOL 8.1 in 2010 -- given that we are now
> in December, will it be done soon?
>
> (As a packager, I'll be happy to drop is ASAP, so that I can use those
> VMs for new OSes).
We even said November 2010 - see
http://wiki.postgresql.org/wik
IIRC we announced that we will EOL 8.1 in 2010 -- given that we are now
in December, will it be done soon?
(As a packager, I'll be happy to drop is ASAP, so that I can use those
VMs for new OSes).
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL
Heikki Linnakangas writes:
> I don't see the point of the sort-by-relpages code. The order the objects
> are dumped should be irrelevant, as long as you obey the restrictions
> dictated by dependencies. Or is it only needed for the multiple-target-dirs
> feature? Frankly I don't see the point of t
Robert Haas writes:
> Or maybe I do. One other thing I've been thinking about with regard
> to hint bit updates is that we might choose to mark that are
> hint-bit-updated as "untidy" rather than "dirty". The background
Please review archives, you'll find the idea discussed and some patches
to
On 02.12.2010 13:25, Simon Riggs wrote:
On Thu, 2010-12-02 at 12:41 +0200, Heikki Linnakangas wrote:
On 02.12.2010 11:02, Simon Riggs wrote:
The cause of the issue is that replay starts at one LSN and there is a
delay until the RunningXacts WAL record occurs. If there was no delay,
there would
On Thu, 2010-12-02 at 12:41 +0200, Heikki Linnakangas wrote:
> On 02.12.2010 11:02, Simon Riggs wrote:
> > The cause of the issue is that replay starts at one LSN and there is a
> > delay until the RunningXacts WAL record occurs. If there was no delay,
> > there would be no issue at all. In CreateC
On 02.12.2010 07:39, Joachim Wieland wrote:
On Sun, Nov 14, 2010 at 6:52 PM, Joachim Wieland wrote:
You would add a regular parallel dump with
$ pg_dump -j 4 -Fd -f out.dir dbname
So this is an updated series of patches for my parallel pg_dump WIP
patch. Most importantly it now runs on Windo
Hi,
Please find attached the v8 version of the patch, that fixes the following:
Itagaki Takahiro writes:
> * pg_read_binary_file_internal() should return not only the contents
> as char * but also the length, because the file might contain 0x00.
> In addition, null-terminations for the conte
On 02.12.2010 11:02, Simon Riggs wrote:
The cause of the issue is that replay starts at one LSN and there is a
delay until the RunningXacts WAL record occurs. If there was no delay,
there would be no issue at all. In CreateCheckpoint() we start by
grabbing the WAInsertLock and later recording tha
On 2010-12-02 11:27, Yeb Havinga wrote:
With 'inheritance chain' I mean any set of more than one relation that
is the transitive closure of the inheritance parent and child relation
on a given relation.
s/transitive closure/transitive reflexive closure
--
Sent via pgsql-hackers mailing list
On 2010-12-01 16:05, Tom Lane wrote:
Perhaps I should have said "possibly workable proposal". What you wrote
doesn't even begin to cover the interesting part of the problem, namely
how to ensure uniqueness is preserved in the face of concurrent
insertions.
The usual page locking done by nbtree
Hey!1
I am able to change the switch over time.. Thanks alot..
2010/12/2 aaliya zarrin
> Ok.. Thanks I will try!!!
>
> 2010/12/2 Heikki Linnakangas
>
> Oh, and there's another value for the case we're polling the archive, not
>> streaming from master. Search for "5" in XLogPageRead funct
On Thu, 2010-12-02 at 10:39 +0200, Heikki Linnakangas wrote:
> On 01.12.2010 20:51, Heikki Linnakangas wrote:
> > Another approach would be to revisit the way the running-xacts snapshot
> > is taken. Currently, we first take a snapshot, and then WAL-log it.
> > There is a small window between the s
On 01.12.2010 20:51, Heikki Linnakangas wrote:
Another approach would be to revisit the way the running-xacts snapshot
is taken. Currently, we first take a snapshot, and then WAL-log it.
There is a small window between the steps where backends can begin/end
transactions, and recovery has to deal
On ons, 2010-12-01 at 21:27 -0800, Jeff Davis wrote:
> On Wed, 2010-12-01 at 22:16 -0500, Tom Lane wrote:
> > Jeff Davis writes:
> > > When I build HEAD using just "make -s install", everything works fine.
> > > But when I add "-j12", it appears to cause problems. This problem
> > > appeared very
I know world's population. Non of the person thinks alike and still many
peoples goal can be the same. Nothing is virgin in this world. If
someone thinks like that then it is a mistake. My aim is to prove that
Postgresql can be the great leader if we put natural intelligence in
database which is m
90 matches
Mail list logo
