On Jun 11, 2004, at 1:02 PM, Christopher Kings-Lynne wrote:
3. Or even create a pg_get_sequence() function:
SELECT SETVAL(pg_get_sequence(schema.table, col), 17);
Actually, this is the best solution :)
John Hansen and I worked this up. It works, though it's not
schema-aware, afaict.
create or rep
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe we could establish heavier testing for this kind of change so
> potential patches can be tested extensively. Concurrent vacuums with
> all kinds of imaginable operations (insert, updates, deletes), in tight
> loops, could be a start.
VACUUM FULL
Manfred Koizar <[EMAIL PROTECTED]> writes:
> I understand you, honestly. Do I read between your lines that you
> didn't review my previous vacuum.c refactoring patch? Please do. It'd
> make *me* more comfortable.
I did not yet, but I will get to it. I encourage everyone else to
take a look too
Glen Parker wrote:
It has been suggested in past to add such a visibility to index
tuple header so
that index and heaps can be cleaned out of order. In such a case
other backround
It seems to me that the benefit of this wouldn't be all that impressive
*when accessing the cache*, which is the proble
"Bort, Paul" <[EMAIL PROTECTED]> writes:
> Would it make more sense to specify at the time the optional subtransaction
> is committed that it is not critical to the completion of the outer
> transaction?
>
> BEGIN;
> BEGIN;
> DROP TABLE foo;
> COMMIT NON_CRITICAL;
> CREATE TABLE foo (i
3. Or even create a pg_get_sequence() function:
SELECT SETVAL(pg_get_sequence(schema.table, col), 17);
Actually, this is the best solution :)
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subs
Yeah, I know ... we ought to find some way around that, but I dunno
what yet ...
My idea, which I tried hacking, but gave up was to do the following:
1. Extend this command:
ALTER SEQUENCE seqname RESTART WITH 17;
to allow:
ALTER SEQUENCE ON table(col) RESTART WITH 17...
or
ALTER SEQUENCE ON table.
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> I expect that one year after release, there will be ten times as many
> PostgreSQL systems on Win32 as all combined versions now on UNIX flavors
I surely hope not. Especially not multi-gig databases. The folks
running those should know better than to u
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Then if the name given to the id sequence is now different, these dumps
> will not restore. (In this case it will be the same, I'm just
> illustrating the general problem of hard-coding those sequence names in
> the dump - I've never liked i
(moved to -hackers)
If you use sufficiently long table/field names then different tables
could truncate to the same generated names, and in that case there's
some risk of concurrently choosing the same "unique" name. But I don't
recall anyone having complained of that since we started using this
t
I've applied the patch you sent in for this, with some editorializations
--- you were being too aggressive about substituting constants, with the
net effect that the plan was not still parameterized as it was supposed
to be.
I realized along the way that what we're really doing here is inventing
a
On Wed, Jun 09, 2004 at 11:32:08PM -0700, Stephan Szabo wrote:
> > Unfortunately, I've gotten it to fail, but I haven't looked in depth (I'm
> > at work, so I'm doing it during compilations and such.)
[...]
> Okay - I think I see what's going on here.
>
> It looks like deferredTriggerInvokeEven
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Zeugswetter Andreas SB SD
> Sent: Friday, March 05, 2004 1:20 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: Bruce Momjian; Tom Lane; Greg Stark;
> [EMAIL PROTECTED]; PostgreSQL Win32 port list
On Fri, 5 Mar 2004, Rudolpho Gian-Franco Gugliotta wrote:
> Hi,
>
> i'm using the jdbc postgresql driver. I need to fetch the oid of a just
> insertet row
> (getGeneratedKeys() feature). That' why i ask you to provide me the
> source code
> to implement this feature.It would be glad if you te
On Fri, Jun 11, 2004 at 02:00:07AM +0200, Manfred Koizar wrote:
If I may ...
> > so you want to hack up vacuum.c? This
> >module is delicate code --- we've had tons of bugs there in the past
>
> But why is it so delicate? Not only because it handles difficult
> problems, but also because it is
Hi,
i'm using the jdbc postgresql driver. I need to fetch the oid of a just
insertet row
(getGeneratedKeys() feature). That' why i ask you to provide me the
source code
to implement this feature.It would be glad if you tell me how and where
to get
these sources.
Thank you very much,
Rudolpho Gu
On Thu, 10 Jun 2004 17:19:22 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>This does not make me comfortable.
I understand you, honestly. Do I read between your lines that you
didn't review my previous vacuum.c refactoring patch? Please do. It'd
make *me* more comfortable.
> You *think* that tw
On 6/10/2004 8:49 AM, Bruce Momjian wrote:
Jan Wieck wrote:
Make it so that --enable-thread-safety bombs out, but make another
--enable-thread-safey-anyway work the way Tom descibed it.
Sure, we can do that by just not running the thread_test program. In
fact a cross-compile already skips running
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Actually, my idea of sending a message to stderr saying we are using a
> > pre-configured file is so folks aren't surprised by the fact they can't
> > see any stderr anymore.
>
> Hm? I thought we'd just established that the patch was
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Actually, my idea of sending a message to stderr saying we are using a
> pre-configured file is so folks aren't surprised by the fact they can't
> see any stderr anymore.
Hm? I thought we'd just established that the patch wasn't going to
suppress output
Manfred Koizar <[EMAIL PROTECTED]> writes:
> This code is very similar to vacuum_page(). The major difference is
> that vacuum_page() uses vacpage->offsets while the code in repair_frag()
> looks for MOVED_OFF bits in tuple headers. AFAICS the tuples with the
> MOVED_OFF bit set are exactly those
Andreas Pflug wrote:
> Sorry I didn't get back on this earlier, yesterday morning my internet
> access was literally struck by lightning, I'm running temporary hardware
> now.
>
> Bruce Momjian wrote:
>
> Looks good to me. The only issue I saw was that the default file name
> mentioned
> It has been suggested in past to add such a visibility to index
> tuple header so
> that index and heaps can be cleaned out of order. In such a case
> other backround
It seems to me that the benefit of this wouldn't be all that impressive
*when accessing the cache*, which is the problem this dis
Sorry I didn't get back on this earlier, yesterday morning my internet
access was literally struck by lightning, I'm running temporary hardware
now.
Bruce Momjian wrote:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual d
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> >
> >>Looks good to me. The only issue I saw was that the default file name
> >>mentioned in postgresql.conf doesn't match the actual default.
> >>
> >>
> >
> >I'm really not happy with the concept t
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
I agre
Near the end of repair_frag() in vacuum.c -- under the comment /* clean
moved tuples from last page in Nvacpagelist list */ -- there is code
that marks itemids as unused. Itemids affected are those referring to
tuples that have been moved off the last page.
This code is very similar to vacuum_pag
On Thu, Jun 10, 2004 at 03:39:14PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We are considering allowing COMMIT IGNORE ABORT for scripts that want to
> > do a subtransaction, but don't care if it fails, and because it is a
> > script, they can't test the return value to
Tom Lane wisely wrote:
> While we clearly want this functionality, I tend to agree with Barry
> that COMMIT IGNORE ABORT (and the other variants that have
> been floated)
> is a horrid, confusing name for it. I would suggest using
> END with some
> modifier, instead. Perhaps
>
> END [ WO
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Jun 10, 2004 at 03:39:14PM -0400, Tom Lane wrote:
>> END doesn't so directly imply that you are trying to commit a failed
>> transaction.
> The problem with END is how about executing it inside a PL/pgSQL
> function. Can we distinguish it from
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We are considering allowing COMMIT IGNORE ABORT for scripts that want to
> do a subtransaction, but don't care if it fails, and because it is a
> script, they can't test the return value to send ROLLBACK:
While we clearly want this functionality, I tend
Well, the default behavior of COMMIT for an aborted subtransaction is
that it will abort the upper transaction too, so I think this is the
behavior you want.
We are considering allowing COMMIT IGNORE ABORT for scripts that want to
do a subtransaction, but don't care if it fails, and because it is
Am I the only one who has a hard time understanding why COMMIT in the
case of an error is allowed? Since nothing is actually committed, but
instead everything was actually rolled back. Isn't it misleading to
allow a commit under these circumstances?
Then to further extend the commit syntax wi
Bruce Momjian wrote:
> I understand your points below. However, the group has weighed in the
> direction of clearly showing non-default values and not duplicating
> documentation. We can change that, but you will need more folks
> agreeing with your direction.
I don't remember the behaviour but t
"Mohawksoft":
> I don't think anyone who has seriously looked at these issues has
> concluded that PostgreSQL works fine in these cases. The question is what,
> if anything, can be done? The frequent update issue really affects
> PostgreSQL's acceptance in web applications, and one which MySQL see
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Okay, I've repackaged it, and temporarily put everything into
> /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed
> something again (I rm -rf'd the old build tree and re-cvs exported it, so
> it started clean), I'll move those
Title: Message
1. I installed
the latest version of Mingw from:
http://www.mingw.org/download.shtml
2. I installed
the current snapshot of Postgresql.
3. I tried
./configure -- went fine
4. I tried
make clean -- went fine
5. I tried
make and hit a few snags.
6.
For
both:
/
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
My feeling is that we need not support tablespaces on OS's without
symlinks.
>
>> To create symlinked directories on Win2k NTFS see:
>> http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
>> I think Win2000 or XP wo
"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <[EMAIL PROTECTED]> writes:
> The only thing I still don't understand is the "not in in-progress
> state" thing.
At the point where it's trying to send a NOTIFY, it's partially out
of its transaction --- the state has become TRANS_COMMIT instead of
TRANS_INPROGR
[EMAIL PROTECTED] wrote:
The session table is a different issue, but has the same problems. You
have an active website, hundreds or thousands of hits a second, and you
want to manage sessions for this site. Sessions are created, updated many
times, and deleted. Performance degrades steadily until a
On Jun 10, 2004, at 10:30 AM, [EMAIL PROTECTED] wrote:
Prior to lazy vacuum, this was impossible.
Do you know for sure that lazy vacuum and/or autovacuum does
not indeed solve / alleviate the symptoms of the general problem
of very high rate table updates?
Back to lurking!
James Robinson
Socia
Greg Stark <[EMAIL PROTECTED]> writes:
> Following this path, perhaps the array i/o syntax should be changed to
> use []s
I would think about that if there weren't compatibility issues to worry
about, but in practice the pain from such an incompatible change would
vastly outweigh the benefit.
> a
OK, the problem I am having with whole discussion, on several fronts, is
the idea of performance. If performance and consistent behavior were not
*important* issues to a project, a summary table would work fine, and I
could just vacuum frequently.
Currently a client needs to vacuum two summary tab
"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <[EMAIL PROTECTED]> writes:
> A final question: as far as you can remember, may this be an issue already
> fixed in later versions?
I should have looked in the code before, because indeed we have a recent
bug fix addressing exactly this issue. Here's the commit
I am using table inheritance and it simplifies things for me a lot, but there
is one thing that is missing: trigger inheritance (I do not mean constraint
triggers).
So far I wrote function that copy all non-constraint triggers from parent to
child table, but I must call that function
I have emailed Michael Meskes to get his help in resolving open ecpg
issues for 7.4.X.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
Jan Wieck wrote:
> On 6/10/2004 2:11 AM, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> >> be supplied by the connection string in libpq on platforms that want
> >> threads and don't have getpwuid_r()
I understand your points below. However, the group has weighed in the
direction of clearly showing non-default values and not duplicating
documentation. We can change that, but you will need more folks
agreeing with your direction.
---
Dear Greg,
> > One idea that has been floated around is to pull the docs automatically
> > from SGML and put them in postgresql.conf. We do that for psql's use of
> > \help now, so it seems this is possible.
>
> I'm not sure this is the way to go. The SGML should be more detailed, and
> also ass
Thomas Swan <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> The advantage of symlinks is that an administrator could see how things
>> are laid out from the command line.
>>
> That's a poor reason to require symlinks. The administrator can just as
> easily open up psql and query pg_tablespa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> [blink] This seems to miss out on the actual point of the thread (hash
> >> bucket size shouldn't be a disk page) in favor of an entirely
> >> unsupported sub-suggestion.
>
> > Yes, I was unsure of the text mysel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> We discussed this and thought that it would end up duplicating stuff
> already in the docs
Which is fine. Keeping some documentation in the file itself is a
necessity. For example, we've changed "sort_mem" to "work_mem".
There should at the lea
When grilled further on (Wed, 3 Mar 2004 22:40:50 -0500 (EST)),
Bruce Momjian <[EMAIL PROTECTED]> confessed:
>
> Well, it must have hit the lists if I have put it in the patch queue, no?
>
> ---
>
> Hey Bruce,
>
> I never
While adapting an application to make use of the new protocol, I've
faced one problem. I cannot execute a prepared query and fetch the result in
several time. The multiple fetch is accessible with cursor in SQL but I
haven't found any way to execute a prepared query in a cursor.
The docum
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > ! *** If you are going to modify the lexer files or build from CVS,
> > the installed ! *** version of Bison is too old. Bison version 1.875
> > or later is required.])
>
> Bison has nothing to do with the lexer files.
Oops, sorry, new text:
**
Bruce Momjian wrote:
> ! *** If you are going to modify the lexer files or build from CVS,
> the installed ! *** version of Bison is too old. Bison version 1.875
> or later is required.])
Bison has nothing to do with the lexer files.
---(end of broadcast)
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My feeling is that we need not support tablespaces on OS's without
>> symlinks.
> Agreed, but are we going to support non-tablespace installs? I wasn't
> sure that was an option.
A setup containing only the default tablespace cannot
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Joe Conway <[EMAIL PROTECTED]> writes:
>>> Maybe specify an archive location (that of course could be on a separate
>>> partition) that the external archiver should check in addition to the
>>> normal WAL location. At some predetermined
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Maybe specify an archive location (that of course could be on a separate
partition) that the external archiver should check in addition to the
normal WAL location. At some predetermined interval, push WAL log
segments no longer needed to the
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I was trying to be paranoid about users who have multiple postmasters on
> the same machine and want to share a table space while both systems are
> live. There'd be no mechanism to test for that situation if we didn't have
> something like a postmaster.pi
> > regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
>
> BTW, I forgot to mention that the keyword ROW is optional as long as
> you've got at least two items in the row expression, so the above can
> be simplified to
>
> regression=# insert into bar values (((1.1, 2.2), (
On 6/10/2004 2:11 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was
62 matches
Mail list logo
